From harald@alvestrand.no Sat Oct 1 00:25: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 1917921F8AEC for ; Sat, 1 Oct 2011 00:25:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.232 X-Spam-Level: X-Spam-Status: No, score=-108.232 tagged_above=-999 required=5 tests=[AWL=2.067, 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 NadqM+sW60Df for ; Sat, 1 Oct 2011 00:25:47 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 329EB21F8AEA for ; Sat, 1 Oct 2011 00:25:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6FC1C39E0AF; Sat, 1 Oct 2011 09:28:42 +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 jlmRJK+9YUgu; Sat, 1 Oct 2011 09:28:41 +0200 (CEST) Received: from [192.168.1.16] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 32A8A39E038; Sat, 1 Oct 2011 09:28:41 +0200 (CEST) Message-ID: <4E86C124.10706@alvestrand.no> Date: Sat, 01 Oct 2011 09:28:36 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= References: <545388B3-3189-4291-BD1D-52898B888F3E@phonefromhere.com> <9C0BD967-A31E-4ABF-AB6F-CD635E53B82C@phonefromhere.com> <14235661-FD06-4209-8F18-8366AEC50004@phonefromhere.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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 07:25:48 -0000 On 09/30/2011 10:57 PM, Iñaki Baz Castillo wrote: > 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 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. > 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. The scenarios-and-requirements document requires that this be supported. From pravindran@sonusnet.com Sun Oct 2 23:10: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 4A53621F8801 for ; Sun, 2 Oct 2011 23:10:47 -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 9ZNgKepysmW1 for ; Sun, 2 Oct 2011 23:10:46 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 450FC21F87D6 for ; Sun, 2 Oct 2011 23:10:45 -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 p936EHZv011197; Mon, 3 Oct 2011 02:14:17 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail07.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 3 Oct 2011 02:13:45 -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_01CC8193.994BE05F" Date: Mon, 3 Oct 2011 11:43:41 +0530 Message-ID: <2E239D6FCD033C4BAF15F386A979BF510F12FA@sonusinmail02.sonusnet.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] SBC hardware and SHA1 Thread-Index: Acx/pM9oNsnwQyfKTQaJCFUQAhuccAB7O+Aw 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: "Ravindran Parthasarathi" To: "Eric Rescorla" , "Hadriel Kaplan" X-OriginalArrivalTime: 03 Oct 2011 06:13:45.0279 (UTC) FILETIME=[9B5004F0:01CC8193] 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: Mon, 03 Oct 2011 06:10:47 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC8193.994BE05F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable It is possible in SBC Hardware to provide DTLS-SRTP in case customer asks for it. IMO, The performance impacts is based on individual SBC Hardware architecture.=20 =20 Thanks Partha =20 From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Eric Rescorla Sent: Saturday, October 01, 2011 12:41 AM To: Hadriel Kaplan Cc: Subject: Re: [rtcweb] SBC hardware and SHA1 =20 =20 On Fri, Sep 30, 2011 at 9:39 AM, Hadriel Kaplan wrote: =20 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. =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 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. =20 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. =20 -Ekr =20 =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. =20 -hadriel =20 =20 =09 _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb =20 ------_=_NextPart_001_01CC8193.994BE05F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

It is possible in SBC Hardware to provide DTLS-SRTP in = case customer asks for it. IMO, The performance impacts is based on = individual SBC Hardware architecture.

 

Thanks

Partha

 

From:= rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of = Eric Rescorla
Sent: Saturday, October 01, 2011 12:41 AM
To: Hadriel Kaplan
Cc: <rtcweb@ietf.org>
Subject: Re: [rtcweb] SBC hardware and SHA1

 

 

On Fri, Sep 30, 2011 at 9:39 AM, Hadriel Kaplan = <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 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

 

------_=_NextPart_001_01CC8193.994BE05F-- From saul@ag-projects.com Mon Oct 3 00: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 AD84B21F8AF2 for ; Mon, 3 Oct 2011 00:36:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.704 X-Spam-Level: X-Spam-Status: No, score=-1.704 tagged_above=-999 required=5 tests=[AWL=-0.016, 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 hIOCGk+UQPu1 for ; Mon, 3 Oct 2011 00:36:41 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 9E52A21F8AEC for ; Mon, 3 Oct 2011 00:36:40 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 36981B01B7; Mon, 3 Oct 2011 09:39:41 +0200 (CEST) Received: from [192.168.99.36] (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id 46BDDB01B0; Mon, 3 Oct 2011 09:39:29 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: Date: Mon, 3 Oct 2011 09:39:28 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <868B86D5-E4F3-4192-B7CA-9A3F47AD7609@ag-projects.com> References: <4E820825.9090101@skype.net> <4E821E47.4080205@alvestrand.no> <4E82678E.6060304@s kype.net> To: Roman Shpount 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: Mon, 03 Oct 2011 07:36:42 -0000 Hi, Sorry for coming a bit late... >=20 > You just repeated the same thing that I said, just a bit more clearly.=20= >=20 > 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? >=20 > 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. We do deploy ICE-enabled network infrastructure to our customers, the = free http://sip2sip.info site is an example of such a platform. The problem we faced with ICE was the fact that in most cases NAT is = fixed by modifying the SDP and changing c/m lines in order to put a = media relay in between, but this breaks ICE negotiation because there is = no candidate for the new c line. We solved this in two Open Source = projects: OpenSIPS and MediaProxy by also adding a new candidate which = would appear to be a TURN server, so both ends are fooled to believe = there was a candidate. The media relay lets STUN probes pass so that ICE = connectivity checks will succeed. This ensures that if both endpoints do support ICE the negotiation will = succeed. Unfortunately, not many endpoints do implement ICE, so those = that don't would need to be gateway-ed, but IMHO it's for a greater = good. Regards, -- Sa=FAl Ibarra Corretg=E9 AG Projects From hlundin@google.com Mon Oct 3 01:09: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 5224321F8AEA for ; Mon, 3 Oct 2011 01:09:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.259 X-Spam-Level: X-Spam-Status: No, score=-104.259 tagged_above=-999 required=5 tests=[AWL=0.833, 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 II6DaGK5DMib for ; Mon, 3 Oct 2011 01:09:51 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id D4DB121F8AB0 for ; Mon, 3 Oct 2011 01:09:50 -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 p938CkPA022239 for ; Mon, 3 Oct 2011 01:12:46 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1317629566; bh=EjjsVXMkYvd+UdGKBbNMiRHnk6k=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=HbfghAHJdDyU489Y6RC6ald3CELZro8EE3kY1gz6BrtT1Ne+m1E9dAs/4rsvKL1F0 +8cVLelHZtYfBqc8hbahA== 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=EWARUibVA0iarPuHLrwPdYGe5M5w4bRUtRPI2fvjim45LepCWTEasRO1BnnqaYugQ fDxvj6zGtzIugDwyqFa5Q== Received: from ywp17 (ywp17.prod.google.com [10.192.16.17]) by hpaq13.eem.corp.google.com with ESMTP id p938CD66024249 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 3 Oct 2011 01:12:45 -0700 Received: by ywp17 with SMTP id 17so3752892ywp.41 for ; Mon, 03 Oct 2011 01:12:45 -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=Mpz59UU8m3Znp49Jr7bTZVM4nIGYN1yy8w2SximMN84=; b=l7iD+XzVBz71Cu8kLmJF8NmnlbfH8iIk/oisFYqTGDKCZJC4ouBGR7xrDRrwOX8oXK 7W+UpbqDFPwEypyqQGvQ== Received: by 10.100.56.25 with SMTP id e25mr12449584ana.70.1317629564918; Mon, 03 Oct 2011 01:12:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.56.25 with SMTP id e25mr12449575ana.70.1317629564332; Mon, 03 Oct 2011 01:12:44 -0700 (PDT) Received: by 10.100.166.9 with HTTP; Mon, 3 Oct 2011 01:12:44 -0700 (PDT) In-Reply-To: <4E79EA16.7070909@freedesktop.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> <4E79E698.2090905@jesup.org> <4E79EA16.7070909@freedesktop.org> Date: Mon, 3 Oct 2011 10:12:44 +0200 Message-ID: From: Henrik Lundin To: Jim Gettys Content-Type: multipart/alternative; boundary=0016e647661c20ac0604ae608a90 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, 03 Oct 2011 08:09:52 -0000 --0016e647661c20ac0604ae608a90 Content-Type: text/plain; charset=ISO-8859-1 Sorry for my late response. (I've been away for some time.) I'd just like to add my two cents to the discussion on feedback latency. Frequent and rapid feedback is important to ensure stability of the CC; I think we all agree. However, with an algorithm similar to the suggested one, having a receive-side processing and analysis function, the key feature is that feedback _can_ be sent quickly when needed. When everything is ok, feedback can be quite sparse, as long as the rate increments are somewhat adjusted for the system response time (including the feedback latency). When congestion is detected by the receiver, it is important that a feedback message can be sent more or less immediately (say, within 100 ms). However, I do not see the need for constant feedback every RTT or so. /Henrik On Wed, Sep 21, 2011 at 3:43 PM, Jim Gettys wrote: > > 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. > > _______________________________________________ > 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 --0016e647661c20ac0604ae608a90 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sorry for my late response. (I've been away for some time.) I'd jus= t like to add my two cents to the discussion on feedback latency.

<= /div>
Frequent and rapid feedback is important to ensure stability of t= he CC; I think we all agree. However, with an algorithm similar to the sugg= ested one, having a receive-side processing and analysis function, the key = feature is that feedback _can_ be sent quickly when needed. When everything= is ok, feedback can be quite sparse, as long as the rate increments are so= mewhat adjusted for the system response time (including the feedback latenc= y). When congestion is detected by the receiver, it is important that a fee= dback message can be sent more or less immediately (say, within 100 ms). Ho= wever, I do not see the need for constant feedback every RTT or so.

/Henrik





On Wed, Sep 21, 2011 at 3:4= 3 PM, Jim Gettys <jg@freedesktop.org> wrote:
=20 =20 =20

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.=A0 Also, in practice the TCP flows we're competing with a= re rarely long-lived
high-bandwidth flows like GB file transfers.=A0 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.=A0 The long lived flows keep the buffers in your OS/Home router/broadband gear near full, inserting lots of delay.=A0 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).

=20 http://gettys.word= press.com/2010/12/06/whose-house-is-of-glasse-must-not-throw-stones-at-anot= her/

As far as the transient bufferbloat problem caused by web traffic, and why IW10 is a problem in my view at this time, see:

=20 http://www.ietf.org/id/draft-gettys-iw10-consider= ed-harmful-00.txt



As for 1 feedback/RTT, I agree.=A0 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).=A0 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?).
=A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 - Jim


Other protocols may not be so nice.

_______________________________________________
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 6= 46 13 41


--0016e647661c20ac0604ae608a90-- From ingemar.s.johansson@ericsson.com Mon Oct 3 03:53: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 58D2121F8B24 for ; Mon, 3 Oct 2011 03:53:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.043 X-Spam-Level: X-Spam-Status: No, score=-5.043 tagged_above=-999 required=5 tests=[AWL=0.671, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, 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 pckC7aSwl7oF for ; Mon, 3 Oct 2011 03:53:17 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 5981D21F8AE9 for ; Mon, 3 Oct 2011 03:53:12 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-b7-4e8994cd42d8 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.115.84]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 1F.58.20773.DC4998E4; Mon, 3 Oct 2011 12:56:13 +0200 (CEST) Received: from ESESSCMS0366.eemea.ericsson.se ([169.254.2.123]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Mon, 3 Oct 2011 12:55:11 +0200 From: Ingemar Johansson S To: Henrik Lundin , Jim Gettys Date: Mon, 3 Oct 2011 12:55:09 +0200 Thread-Topic: [rtcweb] An input for discussing congestion control (Fwd: New Version Notification for draft-alvestrand-rtcweb-congestion-00.txt) Thread-Index: AcyBpE2UIRiG7Lx4S3WXU1HWwteK4QAAYQrg Message-ID: 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> <4E79EA16.7070909@freedesktop.org> In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: sv-SE, en-US Content-Type: multipart/alternative; boundary="_000_DBB1DC060375D147AC43F310AD987DCC36AE894DEBESESSCMS0366e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== 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, 03 Oct 2011 10:53:21 -0000 --_000_DBB1DC060375D147AC43F310AD987DCC36AE894DEBESESSCMS0366e_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi I guess one thing that should be considered is that a mobile user may make = handover between different radio access types with large differences in ter= ms of e.g throughput. You may have scenarios such as handover from LTE to G= PRS or perhaps you have handover from WiFi to HSPA if a user walks away fro= m a caf=E9. I would expect that these scenarios will become very common in = the future. It is also worth mention that handover between WiFi and 3GPP i= s standardized in 3GPP, which in practice means that this will ultimately h= appen without end user interaction. What the endpoints will notice is poten= tially a large and sudden change in throughput. In cases like these thoughput may drop rapidly. Of course you can sense thi= s with the outlined algoritms that signals feedback only when needed but th= at assumes that you receive packets that you can infer enough statistics on= . Problem is that on the receiver side don't really know that you are about= to receive a packet. With ACK-clocked algorithms like TCP and TFWC the sender simply stops sendi= ng packets when ACK's are not received anymore. Receiver based algos are a = bit more complicated as the risk is higher that the sender will continue to= send packets for some time even though the channel throughput has dropped = considerably, resulting in excessive congestion somewhere along the path. Is this a problem ?. I don't know, I guess time will tell. /Ingemar ________________________________ From: Henrik Lundin [mailto:hlundin@google.com] Sent: den 3 oktober 2011 10:13 To: Jim Gettys 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) Sorry for my late response. (I've been away for some time.) I'd just like t= o add my two cents to the discussion on feedback latency. Frequent and rapid feedback is important to ensure stability of the CC; I t= hink we all agree. However, with an algorithm similar to the suggested one,= having a receive-side processing and analysis function, the key feature is= that feedback _can_ be sent quickly when needed. When everything is ok, fe= edback can be quite sparse, as long as the rate increments are somewhat adj= usted for the system response time (including the feedback latency). When c= ongestion is detected by the receiver, it is important that a feedback mess= age can be sent more or less immediately (say, within 100 ms). However, I d= o not see the need for constant feedback every RTT or so. /Henrik On Wed, Sep 21, 2011 at 3:43 PM, Jim Gettys > wrote: 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 fre= quently less frequent) is overkill, but that's a statement with a lot of gu= t feeling and very few numbers behind it. One advantage we have in RTCWEB is that we can assume that if audio and vid= eo work OK across the network, we're in a good place. We don't have to worr= y about getting gigabyte file transfers to utilize 90% of the link - even t= hogh we have to worry about audio and video functioning while those gigabyt= e transfers are taking place. Agreed. Also, in practice the TCP flows we're competing with are rarely lo= ng-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 bufferbl= oat. The long lived flows keep the buffers in your OS/Home router/broadban= d gear near full, inserting lots of delay. This includes doing backups (lo= cal or remote), uploading videos, downloading videos to disk, bittorrent, e= tc. The netalyzr data is quite grim, particularly when you realise it's a l= ower 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-th= row-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 ma= y be on by default on other modern systems (anyone have any data?). - Jim Other protocols may not be so nice. _______________________________________________ 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 --_000_DBB1DC060375D147AC43F310AD987DCC36AE894DEBESESSCMS0366e_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi
 
I=20 guess one thing that should be considered is that a mobile user may make=20 handover between different radio access types with large differences in ter= ms of=20 e.g throughput. You may have scenarios such as handover from LTE to GPRS or= =20 perhaps you have handover from WiFi to HSPA if a user walks away from a caf= =E9. I=20 would expect that these scenarios will become very common in the future. It= is=20 also worth mention that handover between  WiFi and 3GPP is=20 standardized in 3GPP, which in practice means that this will ultimately hap= pen=20 without end user interaction. What the endpoints will notice is potent= ially=20 a large and sudden change in throughput.
 
In cases like these thoughput may dro= p rapidly.=20 Of course you can sense this with the outlined algoritms that signals feedb= ack=20 only when needed but that assumes that you receive packets that you can inf= er=20 enough statistics on. Problem is that on the receiver side don't really kno= w=20 that you are about to receive a packet.
With=20 ACK-clocked algorithms like TCP and TFWC the sender simply stops sending pa= ckets=20 when ACK's are not received anymore. Receiver based algos are a bit more=20 complicated as the risk is higher that the sender will continue to send pac= kets=20 for some time even though the channel throughput has dropped considera= bly,=20 resulting in excessive congestion somewhere along the path.
 
Is=20 this a problem ?. I don't know, I guess time will tell.
 
/Ingemar

From: Henrik Lundin=20 [mailto:hlundin@google.com]
Sent: den 3 oktober 2011=20 10:13
To: Jim Gettys
Cc: Randell Jesup;=20 rtcweb@ietf.org
Subject: Re: [rtcweb] An input for discussing=20 congestion control (Fwd: New Version Notification for=20 draft-alvestrand-rtcweb-congestion-00.txt)

Sorry for my late response. (I've been away for some time.) I'= d=20 just like to add my two cents to the discussion on feedback latency.

Frequent and rapid feedback is important to ensure stability of the = CC; I=20 think we all agree. However, with an algorithm similar to the suggested o= ne,=20 having a receive-side processing and analysis function, the key feature i= s=20 that feedback _can_ be sent quickly when needed. When everything is ok,=20 feedback can be quite sparse, as long as the rate increments are somewhat= =20 adjusted for the system response time (including the feedback latency). W= hen=20 congestion is detected by the receiver, it is important that a feedback=20 message can be sent more or less immediately (say, within 100 ms). Howeve= r, I=20 do not see the need for constant feedback every RTT or so.

/Henrik





On Wed, Sep 21, 2011 at 3:43 PM, Jim Gettys <jg@freedesktop.org> wrote:

On 09/21/2011 09:28 AM, Randell Jesup wrote:=20
On 9/21/2011 4:23 AM, Harald Alvestrand wrote= :=20
I think receiver->sender reporting every= RTT=20 (or every packet, which is frequently less frequent) is overkill, b= ut=20 that's a statement with a lot of gut feeling and very few numbers b= ehind=20 it.

One advantage we have in RTCWEB is that we can assume t= hat=20 if audio and video work OK across the network, we're in a good plac= e. We=20 don't have to worry about getting gigabyte file transfers to utiliz= e 90%=20 of the link - even thogh we have to worry about audio and video=20 functioning while those gigabyte transfers are taking place.=20

Agreed.  Also, in practice the TCP flows we= 're=20 competing with are rarely long-lived
high-bandwidth flows like GB= file=20 transfers.  Normally they're flurries of short-lived TCP
(wh= ich=20 is important to consider since these short-lived flows can suddenly c= ause=20 buffering
without warning).

You get to= deal=20 with some of each. Both cause havoc in the face of bufferbloat.  T= he=20 long lived flows keep the buffers in your OS/Home router/broadband gear= near=20 full, inserting lots of delay.  This includes doing backups (local= or=20 remote), uploading videos, downloading videos to disk, bittorrent, etc.= The=20 netalyzr data is quite grim, particularly when you realise it's a lower= =20 bound on the problem (the netalyzr test is sensitive to cross traffic a= nd=20 more importantly, tops out by the time it gets to 20Mbps).

http://gettys.wordpress.com/2010/12/06/whose-house-is-o= f-glasse-must-not-throw-stones-at-another/

As=20 far as the transient bufferbloat problem caused by web traffic, and why= IW10=20 is a problem in my view at this time, see:

http://www.ietf.org/id/draft-gettys-iw10-considered-har= mful-00.txt



As for 1 feedback/RTT, I agree.  And= if=20 you wanted to use one feedback/RTT, I'd put the feedback in
a TCP= =20 header extension or design an RTP equivalent that can carry it in the= =20 reverse-direction
media flow (when available).  But that's a= =20 different argument.

I like timestamps, if = only to=20 make it easy to tell the user: you are losing, and it's because of your= =20 broken network.

For TCP, the TCP timestamp option is on by defau= lt in=20 Linux, and I think may be on by default on other modern systems (anyone= have=20 any data?).
           = =20             -=20 Jim


Other protocols may not be so=20 nice.

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


--
Henrik=20 Lundin | WebRTC=20 Software Eng | hlundin@google.com | +46=20 70 646 13 41


--_000_DBB1DC060375D147AC43F310AD987DCC36AE894DEBESESSCMS0366e_-- From hlundin@google.com Mon Oct 3 04:08: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 32C1121F8B1E for ; Mon, 3 Oct 2011 04:08:38 -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 rKvhQrwZEqnk for ; Mon, 3 Oct 2011 04:08:34 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 1394821F8AAC for ; Mon, 3 Oct 2011 04:08:33 -0700 (PDT) Received: from wpaz17.hot.corp.google.com (wpaz17.hot.corp.google.com [172.24.198.81]) by smtp-out.google.com with ESMTP id p93BBZAU000303 for ; Mon, 3 Oct 2011 04:11:35 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1317640295; bh=A8kxvYmn8ErC3ujq9ANoS77bx0I=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=Ka+ZGRczHQmBeLreQgNfMKQiHlPg7hf4p/sA3W0Lczmlj4uztxaEaylFtIcrn/wNP +SmAUnLALrqd4AU7v/ceQ== 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=Vb3/EbQz7rUX3AvD0P8PU1pFt/5kXTxHSciw5uLjF4Oq3soNT4bvcENjXyX/m+cp0 I+l5DhuCFtrPKB5/i5zqA== Received: from gyd12 (gyd12.prod.google.com [10.243.49.204]) by wpaz17.hot.corp.google.com with ESMTP id p93BAiBN002987 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 3 Oct 2011 04:11:34 -0700 Received: by gyd12 with SMTP id 12so3289292gyd.3 for ; Mon, 03 Oct 2011 04:11:30 -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=5Eewa3k/o3tXyclaF77TpdhlYo0DemNcVppbKOKytiw=; b=e5KuFaJ1qH88tUHHQxm7VEYDOd71/LBV6iGHooZsfe4QlUpu+eEPR3z/Y93Jb8OOcX NWhoDj+BTGOUcWW/+sKQ== Received: by 10.100.207.8 with SMTP id e8mr12513201ang.158.1317640289645; Mon, 03 Oct 2011 04:11:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.207.8 with SMTP id e8mr12513191ang.158.1317640289484; Mon, 03 Oct 2011 04:11:29 -0700 (PDT) Received: by 10.100.166.9 with HTTP; Mon, 3 Oct 2011 04:11:29 -0700 (PDT) In-Reply-To: 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> <4E79EA16.7070909@freedesktop.org> Date: Mon, 3 Oct 2011 13:11:29 +0200 Message-ID: From: Henrik Lundin To: Ingemar Johansson S Content-Type: multipart/alternative; boundary=001636b431ef657e7b04ae6309bf 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, 03 Oct 2011 11:08:38 -0000 --001636b431ef657e7b04ae6309bf Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Oct 3, 2011 at 12:55 PM, Ingemar Johansson S < ingemar.s.johansson@ericsson.com> wrote: > ** > Hi > > I guess one thing that should be considered is that a mobile user may mak= e > handover between different radio access types with large differences in > terms of e.g throughput. You may have scenarios such as handover from LTE= to > GPRS or perhaps you have handover from WiFi to HSPA if a user walks away > from a caf=E9. I would expect that these scenarios will become very commo= n in > the future. It is also worth mention that handover between WiFi and 3GPP= is > standardized in 3GPP, which in practice means that this will ultimately > happen without end user interaction. What the endpoints will notice is > potentially a large and sudden change in throughput. > > In cases like these thoughput may drop rapidly. Of course you can sense > this with the outlined algoritms that signals feedback only when needed b= ut > that assumes that you receive packets that you can infer enough statistic= s > on. Problem is that on the receiver side don't really know that you are > about to receive a packet. > With ACK-clocked algorithms like TCP and TFWC the sender simply stops > sending packets when ACK's are not received anymore. Receiver based algos > are a bit more complicated as the risk is higher that the sender will > continue to send packets for some time even though the channel throughput > has dropped considerably, resulting in excessive congestion somewhere alo= ng > the path. > > Is this a problem ?. I don't know, I guess time will tell. > I guess it is a problem. > > /Ingemar > > ------------------------------ > *From:* Henrik Lundin [mailto:hlundin@google.com] > *Sent:* den 3 oktober 2011 10:13 > *To:* Jim Gettys > *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) > > Sorry for my late response. (I've been away for some time.) I'd just like > to add my two cents to the discussion on feedback latency. > > Frequent and rapid feedback is important to ensure stability of the CC; I > think we all agree. However, with an algorithm similar to the suggested o= ne, > having a receive-side processing and analysis function, the key feature i= s > that feedback _can_ be sent quickly when needed. When everything is ok, > feedback can be quite sparse, as long as the rate increments are somewhat > adjusted for the system response time (including the feedback latency). W= hen > congestion is detected by the receiver, it is important that a feedback > message can be sent more or less immediately (say, within 100 ms). Howeve= r, > I do not see the need for constant feedback every RTT or so. > > /Henrik > > > > > > On Wed, Sep 21, 2011 at 3:43 PM, Jim Gettys wrote: > >> >> 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 t= o >> worry about getting gigabyte file transfers to utilize 90% of the link - >> even thogh we have to worry about audio and video functioning while thos= e >> 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 sudden= ly >> 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 whe= n >> 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 w= hy >> 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. >> >> _______________________________________________ >> 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 <%2B46%2070%20646%2013%2041> > > > --=20 Henrik Lundin | WebRTC Software Eng | hlundin@google.com | +46 70 646 13 41 --001636b431ef657e7b04ae6309bf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Oct 3, 2011 at 12:55 PM, Ingemar Johanss= on S <ingemar.s.johansson@ericsson.com> wrote:
Hi
= =A0
I=20 guess one thing that should be considered is that a mobile user may make=20 handover between different radio access types with large differences in ter= ms of=20 e.g throughput. You may have scenarios such as handover from LTE to GPRS or= =20 perhaps you have handover from WiFi to HSPA if a user walks away from a caf= =E9. I=20 would expect that these scenarios will become very common in the future. It= is=20 also worth mention that handover=A0between=A0 WiFi and 3GPP is=20 standardized in 3GPP, which in practice means that this will ultimately hap= pen=20 without=A0end user interaction. What the endpoints will notice is potential= ly=20 a large and sudden change in throughput.
= =A0
I= n cases like these thoughput may drop rapidly.=20 Of course you can sense this with the outlined algoritms that signals feedb= ack=20 only when needed but that assumes that you receive packets that you can inf= er=20 enough statistics on. Problem is that on the receiver side don't really= know=20 that you are about to receive a packet.
With=20 ACK-clocked algorithms like TCP and TFWC the sender simply stops sending pa= ckets=20 when ACK's are not received anymore. Receiver based algos are a bit mor= e=20 complicated as the risk is higher that the sender will continue to send pac= kets=20 for some time even though the channel throughput has=A0dropped considerably= ,=20 resulting in excessive congestion somewhere along the path.
= =A0
Is=20 this a problem ?. I don't know, I guess time will tell.
I guess it is a problem.
=A0
<= /span>
= =A0
/Ingemar

From: Henrik Lundin=20 [mailto:hlundin@g= oogle.com]
Sent: den 3 oktober 2011=20 10:13
To: Jim Gettys
Cc: Randell Jesup;=20 rtcweb@ietf.org<= br>Subject: Re: [rtcweb] An input for discussing=20 congestion control (Fwd: New Version Notification for=20 draft-alvestrand-rtcweb-congestion-00.txt)

=
Sorry for my late response. (I've been away for some time.= ) I'd=20 just like to add my two cents to the discussion on feedback latency.

Frequent and rapid feedback is important to ensure stability of the = CC; I=20 think we all agree. However, with an algorithm similar to the suggested o= ne,=20 having a receive-side processing and analysis function, the key feature i= s=20 that feedback _can_ be sent quickly when needed. When everything is ok,= =20 feedback can be quite sparse, as long as the rate increments are somewhat= =20 adjusted for the system response time (including the feedback latency). W= hen=20 congestion is detected by the receiver, it is important that a feedback= =20 message can be sent more or less immediately (say, within 100 ms). Howeve= r, I=20 do not see the need for constant feedback every RTT or so.

/Henrik





On Wed, Sep 21, 2011 at 3:43 PM, Jim Gettys <jg@freedesktop.org> wrote:

On 09/21/2011 09:28 AM, Randell Jesup wrote:=20
On 9/21/2011 4:23 AM, Harald Alvestrand wrote= :=20
I think receiver->sender reporting every= RTT=20 (or every packet, which is frequently less frequent) is overkill, b= ut=20 that's a statement with a lot of gut feeling and very few numbe= rs behind=20 it.

One advantage we have in RTCWEB is that we can assume t= hat=20 if audio and video work OK across the network, we're in a good = place. We=20 don't have to worry about getting gigabyte file transfers to ut= ilize 90%=20 of the link - even thogh we have to worry about audio and video=20 functioning while those gigabyte transfers are taking place.=20

Agreed.=A0 Also, in practice the TCP flows we= 9;re=20 competing with are rarely long-lived
high-bandwidth flows like GB= file=20 transfers.=A0 Normally they're flurries of short-lived TCP
(w= hich=20 is important to consider since these short-lived flows can suddenly c= ause=20 buffering
without warning).

You get to= deal=20 with some of each. Both cause havoc in the face of bufferbloat.=A0 The= =20 long lived flows keep the buffers in your OS/Home router/broadband gear= near=20 full, inserting lots of delay.=A0 This includes doing backups (local or= =20 remote), uploading videos, downloading videos to disk, bittorrent, etc.= The=20 netalyzr data is quite grim, particularly when you realise it's a l= ower=20 bound on the problem (the netalyzr test is sensitive to cross traffic a= nd=20 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/<= br>
As=20 far as the transient bufferbloat problem caused by web traffic, and why= IW10=20 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.=A0 And if= =20 you wanted to use one feedback/RTT, I'd put the feedback in
a= TCP=20 header extension or design an RTP equivalent that can carry it in the= =20 reverse-direction
media flow (when available).=A0 But that's = a=20 different argument.

I like timestamps, if = only to=20 make it easy to tell the user: you are losing, and it's because of = your=20 broken network.

For TCP, the TCP timestamp option is on by defau= lt in=20 Linux, and I think may be on by default on other modern systems (anyone= have=20 any data?).
=A0=A0=A0 =A0=A0=A0 =A0=A0=A0=20 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 -=20 Jim


Other protocols may not be so=20 nice.

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



--
Henrik=20 Lundin=A0|=A0We= bRTC=20 Software Eng=A0|=A0hlundin@google.com= =A0|=A0+= 46=20 70 646 13 41





--
Henrik Lundin=A0|= =A0WebRTC Software Eng=A0|=A0hlundin@google.com=A0|=A0+46 70 646 13 41


--001636b431ef657e7b04ae6309bf-- From Markus.Isomaki@nokia.com Mon Oct 3 04:56: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 09A9D21F8753 for ; Mon, 3 Oct 2011 04:56:07 -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 DiF5zpjYnsYR for ; Mon, 3 Oct 2011 04:56:06 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 37A3321F86A5 for ; Mon, 3 Oct 2011 04:56:05 -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 p93BwQh5022128 for ; Mon, 3 Oct 2011 14:59:06 +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, 3 Oct 2011 14:58:30 +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; Mon, 3 Oct 2011 13:58:29 +0200 Received: from 008-AM1MPN1-043.mgdnok.nokia.com ([169.254.3.167]) by 008-AM1MMR1-001.mgdnok.nokia.com ([65.54.30.56]) with mapi id 14.01.0339.002; Mon, 3 Oct 2011 13:58:29 +0200 From: To: Thread-Topic: Future requirement: RTC-Web apps must work through interface switching Thread-Index: AcyBw8LOCbj0Q27JT3eGKgpYq050bw== Date: Mon, 3 Oct 2011 11:58:28 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.21.73.37] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 03 Oct 2011 11:58:30.0330 (UTC) FILETIME=[C49051A0:01CC81C3] X-Nokia-AV: Clean Subject: [rtcweb] Future requirement: RTC-Web apps must work through interface switching X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2011 11:56:07 -0000 Hi all, There is one important requirement, which may not be critical today, but wi= ll most likely be in the future. We can assume RTC-Web to be supported in devices like tablets, pads or smar= tphones, that people carry around. We can also assume that when such device= s are carried around, their point of attachement to the Internet will chang= e, even so that the type of access network will change, typically between s= omething like HSPA/LTE and Wi-Fi. Today this will always mean a change of I= P address as well. In the future we may have technologies such as (Proxy)Mo= bile IP in use that will provide IP address preservation, but we can't real= ly count on that. How does this relate to RTC-Web? Interface switching usually happens at the= discretion of the OS or some kind of connection manager. The browser or th= e web application environment has no control over it. At best it, or the JS= application running within, can get some kind of signal of such event happ= ening. For TCP-based client-server things (HTTP, Websocket) it is possible = to react to this by re-establishing the lost TCP connections and state on t= op of them. This is indeed what many (native) apps are able to do today. Th= ere can be some smarter ways in the pipeline as well, such as multipath TCP= , which would make the process of "transitioning" a TCP connection from one= interface/IP to another potentially transparent to the application. But wi= th peer-to-peer and interactive real-time, things get more complicated. It = may of course be that the switching happens due to a sudden loss of coverag= e and is so slow, that voice or video calls are broken anyway. However, in = many cases the old interface can be up while the new one is being establish= ed, and in principle the total loss of connectivity can be avoided. In such= scenarios it would be realistically possible to update the ongoing real-ti= me sessions to a new IP address and port, if there were some kind of end-to= -end or server-assisted mechanism for it. Even a cut of 1-2 seconds would n= ot be as bad as a total loss of the session. What does this mean in terms of requirements? - The first-order requirement is that the browser and/or the JS app, whoeve= r needs to act, has to be able to get events of interface switching in the = same way as native apps can. If it were only the browser who was required t= o get them, we could set standards aside, and declare that the browser does= this as any other app. But if it is the JS app that needs to do something,= then we may need something new as a JS API. I have no clue at the moment i= f the JS apps can learn about this kind of events. And this is clearly not = a RTC-Web specific requirement, but a generic one. I do know that browsers = or HTTP libraries can re-send requests etc. based on IP address change, but= I don't know what a JS Websocket client can do, if anything. - The second requirement is that the media related APIs and transport proto= cols (RTP) have to be flexible enough, that they can at least be extended t= o work so that they do not assume that the session is forever bound to a ce= rtain IP address/port in either end. How this affects the system depends on= what is actually standardized, for instance if the SDP offer/answer model = is included or not. But on the generic level it could be something like thi= s: - If the browser/JS app receives signaling/offer from its peer that peer's= RTP/UDP IP address/port has changed, it has to be able to set these throug= h the media API and re-run STUN checks or whatever is required at that poin= t. This has to be work so that the media session can be otherwise continued= , after the process is completed. - If the browser/JS app receives an event that its own IP address/port has= changed (or is about to change), it has to be able to re-initialize the RT= P/UDP accordingly, re-establish its "signaling connection and state" with i= ts webserver, notify the peer about the change, and re-run STUN checks etc.= as needed. This sounds quite complicated so it may be that we don't want to add this a= s a Day 1 requirement for RTC-Web. But I believe we should try to design th= e APIs and protocols in such a way that this kind of thing can be added lat= er on. There could be other ways too, like MPRTP (http://datatracker.ietf.o= rg/doc/draft-singh-avtcore-mprtp/), we could look at.=20 I suppose the less we standardize about the signaling and offer/answer, the= easier it might be to support these kinds of things as add-on. But whateve= r we standardize, please keep the interface and IP address change in mind. = The outcome could be that we declare that transport (MPTCP, MPRTP) has to d= eal with it, but eventually I think this will have to work one way or the o= ther. Regards, Markus From oej@edvina.net Mon Oct 3 05:02: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 2224821F84D9 for ; Mon, 3 Oct 2011 05:02:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.236 X-Spam-Level: X-Spam-Status: No, score=-2.236 tagged_above=-999 required=5 tests=[AWL=0.013, 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+1aTVzXNEtN for ; Mon, 3 Oct 2011 05:02:19 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id 2880B21F8AE9 for ; Mon, 3 Oct 2011 05:02:19 -0700 (PDT) Received: from [192.168.40.44] (ns.webway.se [87.96.134.125]) by smtp7.webway.se (Postfix) with ESMTPA id BB9B0754BCD5; Mon, 3 Oct 2011 12:05:17 +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: Mon, 3 Oct 2011 14:05:17 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <77D2298D-49EF-4F11-A50C-F1EE17082ECD@edvina.net> References: To: X-Mailer: Apple Mail (2.1244.3) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Future requirement: RTC-Web apps must work through interface switching X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2011 12:02:20 -0000 3 okt 2011 kl. 13:58 skrev : > Hi all, >=20 > There is one important requirement, which may not be critical today, = but will most likely be in the future. >=20 > We can assume RTC-Web to be supported in devices like tablets, pads or = smartphones, that people carry around. We can also assume that when such = devices are carried around, their point of attachement to the Internet = will change, even so that the type of access network will change, = typically between something like HSPA/LTE and Wi-Fi. Today this will = always mean a change of IP address as well. In the future we may have = technologies such as (Proxy)Mobile IP in use that will provide IP = address preservation, but we can't really count on that. >=20 > How does this relate to RTC-Web? Interface switching usually happens = at the discretion of the OS or some kind of connection manager. The = browser or the web application environment has no control over it. At = best it, or the JS application running within, can get some kind of = signal of such event happening. For TCP-based client-server things = (HTTP, Websocket) it is possible to react to this by re-establishing the = lost TCP connections and state on top of them. This is indeed what many = (native) apps are able to do today. There can be some smarter ways in = the pipeline as well, such as multipath TCP, which would make the = process of "transitioning" a TCP connection from one interface/IP to = another potentially transparent to the application. But with = peer-to-peer and interactive real-time, things get more complicated. It = may of course be that the switching happens due to a sudden loss of = coverage and is so slow, that voice or video calls are broken anyway. = However, in many cases the=20 > old interface can be up while the new one is being established, and in = principle the total loss of connectivity can be avoided. In such = scenarios it would be realistically possible to update the ongoing = real-time sessions to a new IP address and port, if there were some kind = of end-to-end or server-assisted mechanism for it. Even a cut of 1-2 = seconds would not be as bad as a total loss of the session. >=20 > What does this mean in terms of requirements? > - The first-order requirement is that the browser and/or the JS app, = whoever needs to act, has to be able to get events of interface = switching in the same way as native apps can. If it were only the = browser who was required to get them, we could set standards aside, and = declare that the browser does this as any other app. But if it is the JS = app that needs to do something, then we may need something new as a JS = API. I have no clue at the moment if the JS apps can learn about this = kind of events. And this is clearly not a RTC-Web specific requirement, = but a generic one. I do know that browsers or HTTP libraries can re-send = requests etc. based on IP address change, but I don't know what a JS = Websocket client can do, if anything. > - The second requirement is that the media related APIs and transport = protocols (RTP) have to be flexible enough, that they can at least be = extended to work so that they do not assume that the session is forever = bound to a certain IP address/port in either end. How this affects the = system depends on what is actually standardized, for instance if the SDP = offer/answer model is included or not. But on the generic level it could = be something like this: > - If the browser/JS app receives signaling/offer from its peer = that peer's RTP/UDP IP address/port has changed, it has to be able to = set these through the media API and re-run STUN checks or whatever is = required at that point. This has to be work so that the media session = can be otherwise continued, after the process is completed. > - If the browser/JS app receives an event that its own IP = address/port has changed (or is about to change), it has to be able to = re-initialize the RTP/UDP accordingly, re-establish its "signaling = connection and state" with its webserver, notify the peer about the = change, and re-run STUN checks etc. as needed. >=20 > This sounds quite complicated so it may be that we don't want to add = this as a Day 1 requirement for RTC-Web. But I believe we should try to = design the APIs and protocols in such a way that this kind of thing can = be added later on. There could be other ways too, like MPRTP = (http://datatracker.ietf.org/doc/draft-singh-avtcore-mprtp/), we could = look at.=20 >=20 > I suppose the less we standardize about the signaling and = offer/answer, the easier it might be to support these kinds of things as = add-on. But whatever we standardize, please keep the interface and IP = address change in mind. The outcome could be that we declare that = transport (MPTCP, MPRTP) has to deal with it, but eventually I think = this will have to work one way or the other. >=20 That is indeed an important observation. THe SIP outbound extension has handling of IP address change during a = registration/connection. But that doesn't imply IP address change during = a call. Software like Asterisk has added protection on the RTP ports so = after initial packets (handling symmetric RTP) Asterisk will not accept = packets from an unknown IP. I would assume that if we had ICE support, = ICE could re-initialize the session and the server could open new = connections. Thanks for this feedback. /O From ibc@aliax.net Mon Oct 3 05:21: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 8C72221F84A2 for ; Mon, 3 Oct 2011 05:21:49 -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 tv+TaEA2dUuy for ; Mon, 3 Oct 2011 05:21:49 -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 D85D421F84B5 for ; Mon, 3 Oct 2011 05:21:48 -0700 (PDT) Received: by vws5 with SMTP id 5so4233580vws.31 for ; Mon, 03 Oct 2011 05:24:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.89.177 with SMTP id bp17mr13877631vdb.447.1317644690820; Mon, 03 Oct 2011 05:24:50 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Mon, 3 Oct 2011 05:24:50 -0700 (PDT) In-Reply-To: References: Date: Mon, 3 Oct 2011 14:24:50 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Markus.Isomaki@nokia.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Future requirement: RTC-Web apps must work through interface switching X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2011 12:21:49 -0000 2011/10/3 : > - The first-order requirement is that the browser and/or the JS app, whoe= ver needs to act, has to be able to get events of interface switching in th= e same way as native apps can. If it were only the browser who was required= to get them, we could set standards aside, and declare that the browser do= es this as any other app. But if it is the JS app that needs to do somethin= g, then we may need something new as a JS API. I have no clue at the moment= if the JS apps can learn about this kind of events. And this is clearly no= t a RTC-Web specific requirement, but a generic one. I do know that browser= s or HTTP libraries can re-send requests etc. based on IP address change, b= ut I don't know what a JS Websocket client can do, if anything. In WebSocket a disconnect() event will be called by JS API if the connection is terminated (this can occur when the server explicity terminates the connection or when the WebSocket client tries to send a message over the WebSocket connection and gets an error because the connection "does not work anymore"). For the last case, a pinging mechanism from the client is a good choice. --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Mon Oct 3 05:26: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 86FCF21F8B0A for ; Mon, 3 Oct 2011 05:26:23 -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.260, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_24=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 fAQAyd20oiQi for ; Mon, 3 Oct 2011 05:26:23 -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 07F9B21F88B7 for ; Mon, 3 Oct 2011 05:26:22 -0700 (PDT) Received: by vcbfo11 with SMTP id fo11so4232505vcb.31 for ; Mon, 03 Oct 2011 05:29:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.184.67 with SMTP id cj3mr3239599vcb.76.1317644964958; Mon, 03 Oct 2011 05:29:24 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Mon, 3 Oct 2011 05:29:24 -0700 (PDT) In-Reply-To: <77D2298D-49EF-4F11-A50C-F1EE17082ECD@edvina.net> References: <77D2298D-49EF-4F11-A50C-F1EE17082ECD@edvina.net> Date: Mon, 3 Oct 2011 14:29:24 +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] Future requirement: RTC-Web apps must work through interface switching X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2011 12:26:23 -0000 2011/10/3 Olle E. Johansson : > THe SIP outbound extension has handling of IP address change during a reg= istration/connection. But that doesn't imply IP address change during a cal= l. When a SIP client implementing the outbound extension (RFC 5626) detects that the TCP (or TLS or WebSocket) connection is terminated/down, it should re-register and should send a re-INVITE for established dialogs telling the peer about its new location and SDP address. In fact, the using RFC 5626 the client does not need to know its exact local IP:port, as the edge proxy would route back incoming in-dialog request using the new client connection. > Software like Asterisk has added protection on the RTP ports so after ini= tial packets (handling symmetric RTP) Asterisk will not accept packets from= an unknown IP. It should allow a change in the source IP:port of the RTP packets in case a re-INVITE has been sent by the peer. > I would assume that if we had ICE support, ICE could re-initialize the se= ssion and the server could open new connections. I expect this to be the same: the client would send a re-INVITE after detecting local address change and Asterisk should accept it and update the session information. Regards. --=20 I=C3=B1aki Baz Castillo From oej@edvina.net Mon Oct 3 05:30: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 2307521F8B24 for ; Mon, 3 Oct 2011 05:30:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.786 X-Spam-Level: X-Spam-Status: No, score=-1.786 tagged_above=-999 required=5 tests=[AWL=-0.437, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_24=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 aLZqpDiLBq+d for ; Mon, 3 Oct 2011 05:30:26 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id 2BC0121F8B27 for ; Mon, 3 Oct 2011 05:30:26 -0700 (PDT) Received: from [192.168.40.44] (ns.webway.se [87.96.134.125]) by smtp7.webway.se (Postfix) with ESMTPA id E4ACF754BD0D; Mon, 3 Oct 2011 12:33:22 +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: Mon, 3 Oct 2011 14:33:22 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <16F2EE6F-78A8-4E77-BDD1-F3FE6CFAF2B5@edvina.net> References: <77D2298D-49EF-4F11-A50C-F1EE17082ECD@edvina.net> To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= X-Mailer: Apple Mail (2.1244.3) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Future requirement: RTC-Web apps must work through interface switching X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2011 12:30:27 -0000 3 okt 2011 kl. 14:29 skrev I=F1aki Baz Castillo: > 2011/10/3 Olle E. Johansson : >> THe SIP outbound extension has handling of IP address change during a = registration/connection. But that doesn't imply IP address change during = a call. >=20 > When a SIP client implementing the outbound extension (RFC 5626) > detects that the TCP (or TLS or WebSocket) connection is > terminated/down, it should re-register and should send a re-INVITE for > established dialogs telling the peer about its new location and SDP > address. In fact, the using RFC 5626 the client does not need to know > its exact local IP:port, as the edge proxy would route back incoming > in-dialog request using the new client connection. Over UDP the client recognizes a new binding using STUN and determines = that the connection has failed and re-initializes. >=20 >=20 >> Software like Asterisk has added protection on the RTP ports so after = initial packets (handling symmetric RTP) Asterisk will not accept = packets from an unknown IP. >=20 > It should allow a change in the source IP:port of the RTP packets in > case a re-INVITE has been sent by the peer. Always. Of course. But previously we always accepted it... >=20 >=20 >> I would assume that if we had ICE support, ICE could re-initialize = the session and the server could open new connections. >=20 > I expect this to be the same: the client would send a re-INVITE after > detecting local address change and Asterisk should accept it and > update the session information. >=20 Right. /O= From ibc@aliax.net Mon Oct 3 05:32: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 B9F5821F8B0B for ; Mon, 3 Oct 2011 05:32:42 -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_24=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 zJmxBIrQC3i5 for ; Mon, 3 Oct 2011 05:32:42 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3ED8F21F8AF7 for ; Mon, 3 Oct 2011 05:32:42 -0700 (PDT) Received: by vcbfo11 with SMTP id fo11so4240136vcb.31 for ; Mon, 03 Oct 2011 05:35:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.120.12 with SMTP id b12mr4207732vcr.111.1317645344296; Mon, 03 Oct 2011 05:35:44 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Mon, 3 Oct 2011 05:35:44 -0700 (PDT) In-Reply-To: <16F2EE6F-78A8-4E77-BDD1-F3FE6CFAF2B5@edvina.net> References: <77D2298D-49EF-4F11-A50C-F1EE17082ECD@edvina.net> <16F2EE6F-78A8-4E77-BDD1-F3FE6CFAF2B5@edvina.net> Date: Mon, 3 Oct 2011 14:35:44 +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] Future requirement: RTC-Web apps must work through interface switching X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2011 12:32:42 -0000 2011/10/3 Olle E. Johansson : >> When a SIP client implementing the outbound extension (RFC 5626) >> detects that the TCP (or TLS or WebSocket) connection is >> terminated/down, it should re-register and should send a re-INVITE for >> established dialogs telling the peer about its new location and SDP >> address. In fact, the using RFC 5626 the client does not need to know >> its exact local IP:port, as the edge proxy would route back incoming >> in-dialog request using the new client connection. > Over UDP the client recognizes a new binding using STUN and determines th= at the connection has failed > and re-initializes. Right, but being in RtcWeb, I expect that the signaling will always be carried within a reliable transport (WebSocket or HTTP). --=20 I=C3=B1aki Baz Castillo From randell-ietf@jesup.org Mon Oct 3 05:32: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 394BB21F8AF7 for ; Mon, 3 Oct 2011 05:32:43 -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 05W5SrQNCFeg for ; Mon, 3 Oct 2011 05:32:42 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 0403A21F86A5 for ; Mon, 3 Oct 2011 05:32:42 -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 1RAhkF-0003DC-VD for rtcweb@ietf.org; Mon, 03 Oct 2011 07:35:44 -0500 Message-ID: <4E89AB33.3050703@jesup.org> Date: Mon, 03 Oct 2011 08:31:47 -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> <4E79E698.2090905@jesup.org> <4E79EA16.7070909@freedesktop.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] 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, 03 Oct 2011 12:32:43 -0000 On 10/3/2011 6:55 AM, Ingemar Johansson S wrote: > I guess one thing that should be considered is that a mobile user may > make handover between different radio access types with large > differences in terms of e.g throughput. You may have scenarios such as > handover from LTE to GPRS or perhaps you have handover from WiFi to > HSPA if a user walks away from a caf. I would expect that these > scenarios will become very common in the future. It is also worth > mention that handover between WiFi and 3GPP is standardized in 3GPP, > which in practice means that this will ultimately happen without end > user interaction. What the endpoints will notice is potentially a > large and sudden change in throughput. > In cases like these thoughput may drop rapidly. Of course you can > sense this with the outlined algoritms that signals feedback only when > needed but that assumes that you receive packets that you can infer > enough statistics on. Problem is that on the receiver side don't > really know that you are about to receive a packet. I suspect in practice you'll see (outgoing) a gap in received packets (delay spike, while the radio in the handset changes access points), followed by packets coming in at ever-increasing delays (because the packets already queued to send are larger than will fit over the interface). Incoming packets will likewise have queued "somewhere" in the network - depending on the type of handover, you could have a burst of lost packets or a delay spike, again (if over-bandwidth in that direction) followed by a series of ever-increasing delays. In either case the signal (once transmission is re-established) should be very clear, and the types of algorithms used in Google's draft should quickly identify a strong "over-bandwidth" signal in the data. Bufferbloat ironically may help in quickly identifying it, since you're less likely to have a lot of losses following by down-ticks in delay. (Though some of the plans I have to modify the algorithm to extend across all the media streams would probably deal with that as well.) So, all-in-all I think the receivers at either end will likely identify the over-bandwidth condition within a small (4? 6? may depend on jitter) number of packets after an interface change. Again, sharing the congestion control will help here (perhaps a lot) by putting all the datapoints into one bucket, so the signal will stabilize much faster. Ok, so once the sides have recognized the sudden over-bandwidth situation, how do we get out of it? In AVPF we're likely able to send an RTCP message anytime we want, so the receiver should be able to send an RTCP as soon as possible. We've already said we plan to use RFC 5506 to reduce sizes of feed back messages, so that will keep the size smaller. It will be stuck behind any already-queued packets (hello, bufferbloat!) but there's little we can do about that. This RTCP feedback could of course be lost, and the CC algorithm should take that into account when it's trying to transmit a significant change in bandwidth (at least a significant reduction) by sending updated feedback messages frequently until stability has been achieved. In some cases, if it's possible, it may be useful to know about a network switchover and perhaps reduce outgoing and ask for a reduction in incoming bandwidth to reduce the risk of a spike in delay over the switchover (at the cost of reduction in quality temporarily). > With ACK-clocked algorithms like TCP and TFWC the sender simply stops > sending packets when ACK's are not received anymore. Receiver based > algos are a bit more complicated as the risk is higher that the sender > will continue to send packets for some time even though the channel > throughput has dropped considerably, resulting in excessive congestion > somewhere along the path. > Is this a problem ?. I don't know, I guess time will tell. > /Ingemar > > ------------------------------------------------------------------------ > *From:* Henrik Lundin [mailto:hlundin@google.com] > *Sent:* den 3 oktober 2011 10:13 > *To:* Jim Gettys > *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) > > Sorry for my late response. (I've been away for some time.) I'd > just like to add my two cents to the discussion on feedback latency. > > Frequent and rapid feedback is important to ensure stability of > the CC; I think we all agree. However, with an algorithm similar > to the suggested one, having a receive-side processing and > analysis function, the key feature is that feedback _can_ be sent > quickly when needed. When everything is ok, feedback can be quite > sparse, as long as the rate increments are somewhat adjusted for > the system response time (including the feedback latency). When > congestion is detected by the receiver, it is important that a > feedback message can be sent more or less immediately (say, within > 100 ms). However, I do not see the need for constant feedback > every RTT or so. > > /Henrik > > > > > > On Wed, Sep 21, 2011 at 3:43 PM, Jim Gettys > wrote: > > > 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. > > _______________________________________________ > 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 -- Randell Jesup randell-ietf@jesup.org From stefan.lk.hakansson@ericsson.com Mon Oct 3 05:38: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 1143121F8AEC for ; Mon, 3 Oct 2011 05:38:03 -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 3MyVKTyckgzL for ; Mon, 3 Oct 2011 05:38:02 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id D8C6721F8AB8 for ; Mon, 3 Oct 2011 05:38:01 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-8a-4e89ad5f5d1a Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id EA.CB.20773.F5DA98E4; Mon, 3 Oct 2011 14:41:03 +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, 3 Oct 2011 14:40:51 +0200 Message-ID: <4E89AD52.5000402@ericsson.com> Date: Mon, 3 Oct 2011 14:40:50 +0200 From: =?ISO-8859-1?Q?Stefan_H=E5kansson?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110922 Thunderbird/3.1.15 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: quoted-printable X-Brightmail-Tracker: AAAAAA== Subject: Re: [rtcweb] Future requirement: RTC-Web apps must work through interface switching X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2011 12:38:03 -0000 Markus, in terms of use case and reqs, do you see anything missing if you look=20 at=20 ,=20 section 4.2.3? In terms of technology I thought ICE would be able to handle this. Stefan On 10/03/2011 01:58 PM, Markus.Isomaki@nokia.com wrote: > Hi all, > > There is one important requirement, which may not be critical today, bu= t will most likely be in the future. > > We can assume RTC-Web to be supported in devices like tablets, pads or = smartphones, that people carry around. We can also assume that when such = devices are carried around, their point of attachement to the Internet wi= ll change, even so that the type of access network will change, typically= between something like HSPA/LTE and Wi-Fi. Today this will always mean a= change of IP address as well. In the future we may have technologies suc= h as (Proxy)Mobile IP in use that will provide IP address preservation, b= ut we can't really count on that. > > How does this relate to RTC-Web? Interface switching usually happens at= the discretion of the OS or some kind of connection manager. The browser= or the web application environment has no control over it. At best it, o= r the JS application running within, can get some kind of signal of such = event happening. For TCP-based client-server things (HTTP, Websocket) it = is possible to react to this by re-establishing the lost TCP connections = and state on top of them. This is indeed what many (native) apps are able= to do today. There can be some smarter ways in the pipeline as well, suc= h as multipath TCP, which would make the process of "transitioning" a TCP= connection from one interface/IP to another potentially transparent to t= he application. But with peer-to-peer and interactive real-time, things g= et more complicated. It may of course be that the switching happens due t= o a sudden loss of coverage and is so slow, that voice or video calls are= broken anyway. However, in many cases the > old interface can be up while the new one is being established, and i= n principle the total loss of connectivity can be avoided. In such scenar= ios it would be realistically possible to update the ongoing real-time se= ssions to a new IP address and port, if there were some kind of end-to-en= d or server-assisted mechanism for it. Even a cut of 1-2 seconds would no= t be as bad as a total loss of the session. > > What does this mean in terms of requirements? > - The first-order requirement is that the browser and/or the JS app, wh= oever needs to act, has to be able to get events of interface switching i= n the same way as native apps can. If it were only the browser who was re= quired to get them, we could set standards aside, and declare that the br= owser does this as any other app. But if it is the JS app that needs to d= o something, then we may need something new as a JS API. I have no clue a= t the moment if the JS apps can learn about this kind of events. And this= is clearly not a RTC-Web specific requirement, but a generic one. I do k= now that browsers or HTTP libraries can re-send requests etc. based on IP= address change, but I don't know what a JS Websocket client can do, if a= nything. > - The second requirement is that the media related APIs and transport p= rotocols (RTP) have to be flexible enough, that they can at least be exte= nded to work so that they do not assume that the session is forever bound= to a certain IP address/port in either end. How this affects the system = depends on what is actually standardized, for instance if the SDP offer/a= nswer model is included or not. But on the generic level it could be some= thing like this: > - If the browser/JS app receives signaling/offer from its peer that pe= er's RTP/UDP IP address/port has changed, it has to be able to set these = through the media API and re-run STUN checks or whatever is required at t= hat point. This has to be work so that the media session can be otherwise= continued, after the process is completed. > - If the browser/JS app receives an event that its own IP address/port= has changed (or is about to change), it has to be able to re-initialize = the RTP/UDP accordingly, re-establish its "signaling connection and state= " with its webserver, notify the peer about the change, and re-run STUN c= hecks etc. as needed. > > This sounds quite complicated so it may be that we don't want to add th= is as a Day 1 requirement for RTC-Web. But I believe we should try to des= ign the APIs and protocols in such a way that this kind of thing can be a= dded later on. There could be other ways too, like MPRTP (http://datatrac= ker.ietf.org/doc/draft-singh-avtcore-mprtp/), we could look at. > > I suppose the less we standardize about the signaling and offer/answer,= the easier it might be to support these kinds of things as add-on. But w= hatever we standardize, please keep the interface and IP address change i= n mind. The outcome could be that we declare that transport (MPTCP, MPRTP= ) has to deal with it, but eventually I think this will have to work one = way or the other. > > Regards, > Markus > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From holmer@google.com Mon Oct 3 05: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 79CC221F8B1E for ; Mon, 3 Oct 2011 05:54:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.31 X-Spam-Level: X-Spam-Status: No, score=-104.31 tagged_above=-999 required=5 tests=[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 DJTKVI6rVBMm for ; Mon, 3 Oct 2011 05:54:39 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 8A5A321F8B05 for ; Mon, 3 Oct 2011 05:54:39 -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 p93CvfiP011927 for ; Mon, 3 Oct 2011 05:57:41 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1317646661; bh=+9ZY3eIXbRy2brNeOmflN0VZOGs=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=KsMwwjBZ61xqiKjs3sRytP+Rf4KC4SIKqxxtNfagqn06y26jeVHndrjupQNo8Chag 0Xq1BnGcIPqWiqqNhHRTQ== 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=HCTqvCrPQXECR0HFJXXqPhfY46Ly5MSGPFp7Qf1RhVv5QNO8262OyqUNApEM/xCCP BDuIEbCropMHq/m8lz4SQ== Received: from eye4 (eye4.prod.google.com [10.208.5.4]) by wpaz9.hot.corp.google.com with ESMTP id p93CvdZ9025799 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 3 Oct 2011 05:57:40 -0700 Received: by eye4 with SMTP id 4so4092532eye.17 for ; Mon, 03 Oct 2011 05:57: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=Z2RK/HxUbvESKNDPaeAOqyZfSW1TUrtJJc3LfNZiCzo=; b=cVE3+lm0KCMsXy63KjhNmmC985cIQLPV1xWpAB/0wv58BT91NomMXnJrDBrTb4d88S G+LNGs57tEW50AaOAxJQ== Received: by 10.213.9.133 with SMTP id l5mr54300ebl.12.1317646658767; Mon, 03 Oct 2011 05:57:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.213.9.133 with SMTP id l5mr54298ebl.12.1317646658508; Mon, 03 Oct 2011 05:57:38 -0700 (PDT) Received: by 10.213.15.82 with HTTP; Mon, 3 Oct 2011 05:57:38 -0700 (PDT) In-Reply-To: <4E89AB33.3050703@jesup.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> <4E79E698.2090905@jesup.org> <4E79EA16.7070909@freedesktop.org> <4E89AB33.3050703@jesup.org> Date: Mon, 3 Oct 2011 14:57:38 +0200 Message-ID: From: Stefan Holmer To: Randell Jesup Content-Type: multipart/alternative; boundary=001517478be80517d904ae648580 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, 03 Oct 2011 12:54:41 -0000 --001517478be80517d904ae648580 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Oct 3, 2011 at 2:31 PM, Randell Jesup wrote= : > On 10/3/2011 6:55 AM, Ingemar Johansson S wrote: > >> I guess one thing that should be considered is that a mobile user may ma= ke >> handover between different radio access types with large differences in >> terms of e.g throughput. You may have scenarios such as handover from LT= E to >> GPRS or perhaps you have handover from WiFi to HSPA if a user walks away >> from a caf=E9. I would expect that these scenarios will become very comm= on in >> the future. It is also worth mention that handover between WiFi and 3GP= P is >> standardized in 3GPP, which in practice means that this will ultimately >> happen without end user interaction. What the endpoints will notice is >> potentially a large and sudden change in throughput. >> In cases like these thoughput may drop rapidly. Of course you can sense >> this with the outlined algoritms that signals feedback only when needed = but >> that assumes that you receive packets that you can infer enough statisti= cs >> on. Problem is that on the receiver side don't really know that you are >> about to receive a packet. >> > > I suspect in practice you'll see (outgoing) a gap in received packets > (delay spike, while the radio in the handset changes access points), > followed by packets coming in at ever-increasing delays (because the pack= ets > already queued to send are larger than will fit over the interface). > Incoming packets will likewise have queued "somewhere" in the network - > depending on the type of handover, you could have a burst of lost packets= or > a delay spike, again (if over-bandwidth in that direction) followed by a > series of ever-increasing delays. > We could get some of the benefits of ACK windows by adding the requirement that RTCP must be sent periodically (every X ms), since periodic RTCP packets can be used as a form of accumulated ACKs. The sender is only allowed to transmit at a rate less than or equal to the rate specified by TMMBR, and must decrease the rate if any of the following is true: 1. No RTCP packet arrives within Y ms (> X ms) 2. The RTCP packet suggests that the receiver didn't receive any data since the previous RTCP. > > In either case the signal (once transmission is re-established) should be > very clear, and the types of algorithms used in Google's draft should > quickly identify a strong "over-bandwidth" signal in the data. Bufferblo= at > ironically may help in quickly identifying it, since you're less likely t= o > have a lot of losses following by down-ticks in delay. (Though some of t= he > plans I have to modify the algorithm to extend across all the media strea= ms > would probably deal with that as well.) > > So, all-in-all I think the receivers at either end will likely identify t= he > over-bandwidth condition within a small (4? 6? may depend on jitter) numb= er > of packets after an interface change. Again, sharing the congestion cont= rol > will help here (perhaps a lot) by putting all the datapoints into one > bucket, so the signal will stabilize much faster. > > Ok, so once the sides have recognized the sudden over-bandwidth situation= , > how do we get out of it? In AVPF we're likely able to send an RTCP messa= ge > anytime we want, so the receiver should be able to send an RTCP as soon a= s > possible. We've already said we plan to use RFC 5506 to reduce sizes of > feed back messages, so that will keep the size smaller. It will be stuc= k > behind any already-queued packets (hello, bufferbloat!) but there's litt= le > we can do about that. > > This RTCP feedback could of course be lost, and the CC algorithm should > take that into account when it's trying to transmit a significant change = in > bandwidth (at least a significant reduction) by sending updated feedback > messages frequently until stability has been achieved. > > In some cases, if it's possible, it may be useful to know about a network > switchover and perhaps reduce outgoing and ask for a reduction in incomin= g > bandwidth to reduce the risk of a spike in delay over the switchover (at = the > cost of reduction in quality temporarily). > > With ACK-clocked algorithms like TCP and TFWC the sender simply stops >> sending packets when ACK's are not received anymore. Receiver based algo= s >> are a bit more complicated as the risk is higher that the sender will >> continue to send packets for some time even though the channel throughpu= t >> has dropped considerably, resulting in excessive congestion somewhere al= ong >> the path. >> Is this a problem ?. I don't know, I guess time will tell. >> /Ingemar >> >> ------------------------------**------------------------------** >> ------------ >> *From:* Henrik Lundin [mailto:hlundin@google.com] >> *Sent:* den 3 oktober 2011 10:13 >> *To:* Jim Gettys >> *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) >> >> Sorry for my late response. (I've been away for some time.) I'd >> just like to add my two cents to the discussion on feedback latency. >> >> Frequent and rapid feedback is important to ensure stability of >> the CC; I think we all agree. However, with an algorithm similar >> to the suggested one, having a receive-side processing and >> analysis function, the key feature is that feedback _can_ be sent >> quickly when needed. When everything is ok, feedback can be quite >> sparse, as long as the rate increments are somewhat adjusted for >> the system response time (including the feedback latency). When >> congestion is detected by the receiver, it is important that a >> feedback message can be sent more or less immediately (say, within >> 100 ms). However, I do not see the need for constant feedback >> every RTT or so. >> >> /Henrik >> >> >> >> >> >> On Wed, Sep 21, 2011 at 3:43 PM, Jim Gettys > > wrote: >> >> >> 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. >> >> ______________________________**_________________ >> 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 >> > > > -- > Randell Jesup > randell-ietf@jesup.org > > > ______________________________**_________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/**listinfo/rtcweb > --001517478be80517d904ae648580 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Mon, Oct 3, 2011 at 2:31 PM, Randell = Jesup <rande= ll-ietf@jesup.org> wrote:
On 10/3/2011 6:55 AM, Ingemar Johansson S wrote:
I guess one thing that should be considered is that a mobile user may make = handover between different radio access types with large differences in ter= ms of e.g throughput. You may have scenarios such as handover from LTE to G= PRS or perhaps you have handover from WiFi to HSPA if a user walks away fro= m a caf=E9. I would expect that these scenarios will become very common in = the future. It is also worth mention that handover between =A0WiFi and 3GPP= is standardized in 3GPP, which in practice means that this will ultimately= happen without end user interaction. What the endpoints will notice is pot= entially a large and sudden change in throughput.
In cases like these thoughput may drop rapidly. Of course you can sense thi= s with the outlined algoritms that signals feedback only when needed but th= at assumes that you receive packets that you can infer enough statistics on= . Problem is that on the receiver side don't really know that you are a= bout to receive a packet.

I suspect in practice you'll see (outgoing) a gap in received packets (= delay spike, while the radio in the handset changes access points), followe= d by packets coming in at ever-increasing delays (because the packets alrea= dy queued to send are larger than will fit over the interface). =A0Incoming= packets will likewise have queued "somewhere" in the network - d= epending on the type of handover, you could have a burst of lost packets or= a delay spike, again (if over-bandwidth in that direction) followed by a s= eries of ever-increasing delays.

We could get some of the benefits of ACK w= indows by adding the requirement that RTCP must be sent periodically (every= X ms), since periodic RTCP packets can be used as a form of accumulated AC= Ks. The sender is only allowed to transmit at a rate less than or equal to = the rate specified by TMMBR, and must decrease the rate if any of the follo= wing is true:

1. No RTCP packet arrives within Y ms (> X ms)
=
2. The RTCP packet suggests that the receiver didn't receive any d= ata since the previous RTCP.
=A0

In either case the signal (once transmission is re-established) should be v= ery clear, and the types of algorithms used in Google's draft should qu= ickly identify a strong "over-bandwidth" signal in the data. =A0B= ufferbloat ironically may help in quickly identifying it, since you're = less likely to have a lot of losses following by down-ticks in delay. =A0(T= hough some of the plans I have to modify the algorithm to extend across all= the media streams would probably deal with that as well.)

So, all-in-all I think the receivers at either end will likely identify the= over-bandwidth condition within a small (4? 6? may depend on jitter) numbe= r of packets after an interface change. =A0Again, sharing the congestion co= ntrol will help here (perhaps a lot) by putting all the datapoints into one= bucket, so the signal will stabilize much faster.

Ok, so once the sides have recognized the sudden over-bandwidth situation, = how do we get out of it? =A0In AVPF we're likely able to send an RTCP m= essage anytime we want, so the receiver should be able to send an RTCP as s= oon as possible. =A0We've already said we plan to use RFC 5506 to reduc= e sizes of feed back messages, so that will keep the size smaller. =A0 It w= ill be stuck behind any already-queued packets (hello, bufferbloat!) =A0but= there's little we can do about that.

This RTCP feedback could of course be lost, and the CC algorithm should tak= e that into account when it's trying to transmit a significant change i= n bandwidth (at least a significant reduction) by sending updated feedback = messages frequently until stability has been achieved.

In some cases, if it's possible, it may be useful to know about a netwo= rk switchover and perhaps reduce outgoing and ask for a reduction in incomi= ng bandwidth to reduce the risk of a spike in delay over the switchover (at= the cost of reduction in quality temporarily).

With ACK-clocked algorithms like TCP and TFWC the sender simply stops sendi= ng packets when ACK's are not received anymore. Receiver based algos ar= e a bit more complicated as the risk is higher that the sender will continu= e to send packets for some time even though the channel throughput has drop= ped considerably, resulting in excessive congestion somewhere along the pat= h.
Is this a problem ?. I don't know, I guess time will tell.
/Ingemar

=A0 =A0------------------------------------------------------------= ------------
=A0 =A0*From:* Henrik Lundin [mailto:hlundin@google.com]
=A0 =A0*Sent:* den 3 oktober 2011 10:13
=A0 =A0*To:* Jim Gettys
=A0 =A0*Cc:* Randell Jesup; rtcweb@ietf.org
=A0 =A0*Subject:* Re: [rtcweb] An input for discussing congestion control<= div class=3D"im">
=A0 =A0(Fwd: New Version Notification for
=A0 =A0draft-alvestrand-rtcweb-congestion-00.txt)

=A0 =A0Sorry for my late response. (I've been away for some time.) I&#= 39;d
=A0 =A0just like to add my two cents to the discussion on feedback latency= .

=A0 =A0Frequent and rapid feedback is important to ensure stability of
=A0 =A0the CC; I think we all agree. However, with an algorithm similar =A0 =A0to the suggested one, having a receive-side processing and
=A0 =A0analysis function, the key feature is that feedback _can_ be sent =A0 =A0quickly when needed. When everything is ok, feedback can be quite =A0 =A0sparse, as long as the rate increments are somewhat adjusted for =A0 =A0the system response time (including the feedback latency). When
=A0 =A0congestion is detected by the receiver, it is important that a
=A0 =A0feedback message can be sent more or less immediately (say, within<= br> =A0 =A0100 ms). However, I do not see the need for constant feedback
=A0 =A0every RTT or so.

=A0 =A0/Henrik





=A0 =A0On Wed, Sep 21, 2011 at 3:43 PM, Jim Gettys <jg@freedesktop.org
<= div class=3D"h5"> =A0 =A0<mailto:= jg@freedesktop.org>> wrote:


=A0 =A0 =A0 =A0On 09/21/2011 09:28 AM, Randell Jesup wrote:
=A0 =A0 =A0 =A0On 9/21/2011 4:23 AM, Harald Alvestrand wrote:
=A0 =A0 =A0 =A0I think receiver->sender reporting every RTT (or every =A0 =A0 =A0 =A0packet, which is frequently less frequent) is overkill, but=
=A0 =A0 =A0 =A0that's a statement with a lot of gut feeling and very f= ew
=A0 =A0 =A0 =A0numbers behind it.

=A0 =A0 =A0 =A0One advantage we have in RTCWEB is that we can assume that<= br> =A0 =A0 =A0 =A0if audio and video work OK across the network, we're in= a
=A0 =A0 =A0 =A0good place. We don't have to worry about getting gigaby= te
=A0 =A0 =A0 =A0file transfers to utilize 90% of the link - even thogh we =A0 =A0 =A0 =A0have to worry about audio and video functioning while those=
=A0 =A0 =A0 =A0gigabyte transfers are taking place.

=A0 =A0 =A0 =A0Agreed. =A0Also, in practice the TCP flows we're compet= ing with
=A0 =A0 =A0 =A0are rarely long-lived
=A0 =A0 =A0 =A0high-bandwidth flows like GB file transfers. =A0Normally =A0 =A0 =A0 =A0they're flurries of short-lived TCP
=A0 =A0 =A0 =A0(which is important to consider since these short-lived flo= ws
=A0 =A0 =A0 =A0can suddenly cause buffering
=A0 =A0 =A0 =A0without warning).

=A0 =A0 =A0 =A0You get to deal with some of each. Both cause havoc in the<= br> =A0 =A0 =A0 =A0face of bufferbloat. =A0The long lived flows keep the buffe= rs in
=A0 =A0 =A0 =A0your OS/Home router/broadband gear near full, inserting lot= s
=A0 =A0 =A0 =A0of delay. =A0This includes doing backups (local or remote),=
=A0 =A0 =A0 =A0uploading videos, downloading videos to disk, bittorrent, e= tc.
=A0 =A0 =A0 =A0The netalyzr data is quite grim, particularly when you real= ise
=A0 =A0 =A0 =A0it's a lower bound on the problem (the netalyzr test is=
=A0 =A0 =A0 =A0sensitive to cross traffic and more importantly, tops out b= y
=A0 =A0 =A0 =A0the time it gets to 20Mbps).

=A0 =A0 =A0 =A0http:/= /gettys.wordpress.com/2010/12/06/whose-house-is-of-glasse-mus= t-not-throw-stones-at-another/

=A0 =A0 =A0 =A0As far as the transient bufferbloat problem caused by web =A0 =A0 =A0 =A0traffic, and why IW10 is a problem in my view at this time,= see:

=A0 =A0 =A0 =A0http://www.ietf.org/id/draft-g= ettys-iw10-considered-harmful-00.txt




=A0 =A0 =A0 =A0As for 1 feedback/RTT, I agree. =A0And if you wanted to use= one
=A0 =A0 =A0 =A0feedback/RTT, I'd put the feedback in
=A0 =A0 =A0 =A0a TCP header extension or design an RTP equivalent that can=
=A0 =A0 =A0 =A0carry it in the reverse-direction
=A0 =A0 =A0 =A0media flow (when available). =A0But that's a different = argument.

=A0 =A0 =A0 =A0I like timestamps, if only to make it easy to tell the user= :
=A0 =A0 =A0 =A0you are losing, and it's because of your broken network= .

=A0 =A0 =A0 =A0For TCP, the TCP timestamp option is on by default in Linux= ,
=A0 =A0 =A0 =A0and I think may be on by default on other modern systems =A0 =A0 =A0 =A0(anyone have any data?).
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0- Jim


=A0 =A0 =A0 =A0Other protocols may not be so nice.

=A0 =A0 =A0 =A0_______________________________________________
=A0 =A0 =A0 =A0rtcweb mailing list
=A0 =A0 =A0 =A0rtcweb= @ietf.org <mailto:rtcweb@ietf.org>

=A0 =A0 =A0 =A0https://www.ietf.org/mailman/listinfo/rtcweb




=A0 =A0-- =A0 =A0 Henrik Lundin | WebRTC Software Eng |hlundin@google.com
=A0 =A0<mailto:= hlundin@google.com> |+46 70 646 13 41
=A0 =A0<tel:%2B46%2070%20646%2013%2041>





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


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


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

--001517478be80517d904ae648580-- From randell-ietf@jesup.org Mon Oct 3 06:30:37 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B68B21F8B3C for ; Mon, 3 Oct 2011 06:30:37 -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 XmqDztbCkui1 for ; Mon, 3 Oct 2011 06:30: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 6519721F8B39 for ; Mon, 3 Oct 2011 06:30: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 1RAieF-00047M-2r for rtcweb@ietf.org; Mon, 03 Oct 2011 08:33:35 -0500 Message-ID: <4E89B8C2.3010608@jesup.org> Date: Mon, 03 Oct 2011 09:29:38 -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: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable 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] Future requirement: RTC-Web apps must work through interface switching X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2011 13:30:37 -0000 On 10/3/2011 7:58 AM, Markus.Isomaki@nokia.com wrote: > Hi all, > > There is one important requirement, which may not be critical today, bu= t will most likely be in the future. > > We can assume RTC-Web to be supported in devices like tablets, pads or = smartphones, that people carry around. We can also assume that when such = devices are carried around, their point of attachement to the Internet wi= ll change, even so that the type of access network will change, typically= between something like HSPA/LTE and Wi-Fi. Today this will always mean a= change of IP address as well. In the future we may have technologies suc= h as (Proxy)Mobile IP in use that will provide IP address preservation, b= ut we can't really count on that. If memory serves (and I haven't checked) interface switching is within=20 scope from what was discussed at prior IETF meetings, though I don't=20 know if it's in any of the current use cases (I think not). We have not = discussed any of the specifics of it, however, and should do so, as well = as decide if it's in-scope for "1.0". There's certainly a case for it,=20 even without mobile devices (switching Wi-Fi hotspots with a laptop, or=20 DHCP-caused IP changes). > > How does this relate to RTC-Web? Interface switching usually happens at= the discretion of the OS or some kind of connection manager. The browser= or the web application environment has no control over it. At best it, o= r the JS application running within, can get some kind of signal of such = event happening. For TCP-based client-server things (HTTP, Websocket) it = is possible to react to this by re-establishing the lost TCP connections = and state on top of them. This is indeed what many (native) apps are able= to do today. There can be some smarter ways in the pipeline as well, suc= h as multipath TCP, which would make the process of "transitioning" a TCP= connection from one interface/IP to another potentially transparent to t= he application. But with peer-to-peer and interactive real-time, things g= et more complicated. It may of course be that the switching happens due t= o a sudden loss of coverage and is so slow, that voice or video calls are= broken anyway. However, in many cases the > old interface can be up while the new one is being established, and i= n principle the total loss of connectivity can be avoided. In such scenar= ios it would be realistically possible to update the ongoing real-time se= ssions to a new IP address and port, if there were some kind of end-to-en= d or server-assisted mechanism for it. Even a cut of 1-2 seconds would no= t be as bad as a total loss of the session. > > What does this mean in terms of requirements? > - The first-order requirement is that the browser and/or the JS app, wh= oever needs to act, has to be able to get events of interface switching i= n the same way as native apps can. If it were only the browser who was re= quired to get them, we could set standards aside, and declare that the br= owser does this as any other app. But if it is the JS app that needs to d= o something, then we may need something new as a JS API. I have no clue a= t the moment if the JS apps can learn about this kind of events. And this= is clearly not a RTC-Web specific requirement, but a generic one. I do k= now that browsers or HTTP libraries can re-send requests etc. based on IP= address change, but I don't know what a JS Websocket client can do, if a= nything. > - The second requirement is that the media related APIs and transport p= rotocols (RTP) have to be flexible enough, that they can at least be exte= nded to work so that they do not assume that the session is forever bound= to a certain IP address/port in either end. How this affects the system = depends on what is actually standardized, for instance if the SDP offer/a= nswer model is included or not. But on the generic level it could be some= thing like this: > - If the browser/JS app receives signaling/offer from its peer that pe= er's RTP/UDP IP address/port has changed, it has to be able to set these = through the media API and re-run STUN checks or whatever is required at t= hat point. This has to be work so that the media session can be otherwise= continued, after the process is completed. Effectively, in SIP/SDP terms, it needs to do a re-INVITE with a new c=3D= =20 address (and new port). The added complication is that the signalling=20 channel will be affected as well, so the application needs to=20 re-establish the signalling channel *then* re-establish the=20 peerconnection and "re-INVITE" to re-establish the media streams. Note that any "custom" signalling someone designs will need to include=20 this ability! (Something they may not realize and may not handle=20 properly...) But that's a different thread/argument. ;-) > - If the browser/JS app receives an event that its own IP address/port= has changed (or is about to change), it has to be able to re-initialize = the RTP/UDP accordingly, re-establish its "signaling connection and state= " with its webserver, notify the peer about the change, and re-run STUN c= hecks etc. as needed. > > This sounds quite complicated so it may be that we don't want to add th= is as a Day 1 requirement for RTC-Web. But I believe we should try to des= ign the APIs and protocols in such a way that this kind of thing can be a= dded later on. There could be other ways too, like MPRTP (http://datatrac= ker.ietf.org/doc/draft-singh-avtcore-mprtp/), we could look at. > > I suppose the less we standardize about the signaling and offer/answer,= the easier it might be to support these kinds of things as add-on. But w= hatever we standardize, please keep the interface and IP address change i= n mind. The outcome could be that we declare that transport (MPTCP, MPRTP= ) has to deal with it, but eventually I think this will have to work one = way or the other. > --=20 Randell Jesup randell-ietf@jesup.org From harald@alvestrand.no Mon Oct 3 07: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 DD46021F8B29 for ; Mon, 3 Oct 2011 07:00:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.886 X-Spam-Level: X-Spam-Status: No, score=-107.886 tagged_above=-999 required=5 tests=[AWL=2.713, 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 QNr6YTH9FMZe for ; Mon, 3 Oct 2011 07:00:11 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id A69E121F8B12 for ; Mon, 3 Oct 2011 07:00:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4B71539E13F for ; Mon, 3 Oct 2011 16:03:11 +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 2IoFlk+yemh3 for ; Mon, 3 Oct 2011 16:03:07 +0200 (CEST) Received: from [172.16.41.139] (unknown [74.125.121.33]) by eikenes.alvestrand.no (Postfix) with ESMTPS id DCABC39E10E for ; Mon, 3 Oct 2011 16:03:06 +0200 (CEST) Message-ID: <4E89C099.3000709@alvestrand.no> Date: Mon, 03 Oct 2011 16:03:05 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [rtcweb] Future requirement: RTC-Web apps must work through interface switching X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2011 14:00:12 -0000 The media channels in Google's ICE-based offerings (Google Talk Video,=20 Google Voice and Hangouts) all are able to survive an interface change=20 by utilizing the alternate candidate mechanisms in ICE. Try this experiment: - Make sure your laptop has a working wireless connection - Connect your laptop to wired Ethernet - Set up a Google Talk Video call with someone - Yank out the Ethernet cord If all goes well, you should see exactly how much of a break this causes = to the call in practice. (If the call disconnects, please file a bug - I'm sure there are cases=20 we don't handle well.) The control channel needs to be reconnected too, of course, but we're=20 not so much in a hurry over that one. Harald On 10/03/2011 01:58 PM, Markus.Isomaki@nokia.com wrote: > Hi all, > > There is one important requirement, which may not be critical today, bu= t will most likely be in the future. > > We can assume RTC-Web to be supported in devices like tablets, pads or = smartphones, that people carry around. We can also assume that when such = devices are carried around, their point of attachement to the Internet wi= ll change, even so that the type of access network will change, typically= between something like HSPA/LTE and Wi-Fi. Today this will always mean a= change of IP address as well. In the future we may have technologies suc= h as (Proxy)Mobile IP in use that will provide IP address preservation, b= ut we can't really count on that. > > How does this relate to RTC-Web? Interface switching usually happens at= the discretion of the OS or some kind of connection manager. The browser= or the web application environment has no control over it. At best it, o= r the JS application running within, can get some kind of signal of such = event happening. For TCP-based client-server things (HTTP, Websocket) it = is possible to react to this by re-establishing the lost TCP connections = and state on top of them. This is indeed what many (native) apps are able= to do today. There can be some smarter ways in the pipeline as well, suc= h as multipath TCP, which would make the process of "transitioning" a TCP= connection from one interface/IP to another potentially transparent to t= he application. But with peer-to-peer and interactive real-time, things g= et more complicated. It may of course be that the switching happens due t= o a sudden loss of coverage and is so slow, that voice or video calls are= broken anyway. However, in many cases the > old interface can be up while the new one is being established, and i= n principle the total loss of connectivity can be avoided. In such scenar= ios it would be realistically possible to update the ongoing real-time se= ssions to a new IP address and port, if there were some kind of end-to-en= d or server-assisted mechanism for it. Even a cut of 1-2 seconds would no= t be as bad as a total loss of the session. > > What does this mean in terms of requirements? > - The first-order requirement is that the browser and/or the JS app, wh= oever needs to act, has to be able to get events of interface switching i= n the same way as native apps can. If it were only the browser who was re= quired to get them, we could set standards aside, and declare that the br= owser does this as any other app. But if it is the JS app that needs to d= o something, then we may need something new as a JS API. I have no clue a= t the moment if the JS apps can learn about this kind of events. And this= is clearly not a RTC-Web specific requirement, but a generic one. I do k= now that browsers or HTTP libraries can re-send requests etc. based on IP= address change, but I don't know what a JS Websocket client can do, if a= nything. > - The second requirement is that the media related APIs and transport p= rotocols (RTP) have to be flexible enough, that they can at least be exte= nded to work so that they do not assume that the session is forever bound= to a certain IP address/port in either end. How this affects the system = depends on what is actually standardized, for instance if the SDP offer/a= nswer model is included or not. But on the generic level it could be some= thing like this: > - If the browser/JS app receives signaling/offer from its peer that pe= er's RTP/UDP IP address/port has changed, it has to be able to set these = through the media API and re-run STUN checks or whatever is required at t= hat point. This has to be work so that the media session can be otherwise= continued, after the process is completed. > - If the browser/JS app receives an event that its own IP address/port= has changed (or is about to change), it has to be able to re-initialize = the RTP/UDP accordingly, re-establish its "signaling connection and state= " with its webserver, notify the peer about the change, and re-run STUN c= hecks etc. as needed. > > This sounds quite complicated so it may be that we don't want to add th= is as a Day 1 requirement for RTC-Web. But I believe we should try to des= ign the APIs and protocols in such a way that this kind of thing can be a= dded later on. There could be other ways too, like MPRTP (http://datatrac= ker.ietf.org/doc/draft-singh-avtcore-mprtp/), we could look at. > > I suppose the less we standardize about the signaling and offer/answer,= the easier it might be to support these kinds of things as add-on. But w= hatever we standardize, please keep the interface and IP address change i= n mind. The outcome could be that we declare that transport (MPTCP, MPRTP= ) has to deal with it, but eventually I think this will have to work one = way or the other. > > Regards, > Markus > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From Markus.Isomaki@nokia.com Mon Oct 3 07:37: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 3F24321F8B2F for ; Mon, 3 Oct 2011 07:37:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.21 X-Spam-Level: X-Spam-Status: No, score=-3.21 tagged_above=-999 required=5 tests=[AWL=0.389, 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 R6fcRQuUGwzy for ; Mon, 3 Oct 2011 07:37:58 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 40FF621F8B28 for ; Mon, 3 Oct 2011 07:37:58 -0700 (PDT) Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p93Eeir7031445; Mon, 3 Oct 2011 17:40:56 +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); Mon, 3 Oct 2011 17:40:49 +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; Mon, 3 Oct 2011 16:40:49 +0200 Received: from 008-AM1MPN1-043.mgdnok.nokia.com ([169.254.3.167]) by 008-AM1MMR1-002.mgdnok.nokia.com ([65.54.30.57]) with mapi id 14.01.0339.002; Mon, 3 Oct 2011 16:40:49 +0200 From: To: , Thread-Topic: [rtcweb] Future requirement: RTC-Web apps must work through interface switching Thread-Index: AcyBw8LOCbj0Q27JT3eGKgpYq050bwAAKV6AAAUGtUA= Date: Mon, 3 Oct 2011 14:40:48 +0000 Message-ID: References: <4E89C099.3000709@alvestrand.no> In-Reply-To: <4E89C099.3000709@alvestrand.no> 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: 03 Oct 2011 14:40:49.0712 (UTC) FILETIME=[71B01300:01CC81DA] X-Nokia-AV: Clean Subject: Re: [rtcweb] Future requirement: RTC-Web apps must work through interface switching X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2011 14:37:59 -0000 Hi Harald, Well, things may already be better than what I expected :) >The control channel needs to be reconnected too, of course, but we're not = so >much in a hurry over that one. So you're not signaling anything at the point of the switch, but you have s= et two alternatives beforehand? In the mobile use case, the available inter= faces come and go, so we can't offer all alternate candidates upfront. Howe= ver, if we can keep the "old" interface up for a while after the "new" one = appears, we can add the new candidate at that point. This would be the so c= alled make-before-break switch. The worst case is that we loose the old int= erface at the same time as new one comes available, so the new alternative = can only be sent over the new interface AFTER the signaling has been reconn= ected. This would be break-before-make. If the underlying OS can handle mul= ti-homing, we should in most cases only need the make-before-break type of = switching. However, as we know, a device can run out of Wi-Fi coverate quit= e abruptly and it is not always clear that the cellular connectivity is ful= ly up at that point. I don't know all nuances of ICE by heart, but is it so that the alternate c= andidates can be added in an offer at any point? In that case we should be = able to cover most cases quite well. Markus >-----Original Message----- >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf >Of ext Harald Alvestrand >Sent: 03 October, 2011 17:03 >To: rtcweb@ietf.org >Subject: Re: [rtcweb] Future requirement: RTC-Web apps must work through >interface switching > >The media channels in Google's ICE-based offerings (Google Talk Video, >Google Voice and Hangouts) all are able to survive an interface change by >utilizing the alternate candidate mechanisms in ICE. > >Try this experiment: >- Make sure your laptop has a working wireless connection >- Connect your laptop to wired Ethernet >- Set up a Google Talk Video call with someone >- Yank out the Ethernet cord > >If all goes well, you should see exactly how much of a break this causes t= o the >call in practice. >(If the call disconnects, please file a bug - I'm sure there are cases we = don't >handle well.) > >The control channel needs to be reconnected too, of course, but we're not = so >much in a hurry over that one. > > Harald > > >On 10/03/2011 01:58 PM, Markus.Isomaki@nokia.com wrote: >> Hi all, >> >> There is one important requirement, which may not be critical today, but= will >most likely be in the future. >> >> We can assume RTC-Web to be supported in devices like tablets, pads or >smartphones, that people carry around. We can also assume that when such >devices are carried around, their point of attachement to the Internet wil= l >change, even so that the type of access network will change, typically >between something like HSPA/LTE and Wi-Fi. Today this will always mean a >change of IP address as well. In the future we may have technologies such = as >(Proxy)Mobile IP in use that will provide IP address preservation, but we = can't >really count on that. >> >> How does this relate to RTC-Web? Interface switching usually happens >> at the discretion of the OS or some kind of connection manager. The >> browser or the web application environment has no control over it. At >> best it, or the JS application running within, can get some kind of >> signal of such event happening. For TCP-based client-server things >> (HTTP, Websocket) it is possible to react to this by re-establishing >> the lost TCP connections and state on top of them. This is indeed what >> many (native) apps are able to do today. There can be some smarter >> ways in the pipeline as well, such as multipath TCP, which would make >> the process of "transitioning" a TCP connection from one interface/IP >> to another potentially transparent to the application. But with >> peer-to-peer and interactive real-time, things get more complicated. >> It may of course be that the switching happens due to a sudden loss of >> coverage and is so slow, that voice or video calls are broken anyway. >> However, in many cases th > e >> old interface can be up while the new one is being established, and in >principle the total loss of connectivity can be avoided. In such scenarios= it >would be realistically possible to update the ongoing real-time sessions t= o a >new IP address and port, if there were some kind of end-to-end or server- >assisted mechanism for it. Even a cut of 1-2 seconds would not be as bad a= s a >total loss of the session. >> >> What does this mean in terms of requirements? >> - The first-order requirement is that the browser and/or the JS app, >whoever needs to act, has to be able to get events of interface switching = in >the same way as native apps can. If it were only the browser who was >required to get them, we could set standards aside, and declare that the >browser does this as any other app. But if it is the JS app that needs to = do >something, then we may need something new as a JS API. I have no clue at >the moment if the JS apps can learn about this kind of events. And this is >clearly not a RTC-Web specific requirement, but a generic one. I do know t= hat >browsers or HTTP libraries can re-send requests etc. based on IP address >change, but I don't know what a JS Websocket client can do, if anything. >> - The second requirement is that the media related APIs and transport >protocols (RTP) have to be flexible enough, that they can at least be exte= nded >to work so that they do not assume that the session is forever bound to a >certain IP address/port in either end. How this affects the system depends= on >what is actually standardized, for instance if the SDP offer/answer model = is >included or not. But on the generic level it could be something like this: >> - If the browser/JS app receives signaling/offer from its peer that >peer's RTP/UDP IP address/port has changed, it has to be able to set these >through the media API and re-run STUN checks or whatever is required at th= at >point. This has to be work so that the media session can be otherwise >continued, after the process is completed. >> - If the browser/JS app receives an event that its own IP address/port >has changed (or is about to change), it has to be able to re-initialize th= e >RTP/UDP accordingly, re-establish its "signaling connection and state" wit= h its >webserver, notify the peer about the change, and re-run STUN checks etc. a= s >needed. >> >> This sounds quite complicated so it may be that we don't want to add thi= s as >a Day 1 requirement for RTC-Web. But I believe we should try to design the >APIs and protocols in such a way that this kind of thing can be added late= r on. >There could be other ways too, like MPRTP >(http://datatracker.ietf.org/doc/draft-singh-avtcore-mprtp/), we could loo= k >at. >> >> I suppose the less we standardize about the signaling and offer/answer, = the >easier it might be to support these kinds of things as add-on. But whateve= r we >standardize, please keep the interface and IP address change in mind. The >outcome could be that we declare that transport (MPTCP, MPRTP) has to deal >with it, but eventually I think this will have to work one way or the othe= r. >> >> Regards, >> Markus >> _______________________________________________ >> 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 Oct 3 07: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 D006221F8B29 for ; Mon, 3 Oct 2011 07:38:56 -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 BQ79QHU+w8NP for ; Mon, 3 Oct 2011 07:38:56 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 404DB21F8B28 for ; Mon, 3 Oct 2011 07:38:56 -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 p93EgTu6018581 for ; Mon, 3 Oct 2011 10:42:29 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail07.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 3 Oct 2011 10:41:57 -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: Mon, 3 Oct 2011 20:11:54 +0530 Message-ID: <2E239D6FCD033C4BAF15F386A979BF510F1367@sonusinmail02.sonusnet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review request for RTCWeb standard signaling protocol Thread-Index: AcyB2M8p5Sh3naz7SPaFx9XGCjJhjQAABSnA From: "Ravindran Parthasarathi" To: X-OriginalArrivalTime: 03 Oct 2011 14:41:57.0349 (UTC) FILETIME=[9A00A950:01CC81DA] Subject: [rtcweb] Review request for RTCWeb standard 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, 03 Oct 2011 14:38:56 -0000 SGkgYWxsLA0KDQpSVENXZWIgc3RhbmRhcmQgc2lnbmFsaW5nIHByb3RvY29sIChodHRwOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1wYXJ0aGEtcnRjd2ViLXNpZ25hbGluZy0wMCkgZHJhZnQg bGlzdCB0aGUgbmVlZCBmb3Igc3RhbmRhcmQgc2lnbmFsaW5nIHByb3RvY29sIGJldHdlZW4gUlRD V2ViIGNsaWVudCAoYnJvd3NlcikgYW5kIFJUQ1dlYiBzZXJ2ZXIgYW5kIHRoZSBwb3NzaWJsZSBz aWduYWxpbmcgcHJvdG9jb2wgZm9yIHRoZSBzYW1lLiBUaGlzIGRyYWZ0IGlzIHdyaXR0ZW4gYmFz ZWQgb24gaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3J0Y3dlYi9jdXJyZW50 L21zZzAxMTcyLmh0bWwgbWFpbCB0aHJlYWQgZGlzY3Vzc2lvbi4gQ291bGQgeW91IHBsZWFzZSBw cm92aWRlIHlvdXIgdmFsdWFibGUgY29tbWVudHMuDQoNClRoYW5rcw0KUGFydGhhDQoNCi0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21h aWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KU2VudDogTW9uZGF5LCBPY3RvYmVyIDAz LCAyMDExIDc6NTYgUE0NClRvOiBSYXZpbmRyYW4gUGFydGhhc2FyYXRoaQ0KQ2M6IFJhdmluZHJh biBQYXJ0aGFzYXJhdGhpDQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRy YWZ0LXBhcnRoYS1ydGN3ZWItc2lnbmFsaW5nLTAwLnR4dA0KDQpBIG5ldyB2ZXJzaW9uIG9mIEkt RCwgZHJhZnQtcGFydGhhLXJ0Y3dlYi1zaWduYWxpbmctMDAudHh0IGhhcyBiZWVuIHN1Y2Nlc3Nm dWxseSBzdWJtaXR0ZWQgYnkgUGFydGhhc2FyYXRoaSBSYXZpbmRyYW4gYW5kIHBvc3RlZCB0byB0 aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpGaWxlbmFtZToJIGRyYWZ0LXBhcnRoYS1ydGN3ZWItc2ln bmFsaW5nDQpSZXZpc2lvbjoJIDAwDQpUaXRsZToJCSBSVENXZWIgc3RhbmRhcmQgc2lnbmFsaW5n IHByb3RvY29sDQpDcmVhdGlvbiBkYXRlOgkgMjAxMS0xMC0wMw0KV0cgSUQ6CQkgSW5kaXZpZHVh bCBTdWJtaXNzaW9uDQpOdW1iZXIgb2YgcGFnZXM6IDgNCg0KQWJzdHJhY3Q6DQogICBUaGUgc3Rh bmRhcmRpemF0aW9uIG9mIFJlYWwgdGltZSBjb21tdW5pY2F0aW9uIGJldHdlZW4gYnJvd3NlcnMg aXMgdG8NCiAgIHByb3ZpZGUgdGhlIGluZnJhc3RydWN0dXJlIGZvciBhdWRpbywgdmlkZW8sIHRl eHQgY29tbXVuaWNhdGlvbiB1c2luZw0KICAgc3RhbmRhcmQgaW50ZXJmYWNlIHNvIHRoYXQgaW50 ZXJvcGVyYWJsZSBjb21tdW5pY2F0aW9uIGNhbiBiZQ0KICAgZXN0YWJsaXNoZWQgYmV0d2VlbiBh bnkgY29tcGF0aWJsZSBicm93c2Vycy4gIFJUQ1dlYiBzcGVjaWZpYw0KICAgSmF2YXNjcmlwdCBB UEkgd2lsbCBiZSBwcm92aWRlZCBieSBicm93c2VycyBmb3IgZGV2ZWxvcGluZyByZWFsLXRpbWUN CiAgIHdlYiBhcHBsaWNhdGlvbi4gIEl0IGlzIHBvc3NpYmxlIHRvIGRldmVsb3Agc2lnbmFsaW5n IHByb3RvY29sIGxpa2UNCiAgIFNlc3Npb24gSW5pdGlhdGlvbiBQcm90b2NvbCAoU0lQKSBvciBK aW5nbGUgb3Igd2Vic29ja2V0IGV4dGVuc2lvbiBvcg0KICAgY3VzdG9tLW1hZGUgc2lnbmFsaW5n IHByb3RvY29sIGluIEphdmFzY3JpcHQuICBUaGVyZSBhcmUgbG90cyBvZg0KICAgaXNzdWVzIGlu IEphdmFzY3JpcHQgYmFzZWQgc2lnbmFsaW5nIHByb3RvY29sLiAgVGhpcyBkb2N1bWVudCBsaXN0 DQogICB0aGUgbmVlZCBmb3Igc3RhbmRhcmQgc2lnbmFsaW5nIHByb3RvY29sIGJldHdlZW4gUlRD V2ViIGNsaWVudA0KICAgKGJyb3dzZXIpIGFuZCBSVENXZWIgc2VydmVyIGFuZCBwb3NzaWJsZSBz aWduYWxpbmcgcHJvdG9jb2wgZm9yIHRoZQ0KICAgc2FtZS4NCg0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIA0KDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQo= From harald@alvestrand.no Mon Oct 3 07:48: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 76D7E21F8634 for ; Mon, 3 Oct 2011 07:48:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.055 X-Spam-Level: X-Spam-Status: No, score=-108.055 tagged_above=-999 required=5 tests=[AWL=2.544, 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 KVRWAAlfr5FJ for ; Mon, 3 Oct 2011 07:48:33 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 4612021F8AAA for ; Mon, 3 Oct 2011 07:48:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 670BA39E13F; Mon, 3 Oct 2011 16:51: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 3IMqc-RUD2dk; Mon, 3 Oct 2011 16:51:31 +0200 (CEST) Received: from [172.16.41.139] (unknown [74.125.121.33]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 3752C39E10E; Mon, 3 Oct 2011 16:51:31 +0200 (CEST) Message-ID: <4E89CBF1.8050207@alvestrand.no> Date: Mon, 03 Oct 2011 16:51:29 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: Markus.Isomaki@nokia.com References: <4E89C099.3000709@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] Future requirement: RTC-Web apps must work through interface switching X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2011 14:48:34 -0000 On 10/03/2011 04:40 PM, Markus.Isomaki@nokia.com wrote: > Hi Harald, > > Well, things may already be better than what I expected :) > >> The control channel needs to be reconnected too, of course, but we're not so >> much in a hurry over that one. > So you're not signaling anything at the point of the switch, but you have set two alternatives beforehand? In the mobile use case, the available interfaces come and go, so we can't offer all alternate candidates upfront. However, if we can keep the "old" interface up for a while after the "new" one appears, we can add the new candidate at that point. Section 9 of RFC 5245 is the procedure for adding more candidates during the call. It supports make-before-break: 9.1.1.1. ICE Restarts An agent MAY restart ICE processing for an existing media stream. An ICE restart, as the name implies, will cause all previous states of ICE processing to be flushed and checks to start anew. The only difference between an ICE restart and a brand new media session is that, during the restart, media can continue to be sent to the previously validated pair. > This would be the so called make-before-break switch. The worst case is that we loose the old interface at the same time as new one comes available, so the new alternative can only be sent over the new interface AFTER the signaling has been reconnected. This would be break-before-make. If the underlying OS can handle multi-homing, we should in most cases only need the make-before-break type of switching. However, as we know, a device can run out of Wi-Fi coverate quite abruptly and it is not always clear that the cellular connectivity is fully up at that point. > > I don't know all nuances of ICE by heart, but is it so that the alternate candidates can be added in an offer at any point? In that case we should be able to cover most cases quite well. > > Markus > >> -----Original Message----- >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf >> Of ext Harald Alvestrand >> Sent: 03 October, 2011 17:03 >> To: rtcweb@ietf.org >> Subject: Re: [rtcweb] Future requirement: RTC-Web apps must work through >> interface switching >> >> The media channels in Google's ICE-based offerings (Google Talk Video, >> Google Voice and Hangouts) all are able to survive an interface change by >> utilizing the alternate candidate mechanisms in ICE. >> >> Try this experiment: >> - Make sure your laptop has a working wireless connection >> - Connect your laptop to wired Ethernet >> - Set up a Google Talk Video call with someone >> - Yank out the Ethernet cord >> >> If all goes well, you should see exactly how much of a break this causes to the >> call in practice. >> (If the call disconnects, please file a bug - I'm sure there are cases we don't >> handle well.) >> >> The control channel needs to be reconnected too, of course, but we're not so >> much in a hurry over that one. >> >> Harald >> >> >> On 10/03/2011 01:58 PM, Markus.Isomaki@nokia.com wrote: >>> Hi all, >>> >>> There is one important requirement, which may not be critical today, but will >> most likely be in the future. >>> We can assume RTC-Web to be supported in devices like tablets, pads or >> smartphones, that people carry around. We can also assume that when such >> devices are carried around, their point of attachement to the Internet will >> change, even so that the type of access network will change, typically >> between something like HSPA/LTE and Wi-Fi. Today this will always mean a >> change of IP address as well. In the future we may have technologies such as >> (Proxy)Mobile IP in use that will provide IP address preservation, but we can't >> really count on that. >>> How does this relate to RTC-Web? Interface switching usually happens >>> at the discretion of the OS or some kind of connection manager. The >>> browser or the web application environment has no control over it. At >>> best it, or the JS application running within, can get some kind of >>> signal of such event happening. For TCP-based client-server things >>> (HTTP, Websocket) it is possible to react to this by re-establishing >>> the lost TCP connections and state on top of them. This is indeed what >>> many (native) apps are able to do today. There can be some smarter >>> ways in the pipeline as well, such as multipath TCP, which would make >>> the process of "transitioning" a TCP connection from one interface/IP >>> to another potentially transparent to the application. But with >>> peer-to-peer and interactive real-time, things get more complicated. >>> It may of course be that the switching happens due to a sudden loss of >>> coverage and is so slow, that voice or video calls are broken anyway. >>> However, in many cases th >> e >>> old interface can be up while the new one is being established, and in >> principle the total loss of connectivity can be avoided. In such scenarios it >> would be realistically possible to update the ongoing real-time sessions to a >> new IP address and port, if there were some kind of end-to-end or server- >> assisted mechanism for it. Even a cut of 1-2 seconds would not be as bad as a >> total loss of the session. >>> What does this mean in terms of requirements? >>> - The first-order requirement is that the browser and/or the JS app, >> whoever needs to act, has to be able to get events of interface switching in >> the same way as native apps can. If it were only the browser who was >> required to get them, we could set standards aside, and declare that the >> browser does this as any other app. But if it is the JS app that needs to do >> something, then we may need something new as a JS API. I have no clue at >> the moment if the JS apps can learn about this kind of events. And this is >> clearly not a RTC-Web specific requirement, but a generic one. I do know that >> browsers or HTTP libraries can re-send requests etc. based on IP address >> change, but I don't know what a JS Websocket client can do, if anything. >>> - The second requirement is that the media related APIs and transport >> protocols (RTP) have to be flexible enough, that they can at least be extended >> to work so that they do not assume that the session is forever bound to a >> certain IP address/port in either end. How this affects the system depends on >> what is actually standardized, for instance if the SDP offer/answer model is >> included or not. But on the generic level it could be something like this: >>> - If the browser/JS app receives signaling/offer from its peer that >> peer's RTP/UDP IP address/port has changed, it has to be able to set these >> through the media API and re-run STUN checks or whatever is required at that >> point. This has to be work so that the media session can be otherwise >> continued, after the process is completed. >>> - If the browser/JS app receives an event that its own IP address/port >> has changed (or is about to change), it has to be able to re-initialize the >> RTP/UDP accordingly, re-establish its "signaling connection and state" with its >> webserver, notify the peer about the change, and re-run STUN checks etc. as >> needed. >>> This sounds quite complicated so it may be that we don't want to add this as >> a Day 1 requirement for RTC-Web. But I believe we should try to design the >> APIs and protocols in such a way that this kind of thing can be added later on. >> There could be other ways too, like MPRTP >> (http://datatracker.ietf.org/doc/draft-singh-avtcore-mprtp/), we could look >> at. >>> I suppose the less we standardize about the signaling and offer/answer, the >> easier it might be to support these kinds of things as add-on. But whatever we >> standardize, please keep the interface and IP address change in mind. The >> outcome could be that we declare that transport (MPTCP, MPRTP) has to deal >> with it, but eventually I think this will have to work one way or the other. >>> Regards, >>> Markus >>> _______________________________________________ >>> 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 Mon Oct 3 08: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 BC26F21F8B70 for ; Mon, 3 Oct 2011 08:34:02 -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 IzCvJWpwzAee for ; Mon, 3 Oct 2011 08:34:02 -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 0BE3B21F8B2F for ; Mon, 3 Oct 2011 08:34:01 -0700 (PDT) Received: by vws5 with SMTP id 5so4492452vws.31 for ; Mon, 03 Oct 2011 08:37:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.68.97 with SMTP id v1mr64927vdt.313.1317656224337; Mon, 03 Oct 2011 08:37:04 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Mon, 3 Oct 2011 08:37:03 -0700 (PDT) In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF510F1367@sonusinmail02.sonusnet.com> References: <2E239D6FCD033C4BAF15F386A979BF510F1367@sonusinmail02.sonusnet.com> Date: Mon, 3 Oct 2011 17:37:03 +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] Review request for RTCWeb standard 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, 03 Oct 2011 15:34:02 -0000 2011/10/3 Ravindran Parthasarathi : > Hi all, > > RTCWeb standard signaling protocol (http://tools.ietf.org/html/draft-part= ha-rtcweb-signaling-00) draft list the need for standard signaling protocol= between RTCWeb client (browser) and RTCWeb server and the possible signali= ng protocol for the same. This draft is written based on http://www.ietf.or= g/mail-archive/web/rtcweb/current/msg01172.html mail thread discussion. Cou= ld you please provide your valuable comments. Hi Ravindran, The draft just talks about supposed advantages of using a "default/standard" signaling protocol for WebRTC, and clearly ignores all the disadvantages that people in this list has explained in several threads. So I must repeat them: 1) If the browsers speak *native* SIP (or any other protocol) 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). It would be possible just in case the signaling protocol is HTTP or WebSocket. 2) By forcing a specific signaling protocol between rtcweb client and server, you force the existence of ugly signaling gateways (rtcweb to SIP/XMPP). Your draft shows it as an advantage: o Gateway for RTCWeb server and legacy signaling protocol is easy in case standard RTCweb signaling protocol is used. Easy??? that should be a joke. Doing protocol conversion/gateway always means loss of features. If not, take any current JSON-AJAX-based "web softphone" in which there is a conversion from the custom (always custom!!!) JSON protocol to SIP protocol in a "special" gateway, and let me know which one allows "exotic" features like parallel forking or call transfer. Please, don't mandate a gateway for signalling protocol, please. I *do* know that SIP and XMPP can be ***fully*** implemented in JavaScript by using websocket as transport protocol and a SIP/XMPP proxy/server that also implements SIP/XMPP over WebSocket (this is not protocol gateway!! this is ***pure*** SIP/XMPP). In the other side, I think you don't fully understand how WWW world works for years. Your draft talks about some "issues" (which IMHO are not issues at all), comments in line: > 3. Issues without RTCWeb standard signaling protocol > > The issues in creating non standard RTCWeb sigaling protocol are > > o Without RTCWeb standard signaling protocol, each website developer > has to understand the complication of signaling protocol for > making the real-time communication. For sure there will appear signalling libraries, some of them GPL some others not. WWW is a jungle, trying to mandate something never works. And I don't want to be limited by the basic features that your "RTCWeb standard signaling protocol" would provide. > o Downloading the complete RTCWeb signaling protocol Javascript is > inefficient as it impact performance and setup delay of real-time > communication. The caching of Javascript shall avoid downloading > the signaling protocol in each time RTCWeb server is accessed. > But the Javascript cache is possible to be removed often which > leads to the impact. Ok, let me say something similar: Downloading the complete Gmail Javascript is inefficient as it impact performance and setup delay of real-time communication. So we need to create a "standard webmail protocol" so Gmail, Hotmail, Yahoo and all the webmail providers would use them and all the browsers would natively implement it. > o Also, browser has to download each website signaling protocol > indepentely Same as above. When you visit Gmail you download the complete JS code from Gmail. If later you visit Hotmail you download the complete JS code from Hotmail. That's how WWW works. Welcome. --=20 I=C3=B1aki Baz Castillo From pravindran@sonusnet.com Mon Oct 3 11:21: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 1CD2B21F8D17 for ; Mon, 3 Oct 2011 11:21:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.5 X-Spam-Level: X-Spam-Status: No, score=-2.5 tagged_above=-999 required=5 tests=[AWL=0.099, 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 CCkTLyIQRMZB for ; Mon, 3 Oct 2011 11:21:08 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id E93D821F8D06 for ; Mon, 3 Oct 2011 11:21:07 -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 p93IOcek001668; Mon, 3 Oct 2011 14:24:38 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail07.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 3 Oct 2011 14:24:05 -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, 3 Oct 2011 23:54:02 +0530 Message-ID: <2E239D6FCD033C4BAF15F386A979BF510F137B@sonusinmail02.sonusnet.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/j8bw5yK0pVrCArA 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: "Ravindran Parthasarathi" To: "Hadriel Kaplan" X-OriginalArrivalTime: 03 Oct 2011 18:24:05.0170 (UTC) FILETIME=[A200C120:01CC81F9] 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, 03 Oct 2011 18:21:09 -0000 Hadriel, Sorry for the delay response. I have mentioned the reason for "standard = signaling protocol" as a separate draft and the related thread is = http://www.ietf.org/mail-archive/web/rtcweb/current/msg01733.html.=20 I agree to the fact that SCCP protocol is decided by Cisco folks but it = does not mean that every company in the world has to create their own = version of SCCP protocol and IETF should not force every company to = re-invent the wheel. The intention of standard signaling protocol is not against those who = have the interest in creating their own proprietary signaling protocol. = The main purpose is for the welfare of those whose focus is not = signaling but interested in Real-time communication. JavaScript library = by third party is worst case in case there is no native standard = signaling protocol exists for RTCWeb. Let us discuss how much services has to be provided by standard = signaling protocol. Thanks Partha >-----Original Message----- >From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] >Sent: Friday, September 16, 2011 7:55 AM >To: Ravindran Parthasarathi >Cc: Sa=FAl Ibarra Corretg=E9; >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 From pravindran@sonusnet.com Mon Oct 3 12:09: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 ED80B21F8DB3 for ; Mon, 3 Oct 2011 12:09:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.351 X-Spam-Level: X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[AWL=-0.052, 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 nQ+NZJTG4vIf for ; Mon, 3 Oct 2011 12:09:55 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 38D3021F8C69 for ; Mon, 3 Oct 2011 12:09:23 -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 p93JCoX5000763; Mon, 3 Oct 2011 15:12:50 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail04.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 3 Oct 2011 15:10: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="utf-8" Content-Transfer-Encoding: base64 Date: Tue, 4 Oct 2011 00:40:54 +0530 Message-ID: <2E239D6FCD033C4BAF15F386A979BF510F137E@sonusinmail02.sonusnet.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] Review request for RTCWeb standard signaling protocol Thread-Index: AcyB4k/+WtIgkO3sQVWGgZby0wyyzwAGJYdA References: <2E239D6FCD033C4BAF15F386A979BF510F1367@sonusinmail02.sonusnet.com> From: "Ravindran Parthasarathi" To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= X-OriginalArrivalTime: 03 Oct 2011 19:10:56.0596 (UTC) FILETIME=[2DBE5140:01CC8200] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Review request for RTCWeb standard 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, 03 Oct 2011 19:09:57 -0000 SW5ha2ksDQoNCjxzbmlwPg0KIiBUaGUgZHJhZnQganVzdCB0YWxrcyBhYm91dCBzdXBwb3NlZCBh ZHZhbnRhZ2VzIG9mIHVzaW5nIGEgImRlZmF1bHQvc3RhbmRhcmQiIHNpZ25hbGluZyBwcm90b2Nv bCBmb3IgV2ViUlRDIg0KPC9zbmlwPg0KSSdtIGhhcHB5IHRvIGhlYXIgZnJvbSB5b3UgdGhhdCBS VENXZWIgc3RhbmRhcmQgc2lnbmFsaW5nIHByb3RvY29sIGhhcyBzb21lIGFkdmFudGFnZXMuIA0K DQpJIHRob3VnaHQgdGhhdCBhdCBsZWFzdCB5b3Ugd2lsbCB1bmRlcnN0YW5kIG15IHBvaW50IGFm dGVyIGxvb2tpbmcgYXQgdGhlIGRyYWZ0IGJ1dCBkb2VzIG5vdCBzZWVtcyB0byBiZS4gUGxlYXNl IG5vdGUgdGhhdCBSVENXZWIgc3RhbmRhcmQgc2lnbmFsaW5nIHByb3RvY29sIGlzIG5vdCBhZ2Fp bnN0IGhhdmluZyBwcm9wcmlldGFyeSBwcm90b2NvbCBhbmQgSSBoYXZlIGV4cGxhaW5lZCBpbiBT ZWMgNCBvZiB0aGUgZHJhZnQgYXMgDQoNCiIgIFRoZSBkZWZpbmluZyBzaWduYWxpbmcgcHJvdG9j b2wgaXMgbm90IGEgaGluZHJhbmNlIGZvciBhbnkgaW5ub3ZhdGl2ZQ0KICAgUlRDV2ViIHNpZ25h bGluZyBwcm90b2NvbCBkZXZlbG9wbWVudCBhcyBpdCBpcyBjb21wbGVtZW50YXJ5DQogICBzb2x1 dGlvbi4iDQoNCkkgY291bGQgbm90IHVuZGVyc3RhbmQgc29tZSBvZiB5b3VyIGFyZ3VtZW50LCBQ bGVhc2UgcmVhZCBpbmxpbmUgZm9yIGRldGFpbHMuDQoNClRoYW5rcw0KUGFydGhhDQoNCj4tLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPkZyb206IEnDsWFraSBCYXogQ2FzdGlsbG8gW21haWx0 bzppYmNAYWxpYXgubmV0XQ0KPlNlbnQ6IE1vbmRheSwgT2N0b2JlciAwMywgMjAxMSA5OjA3IFBN DQo+VG86IFJhdmluZHJhbiBQYXJ0aGFzYXJhdGhpDQo+Q2M6IHJ0Y3dlYkBpZXRmLm9yZw0KPlN1 YmplY3Q6IFJlOiBbcnRjd2ViXSBSZXZpZXcgcmVxdWVzdCBmb3IgUlRDV2ViIHN0YW5kYXJkIHNp Z25hbGluZw0KPnByb3RvY29sDQo+DQo+MjAxMS8xMC8zIFJhdmluZHJhbiBQYXJ0aGFzYXJhdGhp IDxwcmF2aW5kcmFuQHNvbnVzbmV0LmNvbT46DQo+PiBIaSBhbGwsDQo+Pg0KPj4gUlRDV2ViIHN0 YW5kYXJkIHNpZ25hbGluZyBwcm90b2NvbCAoaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtDQo+cGFydGhhLXJ0Y3dlYi1zaWduYWxpbmctMDApIGRyYWZ0IGxpc3QgdGhlIG5lZWQgZm9y IHN0YW5kYXJkIHNpZ25hbGluZw0KPnByb3RvY29sIGJldHdlZW4gUlRDV2ViIGNsaWVudCAoYnJv d3NlcikgYW5kIFJUQ1dlYiBzZXJ2ZXIgYW5kIHRoZQ0KPnBvc3NpYmxlIHNpZ25hbGluZyBwcm90 b2NvbCBmb3IgdGhlIHNhbWUuIFRoaXMgZHJhZnQgaXMgd3JpdHRlbiBiYXNlZCBvbg0KPmh0dHA6 Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9ydGN3ZWIvY3VycmVudC9tc2cwMTE3Mi5o dG1sIG1haWwNCj50aHJlYWQgZGlzY3Vzc2lvbi4gQ291bGQgeW91IHBsZWFzZSBwcm92aWRlIHlv dXIgdmFsdWFibGUgY29tbWVudHMuDQo+DQo+SGkgUmF2aW5kcmFuLA0KPg0KPlRoZSBkcmFmdCBq dXN0IHRhbGtzIGFib3V0IHN1cHBvc2VkIGFkdmFudGFnZXMgb2YgdXNpbmcgYQ0KPiJkZWZhdWx0 L3N0YW5kYXJkIiBzaWduYWxpbmcgcHJvdG9jb2wgZm9yIFdlYlJUQywgYW5kIGNsZWFybHkgaWdu b3Jlcw0KPmFsbCB0aGUgZGlzYWR2YW50YWdlcyB0aGF0IHBlb3BsZSBpbiB0aGlzIGxpc3QgaGFz IGV4cGxhaW5lZCBpbg0KPnNldmVyYWwgdGhyZWFkcy4gU28gSSBtdXN0IHJlcGVhdCB0aGVtOg0K Pg0KPg0KPjEpIElmIHRoZSBicm93c2VycyBzcGVhayAqbmF0aXZlKiBTSVAgKG9yIGFueSBvdGhl ciBwcm90b2NvbCkgdGhlbiB0aGUNCj53ZWIgc2VydmVyIGlzIHVuYXdhcmUgb2Ygd2hhdCBpcyBo YXBwZW5pbmcgYXQgbWVkaWEgbGV2ZWwgYmV0d2VlbiB0aGUNCj52aXNpdG9ycyAoYmVjYXVzZSB0 aGUgd2ViIHNlcnZlciwgd2hlcmUgdGhlIGFwcGxpY2F0aW9uIGxvZ2ljIGlzLCBkb2VzDQo+bm90 IHNlZSB0aGUgc2lnbmFsaW5nIHRyYWZmaWMpLiBJdCB3b3VsZCBiZSBwb3NzaWJsZSBqdXN0IGlu IGNhc2UgdGhlDQo+c2lnbmFsaW5nIHByb3RvY29sIGlzIEhUVFAgb3IgV2ViU29ja2V0Lg0KDQo8 cGFydGhhPiBJIGd1ZXNzIHRoYXQgeW91IHByb3Bvc2UgdG8gaGF2ZSB3ZWJzb2NrZXQgb3IgSFRU UCBiYXNlZCBzaWduYWxpbmcgcHJvdG9jb2wgYW5kIG5vdCBwcmVmZXJyaW5nIFNJUC4gSSdtIG9r IHRvIGhhdmUgYW55IG9uZSBvZiB0aGUgc3RhbmRhcmQgc2lnbmFsaW5nIHByb3RvY29sIGFuZCBu b3QuIFNvLCB3ZSBoYXZlIG5vIGRpc2FncmVlbWVudCBhdCB0aGlzIGxldmVsIGZvciB0aGUgZHJh ZnQuIDwvcGFydGhhPg0KDQo+DQo+MikgQnkgZm9yY2luZyBhIHNwZWNpZmljIHNpZ25hbGluZyBw cm90b2NvbCBiZXR3ZWVuIHJ0Y3dlYiBjbGllbnQgYW5kDQo+c2VydmVyLCB5b3UgZm9yY2UgdGhl IGV4aXN0ZW5jZSBvZiB1Z2x5IHNpZ25hbGluZyBnYXRld2F5cyAocnRjd2ViIHRvDQo+U0lQL1hN UFApLiANCg0KPHBhcnRoYT4gSW4gY2FzZSB5b3UgaGF2ZSBhbnkgc29sdXRpb24gKG90aGVyIHRo YW4gU0lQKSBpbiBSVENXZWIgd2l0aCBhbnkgc2lnbmFsaW5nIGdhdGV3YXksIGxldCB1cyBkaXNj dXNzLiBQbGVhc2UgZG9u4oCZdCBtZW50aW9uZWQgeW91ciB3ZWJzb2NrZXQgdHVubmVsaW5nIFNJ UCBhcyBhIHNvbHV0aW9uLiBFdmVuIGluIHlvdXIgcHJvcG9zZWQgbWVjaGFuaXNtLCBnYXRld2F5 IChCMkJVQSkgaGFzIHRvIHJlbW92ZSB0aGUgd2Vic29ja2V0IHRyYW5zcG9ydCBhbmQgZm9yd2Fy ZCBTSVAgbWVzc2FnZXMgd2l0aCBhcHByb3ByaWF0ZSBjaGFuZ2VzLiBJU1RNLCB5b3UgYXJlIHNp bXBseSBhcmd1aW5nIDwvcGFydGhhPg0KDQpZb3VyIGRyYWZ0IHNob3dzIGl0IGFzIGFuIGFkdmFu dGFnZToNCj4NCj4gICBvICBHYXRld2F5IGZvciBSVENXZWIgc2VydmVyIGFuZCBsZWdhY3kgc2ln bmFsaW5nIHByb3RvY29sIGlzIGVhc3kgaW4NCj4gICAgICBjYXNlIHN0YW5kYXJkIFJUQ3dlYiBz aWduYWxpbmcgcHJvdG9jb2wgaXMgdXNlZC4NCj4NCj5FYXN5Pz8/IHRoYXQgc2hvdWxkIGJlIGEg am9rZS4gRG9pbmcgcHJvdG9jb2wgY29udmVyc2lvbi9nYXRld2F5DQo+YWx3YXlzIG1lYW5zIGxv c3Mgb2YgZmVhdHVyZXMuIElmIG5vdCwgdGFrZSBhbnkgY3VycmVudA0KPkpTT04tQUpBWC1iYXNl ZCAid2ViIHNvZnRwaG9uZSIgaW4gd2hpY2ggdGhlcmUgaXMgYSBjb252ZXJzaW9uIGZyb20NCj50 aGUgY3VzdG9tIChhbHdheXMgY3VzdG9tISEhKSBKU09OIHByb3RvY29sIHRvIFNJUCBwcm90b2Nv bCBpbiBhDQo+InNwZWNpYWwiIGdhdGV3YXksIGFuZCBsZXQgbWUga25vdyB3aGljaCBvbmUgYWxs b3dzICJleG90aWMiIGZlYXR1cmVzDQo+bGlrZSBwYXJhbGxlbCBmb3JraW5nIG9yIGNhbGwgdHJh bnNmZXIuDQo+DQoNCjxwYXJ0aGE+IEkgbWVhbnQgZm9yICJlYXN5IiBpbiB0aGUgY29tcGFyYXRp dmUgc2Vuc2UuIFByb3RvY29sIGNvbnZlcnNpb24vZ2F0ZXdheSBkb2VzIG5vdCBtZWFucyBsb3Nz IG9mIGZlYXR1cmVzIGFuZCB0aGlzIGlzIGJhc2VkIG9uIG15IGV4cGVyaWVuY2Ugb24gZ2F0ZXdh eXMgd2hpY2ggc3VwcG9ydHMgbXVsdGlwbGUgcHJvdG9jb2wgbmFtZWx5IElTRE4sIElTVVAsIFNJ UCwgSC4zMjMsIE1HQ1AsIFNDQ1Agc2ltdWx0YW5lb3VzbHkuIFdlYnNvY2tldCBvciBIVFRQIHdp bGwgYmUgb25lIGFub3RoZXIgYWRkaXRpb24gc2lnbmFsaW5nIHByb3RvY29sIGluIHRob3NlIGdh dGV3YXkgZm9yIGludGVyb3Agd2l0aCBleGlzdGluZyBzaWduYWxpbmcgcHJvdG9jb2wuIEluIGNh c2UgeW91IHRoaW5rIHRoYXQgaXQgaXMgY2FrZXdhbGsgam9iIHRoZW4geW91IGFyZSB3cm9uZy4g RWFjaCBwcm90b2NvbCBtYXBwaW5nIHdpbGwgaW52b2x2ZSBzb21lIGNpcmN1cyBkdXJpbmcgY29u dmVyc2lvbiBsaWtlIGV4dHJhIFJFLUlOVklURS4gDQoNCk15IGNvbXBhcmlzb24gaXMgYmV0d2Vl biAieW91ciBwcm9wb3NhbCBjdXN0b20gbWFkZSBSVENXZWIgc2lnbmFsaW5nIHRvIGZlZGVyYXRl ZCBzaWduYWxpbmcgcHJvdG9jb2wiIHRvICJSVENXZWIgc3RhbmRhcmQgc2lnbmFsaW5nIHByb3Rv Y29sIHRvIGZlZGVyYXRlZCBzaWduYWxpbmcgcHJvdG9jb2wiLiA8L3BhcnRoYT4NCg0KDQo+UGxl YXNlLCBkb24ndCBtYW5kYXRlIGEgZ2F0ZXdheSBmb3Igc2lnbmFsbGluZyBwcm90b2NvbCwgcGxl YXNlLiBJDQo+KmRvKiBrbm93IHRoYXQgU0lQIGFuZCBYTVBQIGNhbiBiZSAqKipmdWxseSoqKiBp bXBsZW1lbnRlZCBpbg0KPkphdmFTY3JpcHQgYnkgdXNpbmcgd2Vic29ja2V0IGFzIHRyYW5zcG9y dCBwcm90b2NvbCBhbmQgYSBTSVAvWE1QUA0KPnByb3h5L3NlcnZlciB0aGF0IGFsc28gaW1wbGVt ZW50cyBTSVAvWE1QUCBvdmVyIFdlYlNvY2tldCAodGhpcyBpcyBub3QNCj5wcm90b2NvbCBnYXRl d2F5ISEgdGhpcyBpcyAqKipwdXJlKioqIFNJUC9YTVBQKS4NCg0KPHBhcnRoYT4gUGxlYXNlIG5v dGUgdGhhdCBSVENXZWIgc2VydmVyIGluIHlvdXIgaW1wbGVtZW50YXRpb24gaGFzIHRvIGFjdHMg YXMgZ2F0ZXdheSB0byByZW1vdmUgd2Vic29ja2V0IHR1bm5lbC4gR2F0ZXdheSBpbmNsdWRlcyBC MkJVQSB3aXRoIGRpZmZlcmVudCB0cmFuc3BvcnQuIEFuZCBhbHNvLCB5b3VyIGFyZ3VtZW50IGlz IG5vdCByZWxhdGVkIHRvIG15IGRyYWZ0IDwvcGFydGhhPg0KDQo+DQo+DQo+DQo+SW4gdGhlIG90 aGVyIHNpZGUsIEkgdGhpbmsgeW91IGRvbid0IGZ1bGx5IHVuZGVyc3RhbmQgaG93IFdXVyB3b3Js ZA0KPndvcmtzIGZvciB5ZWFycy4gWW91ciBkcmFmdCB0YWxrcyBhYm91dCBzb21lICJpc3N1ZXMi ICh3aGljaCBJTUhPIGFyZQ0KPm5vdCBpc3N1ZXMgYXQgYWxsKSwgY29tbWVudHMgaW4gbGluZToN Cj4NCj4NCj4+IDMuICBJc3N1ZXMgd2l0aG91dCBSVENXZWIgc3RhbmRhcmQgc2lnbmFsaW5nIHBy b3RvY29sDQo+Pg0KPj4gICBUaGUgaXNzdWVzIGluIGNyZWF0aW5nIG5vbiBzdGFuZGFyZCBSVENX ZWIgc2lnYWxpbmcgcHJvdG9jb2wgYXJlDQo+Pg0KPj4gICBvICBXaXRob3V0IFJUQ1dlYiBzdGFu ZGFyZCBzaWduYWxpbmcgcHJvdG9jb2wsIGVhY2ggd2Vic2l0ZQ0KPmRldmVsb3Blcg0KPj4gICAg ICBoYXMgdG8gdW5kZXJzdGFuZCB0aGUgY29tcGxpY2F0aW9uIG9mIHNpZ25hbGluZyBwcm90b2Nv bCBmb3INCj4+ICAgICBtYWtpbmcgdGhlIHJlYWwtdGltZSBjb21tdW5pY2F0aW9uLg0KPg0KPkZv ciBzdXJlIHRoZXJlIHdpbGwgYXBwZWFyIHNpZ25hbGxpbmcgbGlicmFyaWVzLCBzb21lIG9mIHRo ZW0gR1BMIHNvbWUNCj5vdGhlcnMgbm90LiANCg0KPHBhcnRoYT4gR1BMIG9yIG5vdCBpcyBvbmUg b2YgdGhlIGlzc3VlIHdpdGggM3JkIHBhcnR5IHNpZ25hbGluZyBsaWJyYXJpZXMgPC9wYXJ0aGE+ DQoNCldXVyBpcyBhIGp1bmdsZSwgdHJ5aW5nIHRvIG1hbmRhdGUgc29tZXRoaW5nIG5ldmVyIHdv cmtzLg0KDQo8cGFydGhhPiBJIGJlbGlldmUgdGhhdCBSVEN3ZWIgbWFuZGF0aW5nIChtZWRpYSwg c2VjdXJpdHkpIHdvcmtzIGZvciBXV1cganVuZ2xlLiA8L3BhcnRoYT4NCg0KPkFuZCBJIGRvbid0 IHdhbnQgdG8gYmUgbGltaXRlZCBieSB0aGUgYmFzaWMgZmVhdHVyZXMgdGhhdCB5b3VyICJSVENX ZWINCj5zdGFuZGFyZCBzaWduYWxpbmcgcHJvdG9jb2wiIHdvdWxkIHByb3ZpZGUuDQo+DQoNCjxw YXJ0aGE+IE9mIGNvdXJzZSwgdGhlIGxpbWl0ZWQgZmVhdHVyZSAiUlRDV2ViIHN0YW5kYXJkIHNp Z25hbGluZyBwcm90b2NvbCIgaXMgbm90IGZvciBwb3dlciB1c2VyIGxpa2UgeW91IGFuZCBhbHNv IGl0IGRvZXMgbm90IGhpbmRlciBhbnkgb2YgeW91ciBhY3Rpdml0eS4gQnV0IEknbSBmYWlsIHRv IHVuZGVyc3RhbmQgeW91ciBhcmd1bWVudCBmb3Igbm90IGhhdmluZyBzdGFuZGFyZCBzaWduYWxp bmcgcHJvdG9jb2wgPC9wYXJ0aGE+DQoNCj4NCj4+ICAgbyAgRG93bmxvYWRpbmcgdGhlIGNvbXBs ZXRlIFJUQ1dlYiBzaWduYWxpbmcgcHJvdG9jb2wgSmF2YXNjcmlwdCBpcw0KPj4gICAgICBpbmVm ZmljaWVudCBhcyBpdCBpbXBhY3QgcGVyZm9ybWFuY2UgYW5kIHNldHVwIGRlbGF5IG9mIHJlYWwt dGltZQ0KPj4gICAgICBjb21tdW5pY2F0aW9uLiAgVGhlIGNhY2hpbmcgb2YgSmF2YXNjcmlwdCBz aGFsbCBhdm9pZCBkb3dubG9hZGluZw0KPj4gICAgICB0aGUgc2lnbmFsaW5nIHByb3RvY29sIGlu IGVhY2ggdGltZSBSVENXZWIgc2VydmVyIGlzIGFjY2Vzc2VkLg0KPj4gICAgICBCdXQgdGhlIEph dmFzY3JpcHQgY2FjaGUgaXMgcG9zc2libGUgdG8gYmUgcmVtb3ZlZCBvZnRlbiB3aGljaA0KPj4g ICAgICBsZWFkcyB0byB0aGUgaW1wYWN0Lg0KPg0KPk9rLCBsZXQgbWUgc2F5IHNvbWV0aGluZyBz aW1pbGFyOg0KPg0KPiAgICAgIERvd25sb2FkaW5nIHRoZSBjb21wbGV0ZSBHbWFpbCBKYXZhc2Ny aXB0IGlzDQo+ICAgICAgaW5lZmZpY2llbnQgYXMgaXQgaW1wYWN0IHBlcmZvcm1hbmNlIGFuZCBz ZXR1cCBkZWxheSBvZiByZWFsLXRpbWUNCj4gICAgICBjb21tdW5pY2F0aW9uLiBTbyB3ZSBuZWVk IHRvIGNyZWF0ZSBhICJzdGFuZGFyZCB3ZWJtYWlsIHByb3RvY29sIg0KPiAgICAgIHNvIEdtYWls LCBIb3RtYWlsLCBZYWhvbyBhbmQgYWxsIHRoZSB3ZWJtYWlsIHByb3ZpZGVycyB3b3VsZCB1c2UN Cj4gICAgICB0aGVtIGFuZCBhbGwgdGhlIGJyb3dzZXJzIHdvdWxkIG5hdGl2ZWx5IGltcGxlbWVu dCBpdC4NCj4NCj4NCj4+ICAgbyAgQWxzbywgYnJvd3NlciBoYXMgdG8gZG93bmxvYWQgZWFjaCB3 ZWJzaXRlIHNpZ25hbGluZyBwcm90b2NvbA0KPj4gICAgICBpbmRlcGVudGVseQ0KPg0KPlNhbWUg YXMgYWJvdmUuIFdoZW4geW91IHZpc2l0IEdtYWlsIHlvdSBkb3dubG9hZCB0aGUgY29tcGxldGUg SlMgY29kZQ0KPmZyb20gR21haWwuIElmIGxhdGVyIHlvdSB2aXNpdCBIb3RtYWlsIHlvdSBkb3du bG9hZCB0aGUgY29tcGxldGUgSlMNCj5jb2RlIGZyb20gSG90bWFpbC4gVGhhdCdzIGhvdyBXV1cg d29ya3MuIFdlbGNvbWUuDQoNCg0KPHBhcnRoYT4gVGhlcmUgaXMgbm8gY29tcGFyaXNvbiBiZXR3 ZWVuIG5vbi1yZWFsIHRpbWUgcHJvdG9jb2wgYW5kIHJlYWwtdGltZSBwcm90b2NvbC4gSSBhZ3Jl ZSB0aGF0IG5vbi1yZWFsIHRpbWUgV1dXIHdvcmtzIGluIHRoaXMgZmFzaGlvbiB3aGljaCBpcyBu b3QgYXBwcm9wcmlhdGUgZm9yIHJlYWwtdGltZSBhcHBsaWNhdGlvbi4gQWxzbywgcGxlYXNlIG5v dGUgdGhhdCBudW1iZXIgb2YgZS1tYWlsIHByb3ZpZGVyIHRvIHJlYWwtdGltZSBhcHBsaWNhdGlv biB3aWxsIGJlIHZlcnkgZGlmZmVyZW50LiBTYXkgSSdsbCBwcm92aWRlIFJUQ1dlYiBhcHBsaWNh dGlvbiBpbiBteSBwZXJzb25hbCB3ZWJzaXRlIGZvciBjb21tdW5pY2F0aW5nIHdpdGggbWUgaW4g bXkgbW9iaWxlLiAgPC9wYXJ0aGE+DQo+DQo+DQo+DQo+LS0NCj5Jw7Fha2kgQmF6IENhc3RpbGxv DQo+PGliY0BhbGlheC5uZXQ+DQo= From ibc@aliax.net Mon Oct 3 13:25: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 1110221F8E2C for ; Mon, 3 Oct 2011 13:25: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 FJoEh2wLG+hM for ; Mon, 3 Oct 2011 13:25:25 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 36F8221F8DD1 for ; Mon, 3 Oct 2011 13:24:51 -0700 (PDT) Received: by vcbfo11 with SMTP id fo11so4839673vcb.31 for ; Mon, 03 Oct 2011 13:27:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.184.67 with SMTP id cj3mr121183vcb.76.1317673673731; Mon, 03 Oct 2011 13:27:53 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Mon, 3 Oct 2011 13:27:53 -0700 (PDT) In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF510F137E@sonusinmail02.sonusnet.com> References: <2E239D6FCD033C4BAF15F386A979BF510F1367@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF510F137E@sonusinmail02.sonusnet.com> Date: Mon, 3 Oct 2011 22:27:53 +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] Review request for RTCWeb standard 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, 03 Oct 2011 20:25:27 -0000 2011/10/3 Ravindran Parthasarathi : > > " The draft just talks about supposed advantages of using a "default/stan= dard" signaling protocol for WebRTC" > > I'm happy to hear from you that RTCWeb standard signaling protocol has so= me advantages. Hi Ravindran. I've never said that. I just said that your draft "talks about *supposed* advantages. More inline. > I thought that at least you will understand my point after looking at the= draft but does not seems to be. Please note that RTCWeb standard signaling= protocol is not against having proprietary protocol and I have explained i= n Sec 4 of the draft as > > " =C2=A0The defining signaling protocol is not a hindrance for any innova= tive > =C2=A0 RTCWeb signaling protocol development as it is complementary > =C2=A0 solution." I will comment about this at the end of this mail. >>1) If the browsers speak *native* SIP (or any other protocol) 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). It would be possible just in case the >>signaling protocol is HTTP or WebSocket. > > I guess that you propose to have websocket or HTTP based signali= ng protocol and not preferring SIP. I'm ok to have any one of the standard = signaling protocol and not. So, we have no disagreement at this level for t= he draft. Not exactly. I propose nothing. I don't propose a "default signaling protocol" at all (reasons in the rest of the mail). >>2) By forcing a specific signaling protocol between rtcweb client and >>server, you force the existence of ugly signaling gateways (rtcweb to >>SIP/XMPP). > > In case you have any solution (other than SIP) in RTCWeb with an= y signaling gateway, let us discuss. Please don=E2=80=99t mentioned your we= bsocket tunneling SIP as a solution. Even in your proposed mechanism, gatew= ay (B2BUA) has to remove the websocket transport and forward SIP messages w= ith appropriate changes. ISTM, you are simply arguing First of all, WebSocket is a *transport* protocol, rather than an application protocol as you suggest in different comments. The separation between a transport protocol and an application protocol is just logical: A transport protocol carries messages of an application protocol. WebSocket by itself is just nothing. The developer must use or create a WebSocket subprotocol by defining messages to be send via the WebSocket connection, and such protocol is coded in JavaScript!. So WebSocket is a transport protocol as UDP or TCP. Or would you consider UDP over TCP as an application protocol? >> =C2=A0 o =C2=A0Gateway for RTCWeb server and legacy signaling protocol i= s easy in >> =C2=A0 =C2=A0 =C2=A0case standard RTCweb signaling protocol is used. >> >>Easy??? that should be a joke. Doing protocol conversion/gateway >>always means loss of features. If not, take any current >>JSON-AJAX-based "web softphone" in which there is a conversion from >>the custom (always custom!!!) JSON protocol to SIP protocol in a >>"special" gateway, and let me know which one allows "exotic" features >>like parallel forking or call transfer. > > I meant for "easy" in the comparative sense. Protocol conversion= /gateway does not means loss of features and this is based on my experience= on gateways which supports multiple protocol namely ISDN, ISUP, SIP, H.323= , MGCP, SCCP simultaneously. Websocket or HTTP will be one another addition= signaling protocol Again: WebSocket is not a signaling protocol. IMHO you should take a look to http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-17. > in those gateway for interop with existing signaling protocol. In case yo= u think that it is cakewalk job then you are wrong. Each protocol mapping w= ill involve some circus during conversion like extra RE-INVITE. I just think that the best way to interoperate with protocol A is by using protocol A, rather than using protocol B and a gateway A/B. >>Please, don't mandate a gateway for signalling protocol, please. I >>*do* know that SIP and XMPP can be ***fully*** implemented in >>JavaScript by using websocket as transport protocol and a SIP/XMPP >>proxy/server that also implements SIP/XMPP over WebSocket (this is not >>protocol gateway!! this is ***pure*** SIP/XMPP). > > Please note that RTCWeb server in your implementation has to act= s as gateway to remove websocket tunnel. Gateway includes B2BUA with differ= ent transport. I've already explained that WebSocket must be considered a transport protocol, so a SIP proxy implementing SIP over WebSocket *transport* is not a B2BUA. It's the same concept as a common SIP proxy implementing UDP and TCP, and allowing a request to come via UDP and leave the proxy via TCP. I've just added a new transport: WebSocket. That changes nothing from the point of view of what a SIP proxy is supposed to do. It's not a B2BUA. > And also, your argument is not related to my draft IMHO it's related as your draft assumes the need for a gateway performing application gateway. > WWW is a jungle, trying to mandate something never works. > > I believe that RTCweb mandating (media, security) works for WWW = jungle. Yes, but you are trying to mandate something that is unnecessary, since what you propose can already be done by custom JavaScript. About your text: "The defining signaling protocol is not a hindrance for any innovative RTCWeb signaling protocol development as it is complementary solution." It does not convince me since in other mails you have suggested that WebRTC should just allow communication between browsers. >>And I don't want to be limited by the basic features that your "RTCWeb >>standard signaling protocol" would provide. >> > > Of course, the limited feature "RTCWeb standard signaling protoc= ol" is not for power user like you and also it does not hinder any of your = activity. But I'm fail to understand your argument for not having standard = signaling protocol Having a standard signaling protocol meanst that browsers must natively implement it, and I think that's unnecessary. In the same way you could expect that something like jQuery should be part of the JavaScript stack in browsers, but it is not, and *lot* of people uses jQuery, and they can use a newer version of jQuery when it's available without having to wait for a new version of *every* webbrowsers. The web developer just needs to include the desired jQuery version in its web application and it's done. If jQuery would be part of the JS stack, then a web developer would never know wheter their clients use a browser that implements jQuery version X or Y. That stops innovation, and the very same for a "default rtcweb signaling protocol". >>> =C2=A0 o =C2=A0Downloading the complete RTCWeb signaling protocol Javas= cript is >>> =C2=A0 =C2=A0 =C2=A0inefficient as it impact performance and setup dela= y of real-time >>> =C2=A0 =C2=A0 =C2=A0communication. =C2=A0The caching of Javascript shal= l avoid downloading >>> =C2=A0 =C2=A0 =C2=A0the signaling protocol in each time RTCWeb server i= s accessed. >>> =C2=A0 =C2=A0 =C2=A0But the Javascript cache is possible to be removed = often which >>> =C2=A0 =C2=A0 =C2=A0leads to the impact. >> >>Ok, let me say something similar: >> >> =C2=A0 =C2=A0 =C2=A0Downloading the complete Gmail Javascript is >> =C2=A0 =C2=A0 =C2=A0inefficient as it impact performance and setup delay= of real-time >> =C2=A0 =C2=A0 =C2=A0communication. So we need to create a "standard webm= ail protocol" >> =C2=A0 =C2=A0 =C2=A0so Gmail, Hotmail, Yahoo and all the webmail provide= rs would use >> =C2=A0 =C2=A0 =C2=A0them and all the browsers would natively implement i= t. >> >> >>> =C2=A0 o =C2=A0Also, browser has to download each website signaling pro= tocol >>> =C2=A0 =C2=A0 =C2=A0indepentely >> >>Same as above. When you visit Gmail you download the complete JS code >>from Gmail. If later you visit Hotmail you download the complete JS >>code from Hotmail. That's how WWW works. Welcome. > > > There is no comparison between non-real time protocol and real-t= ime protocol. I agree that non-real time WWW works in this fashion which is= not appropriate for real-time application. Also, please note that number o= f e-mail provider to real-time application will be very different. Say I'll= provide RTCWeb application in my personal website for communicating with m= e in my mobile. =C2=A0 Open Gmail, open ebuddy.com, open Facebook, open any web page in which there is a *realtime* chat, and voil=C3=A1, you get a realtime protocol. Fortunately all these apps could use WebSocket soon rather than dealing with ugly HTTP long polling or HTTP Comet. In all those cases, the realtime protocol is implemented using a custom JavaScript code that the browser MUST download. The same when WebSocket arrives since WebSocket is just a transport protocol and it requires custom JavaScript code implementing a real protocol on top of it. Now a suggestion: instead of trying to propose a default rtcweb signaling protocol built-in the web browser, why don't you create a signaling protocol on top of WebSocket (for example using JSON messages exchange) and publish it? If for example such protocol or implementation has a bug, you can fix it by publishing a new version, and the web developers will just need to provide the new JavaScript file, rather than having to wait for *all* the web browsers in the world to fix the bug and *all* the humans in the world to upgrade their web browsers. Wouldn't that stop innovation?? Regards. --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Mon Oct 3 13: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 D5E9121F8E4E for ; Mon, 3 Oct 2011 13:29:24 -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 f8fX2+JKVv1H for ; Mon, 3 Oct 2011 13:29: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 DA74521F8E46 for ; Mon, 3 Oct 2011 13:29:23 -0700 (PDT) Received: by vws5 with SMTP id 5so4847513vws.31 for ; Mon, 03 Oct 2011 13:32:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.68.97 with SMTP id v1mr334324vdt.313.1317673946830; Mon, 03 Oct 2011 13:32:26 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Mon, 3 Oct 2011 13:32:26 -0700 (PDT) In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF510F137B@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> <2E239D6FCD033C4BAF15F386A979BF510F137B@sonusinmail02.sonusnet.com> Date: Mon, 3 Oct 2011 22:32:26 +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: Mon, 03 Oct 2011 20:29:24 -0000 2011/10/3 Ravindran Parthasarathi : > I agree to the fact that SCCP protocol is decided by Cisco folks but it d= oes not mean that every company in the world has to create their own versio= n of SCCP protocol and IETF should not force every company to re-invent the= wheel. I agree, but that's not mean that a default signaling protocol built-in the browser is required. Lot of people uses jQuery and nobody asks for it to be included in browsers JS stack natively. What you suggest can easily achieved with a JS library implementing your so much desired default signaling protocol. --=20 I=C3=B1aki Baz Castillo From s.choi@computer.or.kr Mon Oct 3 17:17: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 8FADD21F8CF7 for ; Mon, 3 Oct 2011 17:17:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.017 X-Spam-Level: X-Spam-Status: No, score=-1.017 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 lNEWipVGj7BH for ; Mon, 3 Oct 2011 17:17:36 -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 754E321F8C3C for ; Mon, 3 Oct 2011 17:17:05 -0700 (PDT) Received: by bkaq10 with SMTP id q10so6573093bka.31 for ; Mon, 03 Oct 2011 17:20:08 -0700 (PDT) Received: by 10.204.138.211 with SMTP id b19mr284637bku.257.1317687608224; Mon, 03 Oct 2011 17:20:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.41.202 with HTTP; Mon, 3 Oct 2011 17:19:48 -0700 (PDT) In-Reply-To: <4E89AB33.3050703@jesup.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> <4E79E698.2090905@jesup.org> <4E79EA16.7070909@freedesktop.org> <4E89AB33.3050703@jesup.org> From: Soo-Hyun Choi Date: Tue, 4 Oct 2011 09:19:48 +0900 Message-ID: To: Randell Jesup , Henrik Lundin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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, 04 Oct 2011 00:17:37 -0000 On Mon, Oct 3, 2011 at 21:31, Randell Jesup wrote: > > I suspect in practice you'll see (outgoing) a gap in received packets (de= lay > spike, while the radio in the handset changes access points), followed by > packets coming in at ever-increasing delays (because the packets already > queued to send are larger than will fit over the interface). =A0Incoming > packets will likewise have queued "somewhere" in the network - depending = on > the type of handover, you could have a burst of lost packets or a delay > spike, again (if over-bandwidth in that direction) followed by a series o= f > ever-increasing delays. > > In either case the signal (once transmission is re-established) should be > very clear, and the types of algorithms used in Google's draft should > quickly identify a strong "over-bandwidth" signal in the data. =A0Bufferb= loat > ironically may help in quickly identifying it, since you're less likely t= o > have a lot of losses following by down-ticks in delay. =A0(Though some of= the > plans I have to modify the algorithm to extend across all the media strea= ms > would probably deal with that as well.) > > So, all-in-all I think the receivers at either end will likely identify t= he > over-bandwidth condition within a small (4? 6? may depend on jitter) numb= er > of packets after an interface change. =A0Again, sharing the congestion co= ntrol > will help here (perhaps a lot) by putting all the datapoints into one > bucket, so the signal will stabilize much faster. I'd much appreciated if Google folks could present related data points similar to the cases that you mentioned, if they have. > > Ok, so once the sides have recognized the sudden over-bandwidth situation= , > how do we get out of it? =A0In AVPF we're likely able to send an RTCP mes= sage > anytime we want, so the receiver should be able to send an RTCP as soon a= s > possible. =A0We've already said we plan to use RFC 5506 to reduce sizes o= f > feed back messages, so that will keep the size smaller. =A0 It will be st= uck > behind any already-queued packets (hello, bufferbloat!) =A0but there's li= ttle > we can do about that. > > This RTCP feedback could of course be lost, and the CC algorithm should t= ake > that into account when it's trying to transmit a significant change in > bandwidth (at least a significant reduction) by sending updated feedback > messages frequently until stability has been achieved. Sure - any kind of Ack-based CC mechanisms are significantly influenced by the reliability of Ack flows. > > In some cases, if it's possible, it may be useful to know about a network > switchover and perhaps reduce outgoing and ask for a reduction in incomin= g > bandwidth to reduce the risk of a spike in delay over the switchover (at = the > cost of reduction in quality temporarily). > >> With ACK-clocked algorithms like TCP and TFWC the sender simply stops >> sending packets when ACK's are not received anymore. Receiver based algo= s >> are a bit more complicated as the risk is higher that the sender will >> continue to send packets for some time even though the channel throughpu= t >> has dropped considerably, resulting in excessive congestion somewhere al= ong >> the path. >> Is this a problem ?. I don't know, I guess time will tell. Ack-clock based CC algos are simpler to implement in real apps as it does not require a complicated non-linear computation in the algos. From pravindran@sonusnet.com Mon Oct 3 22:31: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 702DD21F8DE7 for ; Mon, 3 Oct 2011 22:31:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.351 X-Spam-Level: X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[AWL=-0.052, 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 A9RtJFF-JI36 for ; Mon, 3 Oct 2011 22:31:41 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 9D75E21F8E18 for ; Mon, 3 Oct 2011 22:31:41 -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 p945ZFVj017932; Tue, 4 Oct 2011 01:35:15 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail04.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 4 Oct 2011 01:34:38 -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, 4 Oct 2011 11:04:34 +0530 Message-ID: <2E239D6FCD033C4BAF15F386A979BF510F1392@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: AcyCC5O0D25GrXvHTleT4m7LMW7OkAAR+UDQ References: <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com><05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com><2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com><16880306-5B3A-4EFD-ADE4-1201138D9182@acmepacket.com><2E239D6FCD033C4BAF15F386A979BF510F137B@sonusinmail02.sonusnet.com> From: "Ravindran Parthasarathi" To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= X-OriginalArrivalTime: 04 Oct 2011 05:34:38.0051 (UTC) FILETIME=[4EAB3330:01CC8257] 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, 04 Oct 2011 05:31:42 -0000 SGkgSW5ha2ksDQoNCkhvcGUgeW91IGFncmVlIHRoYXQgUmVhbC10aW1lIGNvbW11bmljYXRpb24g aW4gd2ViIGlzIHBvc3NpYmxlIHdpdGhvdXQgUlRDV2ViIHN0YW5kYXJkIGFuZCBpdCBpcyBjbGVh cmx5IHN0YXRlZCBpbiBSVENXZWIgY2hhcnRlciBmaXJzdCBsaW5lIGFzIHdlbGwgIlRoZXJlIGFy ZSBhIG51bWJlciBvZiBwcm9wcmlldGFyeSBpbXBsZW1lbnRhdGlvbnMgdGhhdCBwcm92aWRlIGRp cmVjdA0KICBpbnRlcmFjdGl2ZSByaWNoIGNvbW11bmljYXRpb24gdXNpbmcgYXVkaW8sIHZpZGVv LCBjb2xsYWJvcmF0aW9uLA0KICBnYW1lcywgZXRjLiBiZXR3ZWVuIHR3byBwZWVycycgd2ViLWJy b3dzZXJzLiIuIEkgdW5kZXJzdGFuZCB0aGF0IGpxdWVyeSBvciBsaWJqaW5nbGUgbGlicmFyeSBt YXkgYWN0IGFzIGFuIGFsdGVybmF0aXZlIGJ1dCBpdCBpcyBmYXIgYmV0dGVyIGluIGNhc2Ugc2ln bmFsaW5nIHByb3RvY29sIGlzIHByb3ZpZGVkIGluIHRoZSBicm93c2VyIHBsYXRmb3JtIGl0c2Vs Zi4gDQoNCkFzIGEgUlRDd2ViIGRldmVsb3BlciwgdGhlIHN0YW5kYXJkIHNpZ25hbGluZyBwcm90 b2NvbCBoZWxwcyBhcyBmb2xsb3dzOg0KDQoxKSB0aGVyZSBpcyBubyBuZWVkIHRvIHBlZWsgaW50 byBlYWNoIGxpY2Vuc2Ugb2YganF1ZXJ5IGxpYnJhcnkgYW5kIHVuZGVyc3RhbmQgdGhlIHRlcm1z IGFuZCBjb25kaXRpb25zIGZvciBkZXZlbG9waW5nIHRoZSByZWFsLXRpbWUgYXBwbGljYXRpb24u DQoyKSBObyBuZWVkIG9mIGV2ZXJ5IGJyb3dzZXIgdXNlciB0byBkb3dubG9hZCBqcXVlcnkgbGli cmFyeSBmcm9tIGVhY2ggd2Vic2l0ZS4gVW5saWtlIGZldyBudW1iZXIgb2YgRS1tYWlsIHByb3Zp ZGVyIChnbWFpbCwgeWFob28sIGhvdG1haWwpLCB0aGUgcmVhbC10aW1lIGFwcGxpY2F0aW9uIHBy b3ZpZGVyIHdpbGwgYmUgaHVnZS4gQnV0IG51bWJlciBvZiBicm93c2VyIGlzIGdvaW5nIHRvIGJl IGNvdW50YWJsZSBhbmQgbm90IGFzIG11Y2ggYXMgcmVhbC10aW1lIHdlYnNpdGVzIGFyZS4NCjMp IEkgaGVhcmQgZnJvbSB3ZWIgZGV2ZWxvcGVyIGFib3V0IGJyb3dzZXIgY29tcGF0aWJsZSBqcXVl cnkgZGV2ZWxvcG1lbnQgc3Rvcnkgd2hpY2ggaXMgc2FtZSBhcyBTSVAgaW50ZXJvcCBpc3N1ZXMu IA0KNCkgUGVyZm9ybSBvZiB0aGUgbmF0aXZlIHNpZ25hbGluZyBwcm90b2NvbCB3aWxsIGJlIGJl dHRlciB0aGFuIGpxdWVyeSBsaWJyYXJ5LiBQbGVhc2Ugbm90ZSB0aGF0IHBsdWdpbiBpcyBmb3Ji aWRkZW4gaW4gUlRDV2ViIGNsaWVudCAoYnJvd3NlcikuDQoNCklNTywgSnF1ZXJ5IHdpbGwgbm90 IHNvbHZlIHRoZSBpbmRlbnRlZCBwcm9ibGVtLiAgDQoNClRoZSBtYWluIG1vdGl2ZSBmb3IgUlRD V2ViIHN0YW5kYXJkIHNpZ25hbGluZyBpcyByYXBpZCByZWFsLXRpbWUgYXBwbGljYXRpb24gaW4g YnJvd3NlciBwbGF0Zm9ybSBieSBhbnkgd2ViIGRldmVsb3BlciBhbmQgdGhlcmUgc2hvdWxkIGJl IG5vIG5lZWQgb2Ygc2lnbmFsaW5nIGV4cGVydCBpbiBlYWNoIHdlYnNpdGUgZGV2ZWxvcG1lbnQg dGVhbS4gDQoNClRoYW5rcw0KUGFydGhhDQoNCg0KDQo+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj5Gcm9tOiBJw7Fha2kgQmF6IENhc3RpbGxvIFttYWlsdG86aWJjQGFsaWF4Lm5ldF0NCj5T ZW50OiBUdWVzZGF5LCBPY3RvYmVyIDA0LCAyMDExIDI6MDIgQU0NCj5UbzogUmF2aW5kcmFuIFBh cnRoYXNhcmF0aGkNCj5DYzogSGFkcmllbCBLYXBsYW47IHJ0Y3dlYkBpZXRmLm9yZw0KPlN1Ympl Y3Q6IFJlOiBbcnRjd2ViXSBSVENXZWIgZGVmYXVsdCBzaWduYWxpbmcgcHJvdG9jb2wgW3dhcyBS RTogQWJvdXQNCj5kZWZpbmluZyBhIHNpZ25hbGluZyBwcm90b2NvbCBmb3IgV2ViUlRDIChvciBu b3QpXQ0KPg0KPjIwMTEvMTAvMyBSYXZpbmRyYW4gUGFydGhhc2FyYXRoaSA8cHJhdmluZHJhbkBz b251c25ldC5jb20+Og0KPj4gSSBhZ3JlZSB0byB0aGUgZmFjdCB0aGF0IFNDQ1AgcHJvdG9jb2wg aXMgZGVjaWRlZCBieSBDaXNjbyBmb2xrcyBidXQNCj5pdCBkb2VzIG5vdCBtZWFuIHRoYXQgZXZl cnkgY29tcGFueSBpbiB0aGUgd29ybGQgaGFzIHRvIGNyZWF0ZSB0aGVpciBvd24NCj52ZXJzaW9u IG9mIFNDQ1AgcHJvdG9jb2wgYW5kIElFVEYgc2hvdWxkIG5vdCBmb3JjZSBldmVyeSBjb21wYW55 IHRvIHJlLQ0KPmludmVudCB0aGUgd2hlZWwuDQo+DQo+SSBhZ3JlZSwgYnV0IHRoYXQncyBub3Qg bWVhbiB0aGF0IGEgZGVmYXVsdCBzaWduYWxpbmcgcHJvdG9jb2wNCj5idWlsdC1pbiB0aGUgYnJv d3NlciBpcyByZXF1aXJlZC4gTG90IG9mIHBlb3BsZSB1c2VzIGpRdWVyeSBhbmQgbm9ib2R5DQo+ YXNrcyBmb3IgaXQgdG8gYmUgaW5jbHVkZWQgaW4gYnJvd3NlcnMgSlMgc3RhY2sgbmF0aXZlbHku DQo+DQo+V2hhdCB5b3Ugc3VnZ2VzdCBjYW4gZWFzaWx5IGFjaGlldmVkIHdpdGggYSBKUyBsaWJy YXJ5IGltcGxlbWVudGluZw0KPnlvdXIgc28gbXVjaCBkZXNpcmVkIGRlZmF1bHQgc2lnbmFsaW5n IHByb3RvY29sLg0KPg0KPg0KPg0KPi0tDQo+ScOxYWtpIEJheiBDYXN0aWxsbw0KPjxpYmNAYWxp YXgubmV0Pg0K From saul@ag-projects.com Mon Oct 3 23:58: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 5D5C421F8CF9 for ; Mon, 3 Oct 2011 23:58:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.703 X-Spam-Level: X-Spam-Status: No, score=-1.703 tagged_above=-999 required=5 tests=[AWL=-0.015, 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 AmTQUKqUVO3M for ; Mon, 3 Oct 2011 23:58:33 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id A01F521F8CD6 for ; Mon, 3 Oct 2011 23:58:32 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 4017EB01B7; Tue, 4 Oct 2011 09:01:36 +0200 (CEST) Received: from [192.168.99.36] (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id 66E18B019A; Tue, 4 Oct 2011 09:01:35 +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: <2E239D6FCD033C4BAF15F386A979BF510F1392@sonusinmail02.sonusnet.com> Date: Tue, 4 Oct 2011 09:01:34 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <202AF153-5B5E-40B8-A31A-C9DD95AA09C5@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><2E239D6FCD033C4BAF15F386A979BF510F137B@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF510F1392@sonusinmail02.sonusnet.com> To: Ravindran Parthasarathi 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: Tue, 04 Oct 2011 06:58:34 -0000 Hi, On Oct 4, 2011, at 7:34 AM, Ravindran Parthasarathi wrote: > Hi Inaki, >=20 > Hope you agree that Real-time communication in web is possible without = RTCWeb standard and it is clearly stated in RTCWeb charter first line as = well "There are a number of proprietary implementations that provide = direct > interactive rich communication using audio, video, collaboration, > games, etc. between two peers' web-browsers.". I understand that = jquery or libjingle library may act as an alternative but it is far = better in case signaling protocol is provided in the browser platform = itself.=20 >=20 > As a RTCweb developer, the standard signaling protocol helps as = follows: >=20 > 1) there is no need to peek into each license of jquery library and = understand the terms and conditions for developing the real-time = application. This is something you always need to do regardless of the project IMHO, = you need to check that all libraries you use are fine with your license = ASO, I don't see how RTCWeb is different here. > 2) No need of every browser user to download jquery library from each = website. Unlike few number of E-mail provider (gmail, yahoo, hotmail), = the real-time application provider will be huge. But number of browser = is going to be countable and not as much as real-time websites are. What is "huge" for you these days? Assuming it's a JS library, it can be = compressed. > 3) I heard from web developer about browser compatible jquery = development story which is same as SIP interop issues.=20 Yet you are bringing a new iterop issue to the table: SIP or XMPP <-> = the protocol in the browsers. > 4) Perform of the native signaling protocol will be better than jquery = library. Please note that plugin is forbidden in RTCWeb client = (browser). >=20 Well, it's a client, not a server, so performance will definitely not be = an issue. I didn't get that last part, do you mean that plugins are forbidden in = RTCWeb client? Anyway, JS is enough. I'm not sure about Googles' plans = with regards to NaCl, but if they plan to push that technology forward = so that other browsers implement it, the signaling could even be done in = C, in case you are worried about performance, though I know it's not an = issue. Regards, -- Sa=FAl Ibarra Corretg=E9 AG Projects From saul@ag-projects.com Tue Oct 4 00:21: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 C379021F8B8D for ; Tue, 4 Oct 2011 00:21:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.703 X-Spam-Level: X-Spam-Status: No, score=-1.703 tagged_above=-999 required=5 tests=[AWL=-0.015, 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 nb4iG3HU7L03 for ; Tue, 4 Oct 2011 00:21:21 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id DE50621F8B8B for ; Tue, 4 Oct 2011 00:21:20 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 688B9B01B8; Tue, 4 Oct 2011 09:24:24 +0200 (CEST) Received: from [192.168.99.36] (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id A14A9B019A; Tue, 4 Oct 2011 09:24:11 +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: <2E239D6FCD033C4BAF15F386A979BF510F1367@sonusinmail02.sonusnet.com> Date: Tue, 4 Oct 2011 09:24:10 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2E239D6FCD033C4BAF15F386A979BF510F1367@sonusinmail02.sonusnet.com> To: Ravindran Parthasarathi X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Review request for RTCWeb standard 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: Tue, 04 Oct 2011 07:21:22 -0000 Hi, Here are some comments after the first read: "There are lots of issues in Javascript based signaling protocol." What issues? Do you have an implementation to sustain that statement? "Architecture" I guess you noticed that the architecture graph in your draft is = exactly the SIP trapezoid. But we can't make everyone happy, XMPP guys = will want to use XMPP and SIP guys will want to use SIP, there is no = need to force people to use either, or any other. "Without RTCWeb standard signaling protocol, each website developer has to understand the complication of signaling protocol for making the real-time communication." With libraries like jQuery one doesn't need to know about xmlhttprequest = anymore, so I'd say the same would be true for any signaling sibrary = developed by a thirst party. It could expose a simple API for other = developers to use, but of course, the one building the library itself = *has* to know about the protocol. "Also, browser has to download each website signaling protocol indepentely" Of course, same as with any other JS library or plugin. Why do you see a = difference between the signaling protocol for RTCweb and everything = else? Overall, I didn't see any key points for the need of a default signaling = protocol. I wouldn't agree with it even if you advocated for SIP, this = should be up to the developer. Regards, -- Sa=FAl Ibarra Corretg=E9 AG Projects From harald@alvestrand.no Tue Oct 4 01: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 341D121F8D2B for ; Tue, 4 Oct 2011 01:18:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.204 X-Spam-Level: X-Spam-Status: No, score=-108.204 tagged_above=-999 required=5 tests=[AWL=2.394, 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 ze9ldBodIrxX for ; Tue, 4 Oct 2011 01:18:54 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 095D421F8CF6 for ; Tue, 4 Oct 2011 01:18:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id AD52039E132 for ; Tue, 4 Oct 2011 10:21:57 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BJU477IisJxA for ; Tue, 4 Oct 2011 10:21:56 +0200 (CEST) Received: from [172.16.41.139] (unknown [74.125.121.33]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 03F9939E048 for ; Tue, 4 Oct 2011 10:21:55 +0200 (CEST) Message-ID: <4E8AC222.4050308@alvestrand.no> Date: Tue, 04 Oct 2011 10:21:54 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: rtcweb@ietf.org References: <2E239D6FCD033C4BAF15F386A979BF510F1367@sonusinmail02.sonusnet.com> In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF510F1367@sonusinmail02.sonusnet.com> Content-Type: multipart/alternative; boundary="------------010006050504020305060001" Subject: Re: [rtcweb] Review request for RTCWeb standard 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: Tue, 04 Oct 2011 08:18:55 -0000 This is a multi-part message in MIME format. --------------010006050504020305060001 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Ravindran, the core part of your document seems to me to be this list: The following Signaling protocols will qualify for becoming standard RTCWeb signaling protocol 1. Jingle 2. Websocket with SDP offer/answer 3. SIP 4. SIPLite [I-D.cbran-rtcweb-protocols ] 5. Websocket with custom XML 6. Megaco [RFC5125 ] 7. Websocket with SIP [I-D.ibc-rtcweb-sip-websocket ] 8. HTTP with custom XML 9. ??? TBD: Pros and cons for each of the signaling mechanism has to be added My reading of your document is that you want the RTCWEB working group to pick exactly one of these alternatives, and insist that all conformant implementations of RTCWEB support this protocol. I disagree with: a) that this is needed b) that this is a good idea The reasons why it is not a good idea have been raised multiple times, and spending continued effort on trying to debate which of the alternatives you list above is "the best one" is distracting to our purpose of getting the RTCWEB protocol suite done. I do not support pursuing your suggested direction of work in this working group. Harald On 10/03/2011 04:41 PM, Ravindran Parthasarathi wrote: > Hi all, > > RTCWeb standard signaling protocol (http://tools.ietf.org/html/draft-partha-rtcweb-signaling-00) draft list the need for standard signaling protocol between RTCWeb client (browser) and RTCWeb server and the possible signaling protocol for the same. This draft is written based on http://www.ietf.org/mail-archive/web/rtcweb/current/msg01172.html mail thread discussion. Could you please provide your valuable comments. > > Thanks > Partha > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Monday, October 03, 2011 7:56 PM > To: Ravindran Parthasarathi > Cc: Ravindran Parthasarathi > Subject: New Version Notification for draft-partha-rtcweb-signaling-00.txt > > A new version of I-D, draft-partha-rtcweb-signaling-00.txt has been successfully submitted by Parthasarathi Ravindran and posted to the IETF repository. > > Filename: draft-partha-rtcweb-signaling > Revision: 00 > Title: RTCWeb standard signaling protocol > Creation date: 2011-10-03 > WG ID: Individual Submission > Number of pages: 8 > > Abstract: > The standardization of Real time communication between browsers is to > provide the infrastructure for audio, video, text communication using > standard interface so that interoperable communication can be > established between any compatible browsers. RTCWeb specific > Javascript API will be provided by browsers for developing real-time > web application. It is possible to develop signaling protocol like > Session Initiation Protocol (SIP) or Jingle or websocket extension or > custom-made signaling protocol in Javascript. There are lots of > issues in Javascript based signaling protocol. This document list > the need for standard signaling protocol between RTCWeb client > (browser) and RTCWeb server and possible signaling protocol for the > same. > > > > > The IETF Secretariat > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --------------010006050504020305060001 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Ravindran,

the core part of your document seems to me to be this list:

   The following Signaling protocols will qualify for becoming standard
   RTCWeb signaling protocol

   1.  Jingle
   2.  Websocket with SDP offer/answer
   3.  SIP
   4.  SIPLite [I-D.cbran-rtcweb-protocols]
   5.  Websocket with custom XML
   6.  Megaco [RFC5125]
   7.  Websocket with SIP [I-D.ibc-rtcweb-sip-websocket]
   8.  HTTP with custom XML
   9.  ???

   TBD: Pros and cons for each of the signaling mechanism has to be
   added

My reading of your document is that you want the RTCWEB working group to pick exactly one of these alternatives, and insist that all conformant implementations of RTCWEB support this protocol.

I disagree with:

a) that this is needed
b) that this is a good idea

The reasons why it is not a good idea have been raised multiple times, and spending continued effort on trying to debate which of the alternatives you list above is "the best one" is distracting to our purpose of getting the RTCWEB protocol suite done.

I do not support pursuing your suggested direction of work in this working group.

                     Harald





On 10/03/2011 04:41 PM, Ravindran Parthasarathi wrote: 
Hi all,

RTCWeb standard signaling protocol (http://tools.ietf.org/html/draft-partha-rtcweb-signaling-00) draft list the need for standard signaling protocol between RTCWeb client (browser) and RTCWeb server and the possible signaling protocol for the same. This draft is written based on http://www.ietf.org/mail-archive/web/rtcweb/current/msg01172.html mail thread discussion. Could you please provide your valuable comments.

Thanks
Partha

-----Original Message-----
From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] 
Sent: Monday, October 03, 2011 7:56 PM
To: Ravindran Parthasarathi
Cc: Ravindran Parthasarathi
Subject: New Version Notification for draft-partha-rtcweb-signaling-00.txt

A new version of I-D, draft-partha-rtcweb-signaling-00.txt has been successfully submitted by Parthasarathi Ravindran and posted to the IETF repository.

Filename:	 draft-partha-rtcweb-signaling
Revision:	 00
Title:		 RTCWeb standard signaling protocol
Creation date:	 2011-10-03
WG ID:		 Individual Submission
Number of pages: 8

Abstract:
   The standardization of Real time communication between browsers is to
   provide the infrastructure for audio, video, text communication using
   standard interface so that interoperable communication can be
   established between any compatible browsers.  RTCWeb specific
   Javascript API will be provided by browsers for developing real-time
   web application.  It is possible to develop signaling protocol like
   Session Initiation Protocol (SIP) or Jingle or websocket extension or
   custom-made signaling protocol in Javascript.  There are lots of
   issues in Javascript based signaling protocol.  This document list
   the need for standard signaling protocol between RTCWeb client
   (browser) and RTCWeb server and possible signaling protocol for the
   same.

                                                                                  


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

--------------010006050504020305060001-- From tim@phonefromhere.com Tue Oct 4 02:13: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 ACC1921F8C53 for ; Tue, 4 Oct 2011 02:13:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.546 X-Spam-Level: X-Spam-Status: No, score=-2.546 tagged_above=-999 required=5 tests=[AWL=0.053, 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 8MuNp55leRRc for ; Tue, 4 Oct 2011 02:13: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 9E3BA21F8C52 for ; Tue, 4 Oct 2011 02:13:42 -0700 (PDT) Received: from [192.168.0.14] (unknown [93.89.81.113]) by zimbra.westhawk.co.uk (Postfix) with ESMTP id BB31337A903; Tue, 4 Oct 2011 10:29:29 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Tim Panton In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF510F137B@sonusinmail02.sonusnet.com> Date: Tue, 4 Oct 2011 10:16:26 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <226C9800-9791-465A-B519-40935E2D135F@phonefromhere.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> <2E239D6FCD033C4BAF15F386A979BF510F137B@sonusinmail02.sonusnet.com> To: Ravindran Parthasarathi 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: Tue, 04 Oct 2011 09:13:43 -0000 On 3 Oct 2011, at 19:24, Ravindran Parthasarathi wrote: > Hadriel, >=20 > Sorry for the delay response. I have mentioned the reason for = "standard signaling protocol" as a separate draft and the related thread = is http://www.ietf.org/mail-archive/web/rtcweb/current/msg01733.html.=20 >=20 > I agree to the fact that SCCP protocol is decided by Cisco folks but = it does not mean that every company in the world has to create their own = version of SCCP protocol and IETF should not force every company to = re-invent the wheel. >=20 > The intention of standard signaling protocol is not against those who = have the interest in creating their own proprietary signaling protocol. = The main purpose is for the welfare of those whose focus is not = signaling but interested in Real-time communication. JavaScript library = by third party is worst case in case there is no native standard = signaling protocol exists for RTCWeb. >=20 > Let us discuss how much services has to be provided by standard = signaling protocol. >=20 > Thanks > Partha Partha - here's a quick review of = http://tools.ietf.org/html/draft-partha-rtcweb-signaling-00 I'm not going to go through it line by line as I disagree with almost = all of it, so I focus on 2 key assumptions: Firstly ->=20 Fig 1 is wrong - in the _huge_ majority of instances there will be only one web server in such a diagram. Federated services will only be = the minority case. Where services do interconnect, they will (As in the SIP and PSTN world = today) go through=20 policy gateways which will manage tariffs and dataflow into and out of = the service. So there should be either 1 web server or 2 webservers and 2 policy = gateways. If you correct this diagram the rest of the document is invalidated. Secondly -> You assume that being compatible with a legacy protocol would be a good = thing,=20 but don't examine why.=20 I contend that there is no suitable legacy protocol and no advantage = would be conveyed by=20 implementing one directly in a browser. I'll use SIP to illustrate my = point: The illusion is that there are lots of SIP devices that users are = itching to call from their browsers. There aren't. Almost all the SIP devices in the world are = behind policy firewalls and are not directly accessible from a browser based SIP implementation. Even if they were reachable, our experience of browser based realtime = audio (at phonefromhere.com) shows that people don't use the browser to call = PSTN-like endpoints. If they want a PSTN experience, they pick up one of the 3+ = phones available to them.=20 (What they do use browser based realtime audio for is dating, conference = calls, collaboration etc) Even if all the SIP devices were reachable and people wanted to reach = them,=20 we still should not be using that as the core case to base the webRTC = spec upon. There are (I guess) already more users of the facebook site than there = are SIP devices. Conclusion ->=20 So we should focus upon the most common use-case and not get distracted = into discussing=20 what is at best an edge case. The risk of such a discussion (of a standard signalling protocol) is = that we will still be discussing it in 3=20 years time and each of the browser makers will have implemented their = own subtly different webRTC solutions. Tim, speaking for himself, but based on bitter experience at = phonefromhere.com From Markus.Isomaki@nokia.com Tue Oct 4 02:52: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 9776821F8C5A for ; Tue, 4 Oct 2011 02:52:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.766 X-Spam-Level: X-Spam-Status: No, score=-2.766 tagged_above=-999 required=5 tests=[AWL=-0.166, 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 T3FQK2UvfMfr for ; Tue, 4 Oct 2011 02:52:56 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id E33A321F8C57 for ; Tue, 4 Oct 2011 02:52:55 -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 p949tYOB010287; Tue, 4 Oct 2011 12:55:57 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 4 Oct 2011 12:55:31 +0300 Received: from 008-AM1MMR1-006.mgdnok.nokia.com (65.54.30.61) by NOK-am1MHUB-01.mgdnok.nokia.com (65.54.30.5) with Microsoft SMTP Server (TLS) id 8.2.255.0; Tue, 4 Oct 2011 11:53:55 +0200 Received: from 008-AM1MPN1-043.mgdnok.nokia.com ([169.254.3.167]) by 008-AM1MMR1-006.mgdnok.nokia.com ([65.54.30.61]) with mapi id 14.01.0339.002; Tue, 4 Oct 2011 11:53:55 +0200 From: To: Thread-Topic: [rtcweb] Future requirement: RTC-Web apps must work through interface switching Thread-Index: AcyBw8LOCbj0Q27JT3eGKgpYq050b///5dcA//56Y7A= Date: Tue, 4 Oct 2011 09:53: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: [172.21.75.37] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 04 Oct 2011 09:55:31.0301 (UTC) FILETIME=[C0BB9950:01CC827B] X-Nokia-AV: Clean Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Future requirement: RTC-Web apps must work through interface switching X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 09:52:56 -0000 SGksIA0KDQpJw7Fha2kgQmF6IENhc3RpbGxvIHdyb3RlOg0KPg0KPkluIFdlYlNvY2tldCBhIGRp c2Nvbm5lY3QoKSBldmVudCB3aWxsIGJlIGNhbGxlZCBieSBKUyBBUEkgaWYgdGhlIGNvbm5lY3Rp b24gaXMNCj50ZXJtaW5hdGVkICh0aGlzIGNhbiBvY2N1ciB3aGVuIHRoZSBzZXJ2ZXIgZXhwbGlj aXR5IHRlcm1pbmF0ZXMgdGhlDQo+Y29ubmVjdGlvbiBvciB3aGVuIHRoZSBXZWJTb2NrZXQgY2xp ZW50IHRyaWVzIHRvIHNlbmQgYSBtZXNzYWdlIG92ZXIgdGhlDQo+V2ViU29ja2V0IGNvbm5lY3Rp b24gYW5kIGdldHMgYW4gZXJyb3IgYmVjYXVzZSB0aGUgY29ubmVjdGlvbiAiZG9lcyBub3QNCj53 b3JrIGFueW1vcmUiKS4gRm9yIHRoZSBsYXN0IGNhc2UsIGEgcGluZ2luZyBtZWNoYW5pc20gZnJv bSB0aGUgY2xpZW50IGlzIGENCj5nb29kIGNob2ljZS4NCj4NCg0KSXMgaXQgcG9zc2libGUgZm9y IHRoZSBicm93c2VyIHRvIGNhbGwgZGlzY29ubmVjdCgpIGFsc28gZm9yIG1vcmUgZXhwbGljaXQg cmVhc29ucywgc3VjaCB0aGF0IGl0IGhhcyBpdHNlbGYgbGVhcm5lZCB0aGF0IHRoZSBjdXJyZW50 IGludGVyZmFjZS9zb2NrZXQgaGFzIGJlY29tZSBkaXNjb25uZWN0ZWQ/IFRoaXMgd2F5IHRoZSBK UyBhcHBsaWNhdGlvbiB3b3VsZCBnZXQgdGhlIHNpZ25hbCBpbW1lZGlhdGVseSByYXRoZXIgdGhh biBoYXZpbmcgdG8gd2FpdCBmb3IgdGhlIG5leHQgcGluZy4gSW4gdGhhdCBjYXNlIHRoaXMgc2hv dWxkIGJlIE9LLiBUaGUgZGlzY29ubmVjdCgpIGZ1bmN0aW9uIHNob3VsZCB0aGVuIGhhdmUgdGhl IGNvZGUgZm9yIHJlLWNyZWF0aW5nIHRoZSB3ZWJzb2NrZXQgY29ubmVjdGlvbiwgdGhpcyB0aW1l IG92ZXIgdGhlIG5ldyAoZGVmYXVsdCkgaW50ZXJmYWNlLCBhbmQgcmVjcmVhdGluZyB0aGUgbmVj ZXNzYXJ5IHN0YXRlIG9uIHRvcCBvZiBpdCBpbiB0aGUgYXBwbGljYXRpb24gbGV2ZWwuIFRoaXMg d291bGQgY3JlYXRlIGEgZmV3IHNlY29uZHMgb2YgZGlzY29ubmVjdCBiZXR3ZWVuIHRoZSBjbGll bnQgYW5kIHRoZSBzZXJ2ZXIsIHdoaWNoIG1pZ2h0IGJlIE9LIGZvciBtb3N0IGFwcHMuIFBlcmZl Y3QgaGFuZGxpbmcgb2YgdGhpcyBjYXNlLCBpLmUuIGJlaW5nIGFibGUgdG8gb3BlbiB0aGUgbmV3 IGNvbm5lY3Rpb24gYmVmb3JlIHRoZSBvbGQgb25lIGlzIGxvc3QsIHdvdWxkIHByb2JhYmx5IHJl cXVpcmUgY2hhbmdlcyBpbiB0aGUgV2Vic29ja2V0IEFQSS4gT3IsIHVzZSBvZiBNUFRDUC4NCg0K TWFya3VzDQo= From Markus.Isomaki@nokia.com Tue Oct 4 03:08: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 2FDD521F8C72 for ; Tue, 4 Oct 2011 03:08:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.724 X-Spam-Level: X-Spam-Status: No, score=-2.724 tagged_above=-999 required=5 tests=[AWL=-0.125, 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 q6aJwrRz3wj2 for ; Tue, 4 Oct 2011 03:08:22 -0700 (PDT) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id 6004C21F8C4E for ; Tue, 4 Oct 2011 03:08:21 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-sa02.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p94AB5OD024600; Tue, 4 Oct 2011 13:11:24 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 4 Oct 2011 13:11:01 +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; Tue, 4 Oct 2011 12:11:00 +0200 Received: from 008-AM1MPN1-043.mgdnok.nokia.com ([169.254.3.167]) by 008-AM1MMR1-002.mgdnok.nokia.com ([65.54.30.57]) with mapi id 14.01.0339.002; Tue, 4 Oct 2011 12:11:00 +0200 From: To: Thread-Topic: [rtcweb] Future requirement: RTC-Web apps must work through interface switching Thread-Index: AcyBw8LOCbj0Q27JT3eGKgpYq050bwAAKV6AAAUGtUD//+VQgP/+nwAg Date: Tue, 4 Oct 2011 10:10:59 +0000 Message-ID: References: <4E89C099.3000709@alvestrand.no> <4E89CBF1.8050207@alvestrand.no> In-Reply-To: <4E89CBF1.8050207@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.21.75.37] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 04 Oct 2011 10:11:01.0459 (UTC) FILETIME=[EB267230:01CC827D] X-Nokia-AV: Clean Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Future requirement: RTC-Web apps must work through interface switching X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 10:08:23 -0000 Hi Harald, I have a few additional questions to make sure this can work. >Section 9 of RFC 5245 is the procedure for adding more candidates during t= he >call. >It supports make-before-break: > >9.1.1.1. ICE Restarts > > An agent MAY restart ICE processing for an existing media stream. An > ICE restart, as the name implies, will cause all previous states of > ICE processing to be flushed and checks to start anew. The only > difference between an ICE restart and a brand new media session is > that, during the restart, media can continue to be sent to the > previously validated pair. > This seems to be the right mechanism. But this has to be triggered at any t= ime when a new interface becomes available. For instance, when the device e= nters Wi-Fi coverage and is able to connect to the Wi-Fi network. The brows= er itself can clearly learn about this through some OS/platform specific AP= Is. So, if it is the browser who is responsible for sending the new offer, = it can do it. If it is the JS application, it would need some event that it= knows it should do so.=20 Is it then so that the STUN connectivity checks are run for the new candida= tes as soon as they are added? And if we want to be able to use the new can= didates immediately after the old IP/interface has become disconnected, bot= h ends will have to keep the NAT/FW state alive for these candidates as lon= g as they are in the latest offer? Finally, how does the other peer (who's own connectivity has not changed) k= now when to start using a new candidate pair? Is it after it starts receivi= ng packets from the other end over that candiate pair? Or is it based on so= me ICMP error?=20 Since media is potentially end-to-end even between service providers, we wi= ll have to be careful that things work between two pairs. Including pairs t= hat are e.g. SBC's implementing ICE. Markus=20 From ibc@aliax.net Tue Oct 4 03: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 35C6721F8C92 for ; Tue, 4 Oct 2011 03:14:53 -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.041, 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 VyCvZ2RrRIVD for ; Tue, 4 Oct 2011 03:14:52 -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 B907621F8C8D for ; Tue, 4 Oct 2011 03:14:51 -0700 (PDT) Received: by vws5 with SMTP id 5so266520vws.31 for ; Tue, 04 Oct 2011 03:17:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.23.4 with SMTP id i4mr892662vdf.514.1317723476219; Tue, 04 Oct 2011 03:17:56 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Tue, 4 Oct 2011 03:17:56 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Tue, 4 Oct 2011 03:17:56 -0700 (PDT) Date: Tue, 4 Oct 2011 12:17:56 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Ravindran Parthasarathi Content-Type: multipart/alternative; boundary=20cf307ca582b658b804ae766797 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, 04 Oct 2011 10:14:53 -0000 --20cf307ca582b658b804ae766797 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 2011/10/4 Ravindran Parthasarathi : > I understand that jquery or libjingle library may act as an alternative but it is far better in case signaling protocol is provided in the browser platform itself. I've never said that jQuery is an alternative for rtcweb, where/when did I say that? jQuery is a JS library for easy management of the page DOM and some JS effects. > As a RTCweb developer, the standard signaling protocol helps as follows: > > 1) there is no need to peek into each license of jquery library and understand the terms and conditions for developing the real-time application. Not a good argument IMHO. > 2) No need of every browser user to download jquery library from each website. Unlike few number of E-mail provider (gmail, yahoo, hotmail), the real-time application provider will be huge. But number of browser is going to be countable and not as much as real-time websites are. Will you ignore my arguments again and again?? What about all my text explaining that a native signaling protocol built-in the browsers means tha= t for fixing any bug all the browsers in the world must be fixed and all the humans in the world must update their browsers?? could you please NOT ignor= e this argument again and just reply to it? Also, you say "No need of every browser user to download jquery library fro= m each website". As said above jQuery is not about rtcweb but about pure JavaScript and HTML/DOM (maybe in a future it includes a signaling protocol for rtcweb, who knows...). But for your information, today *every browsers* download jQuery library from each website including it, everyday, and that is NOT a problem (regardless how much you insist on that as if it was a problem). It's NOT a problem, it's an advantage as each web developer can include the version of jQuery he desires for his application, and update it when needed without requiring a new version of Firefox or Chrome in all the web visitors! Is it so hard to understand this Ravindran? Will you reply something interesting to this? or just "no need of every browser to downloa= d the javascript library"? > 3) I heard from web developer about browser compatible jquery development story which is same as SIP interop issues. Press F5 or Ctrl+R and you get a new version of jQuery (if the web develope= r included it). But if the bug is in the web browser (as in the *native* signaling stack you propose) then the user must update his web browser. Please, DON'T ignore this argument again. > 4) Perform of the native signaling protocol will be better than jquery library. Please note that plugin is forbidden in RTCWeb client (browser). You should demostrate that a signaling protocol in JavaScript is a bad idea rather than speaking about performance issues with no real tests and code. = I have *real* JS code implementing signaling and there is no performance issues at all. JavaScript is very optimized in most of the browsers. > IMO, Jquery will not solve the indented problem. Of course not! jQuery is not a rtcweb signaling protocol! I just put jQuery as a real example of a very extended JS library that lot of web sites include and millons of web browsers download every day (without that being = a problem as you insist). > The main motive for RTCWeb standard signaling is rapid real-time application in browser platform by any web developer and there should be no need of signaling expert in each website development team. Again: any good and extended JavaScript library will do the same by hidding signaling complexity to the web developer. No need for forcing browsers vendor to include,mantain and upgrade a native signaling protocol. Anyhow, IMHO this discussion is a no-go. --=20 I=C3=B1aki Baz Castillo --20cf307ca582b658b804ae766797 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

2011/10/4 Ravindran Parthasarathi <pravindran@sonusnet.com>:
> =C2=A0I understand that jquery or libjingle library may act as an alte= rnative but it is far better in case signaling protocol is provided in the = browser platform itself.

I've never said that jQuery is an alternative for rtcweb, where/when= did I say that?
jQuery is a JS library for easy management of the page DOM and some JS effe= cts.

> As a RTCweb developer, the standard signaling protocol helps as fol= lows:
>
> 1) there is no need to peek into each license of jquery library and un= derstand the terms and conditions for developing the real-time application.=

Not a good argument IMHO.

> 2) No need of every browser user to download jquery library from ea= ch website. Unlike few number of E-mail provider (gmail, yahoo, hotmail), t= he real-time application provider will be huge. But number of browser is go= ing to be countable and not as much as real-time websites are.

Will you ignore my arguments again and again?? What about all my text ex= plaining that a native signaling protocol built-in the browsers means that = for fixing any bug all the browsers in the world must be fixed and all the = humans in the world must update their browsers?? could you please NOT ignor= e this argument again and just reply to it?

Also, you say "No need of every browser user to download jquery lib= rary from each website". As said above jQuery is not about rtcweb but = about pure JavaScript and HTML/DOM (maybe in a future it includes a signali= ng protocol for rtcweb, who knows...). But for your information, today *eve= ry browsers* download jQuery library from each website including it, everyd= ay, and that is NOT a problem (regardless how much you insist on that as if= it was a problem). It's NOT a problem, it's an advantage as each w= eb developer can include the version of jQuery he desires for his applicati= on, and update it when needed without requiring a new version of Firefox or= Chrome in all the web visitors! Is it so hard to understand this Ravindran= ? Will you reply something interesting to this? or just "no need of ev= ery browser to download the javascript library"?


> 3) I heard from web developer about browser compatible jquery devel= opment story which is same as SIP interop issues.

Press F5 or Ctrl+R and you get a new version of jQuery (if the web devel= oper included it). But if the bug is in the web browser (as in the *native*= signaling stack you propose) then the user must update his web browser.

Please, DON'T ignore this argument again.

> 4) Perform of the native signaling protocol will be better than jqu= ery library. Please note that plugin is forbidden in RTCWeb client (browser= ).

You should demostrate that a signaling protocol in JavaScript is a bad i= dea rather than speaking about performance issues with no real tests and co= de. I have *real* JS code implementing signaling and there is no performanc= e issues at all. JavaScript is very optimized in most of the browsers.

> IMO, Jquery will not solve the indented problem.

Of course not! jQuery is not a rtcweb signaling protocol! I just put jQu= ery as a real example of a very extended JS library that lot of web sites i= nclude and millons of web browsers download every day (without that being a= problem as you insist).

> The main motive for RTCWeb standard signaling is rapid real-time ap= plication in browser platform by any web developer and there should be no n= eed of signaling expert in each website development team.

Again: any good and extended JavaScript library will do the same by hidd= ing signaling complexity to the web developer. No need for forcing browsers= vendor to include,mantain and upgrade a native signaling protocol.

Anyhow, IMHO this discussion is a no-go.

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

--20cf307ca582b658b804ae766797-- From internet-drafts@ietf.org Tue Oct 4 06:06: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 618CC21F8CAA; Tue, 4 Oct 2011 06:06:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.586 X-Spam-Level: X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=0.013, 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 GpVmwKeWzko5; Tue, 4 Oct 2011 06:06:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCB1921F8CA7; Tue, 4 Oct 2011 06:06:05 -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: <20111004130605.29904.76836.idtracker@ietfa.amsl.com> Date: Tue, 04 Oct 2011 06:06:05 -0700 Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-use-cases-and-requirements-06.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, 04 Oct 2011 13:06:06 -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-06.txt Pages : 24 Date : 2011-10-04 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-06.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-06.txt From stefan.lk.hakansson@ericsson.com Tue Oct 4 06:09:28 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D662021F8C3F for ; Tue, 4 Oct 2011 06:09:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.328 X-Spam-Level: X-Spam-Status: No, score=-6.328 tagged_above=-999 required=5 tests=[AWL=-0.029, 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 CSuzcmC2tBug for ; Tue, 4 Oct 2011 06: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 E893B21F8C13 for ; Tue, 4 Oct 2011 06:09:10 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-3b-4e8b062fafdd Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.115.96]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id E0.3A.20773.F260B8E4; Tue, 4 Oct 2011 15:12:15 +0200 (CEST) Received: from [150.132.142.233] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.137.0; Tue, 4 Oct 2011 15:11:22 +0200 Message-ID: <4E8B05F9.2090804@ericsson.com> Date: Tue, 4 Oct 2011 15:11:21 +0200 From: =?UTF-8?B?U3RlZmFuIEjDpWthbnNzb24gTEs=?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110922 Thunderbird/3.1.15 MIME-Version: 1.0 To: rtcweb@ietf.org, public-webrtc@w3.org 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-06.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, 04 Oct 2011 13:09:28 -0000 A new version has be uploaded. From the change log: Changes from draft-ietf-rtcweb-use-cases-and-requirements-05 o Added use-case "global service provider", derived reqs associated with several STUN/TURN servers o Added use-case "enterprise aspects", derived req associated with enabling the network provider to supply STUN and TURN servers o The requirements from the above are ICE specific and labeled accordingly o Separated the requirements phrased like "processing such as pan, mix and render" for audio to be specific reqs on spatialization, level measurement, level adjustment and mixing (discussed on the lists in http://www.ietf.org/mail-archive/web/rtcweb/current/msg01648.html and http://lists.w3.org/Archives/Public/public-webrtc/2011Sep/ 0102.html) o Added use-case on sharing as decided in http://www.ietf.org/mail-archive/web/rtcweb/current/msg01700.html, derived reqs F30 and A21 o Added the list of common considerations proposed in mail http://www.ietf.org/mail-archive/web/rtcweb/current/msg01562.html to the Introduction of the use-case section As always, comments and feedback is most welcome. Stefan -------- Original Message -------- Subject: New Version Notification for draft-ietf-rtcweb-use-cases-and-requirements-06.txt Date: Tue, 4 Oct 2011 15:06:05 +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-06.txt has been successfully submitted by Stefan Hakansson and posted to the IETF repository. Filename: draft-ietf-rtcweb-use-cases-and-requirements Revision: 06 Title: Web Real-Time Communication Use-cases and Requirements Creation date: 2011-10-04 WG ID: rtcweb Number of pages: 24 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 magnus.westerlund@ericsson.com Tue Oct 4 07:31: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 A6A2D21F8D52 for ; Tue, 4 Oct 2011 07:31:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.411 X-Spam-Level: X-Spam-Status: No, score=-105.411 tagged_above=-999 required=5 tests=[AWL=-0.966, BAYES_00=-2.599, FRT_BELOW2=2.154, 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 QD4N9ySM7xZN for ; Tue, 4 Oct 2011 07:31: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 BE70F21F8D47 for ; Tue, 4 Oct 2011 07:31:13 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-ac-4e8b196a0ab6 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 8D.15.20773.A691B8E4; Tue, 4 Oct 2011 16:34:18 +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, 4 Oct 2011 16:33:22 +0200 Message-ID: <4E8B192E.80809@ericsson.com> Date: Tue, 4 Oct 2011 16:33:18 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0) Gecko/20110922 Thunderbird/7.0 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] Summary of ICE discussion X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 14:31:14 -0000 WG, I have bellow tired to summarize the result of the ICE discussion. This is intended as furthering this discussion and form a basis for going forward in the consensus process. I do expect people that disagree with my summary of the discussion to speak up. Major requirements - Need for data transmission consent for protocols using UDP as the traffic receiver needs to consent to receiving the data - Perform NAT and FW traversal when ever needed - Support IPv4 to IPv6 transition Desired behavior: - Be interoperable with deployed legacy systems as SIP Trunk, PSTN gateways, VoIP phones. WG chairs conclusion of discussion so far: - ICE is so far the only solution that provides the security goals and have any legacy deployment. - ICE usage will require that STUN connectivity MUST have succeeded prior to any data transmission to fulfill security goals. * The Browser will enforce this requirement to prevent being an attack vector in all cases. - If anyone can find a solution that fulfill the security goals and have improved legacy interoperability people would be interested in that solution. So far RTCP has been discarded as insufficient. - Media Gateway can support a reduced functionality set from Full ICE Cheers Magnus Westerlund as WG chair ---------------------------------------------------------------------- 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 Tue Oct 4 07:41: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 664F621F8C53 for ; Tue, 4 Oct 2011 07:41:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.559 X-Spam-Level: X-Spam-Status: No, score=-1.559 tagged_above=-999 required=5 tests=[AWL=-1.036, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FRT_BELOW2=2.154, 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 DYbVH4W5m3Od for ; Tue, 4 Oct 2011 07:41:20 -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 CEC1B21F8BAD for ; Tue, 4 Oct 2011 07:41:19 -0700 (PDT) Received: by vcbfo11 with SMTP id fo11so543602vcb.31 for ; Tue, 04 Oct 2011 07:44:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.186.134 with SMTP id fk6mr1138387vdc.380.1317739463781; Tue, 04 Oct 2011 07:44:23 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Tue, 4 Oct 2011 07:44:23 -0700 (PDT) In-Reply-To: <4E8B192E.80809@ericsson.com> References: <4E8B192E.80809@ericsson.com> Date: Tue, 4 Oct 2011 16:44:23 +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] Summary of ICE discussion X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 14:41:20 -0000 2011/10/4 Magnus Westerlund : > I have bellow tired to summarize the result of the ICE discussion. This > is intended as furthering this discussion and form a basis for going > forward in the consensus process. I do expect people that disagree with > my summary of the discussion to speak up. > > Major requirements > > - Need for data transmission consent for protocols using UDP as the > traffic receiver needs to consent to receiving the data > > - Perform NAT and FW traversal when ever needed > > - Support IPv4 to IPv6 transition > > Desired behavior: > > - Be interoperable with deployed legacy systems as SIP Trunk, PSTN > gateways, VoIP phones. > > WG chairs conclusion of discussion so far: > > - ICE is so far the only solution that provides the security goals and > have any legacy deployment. > > - ICE usage will require that STUN connectivity MUST have succeeded > prior to any data transmission to fulfill security goals. > > =C2=A0* The Browser will enforce this requirement to prevent being an att= ack > vector in all cases. > > - If anyone can find a solution that fulfill the security goals and have > improved legacy interoperability people would be interested in that > solution. So far RTCP has been discarded as insufficient. > > - Media Gateway can support a reduced functionality set from Full ICE I agree with all the above. --=20 I=C3=B1aki Baz Castillo From randell-ietf@jesup.org Tue Oct 4 07:44: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 2A2AF21F8C4E for ; Tue, 4 Oct 2011 07:44:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[AWL=0.029, 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 V-HFGVHutENz for ; Tue, 4 Oct 2011 07:44: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 2220321F8B68 for ; Tue, 4 Oct 2011 07:44:13 -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 1RB6H8-0007AI-2p for rtcweb@ietf.org; Tue, 04 Oct 2011 09:47:18 -0500 Message-ID: <4E8B1B86.2080805@jesup.org> Date: Tue, 04 Oct 2011 10:43: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: 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> <2E239D6FCD033C4BAF15F386A979BF510F137B@sonusinmail02.sonusnet.com> <226C9800-9791-465A-B519-40935E2D135F@phonefromhere.com> In-Reply-To: <226C9800-9791-465A-B519-40935E2D135F@phonefromhere.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: Tue, 04 Oct 2011 14:44:14 -0000 On 10/4/2011 5:16 AM, Tim Panton wrote: > Partha - here's a quick review of http://tools.ietf.org/html/draft-partha-rtcweb-signaling-00 > > I'm not going to go through it line by line as I disagree with almost all of it, so I > focus on 2 key assumptions: > > Firstly -> > > Fig 1 is wrong - in the _huge_ majority of instances there will be > only one web server in such a diagram. Federated services will only be the minority case. Agreed. > Secondly -> > > You assume that being compatible with a legacy protocol would be a good thing, > but don't examine why. > I contend that there is no suitable legacy protocol and no advantage would be conveyed by > implementing one directly in a browser. I'll use SIP to illustrate my point: > > The illusion is that there are lots of SIP devices that users are itching to call from their browsers. There aren't. I agree, that is not a reason for any standard on signalling (though as you say Partha didn't actually give a reason). If someone is building an access-the-PSTN app (and they will), they can use or build a lib to do so - though I'll also mention these fully-functional JS SIP/etc libraries we presume don't exist yet and are a lot of work to write and debug. A Skype can do so easily; a small PBX add-on company using Asterisk not so much. I have a different argument: I want it to be *easy* for a website author/app developer to add audio or video for their users. The developers aren't experts on glare, forking, the intricacies of getting offer-answer (or whatever) right, ad nauseum. If you ask them to *design* their own protocol, they'll make a ton of 'rookie' mistakes. And for added fun, they'll likely never correct them and in many cases never understand why the bug is occasionally reported by their users. A random example is forking - forking will happen (forward call to all the devices the person logged in under) , and handling forking well requires some thought and experience. The obvious answer is "those people shouldn't design a protocol (leave that to the big guys), they should use a standard library." Ok, great, but: 1) These don't exist yet (minor issue; one presumes they'll exist "soon") 2) The quality and testing of these libraries is unlikely to equal that of existing signalling stacks available freely for quite a while 3) Inaki's (sorry about the cedilla) point about "website-based libraries can be updated more often than ones baked into a browser" is valid, but it has a flip-side - the swarm of smaller users of webrtc are likely to download a version of jSIP.js (or whatever) and are not likely to actively track updates. My understanding is that this is rife in the use of things like jquery - upgrading is time-consuming and risks breakage, and requires QA. People grab one version and never change it - while Firefox for example updates every 6 weeks. (He may have a better argument with IE users, especially in business, but my point still holds.) The larger, sophisticated users are more likely to update, or debug problems when they occur, so I'm not worried about them - and they can use jSIP.js regardless if there's a signalling protocol in the browser. Point 3 is in ways the strongest point here, since I assume these libraries will exist at some point. You'll note I'm not arguing for SIP here - I'm arguing that there are valid reasons for easy default signalling *as and option*, especially for the health of the "little guy" app/service developer who wants to add RT media. If we had a functional, debugged, standard JS protocol that was free and we could figure a way for app developers to ease the update process, it would undercut my argument - but we don't have that, and we can't count on that, at least not for a while. It does not *have* to be any existing signalling standard - though using one of those is probably easiest, quickest (if the wars over whether/what subside) and least error-prone. > Conclusion -> > > So we should focus upon the most common use-case and not get distracted into discussing > what is at best an edge case. > > The risk of such a discussion (of a standard signalling protocol) is that we will still be discussing it in 3 years time and each of the browser makers will have implemented their own subtly different webRTC solutions. Yes, this is critical. We need to finish it. I'd rather have it finished and a strong project to build a "standard" external JS library under way than to have the whole thing wait. But if I had my druthers (what the bleep are those, anyways?) I'd have an optional signalling protocol available. -- Randell Jesup randell-ietf@jesup.org From randell-ietf@jesup.org Tue Oct 4 08:06: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 EC41A21F8C50 for ; Tue, 4 Oct 2011 08:06:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[AWL=0.029, 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 DhfKzPy0kYnz for ; Tue, 4 Oct 2011 08:06: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 694DE21F8BBD for ; Tue, 4 Oct 2011 08:06: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 1RB6cb-00014r-DB for rtcweb@ietf.org; Tue, 04 Oct 2011 10:09:29 -0500 Message-ID: <4E8B20BA.3080906@jesup.org> Date: Tue, 04 Oct 2011 11:05: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: <4E8B192E.80809@ericsson.com> In-Reply-To: <4E8B192E.80809@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] Summary of ICE discussion X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 15:06:25 -0000 On 10/4/2011 10:33 AM, Magnus Westerlund wrote: > Major requirements > > - Need for data transmission consent for protocols using UDP as the > traffic receiver needs to consent to receiving the data > > - Perform NAT and FW traversal when ever needed > > - Support IPv4 to IPv6 transition > > Desired behavior: > > - Be interoperable with deployed legacy systems as SIP Trunk, PSTN > gateways, VoIP phones. > > WG chairs conclusion of discussion so far: > > - ICE is so far the only solution that provides the security goals and > have any legacy deployment. > > - ICE usage will require that STUN connectivity MUST have succeeded > prior to any data transmission to fulfill security goals. > > * The Browser will enforce this requirement to prevent being an attack > vector in all cases. > > - If anyone can find a solution that fulfill the security goals and have > improved legacy interoperability people would be interested in that > solution. So far RTCP has been discarded as insufficient. I've been discussing some options on this with Cullen on the side. No breakthroughs yet, though there may still be some hope. If there's something there I'll post it soon, otherwise assume it didn't pan out. One observation about the security/attack-vector side of this: Any objection that includes "if an attacker is in a MITM position they could trick the rtcweb client into sending media" is an invalid objection. A MITM attacker could inject or re-route any amount of traffic they wanted already if they're in the media path. I'll also note that an attacker could be in MITM on the signalling side or DNS, but not MITM on the media/ICE routing; those are valid cases to consider. And DNS poisoning doesn't require MITM. -- Randell Jesup randell-ietf@jesup.org From oej@edvina.net Tue Oct 4 08:29: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 8AE5A21F8CC5 for ; Tue, 4 Oct 2011 08:29:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.148 X-Spam-Level: X-Spam-Status: No, score=-1.148 tagged_above=-999 required=5 tests=[AWL=-1.053, BAYES_00=-2.599, FRT_BELOW2=2.154, 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 sa+q6s0yNN1E for ; Tue, 4 Oct 2011 08:29:28 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id 80FAA21F8BB8 for ; Tue, 4 Oct 2011 08:29:14 -0700 (PDT) Received: from [192.168.40.24] (ns.webway.se [87.96.134.125]) by smtp7.webway.se (Postfix) with ESMTPA id 97FC1754BCD5; Tue, 4 Oct 2011 15:32:16 +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: <4E8B192E.80809@ericsson.com> Date: Tue, 4 Oct 2011 17:32:17 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5A391DD5-FEA8-4E3D-A7AA-26D33C07C17C@edvina.net> References: <4E8B192E.80809@ericsson.com> To: Magnus Westerlund X-Mailer: Apple Mail (2.1244.3) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Summary of ICE discussion X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 15:29:28 -0000 4 okt 2011 kl. 16:33 skrev Magnus Westerlund: > WG, >=20 > I have bellow tired to summarize the result of the ICE discussion. = This > is intended as furthering this discussion and form a basis for going > forward in the consensus process. I do expect people that disagree = with > my summary of the discussion to speak up. >=20 > Major requirements >=20 > - Need for data transmission consent for protocols using UDP as the > traffic receiver needs to consent to receiving the data >=20 > - Perform NAT and FW traversal when ever needed >=20 > - Support IPv4 to IPv6 transition >=20 > Desired behavior: >=20 > - Be interoperable with deployed legacy systems as SIP Trunk, PSTN > gateways, VoIP phones. >=20 > WG chairs conclusion of discussion so far: >=20 > - ICE is so far the only solution that provides the security goals and > have any legacy deployment. >=20 > - ICE usage will require that STUN connectivity MUST have succeeded > prior to any data transmission to fulfill security goals. >=20 > * The Browser will enforce this requirement to prevent being an = attack > vector in all cases. >=20 > - If anyone can find a solution that fulfill the security goals and = have > improved legacy interoperability people would be interested in that > solution. So far RTCP has been discarded as insufficient. >=20 > - Media Gateway can support a reduced functionality set from Full ICE >=20 I think Harald brought up that ICE can assist in IP mobility in a = handover situation. I don't know if this is required/desired or ignored = behaviour at this point. /O From ekr@rtfm.com Tue Oct 4 08:30: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 963BE21F8CF8 for ; Tue, 4 Oct 2011 08:30:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[AWL=-0.001, 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 8CANOiWzXefq for ; Tue, 4 Oct 2011 08:30:09 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 920E521F8CF7 for ; Tue, 4 Oct 2011 08:30:09 -0700 (PDT) Received: by eye4 with SMTP id 4so679524eye.31 for ; Tue, 04 Oct 2011 08:33:14 -0700 (PDT) Received: by 10.213.33.136 with SMTP id h8mr764427ebd.21.1317742394263; Tue, 04 Oct 2011 08:33:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.213.22.211 with HTTP; Tue, 4 Oct 2011 08:32:34 -0700 (PDT) In-Reply-To: <4E8B1B86.2080805@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> <2E239D6FCD033C4BAF15F386A979BF510F137B@sonusinmail02.sonusnet.com> <226C9800-9791-465A-B519-40935E2D135F@phonefromhere.com> <4E8B1B86.2080805@jesup.org> From: Eric Rescorla Date: Tue, 4 Oct 2011 08:32:34 -0700 Message-ID: To: Randell Jesup Content-Type: multipart/alternative; boundary=000e0cd1380250cab404ae7acf9c 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, 04 Oct 2011 15:30:10 -0000 --000e0cd1380250cab404ae7acf9c Content-Type: text/plain; charset=ISO-8859-1 On Tue, Oct 4, 2011 at 7:43 AM, Randell Jesup wrote: > > 3) Inaki's (sorry about the cedilla) point about "website-based libraries > can be updated more often than ones baked into a browser" is valid, but it > has a flip-side - the swarm of smaller users of webrtc are likely to > download a version of jSIP.js (or whatever) and are not likely to actively > track updates. My understanding is that this is rife in the use of things > like jquery - upgrading is time-consuming and risks breakage, and requires > QA. People grab one version and never change it - while Firefox for example > updates every 6 weeks. (He may have a better argument with IE users, > especially in business, but my point still holds.) This is my understanding as well, and it's something that is encouraged by the way that these libraries are distributed, namely that the obvious behavior if you go to the JQuery site is to just download one of the canned versions, which of course is specific. Even if you use one of the CDN versions (see: http://docs.jquery.com/Downloading_jQuery#CDN_Hosted_jQuery), the links are all to specific versions. So, the consequence is that people en up nailed to one version. This doesn't necessarily mean that client libraries will upgrade more slowly than the browsers, but as far as I know it's not a decided question either way. Best, -Ekr --000e0cd1380250cab404ae7acf9c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Oct 4, 2011 at 7:43 AM, Randell = Jesup <rande= ll-ietf@jesup.org> wrote:
3) Inaki's (sorry about the cedilla) point about "website-based li= braries can be updated more often than ones baked into a browser" is v= alid, but it has a flip-side - the swarm of smaller users of webrtc are lik= ely to download a version of jSIP.js (or whatever) and are not likely to ac= tively track updates. =A0My understanding is that this is rife in the use o= f things like jquery - upgrading is time-consuming and risks breakage, and = requires QA. =A0People grab one version and never change it - while Firefox= for example updates every 6 weeks. =A0(He may have a better argument with = IE users, especially in business, but my point still holds.) =A0

This is my understanding as well, and it's somethin= g that is encouraged by the way that these
libraries are distribu= ted, namely that the obvious behavior if you go to the JQuery site is to
just download one of the canned versions, which of course is specific.= Even if you use one
the links are all to specific versions. So, the consequence is that pe= ople en up nailed to
one version.

This d= oesn't necessarily mean that client libraries will upgrade more slowly = than the browsers,
but as far as I know it's not a decided question either way.
=

Best,
-Ekr

--000e0cd1380250cab404ae7acf9c-- From ekr@rtfm.com Tue Oct 4 08: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 D801521F8CF7 for ; Tue, 4 Oct 2011 08:31:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 GPwQjAfkaUfp for ; Tue, 4 Oct 2011 08:31:38 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0897B21F8CC5 for ; Tue, 4 Oct 2011 08:31:32 -0700 (PDT) Received: by eye4 with SMTP id 4so681008eye.31 for ; Tue, 04 Oct 2011 08:34:38 -0700 (PDT) Received: by 10.213.7.14 with SMTP id b14mr756380ebb.59.1317742477325; Tue, 04 Oct 2011 08:34:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.213.22.211 with HTTP; Tue, 4 Oct 2011 08:33:57 -0700 (PDT) In-Reply-To: <4E8B20BA.3080906@jesup.org> References: <4E8B192E.80809@ericsson.com> <4E8B20BA.3080906@jesup.org> From: Eric Rescorla Date: Tue, 4 Oct 2011 08:33:57 -0700 Message-ID: To: Randell Jesup Content-Type: multipart/alternative; boundary=0015174c441244365e04ae7ad4b1 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Summary of ICE discussion X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 15:31:39 -0000 --0015174c441244365e04ae7ad4b1 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Oct 4, 2011 at 8:05 AM, Randell Jesup wrote > > One observation about the security/attack-vector side of this: Any > objection that includes "if an attacker is in a MITM position they could > trick the rtcweb client into sending media" is an invalid objection. A MITM > attacker could inject or re-route any amount of traffic they wanted already > if they're in the media path. Concur. ICE is primarily about web attackers, not network attackers. -Ekr --0015174c441244365e04ae7ad4b1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Oct 4, 2011 at 8:05 AM, Randell = Jesup <rande= ll-ietf@jesup.org> wrote
One observation about the security/attack-vector side of this: =A0Any objec= tion that includes "if an attacker is in a MITM position they could tr= ick the rtcweb client into sending media" is an invalid objection. =A0= A MITM attacker could inject or re-route any amount of traffic they wanted = already if they're in the media path.

Concur. ICE is primarily about web attackers, not netwo= rk attackers.

-Ekr
=A0
--0015174c441244365e04ae7ad4b1-- From csp@csperkins.org Tue Oct 4 08:46: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 4125921F8C71 for ; Tue, 4 Oct 2011 08:46:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.539 X-Spam-Level: X-Spam-Status: No, score=-103.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 TbKTXmPcmeqd for ; Tue, 4 Oct 2011 08:46:34 -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 4AD5021F8C6F for ; Tue, 4 Oct 2011 08:46:28 -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 1RB7FM-0004e0-ko; Tue, 04 Oct 2011 15:49:32 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Colin Perkins In-Reply-To: <4E830E89.3050400@alvestrand.no> Date: Tue, 4 Oct 2011 16:49:31 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E830E89.3050400@alvestrand.no> To: Harald Alvestrand X-Mailer: Apple Mail (2.1084) Cc: "rtcweb@ietf.org" Subject: Re: [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: Tue, 04 Oct 2011 15:46:35 -0000 Harald, On 28 Sep 2011, at 13:09, Harald Alvestrand wrote: > I've just posted version -02 of the -overview document. > I'll just paste the change log from the document here: >=20 >> A.6. Changes from draft-ietf-rtcweb-overview -01 to -02 >>=20 >> Added pointers to use cases, security and rtp-usage drafts (now WG >> drafts). >>=20 >> Changed description of SRTP from mandatory-to-use to mandatory-to- >> implement. >>=20 >> Added the "3 principles of negotiation" to the connection = management >> section. >>=20 >> Added an explicit statement that ICE is required for both NAT and >> consent-to-receive. >=20 > Comments are always welcome, and version numbers are cheap! A minor editorial point: the 3rd bullet in section 7 suggests that SDP = for new codecs is specified by MMUSIC. This is inaccurate: the SDP is = done by PAYLOAD, as an algorithmic mapping from the parameters of the = new media type. Suggest changing: 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 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 codecs, old applications written before the codecs were specified should automatically be able to use the new codecs where appropriate with no changes to the JS applications. to 3. When a new codec is specified, and the media type parameters=20 for the new codec are specified in the PAYLOAD WG, no other=20 standardization would should be required for it to be possible to=20= use that in the web browsers. Adding new codecs which might have=20= new media type parameters should not change the APIs between the=20= browser and javascript application. As soon as the browsers=20 support the new codecs, old applications written before the = codecs=20 were specified should automatically be able to use the new codecs=20= where appropriate with no changes to the JS applications.=20 You might also want to add something like "The representation of codec = names and their parameters in the web browsers must be algorithmically = derivable from the media type name and parameters defined in the RTP = payload format specification for the codec. This can be done by using = the media type name and its parameters directly; by using the existing = encoding of that name and parameters into SDP; or by defining an = algorithmic mapping from the media type name and parameters onto a new = signalling format". Colin --=20 Colin Perkins http://csperkins.org/ From jim.mceachern@genband.com Tue Oct 4 08:56: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 7B16321F8CEE for ; Tue, 4 Oct 2011 08:56:29 -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 wBRWMj5VdQ4c for ; Tue, 4 Oct 2011 08:56:28 -0700 (PDT) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by ietfa.amsl.com (Postfix) with ESMTP id 1D91B21F8CE3 for ; Tue, 4 Oct 2011 08:56:27 -0700 (PDT) Received: from mail.genband.com ([63.149.188.88]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP; Tue, 04 Oct 2011 08:59:33 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); Tue, 4 Oct 2011 10:59:15 -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; Tue, 4 Oct 2011 10:59:15 -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: AQHMgqSHFvdI2T8mjE663dxgldXgIJVsU7ag Date: Tue, 4 Oct 2011 15:59:14 +0000 Message-ID: <8584590C8D7DD141AA96D01920FC6C698C8A84ED@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> <2E239D6FCD033C4BAF15F386A979BF510F137B@sonusinmail02.sonusnet.com> <226C9800-9791-465A-B519-40935E2D135F@phonefromhere.com> <4E8B1B86.2080805@jesup.org> In-Reply-To: <4E8B1B86.2080805@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_8584590C8D7DD141AA96D01920FC6C698C8A84EDgbplmail03genba_" MIME-Version: 1.0 X-OriginalArrivalTime: 04 Oct 2011 15:59:15.0789 (UTC) FILETIME=[91242FD0:01CC82AE] X-TM-AS-Product-Ver: SMEX-8.0.0.4160-6.500.1024-18426.000 X-TM-AS-Result: No--15.265600-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: Tue, 04 Oct 2011 15:56:29 -0000 --_002_8584590C8D7DD141AA96D01920FC6C698C8A84EDgbplmail03genba_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Tue, Oct 4, 2011 at 10:43 AM, Randell Jesup wro= te: > I have a different argument: I want it to be *easy* for a website > author/app developer to add audio or video for their users. The > developers aren't experts on glare, forking, the intricacies of getting o= ffer- > answer (or whatever) right, ad nauseum. If you ask them to > *design* their own protocol, they'll make a ton of 'rookie' mistakes. > And for added fun, they'll likely never correct them and in many cases ne= ver > understand why the bug is occasionally reported by their users. >=20 > A random example is forking - forking will happen (forward call to all th= e > devices the person logged in under) , and handling forking well requires > some thought and experience. >=20 The problem with this argument is that it involves complex functionality th= at would not be covered by basic SIP in the browser.=20 Are you proposing that the full SIP stack, with support for forking, early = media, etc. be built into all browsers? If yes, then we are already at the= bottom of the "slippery slope" that people fear.=20 If no, then the app developer will still need to deal with this complexity= . Am I missing something? Jim --_002_8584590C8D7DD141AA96D01920FC6C698C8A84EDgbplmail03genba_ 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="Tue, 04 Oct 2011 15:59:14 GMT"; modification-date="Tue, 04 Oct 2011 15:59:14 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_8584590C8D7DD141AA96D01920FC6C698C8A84EDgbplmail03genba_-- From tim@phonefromhere.com Tue Oct 4 08:57: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 A428B21F8B10 for ; Tue, 4 Oct 2011 08:57:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RRQzzvdE6SQs for ; Tue, 4 Oct 2011 08:57:37 -0700 (PDT) Received: from zimbra.westhawk.co.uk (zimbra.westhawk.co.uk [192.67.4.167]) by ietfa.amsl.com (Postfix) with ESMTP id 3CFA721F8AF2 for ; Tue, 4 Oct 2011 08:57:37 -0700 (PDT) Received: from [192.168.0.14] (unknown [93.89.81.113]) by zimbra.westhawk.co.uk (Postfix) with ESMTP id 59C1B37A903; Tue, 4 Oct 2011 17:13:30 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Tim Panton In-Reply-To: <4E8B1B86.2080805@jesup.org> Date: Tue, 4 Oct 2011 17:00:36 +0100 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> <2E239D6FCD033C4BAF15F386A979BF510F137B@sonusinmail02.sonusnet.com> <226C9800-9791-465A-B519-40935E2D135F@phonefromhere.com> <4E8B1B86.2080805@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: Tue, 04 Oct 2011 15:57:38 -0000 On 4 Oct 2011, at 15:43, Randell Jesup wrote: > On 10/4/2011 5:16 AM, Tim Panton wrote: >> Partha - here's a quick review of = http://tools.ietf.org/html/draft-partha-rtcweb-signaling-00 >>=20 >> I'm not going to go through it line by line as I disagree with almost = all of it, so I >> focus on 2 key assumptions: >>=20 >> Firstly -> >>=20 >> Fig 1 is wrong - in the _huge_ majority of instances there will be >> only one web server in such a diagram. Federated services will only = be the minority case. >=20 > Agreed. >=20 >> Secondly -> >>=20 >> You assume that being compatible with a legacy protocol would be a = good thing, >> but don't examine why. >> I contend that there is no suitable legacy protocol and no advantage = would be conveyed by >> implementing one directly in a browser. I'll use SIP to illustrate my = point: >>=20 >> The illusion is that there are lots of SIP devices that users are = itching to call from their browsers. There aren't. >=20 > I agree, that is not a reason for any standard on signalling (though = as you say Partha didn't actually give a reason). If someone is = building an access-the-PSTN app (and they will), they can use or build a = lib to do so - though I'll also mention these fully-functional JS = SIP/etc libraries we presume don't exist yet and are a lot of work to = write and debug. A Skype can do so easily; a small PBX add-on company = using Asterisk not so much. Here we disagree on 3 fronts : 1) whilst people will do access-the-PSTN apps they will be wasting their = time (IMHO) The growth/interesting area in RTC is not PSTN interconnect. I made the mistake of betting the farm on PSTN interconnect being the = dominant use of an in browser audio component. I was wrong - people used=20= the component for collaboration, dating, games etc - but hardly at all = for PSTN. Look at vivox, skype and the rest - PSTN access is a small and = shrinking use case. We should not let it sway us unduly. 2) Phono's javascript exists and is open source - it works and is based = on xmpp.=20 https://github.com/phono/PhonoSDK/tree/master/modules/phono-js/src/main I'm not claiming that it solves _every_ problem, that it has the ideal = abstraction, =20 or that it is compatible with the yet unwritten RTCweb spec, but it does = serve=20 as a proof by example. 3) the moment RTCweb settles, the asterisk, freeswitch, YATE etc = communities will write a native channel drivers for it. Those platforms have built in http servers, channel independent RTP modules and protocol = independent frameworks that can be leveraged to ease the pain of supporting a new protocol. I've investigated doing one for Asterisk SCF - it looks like a couple of = weeks work. Minimal JS needed and certainly no sip.js=20 >=20 > I have a different argument: I want it to be *easy* for a website = author/app developer to add audio or video for their users. The = developers aren't experts on glare, forking, the intricacies of getting = offer-answer (or whatever) right, ad nauseum. If you ask them to = *design* their own protocol, they'll make a ton of 'rookie' mistakes. = And for added fun, they'll likely never correct them and in many cases = never understand why the bug is occasionally reported by their users. >=20 > A random example is forking - forking will happen (forward call to all = the devices the person logged in under) , and handling forking well = requires some thought and experience. But that thought and experience are (I'd argue) irrelevant, or at least = need a deep review because it isn't the same problem as we solved last time. Worse, we are only guessing what the problem is. Who = says that the forking problem even exists if you let go of the=20 device/call/line centric PSTN model - I'm not convinced. >=20 > The obvious answer is "those people shouldn't design a protocol (leave = that to the big guys), they should use a standard library." Ok, great, = but: >=20 > 1) These don't exist yet (minor issue; one presumes they'll exist = "soon") (see phono) > 2) The quality and testing of these libraries is unlikely to equal = that of existing signalling stacks available freely for quite a while True, but you may be underestimating the difficulty of taking an = existing native SIP/IAX/XXX stack and adding it safely to a browser = framework. Browsers have strict threading and memory requirements (especially when = it comes to access to the DOM/JS)=20 - and that's without event starting on the security issues.=20 By minimizing the native code and maximizing the javascript we put more = of the code on the 'already sandboxed' side of the fence. Also I doubt that the browser makers will all go for the same = pre-existing-native stack, for license reasons if no other. Then you are = faced with the usual interop problems between 4 different stacks implementing = different subsets of a standard. > 3) Inaki's (sorry about the cedilla) point about "website-based = libraries can be updated more often than ones baked into a browser" is = valid, but it has a flip-side - the swarm of smaller users of webrtc are = likely to download a version of jSIP.js (or whatever) and are not likely = to actively track updates. My understanding is that this is rife in the = use of things like jquery - upgrading is time-consuming and risks = breakage, and requires QA. People grab one version and never change it = - while Firefox for example updates every 6 weeks. (He may have a = better argument with IE users, especially in business, but my point = still holds.) The larger, sophisticated users are more likely to = update, or debug problems when they occur, so I'm not worried about them = - and they can use jSIP.js regardless if there's a signalling protocol = in the browser. (following your example, which I don't wholly subscribe to for reasons = mentioned above) The users won't exactly 'download' jSIP.js - the web services they use = will include it.=20 The site's web developers will reference a version that works with the = version of asterisk (say) that they have=20 installed on their server. The last thing they want is the browser to go = spontaneously fixing protocol implementation bugs when they have carefully patched the asterisk to cover up the problem. >=20 > Point 3 is in ways the strongest point here, since I assume these = libraries will exist at some point. >=20 > You'll note I'm not arguing for SIP here - I'm arguing that there are = valid reasons for easy default signalling *as and option*, especially = for the health of the "little guy" app/service developer who wants to = add RT media. If we had a functional, debugged, standard JS protocol = that was free and we could figure a way for app developers to ease the = update process, it would undercut my argument - but we don't have that, = and we can't count on that, at least not for a while. It does not = *have* to be any existing signalling standard - though using one of = those is probably easiest, quickest (if the wars over whether/what = subside) and least error-prone. And I fear that it opens a different, more opaque, can of worms by = encouraging these little-guys to adopt SIP/SER/asterisk just=20 to get in-game push-to-talk. >=20 >=20 >> Conclusion -> >>=20 >> So we should focus upon the most common use-case and not get = distracted into discussing >> what is at best an edge case. >>=20 >> The risk of such a discussion (of a standard signalling protocol) is = that we will still be discussing it in 3 years time and each of the = browser makers will have implemented their own subtly different webRTC = solutions. >=20 > Yes, this is critical. We need to finish it. I'd rather have it = finished and a strong project to build a "standard" external JS library = under way than to have the whole thing wait. But if I had my druthers = (what the bleep are those, anyways?) I'd have an optional signalling = protocol available. I have no problem with an optional signalling library, I just rather it = to be a javascript example not a baked in native default. Tim.= From ted.ietf@gmail.com Tue Oct 4 08:58: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 14A6121F8BC4 for ; Tue, 4 Oct 2011 08:58:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.507 X-Spam-Level: X-Spam-Status: No, score=-3.507 tagged_above=-999 required=5 tests=[AWL=0.091, 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 Qbfxg1bfFfvO for ; Tue, 4 Oct 2011 08:58:21 -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 7D2F321F8B8E for ; Tue, 4 Oct 2011 08:58:21 -0700 (PDT) Received: by yxt33 with SMTP id 33so774238yxt.31 for ; Tue, 04 Oct 2011 09:01:26 -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=7Slh+UGEDqWTFIM0ODXesp0JzgyOJ+zd7rM9ygnxtug=; b=r3WtpHGmGgTyW9R+TYO1vKXoHA+y6H+v5q47vB90HwWXwTWvsMNIgswLrCRc/nAYIQ tE9iUDKIReRpWOzF1/T6scaVmz/QNWCxaJD3BeSUw9ZLfJ7m4Gi7krJQlQTYB0B5XSnL C10Zbv2i3CfGoBtXtV3uhdOZH9Nw3ejVkOB5w= MIME-Version: 1.0 Received: by 10.236.187.35 with SMTP id x23mr7982420yhm.6.1317744086265; Tue, 04 Oct 2011 09:01:26 -0700 (PDT) Received: by 10.236.105.169 with HTTP; Tue, 4 Oct 2011 09:01:26 -0700 (PDT) Date: Tue, 4 Oct 2011 09:01:26 -0700 Message-ID: From: Ted Hardie To: rtcweb@ietf.org Content-Type: multipart/alternative; boundary=20cf303dd5062ab0cb04ae7b3400 Subject: [rtcweb] Making progress on the signaling discussion (NB: Action items enclosed!) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 15:58:22 -0000 --20cf303dd5062ab0cb04ae7b3400 Content-Type: text/plain; charset=ISO-8859-1 At today's Chairs call, Cullen, Magnus and I had a discussion of how to make progress on the signaling discussion. We feel the mailing list discussion needs to have more concrete proposals in order to make progress, and so we're putting forward the following: 1) If you plan to put forward a draft proposing a concrete solution in this space, please send your name to the mailing list with that intent by October 7th *THIS FRIDAY*. 2) Please have a -00 draft out for discussion by October 14th (the following Friday). This is to allow for a discussion and update prior to the -01 deadlines. 3) We will hold a conference call to discuss the drafts on October 21st (the Friday after that). Updates based on that discussion then have until the -01 drafts deadline to be complete. This is aggressive, but we feel we need to have at least -00s for the different ideas in place in order to make real progress. thanks, Ted, Magnus, Cullen --20cf303dd5062ab0cb04ae7b3400 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable At today's Chairs call, Cullen, Magnus and I had a discussion of how to= make progress on the signaling discussion.=A0 We feel the mailing list dis= cussion needs to have more concrete proposals in order to make progress, an= d so we're putting forward the following:

1) If you plan to put forward a draft proposing a concrete solution in = this space, please send your name to the mailing list with that intent by O= ctober 7th *THIS FRIDAY*.

2) Please have a -00 draft out for discuss= ion by October 14th (the following Friday).=A0 This is to allow for a discu= ssion and update prior to the -01 deadlines.

3) We will hold a conference call to discuss the drafts on October 21st= (the Friday after that).

Updates based on that discussion then have= until the -01 drafts deadline to be complete.

This is aggressive, b= ut we feel we need to have at least -00s for the different ideas in place i= n order to make real progress.

thanks,

Ted, Magnus, Cullen
--20cf303dd5062ab0cb04ae7b3400-- From cbran@cisco.com Tue Oct 4 08:59: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 C8C1F21F8CE3 for ; Tue, 4 Oct 2011 08:59:53 -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 XzpJBkGNO-dl for ; Tue, 4 Oct 2011 08:59:53 -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 5EB8221F8BBD for ; Tue, 4 Oct 2011 08:59:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=cbran@cisco.com; l=2682; q=dns/txt; s=iport; t=1317744179; x=1318953779; h=subject:references:content-transfer-encoding:from: in-reply-to:message-id:date:to:cc:mime-version; bh=Y8LWRON58NPslPJLomaF/rFd1UDHOmxdxs3WyN8pHNY=; b=SVCxZG0TRLDB4+TkoC88gIYEP4ZsbzsD1UsVx3DHgp1zqJ8mjD2nZiE8 s9FLNO6LuvunzYnVNhPg4j2biz/UcEu39kC9AxmAqJoGuaOBGyaon3Q6B 57LBojNOiNFMkGd8f/vG32bwfj3mN7gPePqB4bicCik0IvEexHAgwkFrB 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuQGAKcti06rRDoH/2dsb2JhbABChGaiJm0CgQWBUwEBAQMBAQEBDwEQSwsQAgEIBAo0AgInMAEBBBMih1oGmxABjEWRQwOGDzJhBIdIMItuhTCMMg X-IronPort-AV: E=Sophos;i="4.68,485,1312156800"; d="scan'208,217";a="5873603" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 04 Oct 2011 16:02:58 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p94G2wnC029166; Tue, 4 Oct 2011 16:02:58 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); Tue, 4 Oct 2011 09:02:58 -0700 Received: from 72.163.63.12 ([72.163.63.12]) by xmb-sjc-228.amer.cisco.com ([128.107.191.125]) with Microsoft Exchange Server HTTP-DAV ; Tue, 4 Oct 2011 16:02:57 +0000 References: <4E8B192E.80809@ericsson.com> <4E8B20BA.3080906@jesup.org> Content-Transfer-Encoding: 7bit From: "Cary Bran (cbran)" Thread-Topic: [rtcweb] Summary of ICE discussion Thread-Index: AcyCrxW5mSORE16BS1KG+5LRVl48tw== Content-Type: multipart/alternative; boundary="Apple-Mail-287-134560162"; charset="iso-8859-1" In-Reply-To: Message-ID: Date: Tue, 4 Oct 2011 09:02:56 -0700 To: "Eric Rescorla" MIME-Version: 1.0 (iPad Mail 8L1) X-OriginalArrivalTime: 04 Oct 2011 16:02:58.0471 (UTC) FILETIME=[15DEC370:01CC82AF] Cc: Randell Jesup , rtcweb@ietf.org Subject: Re: [rtcweb] Summary of ICE discussion X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 15:59:53 -0000 --Apple-Mail-287-134560162 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I will integrate this into the NAT traversal draft and submit a 02 version o= f draft-cbran-rtcweb-nat for review. -Cary On Oct 4, 2011, at 8:34 AM, "Eric Rescorla" wrote: >=20 >=20 > On Tue, Oct 4, 2011 at 8:05 AM, Randell Jesup wro= te > One observation about the security/attack-vector side of this: Any object= ion that includes "if an attacker is in a MITM position they could trick the= rtcweb client into sending media" is an invalid objection. A MITM attacker= could inject or re-route any amount of traffic they wanted already if they'= re in the media path. >=20 > Concur. ICE is primarily about web attackers, not network attackers. >=20 > -Ekr > =20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --Apple-Mail-287-134560162 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=utf-8
I will integrate this into the NAT traversal draft and submit a 02 version of draft-cbran-rtcweb-nat for review.

-Cary

On Oct 4, 2011, at 8:34 AM, "Eric Rescorla" <ekr@rtfm.com> wrote:



On Tue, Oct 4, 2011 at 8:05 AM, Randell Jesup <randell-ietf@jesup.org> wrote
One observation about the security/attack-vector side of this:  Any objection that includes "if an attacker is in a MITM position they could trick the rtcweb client into sending media" is an invalid objection.  A MITM attacker could inject or re-route any amount of traffic they wanted already if they're in the media path.

Concur. ICE is primarily about web attackers, not network attackers.

-Ekr
 
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb
--Apple-Mail-287-134560162-- From HKaplan@acmepacket.com Tue Oct 4 09:21: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 C35E321F8D8A for ; Tue, 4 Oct 2011 09:21:08 -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_47=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 MSqGm-2z8EZg for ; Tue, 4 Oct 2011 09:21:08 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 230E921F8D86 for ; Tue, 4 Oct 2011 09:21: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; Tue, 4 Oct 2011 12:24:12 -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; Tue, 4 Oct 2011 12:24:13 -0400 From: Hadriel Kaplan To: Randell Jesup Thread-Topic: [rtcweb] Summary of ICE discussion Thread-Index: AQHMgrIMhMqMbPzAz0WUIBBDdBYXVQ== Date: Tue, 4 Oct 2011 16:24:11 +0000 Message-ID: <7EE6A3A6-D628-4EF5-A1E2-FB78C9F8A498@acmepacket.com> References: <4E8B192E.80809@ericsson.com> <4E8B20BA.3080906@jesup.org> In-Reply-To: <4E8B20BA.3080906@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: <936360EE1085B144ACC78A5CA2D17C73@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [rtcweb] Summary of ICE discussion X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 16:21:08 -0000 On Oct 4, 2011, at 11:05 AM, Randell Jesup wrote: > One observation about the security/attack-vector side of this: Any objec= tion that includes "if an attacker is in a MITM position they could trick t= he rtcweb client into sending media" is an invalid objection. A MITM attac= ker could inject or re-route any amount of traffic they wanted already if t= hey're in the media path. I'll also note that an attacker could be in MITM= on the signalling side or DNS, but not MITM on the media/ICE routing; thos= e are valid cases to consider. And DNS poisoning doesn't require MITM. Excellent - I was hoping someone else would feel that way about a MITM on t= he media/ICE path. I'm not sure that's universally agreed on, though: it w= as the main reason for requiring the hash on the STUN connectivity checks, = afaict. The hard part about this all, frankly, is that we're not allowed to trust t= he JavaScript. Since the JavaScript can learn so much, we're stuck with th= e Browser generating something that the JS can't learn but that the media p= eer will learn in the media plane only. The transaction-id of the STUN con= nectivity check essentially provides that proof that the STUN answer comes = from a real media peer willing to participate. Unfortunately RTP has no su= ch proof, and RTCP has one but I think people have said it's not strong eno= ugh? (I can't find where someone said that, but it could be) Regardless, fundamentally it seems to me W3C and Browser manufacturers have= a problem if they can't ever trust JavaScript: plugins and native apps wil= l always be able to do things JS can't do if W3C can't agree on a way for t= he user+browser to safely say "yes, this really is JS I trust, with the sam= e level of trust/policies I give to plugins/apps". I don't mean this for a= ll web-page JS downloads of RTCWeb, but rather for specific sites that I wo= uld have a long-term relationship with. For example if I am a Facebook use= r and Facebook wants to run JS on my browser, I'd be willing to give them c= ontrol similar to downloading a Facebook app, even if it requires me to fol= low the same process of consent that downloading an application does. What= about the Mozilla signed scripts model? For general RTCWeb JS downloads I think requiring ICE and all is fine and g= ood, and frankly I expect most RTCWeb applications to fall in that model an= d not care about legacy SIP or the PSTN. But for some RTCWeb cases it will= communicate with legacy SIP/PSTN and those are the types of applications t= hat I think would have a longer-term relationship with the user, for which = requiring a more stringent JS trust model seems worthwhile to me. -hadriel From bernard_aboba@hotmail.com Tue Oct 4 09:25: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 2149E21F8DE6 for ; Tue, 4 Oct 2011 09:25:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.338 X-Spam-Level: X-Spam-Status: No, score=-101.338 tagged_above=-999 required=5 tests=[AWL=-0.894, BAYES_00=-2.599, FRT_BELOW2=2.154, 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 i+RzS0S0qPs1 for ; Tue, 4 Oct 2011 09:25:30 -0700 (PDT) Received: from blu0-omc3-s15.blu0.hotmail.com (blu0-omc3-s15.blu0.hotmail.com [65.55.116.90]) by ietfa.amsl.com (Postfix) with ESMTP id 7AAF321F8DE5 for ; Tue, 4 Oct 2011 09:25:29 -0700 (PDT) Received: from BLU152-W13 ([65.55.116.72]) by blu0-omc3-s15.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 4 Oct 2011 09:28:34 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_e9b4e328-0b7e-448d-a368-01bc48755880_" X-Originating-IP: [98.237.179.165] From: Bernard Aboba To: Magnus Westerlund Date: Tue, 4 Oct 2011 09:28:34 -0700 Importance: Normal In-Reply-To: References: <4E8B192E.80809@ericsson.com>, MIME-Version: 1.0 X-OriginalArrivalTime: 04 Oct 2011 16:28:34.0995 (UTC) FILETIME=[A9B5B830:01CC82B2] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Summary of ICE discussion X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 16:25:32 -0000 --_e9b4e328-0b7e-448d-a368-01bc48755880_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I think this is a good summary of where we are with respect to ICE=2C and since there are no good alternatives on the table=2C it seems reasonable to move on to the next step.=20 IMHO=2C this would involve a more detailed analysis of the threats and what needs to be done to resolve them.=20 In particular=2C the statement "STUN Connectivity Check MUST have succeeded= " is=20 necessary but not sufficient. We need to get into a discussion of the spe= cific conditions under which media can be sent=2C and what attacks are still possible. For example=2C there exist public STUN servers on the Internet= =2C and=20 RTCWEB should not permit the browser to execute a DoS attack on these serve= rs.=20 Also=2C it would be desirable to prevent a browser from sending much more bandwidth than the receiver has consented to=3B however=2C because signali= ng is largely opaque to the browser=2C it is not obvious (at least to me) how = to=20 prevent this.=20 > 2011/10/4 Magnus Westerlund : > I have bellow tired to summarize the result of the ICE discussion. This > is intended as furthering this discussion and form a basis for going > forward in the consensus process. I do expect people that disagree with > my summary of the discussion to speak up. > > Major requirements > > - Need for data transmission consent for protocols using UDP as the > traffic receiver needs to consent to receiving the data > > - Perform NAT and FW traversal when ever needed > > - Support IPv4 to IPv6 transition > > Desired behavior: > > - Be interoperable with deployed legacy systems as SIP Trunk=2C PSTN > gateways=2C VoIP phones. >=20 > WG chairs conclusion of discussion so far: >=20 > - ICE is so far the only solution that provides the security goals and > have any legacy deployment. > > - ICE usage will require that STUN connectivity MUST have succeeded > prior to any data transmission to fulfill security goals. > > * The Browser will enforce this requirement to prevent being an attack > vector in all cases. > > - If anyone can find a solution that fulfill the security goals and have > improved legacy interoperability people would be interested in that > solution. So far RTCP has been discarded as insufficient. > > - Media Gateway can support a reduced functionality set from Full ICE = --_e9b4e328-0b7e-448d-a368-01bc48755880_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I think this is a good summary of where we are with respect to ICE=2C andsince there are no good alternatives on the table=2C it seems reasonable = to
move on to the next step.

IMHO=2C this would involve a more d= etailed analysis of the threats and what
needs to be done to resolve the= m.

In particular=2C the statement "STUN Connectivity Check MUST hav= e succeeded" is
necessary but not sufficient. =3B =3B We need t= o get into a discussion of the specific
conditions under which media can= be sent=2C and what attacks are still
possible. =3B For example=2C = there exist public STUN servers on the Internet=2C and
RTCWEB should no= t permit the browser to execute a DoS attack on these servers.
Also=2C = it would be desirable to prevent a browser from sending much more
bandwi= dth than the receiver has consented to=3B =3B however=2C because signal= ing
is largely opaque to the browser=2C it is not obvious (at least to m= e) how to
prevent this.

>=3B 2011/10/4 Magnus Westerlund= <=3Bmagnus.westerlund@ericsson.com>=3B:
>=3B I have bellow tired = to summarize the result of the ICE discussion. This
>=3B is intended a= s furthering this discussion and form a basis for going
>=3B forward i= n the consensus process. I do expect people that disagree with
>=3B my= summary of the discussion to speak up.
>=3B
>=3B Major requireme= nts
>=3B
>=3B - Need for data transmission consent for protocols = using UDP as the
>=3B traffic receiver needs to consent to receiving t= he data
>=3B
>=3B - Perform NAT and FW traversal when ever needed=
>=3B
>=3B - Support IPv4 to IPv6 transition
>=3B
>=3B = Desired behavior:
>=3B
>=3B - Be interoperable with deployed lega= cy systems as SIP Trunk=2C PSTN
>=3B gateways=2C VoIP phones.
>= =3B
>=3B WG chairs conclusion of discussion so far:
>=3B
>= =3B - ICE is so far the only solution that provides the security goals and<= br>>=3B have any legacy deployment.
>=3B
>=3B - ICE usage will = require that STUN connectivity MUST have succeeded
>=3B prior to any d= ata transmission to fulfill security goals.
>=3B
>=3B =3B * T= he Browser will enforce this requirement to prevent being an attack
>= =3B vector in all cases.
>=3B
>=3B - If anyone can find a solutio= n that fulfill the security goals and have
>=3B improved legacy intero= perability people would be interested in that
>=3B solution. So far RT= CP has been discarded as insufficient.
>=3B
>=3B - Media Gateway = can support a reduced functionality set from Full ICE

=
= --_e9b4e328-0b7e-448d-a368-01bc48755880_-- From bernard_aboba@hotmail.com Tue Oct 4 09: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 79D2621F8B21 for ; Tue, 4 Oct 2011 09:35:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.191 X-Spam-Level: X-Spam-Status: No, score=-102.191 tagged_above=-999 required=5 tests=[AWL=0.407, 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 KdekGJi2kECs for ; Tue, 4 Oct 2011 09:35:23 -0700 (PDT) Received: from blu0-omc1-s20.blu0.hotmail.com (blu0-omc1-s20.blu0.hotmail.com [65.55.116.31]) by ietfa.amsl.com (Postfix) with ESMTP id 7CC9D21F8B20 for ; Tue, 4 Oct 2011 09:35:23 -0700 (PDT) Received: from BLU152-W10 ([65.55.116.9]) by blu0-omc1-s20.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 4 Oct 2011 09:38:28 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_f7cacf1d-3619-48e0-bf25-836fd5979a43_" X-Originating-IP: [98.237.179.165] From: Bernard Aboba To: , Date: Tue, 4 Oct 2011 09:38:27 -0700 Importance: Normal In-Reply-To: <4E8AC222.4050308@alvestrand.no> References: <2E239D6FCD033C4BAF15F386A979BF510F1367@sonusinmail02.sonusnet.com>, <4E8AC222.4050308@alvestrand.no> MIME-Version: 1.0 X-OriginalArrivalTime: 04 Oct 2011 16:38:28.0447 (UTC) FILETIME=[0B6F4EF0:01CC82B4] Subject: Re: [rtcweb] Review request for RTCWeb standard 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: Tue, 04 Oct 2011 16:35:24 -0000 --_f7cacf1d-3619-48e0-bf25-836fd5979a43_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Agree with Harald on this. Debating which alternative is "the best" is a = distraction. One of the major advantages of RTCWEB is the flexibility it p= rovides with respect to signaling. =20 Date: Tue=2C 4 Oct 2011 10:21:54 +0200 From: harald@alvestrand.no To: rtcweb@ietf.org Subject: Re: [rtcweb] Review request for RTCWeb standard signaling protocol =20 =20 =20 =20 Ravindran=2C =20 the core part of your document seems to me to be this list: =20 The following Signaling protocols will qualify for becoming standard RTCWeb signaling protocol 1. Jingle 2. Websocket with SDP offer/answer 3. SIP 4. SIPLite [I-D.cbran-rtcweb-protocols] 5. Websocket with custom XML 6. Megaco [RFC5125] 7. Websocket with SIP [I-D.ibc-rtcweb-sip-websocket] 8. HTTP with custom XML 9. ??? TBD: Pros and cons for each of the signaling mechanism has to be added =20 My reading of your document is that you want the RTCWEB working group to pick exactly one of these alternatives=2C and insist that all conformant implementations of RTCWEB support this protocol. =20 I disagree with: =20 a) that this is needed b) that this is a good idea =20 The reasons why it is not a good idea have been raised multiple times=2C and spending continued effort on trying to debate which of the alternatives you list above is "the best one" is distracting to our purpose of getting the RTCWEB protocol suite done. =20 I do not support pursuing your suggested direction of work in this working group. =20 Harald =20 =20 =20 =20 =20 On 10/03/2011 04:41 PM=2C Ravindran Parthasarathi wrote: =20 Hi all=2C RTCWeb standard signaling protocol (http://tools.ietf.org/html/draft-partha= -rtcweb-signaling-00) draft list the need for standard signaling protocol b= etween RTCWeb client (browser) and RTCWeb server and the possible signaling= protocol for the same. This draft is written based on http://www.ietf.org/= mail-archive/web/rtcweb/current/msg01172.html mail thread discussion. Could= you please provide your valuable comments. Thanks Partha -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 Sent: Monday=2C October 03=2C 2011 7:56 PM To: Ravindran Parthasarathi Cc: Ravindran Parthasarathi Subject: New Version Notification for draft-partha-rtcweb-signaling-00.txt A new version of I-D=2C draft-partha-rtcweb-signaling-00.txt has been succe= ssfully submitted by Parthasarathi Ravindran and posted to the IETF reposit= ory. Filename: draft-partha-rtcweb-signaling Revision: 00 Title: RTCWeb standard signaling protocol Creation date: 2011-10-03 WG ID: Individual Submission Number of pages: 8 Abstract: The standardization of Real time communication between browsers is to provide the infrastructure for audio=2C video=2C text communication usin= g standard interface so that interoperable communication can be established between any compatible browsers. RTCWeb specific Javascript API will be provided by browsers for developing real-time web application. It is possible to develop signaling protocol like Session Initiation Protocol (SIP) or Jingle or websocket extension or custom-made signaling protocol in Javascript. There are lots of issues in Javascript based signaling protocol. This document list the need for standard signaling protocol between RTCWeb client (browser) and RTCWeb server and possible signaling protocol for the same. = =20 The IETF Secretariat _______________________________________________ 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 = --_f7cacf1d-3619-48e0-bf25-836fd5979a43_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Agree with Harald on this. =3B =3B Debating which alternative is "t= he best" is a distraction. =3B One of the major advantages of RTCWEB is= the flexibility it provides with respect to signaling. =3B

Date: Tue=2C 4 Oct 2011 10:21:54 +0200
From: h= arald@alvestrand.no
To: rtcweb@ietf.org
Subject: Re: [rtcweb] Review = request for RTCWeb standard signaling protocol

=20 =20 =20 =20 Ravindran=2C

the core part of your document seems to me to be this list:

   The following Signaling protocols will qualify for becom=
ing standard
   RTCWeb signaling protocol

   1.  Jingle
   2.  Websocket with SDP offer/answer
   3.  SIP
   4.  SIPLite [I-D.cbran-rtc=
web-protocols]
   5.  Websocket with custom XML
   6.  Megaco [RFC=
5125]
   7.  Websocket with SIP [=
I-D.ibc-rtcweb-sip-websocket]
   8.  HTTP with custom XML
   9.  ???

   TBD: Pros and cons for each of the signaling mechanism has to be
   added

My reading of your document is that you want the RTCWEB working group to pick exactly one of these alternatives=2C and insist that all conformant implementations of RTCWEB support this protocol.

I disagree with:

a) that this is needed
b) that this is a good idea

The reasons why it is not a good idea have been raised multiple times=2C and spending continued effort on trying to debate which of the alternatives you list above is "the best one" is distracting to our purpose of getting the RTCWEB protocol suite done.

I do not support pursuing your suggested direction of work in this working group.

 =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B Harald





On 10/03/2011 04:41 PM=2C Ravindran Parthasarathi wrote: 
Hi all=2C

RTCWeb standard signaling protocol (http://tools.ietf.org/html/draft-partha-rtcweb-signaling-00=
) draft list the need for standard signaling protocol between RTCWeb client=
 (browser) and RTCWeb server and the possible signaling protocol for the sa=
me. This draft is written based on http://www.ietf.org/mail-archive/web/rtcweb/current/msg0117=
2.html mail thread discussion. Could you please provide your valuable c=
omments.

Thanks
Partha

-----Original Message-----
From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.=
org]=20
Sent: Monday=2C October 03=2C 2011 7:56 PM
To: Ravindran Parthasarathi
Cc: Ravindran Parthasarathi
Subject: New Version Notification for draft-partha-rtcweb-signaling-00.txt

A new version of I-D=2C draft-partha-rtcweb-signaling-00.txt has been succe=
ssfully submitted by Parthasarathi Ravindran and posted to the IETF reposit=
ory.

Filename:	 draft-partha-rtcweb-signaling
Revision:	 00
Title:		 RTCWeb standard signaling protocol
Creation date:	 2011-10-03
WG ID:		 Individual Submission
Number of pages: 8

Abstract:
   The standardization of Real time communication between browsers is to
   provide the infrastructure for audio=2C video=2C text communication usin=
g
   standard interface so that interoperable communication can be
   established between any compatible browsers.  RTCWeb specific
   Javascript API will be provided by browsers for developing real-time
   web application.  It is possible to develop signaling protocol like
   Session Initiation Protocol (SIP) or Jingle or websocket extension or
   custom-made signaling protocol in Javascript.  There are lots of
   issues in Javascript based signaling protocol.  This document list
   the need for standard signaling protocol between RTCWeb client
   (browser) and RTCWeb server and possible signaling protocol for the
   same.

                                                                           =
      =20


The IETF Secretariat
_______________________________________________
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
= --_f7cacf1d-3619-48e0-bf25-836fd5979a43_-- From bernard_aboba@hotmail.com Tue Oct 4 09:44: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 6001A21F8BEE for ; Tue, 4 Oct 2011 09:44:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.196 X-Spam-Level: X-Spam-Status: No, score=-101.196 tagged_above=-999 required=5 tests=[AWL=-0.752, BAYES_00=-2.599, FRT_BELOW2=2.154, 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 05m0-36cv8BC for ; Tue, 4 Oct 2011 09:44:02 -0700 (PDT) Received: from blu0-omc3-s4.blu0.hotmail.com (blu0-omc3-s4.blu0.hotmail.com [65.55.116.79]) by ietfa.amsl.com (Postfix) with ESMTP id 8C39421F8BF3 for ; Tue, 4 Oct 2011 09:44:02 -0700 (PDT) Received: from BLU152-W23 ([65.55.116.74]) by blu0-omc3-s4.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 4 Oct 2011 09:47:08 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_22edb0fd-c8a1-4564-9286-bee206ebf313_" X-Originating-IP: [98.237.179.165] From: Bernard Aboba To: Magnus Westerlund Date: Tue, 4 Oct 2011 09:47:07 -0700 Importance: Normal In-Reply-To: References: <4E8B192E.80809@ericsson.com>, , , MIME-Version: 1.0 X-OriginalArrivalTime: 04 Oct 2011 16:47:08.0271 (UTC) FILETIME=[414627F0:01CC82B5] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Summary of ICE discussion X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 16:44:03 -0000 --_22edb0fd-c8a1-4564-9286-bee206ebf313_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable In particular=2C I'm concerned about vulnerabilities created by multiplexin= g audio and video on the same port. When that is done=2C the ICE procedure l= oses some of its DoS prevention properties. From: bernard_aboba@hotmail.com To: magnus.westerlund@ericsson.com Date: Tue=2C 4 Oct 2011 09:28:34 -0700 CC: rtcweb@ietf.org Subject: Re: [rtcweb] Summary of ICE discussion I think this is a good summary of where we are with respect to ICE=2C and since there are no good alternatives on the table=2C it seems reasonable to move on to the next step.=20 IMHO=2C this would involve a more detailed analysis of the threats and what needs to be done to resolve them.=20 In particular=2C the statement "STUN Connectivity Check MUST have succeeded= " is=20 necessary but not sufficient. We need to get into a discussion of the spe= cific conditions under which media can be sent=2C and what attacks are still possible. For example=2C there exist public STUN servers on the Internet= =2C and=20 RTCWEB should not permit the browser to execute a DoS attack on these serve= rs.=20 Also=2C it would be desirable to prevent a browser from sending much more bandwidth than the receiver has consented to=3B however=2C because signali= ng is largely opaque to the browser=2C it is not obvious (at least to me) how = to=20 prevent this.=20 > 2011/10/4 Magnus Westerlund : > I have bellow tired to summarize the result of the ICE discussion. This > is intended as furthering this discussion and form a basis for going > forward in the consensus process. I do expect people that disagree with > my summary of the discussion to speak up. > > Major requirements > > - Need for data transmission consent for protocols using UDP as the > traffic receiver needs to consent to receiving the data > > - Perform NAT and FW traversal when ever needed > > - Support IPv4 to IPv6 transition > > Desired behavior: > > - Be interoperable with deployed legacy systems as SIP Trunk=2C PSTN > gateways=2C VoIP phones. >=20 > WG chairs conclusion of discussion so far: >=20 > - ICE is so far the only solution that provides the security goals and > have any legacy deployment. > > - ICE usage will require that STUN connectivity MUST have succeeded > prior to any data transmission to fulfill security goals. > > * The Browser will enforce this requirement to prevent being an attack > vector in all cases. > > - If anyone can find a solution that fulfill the security goals and have > improved legacy interoperability people would be interested in that > solution. So far RTCP has been discarded as insufficient. > > - Media Gateway can support a reduced functionality set from Full ICE =20 _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb = --_22edb0fd-c8a1-4564-9286-bee206ebf313_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
In particular=2C I'm concerned about vulnerabilities created by multiplexin= g
audio and video on the same port. =3B When that is done=2C the ICE= procedure loses
some of its DoS prevention properties.

From: bernard_aboba@hotmail.com
To: magnus.westerlun= d@ericsson.com
Date: Tue=2C 4 Oct 2011 09:28:34 -0700
CC: rtcweb@ietf= .org
Subject: Re: [rtcweb] Summary of ICE discussion

I think this is a good summary of where we are with respect to ICE=2C andsince there are no good alternatives on the table=2C it seems reasonable = to
move on to the next step.

IMHO=2C this would involve a more d= etailed analysis of the threats and what
needs to be done to resolve the= m.

In particular=2C the statement "STUN Connectivity Check MUST hav= e succeeded" is
necessary but not sufficient. =3B =3B We need t= o get into a discussion of the specific
conditions under which media can= be sent=2C and what attacks are still
possible. =3B For example=2C = there exist public STUN servers on the Internet=2C and
RTCWEB should no= t permit the browser to execute a DoS attack on these servers.
Also=2C = it would be desirable to prevent a browser from sending much more
bandwi= dth than the receiver has consented to=3B =3B however=2C because signal= ing
is largely opaque to the browser=2C it is not obvious (at least to m= e) how to
prevent this.

>=3B 2011/10/4 Magnus Westerlund= <=3Bmagnus.westerlund@ericsson.com>=3B:
>=3B I have bellow tired = to summarize the result of the ICE discussion. This
>=3B is intended a= s furthering this discussion and form a basis for going
>=3B forward i= n the consensus process. I do expect people that disagree with
>=3B my= summary of the discussion to speak up.
>=3B
>=3B Major requireme= nts
>=3B
>=3B - Need for data transmission consent for protocols = using UDP as the
>=3B traffic receiver needs to consent to receiving t= he data
>=3B
>=3B - Perform NAT and FW traversal when ever needed=
>=3B
>=3B - Support IPv4 to IPv6 transition
>=3B
>=3B = Desired behavior:
>=3B
>=3B - Be interoperable with deployed lega= cy systems as SIP Trunk=2C PSTN
>=3B gateways=2C VoIP phones.
>= =3B
>=3B WG chairs conclusion of discussion so far:
>=3B
>= =3B - ICE is so far the only solution that provides the security goals and<= br>>=3B have any legacy deployment.
>=3B
>=3B - ICE usage will = require that STUN connectivity MUST have succeeded
>=3B prior to any d= ata transmission to fulfill security goals.
>=3B
>=3B =3B * T= he Browser will enforce this requirement to prevent being an attack
>= =3B vector in all cases.
>=3B
>=3B - If anyone can find a solutio= n that fulfill the security goals and have
>=3B improved legacy intero= perability people would be interested in that
>=3B solution. So far RT= CP has been discarded as insufficient.
>=3B
>=3B - Media Gateway = can support a reduced functionality set from Full ICE

=

_______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
= --_22edb0fd-c8a1-4564-9286-bee206ebf313_-- From bernard_aboba@hotmail.com Tue Oct 4 11:16: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 97EEB21F8E6C for ; Tue, 4 Oct 2011 11:16:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.147 X-Spam-Level: X-Spam-Status: No, score=-102.147 tagged_above=-999 required=5 tests=[AWL=0.451, 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 8nJGp-R8kti2 for ; Tue, 4 Oct 2011 11:16:18 -0700 (PDT) Received: from blu0-omc4-s29.blu0.hotmail.com (blu0-omc4-s29.blu0.hotmail.com [65.55.111.168]) by ietfa.amsl.com (Postfix) with ESMTP id 0FC1C21F8E5C for ; Tue, 4 Oct 2011 11:16:17 -0700 (PDT) Received: from BLU152-W4 ([65.55.111.137]) by blu0-omc4-s29.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 4 Oct 2011 11:19:23 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_54bf6827-253a-4185-a115-796ae25e567f_" X-Originating-IP: [98.237.179.165] From: Bernard Aboba To: , Date: Tue, 4 Oct 2011 11:19:22 -0700 Importance: Normal In-Reply-To: <4E8B1B86.2080805@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>, <2E239D6FCD033C4BAF15F386A979BF510F137B@sonusinmail02.sonusnet.com>, <226C9800-9791-465A-B519-40935E2D135F@phonefromhere.com>, <4E8B1B86.2080805@jesup.org> MIME-Version: 1.0 X-OriginalArrivalTime: 04 Oct 2011 18:19:23.0316 (UTC) FILETIME=[246AFF40:01CC82C2] 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, 04 Oct 2011 18:16:18 -0000 --_54bf6827-253a-4185-a115-796ae25e567f_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [BA] I think this is the main point. If we finish RTCWEB 1.0 expeditious= ly=2C this will in all likelihood spawn a number of browser-independent signaling libraries=2C as well as dev= eloping a wealth of experience with the limitations of RFCWEB 1.0=2C to inform future efforts.=20 The alternative is to "load up the camel" until it collapses under the weig= ht of (largely irrelevant) use cases. Since the realtime web has been around for over a decade=2C we have= a pretty good idea of what native realtime capabilities would be used for -- and PSTN connectivity has= never been high on the list. > Yes=2C this is critical. We need to finish it. I'd rather have it=20 > finished and a strong project to build a "standard" external JS library=20 > under way than to have the whole thing wait. But if I had my druthers=20 > (what the bleep are those=2C anyways?) I'd have an optional signaling=20 > protocol available. = --_54bf6827-253a-4185-a115-796ae25e567f_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
[BA] =3B I think this is the main point. =3B =3B If we finish R= TCWEB 1.0 expeditiously=2C this will in all likelihood
spawn a number of= browser-independent signaling libraries=2C as well as developing a wealth = of experience
with the limitations of RFCWEB 1.0=2C to inform future eff= orts.

The alternative is to "load up the camel" until it collapses = under the weight of (largely irrelevant) use
cases. =3B Since the re= altime web has been around for over a decade=2C we have a pretty good idea = of what
native realtime capabilities would be used for -- and PSTN conne= ctivity has never been high on the list.


>=3B Yes=2C this= is critical. We need to finish it. I'd rather have it
>=3B finishe= d and a strong project to build a "standard" external JS library
>=3B= under way than to have the whole thing wait. But if I had my druthers >=3B (what the bleep are those=2C anyways?) I'd have an optional signali= ng
>=3B protocol available.

= --_54bf6827-253a-4185-a115-796ae25e567f_-- From ibc@aliax.net Tue Oct 4 15:29: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 202C821F8F2B for ; Tue, 4 Oct 2011 15:29:45 -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.044, 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 SpL7U6qpOXS0 for ; Tue, 4 Oct 2011 15:29: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 80EB821F8E76 for ; Tue, 4 Oct 2011 15:29:44 -0700 (PDT) Received: by vws5 with SMTP id 5so1071113vws.31 for ; Tue, 04 Oct 2011 15:32:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.23.4 with SMTP id i4mr1631136vdf.514.1317767570389; Tue, 04 Oct 2011 15:32:50 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Tue, 4 Oct 2011 15:32:50 -0700 (PDT) In-Reply-To: References: Date: Wed, 5 Oct 2011 00:32:50 +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] Making progress on the signaling discussion (NB: Action items enclosed!) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 22:29:45 -0000 2011/10/4 Ted Hardie : > At today's Chairs call, Cullen, Magnus and I had a discussion of how to m= ake > progress on the signaling discussion.=C2=A0 We feel the mailing list disc= ussion > needs to have more concrete proposals in order to make progress, and so > we're putting forward the following: > > 1) If you plan to put forward a draft proposing a concrete solution in th= is > space, please send your name to the mailing list with that intent by Octo= ber > 7th *THIS FRIDAY* Hi Ted, could you please explain what exactly are you looking for? a concrete signaling mechanism within rtcweb? something native in browsers? something carried by HTTP/WebSocket? If so, I think that this should not be covered by rtcweb, which instead should define a good API for dealing with SDP bodies (plain or XML), create some kind of JavaScript object for mantaining each session status and information (negotiated streams, codecs, local/remote address...). But for sure I miss something so I would like to know what exactly are you looking for in your mail. Thanks a lot. --=20 I=C3=B1aki Baz Castillo From fluffy@cisco.com Tue Oct 4 15:37: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 34DB721F8467 for ; Tue, 4 Oct 2011 15:37:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.041 X-Spam-Level: X-Spam-Status: No, score=-103.041 tagged_above=-999 required=5 tests=[AWL=-0.442, 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 6B-2CDko2Ndi for ; Tue, 4 Oct 2011 15:37:04 -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 D803221F841D for ; Tue, 4 Oct 2011 15:37:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=555; q=dns/txt; s=iport; t=1317768011; x=1318977611; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=6KCqTRfzTQGPJJoZOAtqd9dH6CCzUUlsEvDxjB6478w=; b=Lc1ezyzg62iQQB1Q/JZrarWz3qaGrKg7r2IQGBDH8yDKgXNSY/6pg3aL d16V9q0qjIcuB8mLKED89cfs6P/VfYmICPZwzs3c2gzL1ocGtiBE5YCDt rb7WvgxtRKLWmoysI+MjaDNPPnz4AWnNBBRtjOwD6TfW7K232NZXhb0x1 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAKiKi06rRDoI/2dsb2JhbABCqAuBBYFTAQEBAQIBEgEnPwULCzAWVwYBNIdbmWoBnWyEF4IrYQSHeItuhSeMOg X-IronPort-AV: E=Sophos;i="4.68,487,1312156800"; d="scan'208";a="5949465" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 04 Oct 2011 22:40:11 +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 p94MeAeu031950; Tue, 4 Oct 2011 22:40:10 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: Date: Tue, 4 Oct 2011 16:40:09 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <4CEEC8BB-FC3D-4424-A2D6-D5F96E3DDBDE@cisco.com> References: <4E8B192E.80809@ericsson.com>, To: Bernard Aboba , Paul Hoffman X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Summary of ICE discussion X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 22:37:06 -0000 On Oct 4, 2011, at 10:28 AM, Bernard Aboba wrote: > For example, there exist public STUN servers on the Internet, and=20 > RTCWEB should not permit the browser to execute a DoS attack on these = servers.=20 Note that when STUN was designed, we did some experiments and found that = adding passwords to STUN made it easier to DOS the servers even if you = did not know the password than just having the STUN server respond with = no password. Paul Hoffman (CC'd) might have some interesting stats about = operating a public STUN server.=20 From fluffy@cisco.com Tue Oct 4 15:37:49 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 656B421F8467 for ; Tue, 4 Oct 2011 15:37:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.961 X-Spam-Level: X-Spam-Status: No, score=-101.961 tagged_above=-999 required=5 tests=[AWL=-1.516, BAYES_00=-2.599, FRT_BELOW2=2.154, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Kcl6mkOd2Cv for ; Tue, 4 Oct 2011 15:37:48 -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 E5DE921F84AE for ; Tue, 4 Oct 2011 15:37:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=3301; q=dns/txt; s=iport; t=1317768055; x=1318977655; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=WnqNnx4exeglKaqMFFs/ZIRk34wEe8RV29xrI4obrNI=; b=Ojn31aIMRBhCW7dIy2B7KmYdPy7hqvhhsIwdcgKwAbniGM66yaiEe6VJ ol+JGMS1i/cjEIx9gS98vGdoHS2X4maCvffRFWzxnrhDKwfLEDOdxq7c7 tkfV3T1PJoTGw7Xbr3RStLZwySLMTIbhYljxXeURhfaEMQLHUgQ5j+sL+ A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq4IAHaKi06rRDoI/2dsb2JhbABCmQaPBYEFgVMBAQEBAgEBAQEPASc0CwULCxEDAQIvJygIBhMbB4dbBpltAZ1pA4ZCYQSHeItuhSeEeYdB X-IronPort-AV: E=Sophos;i="4.68,487,1312156800"; d="scan'208";a="5943980" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 04 Oct 2011 22:40:54 +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 p94MeAev031950; Tue, 4 Oct 2011 22:40:54 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: Date: Tue, 4 Oct 2011 16:40:53 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <37C37EE6-3D48-4C77-A025-3207F040572B@cisco.com> References: <4E8B192E.80809@ericsson.com>, , , To: Bernard Aboba X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Summary of ICE discussion X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 22:37:49 -0000 Could you say more... I'm not following your logic. On Oct 4, 2011, at 10:47 AM, Bernard Aboba wrote: > In particular, I'm concerned about vulnerabilities created by = multiplexing > audio and video on the same port. When that is done, the ICE = procedure loses > some of its DoS prevention properties. >=20 > From: bernard_aboba@hotmail.com > To: magnus.westerlund@ericsson.com > Date: Tue, 4 Oct 2011 09:28:34 -0700 > CC: rtcweb@ietf.org > Subject: Re: [rtcweb] Summary of ICE discussion >=20 > I think this is a good summary of where we are with respect to ICE, = and > since there are no good alternatives on the table, it seems reasonable = to > move on to the next step.=20 >=20 > IMHO, this would involve a more detailed analysis of the threats and = what > needs to be done to resolve them.=20 >=20 > In particular, the statement "STUN Connectivity Check MUST have = succeeded" is=20 > necessary but not sufficient. We need to get into a discussion of = the specific > conditions under which media can be sent, and what attacks are still > possible. For example, there exist public STUN servers on the = Internet, and=20 > RTCWEB should not permit the browser to execute a DoS attack on these = servers.=20 > Also, it would be desirable to prevent a browser from sending much = more > bandwidth than the receiver has consented to; however, because = signaling > is largely opaque to the browser, it is not obvious (at least to me) = how to=20 > prevent this.=20 >=20 > > 2011/10/4 Magnus Westerlund : > > I have bellow tired to summarize the result of the ICE discussion. = This > > is intended as furthering this discussion and form a basis for going > > forward in the consensus process. I do expect people that disagree = with > > my summary of the discussion to speak up. > > > > Major requirements > > > > - Need for data transmission consent for protocols using UDP as the > > traffic receiver needs to consent to receiving the data > > > > - Perform NAT and FW traversal when ever needed > > > > - Support IPv4 to IPv6 transition > > > > Desired behavior: > > > > - Be interoperable with deployed legacy systems as SIP Trunk, PSTN > > gateways, VoIP phones. > >=20 > > WG chairs conclusion of discussion so far: > >=20 > > - ICE is so far the only solution that provides the security goals = and > > have any legacy deployment. > > > > - ICE usage will require that STUN connectivity MUST have succeeded > > prior to any data transmission to fulfill security goals. > > > > * The Browser will enforce this requirement to prevent being an = attack > > vector in all cases. > > > > - If anyone can find a solution that fulfill the security goals and = have > > improved legacy interoperability people would be interested in that > > solution. So far RTCP has been discarded as insufficient. > > > > - Media Gateway can support a reduced functionality set from Full = ICE >=20 >=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 fluffy@cisco.com Tue Oct 4 15: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 C14A921F8D43 for ; Tue, 4 Oct 2011 15:53:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.027 X-Spam-Level: X-Spam-Status: No, score=-103.027 tagged_above=-999 required=5 tests=[AWL=-0.428, 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 Ifcaoe1DTZiF for ; Tue, 4 Oct 2011 15:53:13 -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 0654F21F8CBB for ; Tue, 4 Oct 2011 15:53:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=1259; q=dns/txt; s=iport; t=1317768979; x=1318978579; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=y3E5DStYe1HUPoNQ8CUSSYVm6//+1auHZXdtsQ53w8A=; b=AkFmgKS1iL1Z3RPGpf1nDFDdy4TU7HfGXaXFEuqCLMb8mgG0WLkMV5oa SwRWS6PUhy7Oxgz8IpLf0n6/qc4ODbvXMGCgmfdIyXd3o6oyPJkA8EVh/ qBhkjTQQ3mnc5ANKgj0JTYJnEHVRFLntcmmI2aSQxy2EVy0QIe9OzNEmI 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FAMmNi06rRDoJ/2dsb2JhbABCpleBNIEFgVMBAQEBAxIBJz8QCzsLVwY1oToBnWyGQmEEh3iLboUnjDo X-IronPort-AV: E=Sophos;i="4.68,487,1312156800"; d="scan'208";a="5947442" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 04 Oct 2011 22:56:19 +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 p94MuI8o010149; Tue, 4 Oct 2011 22:56:18 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: Date: Tue, 4 Oct 2011 16:56:18 -0600 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>, <2E239D6FCD033C4BAF15F386A979BF510F137B@sonusinmail02.sonusnet.com>, <226C9800-9791-465A-B519-40935E2D135F@phonefromhere.com>, <4E8B1B86.2080805@jesup.org> To: Bernard Aboba 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: Tue, 04 Oct 2011 22:53:13 -0000 On Oct 4, 2011, at 12:19 PM, Bernard Aboba wrote: > [BA] I think this is the main point. If we finish RTCWEB 1.0 = expeditiously, this will in all likelihood > spawn a number of browser-independent signaling libraries, as well as = developing a wealth of experience > with the limitations of RFCWEB 1.0, to inform future efforts.=20 >=20 > The alternative is to "load up the camel" until it collapses under the = weight of (largely irrelevant) use > cases. Since the realtime web has been around for over a decade, we = have a pretty good idea of what > native realtime capabilities would be used for -- and PSTN = connectivity has never been high on the list. So uh, you are right we have a lot of experience with real time = communications on the internet. Things that come to mind over the last = ten years include Microsoft Voice.NET, Vonage, Dialpad, Telio, CBeyond, = Skype, Yahoo Messenger, Fring, Google Voice, Webex. That's not a = systematic sample but just some random things that came to my mind. = Oddly, they all seem to connect with the PSTN. What are the things you = are thinking of that decided that PSTN connectivity was not high on the = list? Perhaps we can look at which ones ended up being successful.=20 From ted.ietf@gmail.com Tue Oct 4 17:03: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 B257921F8DAB for ; Tue, 4 Oct 2011 17:03:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.359 X-Spam-Level: X-Spam-Status: No, score=-3.359 tagged_above=-999 required=5 tests=[AWL=-0.061, 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 vgmQUZHbtB-h for ; Tue, 4 Oct 2011 17:03:34 -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 E711E21F8DA9 for ; Tue, 4 Oct 2011 17:03:33 -0700 (PDT) Received: by gyd12 with SMTP id 12so1236221gyd.31 for ; Tue, 04 Oct 2011 17:06:39 -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=a4+GdpWuU9wdEEGc/K3gN4wYG5fQHyDf6J07/7Alxa0=; b=TQuejoHJxmskMamMwVapREEVAAmgezR7n6qa41k7hjFZ0eVd5aXa+3y5KLsGPzzaef WqqPjh9fLvjad1GHEZW6AGvBeVHaWn6m31wvt3R2a2rgNseJxXyvJJ+9jJyrqQp8q8iK 8WEiOiLmQGCMBF1+rpB7SI03ZxXQvrIg9dHKg= MIME-Version: 1.0 Received: by 10.236.176.130 with SMTP id b2mr355271yhm.57.1317773199170; Tue, 04 Oct 2011 17:06:39 -0700 (PDT) Received: by 10.236.105.169 with HTTP; Tue, 4 Oct 2011 17:06:39 -0700 (PDT) In-Reply-To: References: Date: Tue, 4 Oct 2011 17:06:39 -0700 Message-ID: From: Ted Hardie To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=20cf303f65126e5d8b04ae81fba8 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Making progress on the signaling discussion (NB: Action items enclosed!) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 00:03:34 -0000 --20cf303f65126e5d8b04ae81fba8 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Oct 4, 2011 at 3:32 PM, I=F1aki Baz Castillo wrote: > 2011/10/4 Ted Hardie : > > At today's Chairs call, Cullen, Magnus and I had a discussion of how to > make > > progress on the signaling discussion. We feel the mailing list > discussion > > needs to have more concrete proposals in order to make progress, and so > > we're putting forward the following: > > > > 1) If you plan to put forward a draft proposing a concrete solution in > this > > space, please send your name to the mailing list with that intent by > October > > 7th *THIS FRIDAY* > > Hi Ted, could you please explain what exactly are you looking for? a > concrete signaling mechanism within rtcweb? something native in > browsers? something carried by HTTP/WebSocket? > > Hi I=F1aki, The chairs don't currently detect consensus on how signaling will be handle= d for RTCWeb sessions. We don't want to circumscribe the solution space, but we do feel that there is a need to have concrete proposals, rather than broad statements like, "it shouldn't be in the component X". Concrete proposals for how it will be handled are the best way we see to make sure folks are coming to consensus on something they understand, rather than on rhetoric. > If so, I think that this should not be covered by rtcweb, which > instead should define a good API for dealing with SDP bodies (plain or > XML), create some kind of JavaScript object for mantaining each > session status and information (negotiated streams, codecs, > local/remote address...). > > If you would like to make a concrete proposal for how that JavaScript objec= t is constructed, what it contains, and how it is shipped around, that would be great. Without a statement of what those details are, however, the chairs worry that people will argue (for and against) proposals that have not been made. We await your electrons with great interest! Ted > But for sure I miss something so I would like to know what exactly are > you looking for in your mail. > > Thanks a lot. > > > -- > I=F1aki Baz Castillo > > --20cf303f65126e5d8b04ae81fba8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Oct 4, 2011 at 3:32 PM, I=F1aki Baz Castillo <= ibc@aliax.net> wrote:
2011/10/4 Ted Hardie <ted.ietf@gma= il.com>:
> At today's Chairs call, Cullen, Magnus and I had= a discussion of how to make
> progress on the signaling discussion.=A0 We feel the mailing list disc= ussion
> needs to have more concrete proposals in order to make progress, and s= o
> we're putting forward the following:
>
> 1) If you plan to put forward a draft proposing a concrete solution in= this
> space, please send your name to the mailing list with that intent by O= ctober
> 7th *THIS FRIDAY*

Hi Ted, could you please explain what exactly are you looking for? a<= br> concrete signaling mechanism within rtcweb? something native in
browsers? something carried by HTTP/WebSocket?


Hi I=F1aki,

The chairs don't currently= detect consensus on how signaling will be handled for RTCWeb sessions.=A0 = We don't want to circumscribe the solution space, but we do feel that t= here is a need to have concrete proposals, rather than broad statements lik= e, "it shouldn't be in the component X".=A0 Concrete proposal= s for how it will be handled are the best way we see to make sure folks are= coming to consensus on something they understand, rather than on rhetoric.=


=A0
If so, I think that this should not be covered by rtcweb, which
instead should define a good API for dealing with SDP bodies (plain or
XML), create some kind of JavaScript object for mantaining each
session status and information (negotiated streams, codecs,
local/remote address...).


If you would like to make a concrete proposal for= how that JavaScript object is constructed, what it contains, and how it is= shipped around, that would be great.=A0=A0 Without a statement of what tho= se details are, however, the chairs worry that people will argue (for and a= gainst) proposals that have not been made.=A0

We await your electrons with great interest!

Ted
=A0
But for sure I miss something so I would like to know what exactly are
you looking for in your mail.

Thanks a lot.


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

--20cf303f65126e5d8b04ae81fba8-- From matthew.kaufman@skype.net Tue Oct 4 19:14:12 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1B6421F8C2F for ; Tue, 4 Oct 2011 19:14:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.587 X-Spam-Level: X-Spam-Status: No, score=-5.587 tagged_above=-999 required=5 tests=[AWL=1.012, 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 XOLWeNY+obZt for ; Tue, 4 Oct 2011 19:14:11 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id 0798421F8C28 for ; Tue, 4 Oct 2011 19:14:11 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id 6ED0A16F6; Wed, 5 Oct 2011 04:17:15 +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=wVUHyOQtyBEd0h h+6j8qBW3StL8=; b=CuiNneJs63MO+EGkySJMKGJbYqGWnR0DR00A6Mu0O4qJHM BEAu3+JAPUzBHfi9PM37pdz0UQ48dxpF7fJPI8ypl2sEm5j/bBF8A/w34CUXzPtZ 2ZciXUuwX6ChbbsJSW/Vq/XmgMpFLpLb7pPpzZaiVHVBVOiNYv+x0N1J+LQI4= 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=Pl0VPx51qlxXr45bF3d94i H50Ybs3he3mBCbmRqrHKk/ggmLqJVof9cz1wFNW1hCiSg9TtepvB//RdZfcuqR4w 6whkbzezyto5Y0sjnPpQL8wSSpS5sinp5P2cuDoJcwP1kQlwqS64udapNEbwv3LN gyyRFBlfsEzZBJbQeO1qE= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id 6D41C7FC; Wed, 5 Oct 2011 04:17:15 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id 48D503506F2C; Wed, 5 Oct 2011 04:17:15 +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 JBlbMxgpZPx1; Wed, 5 Oct 2011 04:17:14 +0200 (CEST) Received: from [10.10.155.2] (unknown [198.202.199.254]) by zimbra.skype.net (Postfix) with ESMTPSA id C9B333506E4D; Wed, 5 Oct 2011 04:17:13 +0200 (CEST) Message-ID: <4E8BBDDF.3010100@skype.net> Date: Tue, 04 Oct 2011 19:15:59 -0700 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Ted Hardie 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] Making progress on the signaling discussion (NB: Action items enclosed!) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 02:14:12 -0000 On 10/4/2011 9:01 AM, Ted Hardie wrote: > At today's Chairs call, Cullen, Magnus and I had a discussion of how > to make progress on the signaling discussion. We feel the mailing > list discussion needs to have more concrete proposals in order to make > progress, and so we're putting forward the following: > > 1) If you plan to put forward a draft proposing a concrete solution in > this space, please send your name to the mailing list with that intent > by October 7th *THIS FRIDAY*. I'm going to nominate myself here. > > 2) Please have a -00 draft out for discussion by October 14th (the > following Friday). This is to allow for a discussion and update prior > to the -01 deadlines. > I believe that defining a signaling protocol between web browsers and web servers for RTCWEB is out of scope, so I believe there is no draft required... unless you really want a -00 draft that says "do nothing". I believe that defining a signaling protocol between web servers and other web servers for RTCWEB federation is out for scope for "version 1", so I believe it is not appropriate to submit a draft at this time... unless you really want a -00 draft that says "do nothing for now, use any of the existing protocols until then." > > This is aggressive, but we feel we need to have at least -00s for the > different ideas in place in order to make real progress. > As I pointed out in my presentation at the interim, standardizing the protocol between the web browser and the web server != the protocol between the web browser and the javascript running in it. And so even if you want SDP on the wire, you don't necessarily need SDP in the API... and vice versa. So in this case, I believe standardizing the protocol on the wire for signaling is out of scope. And we're already making good progress on the wire protocol for media (and media consent). Matthew Kaufman From matthew.kaufman@skype.net Tue Oct 4 19: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 6F1E321F8B02 for ; Tue, 4 Oct 2011 19:27:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.616 X-Spam-Level: X-Spam-Status: No, score=-5.616 tagged_above=-999 required=5 tests=[AWL=0.983, 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 4bckR8jwskQj for ; Tue, 4 Oct 2011 19:27:10 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id 97BA821F8B01 for ; Tue, 4 Oct 2011 19:27:10 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id D3CFC16F6; Wed, 5 Oct 2011 04:30:16 +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=ojN35410boJW7j OtOzf0YVeKGd8=; b=rnc5dMXv8a1YS7sBf/Pfm5HmfLow4rm3UdyUdAbLFcMJoM hO962mSwrh7uXlwt65xiCObIoGCPD9FRXSuMZE2qVG7hUXNUwL4hTzLa4bFRyZOQ t3r0lab3+5ZxlwqrywJKL3mXiv2KGrQI9GKUS0FsCm89SmAsARpJDIvVASXsM= 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=L1Y8uow22wFG6w69gYZuNS dUPWoXHk/qkrD8xXD3lXnu4gdYdUyKYmKSanOVjm/MolX4MAyXUr6G5T+XiEP8fs 5l5/BpR1WbqseBBuKnXdaAhlkWuBklpUA3s41+rws61Lt/18F61urZzzAhCfML34 SeqlyRt+P3/n0xDRdfqzg= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id CFDFC7F6; Wed, 5 Oct 2011 04:30:16 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id 9F4C13507097; Wed, 5 Oct 2011 04:30: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 94rCowrVN+fJ; Wed, 5 Oct 2011 04:30:15 +0200 (CEST) Received: from [10.10.155.2] (unknown [198.202.199.254]) by zimbra.skype.net (Postfix) with ESMTPSA id 49BDB350708A; Wed, 5 Oct 2011 04:30:15 +0200 (CEST) Message-ID: <4E8BC0ED.2020001@skype.net> Date: Tue, 04 Oct 2011 19:29:01 -0700 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Roman Shpount References: <545388B3-3189-4291-BD1D-52898B888F3E@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] 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, 05 Oct 2011 02:27:11 -0000 On 9/28/2011 9:12 AM, Roman Shpount wrote: > Few questions that I have in regard to this: > > > 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? > This stuff is exactly what you'll need to add yet more code to solve if you try to bake SDP offer-answer into the browser to turn it 90% of the way into a SIP phone. And exactly what you *don't* need browser code to solve if it is done elsewhere (for instance, the server might be handling the entire SIP and SDP exchange and resolve forking issues at that end without involving the client at all.) Matthew Kaufman From matthew.kaufman@skype.net Tue Oct 4 19:35: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 7832921F8BAB for ; Tue, 4 Oct 2011 19:35:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.493 X-Spam-Level: X-Spam-Status: No, score=-5.493 tagged_above=-999 required=5 tests=[AWL=0.806, 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 eR+y1D05cDNj for ; Tue, 4 Oct 2011 19:35:57 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id 7B08721F8B55 for ; Tue, 4 Oct 2011 19:35:57 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id B8B8316F6; Wed, 5 Oct 2011 04:39:03 +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=ApUzifAnkTMACW HoDT1B28vThQo=; b=oDA5mcPKLyS3a2Ly0VBTxN1ojGi9uIN22WIE6YOSWitURu lOweo8fLEbss/Ps84z11O3l1cMNQfM300kbgq0s5/sT1O/q90MVS6WBgt7gxYvM3 LzWEMMMIZSslXCD0Ivk18yebSCxLMYafINkys2c1ZKbBJknblyTE8ZrE95paY= 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=CUqI6VYdSf/yBvuCYyGLeq ayN2LXoU3FEDGLuX0PuHlkO90Fr9qc8mYU6HdkRYDAnEEerrZ54h7r8wlQzzEwy/ bOLIIWCiPBFmguNA5nkd0SdNKva+44fmWzCuXfmnduwebR3t8J442K6kWbRBUxVz xUT7yYN0QUGCi2y2ZaEa4= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id B325C7F6; Wed, 5 Oct 2011 04:39:03 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id 8FB7C3506EF4; Wed, 5 Oct 2011 04:39:03 +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 MOi1TGWrz7PD; Wed, 5 Oct 2011 04:39:02 +0200 (CEST) Received: from [10.10.155.2] (unknown [198.202.199.254]) by zimbra.skype.net (Postfix) with ESMTPSA id 188B53506E4D; Wed, 5 Oct 2011 04:39:01 +0200 (CEST) Message-ID: <4E8BC2FC.2000809@skype.net> Date: Tue, 04 Oct 2011 19:37:48 -0700 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= References: <545388B3-3189-4291-BD1D-52898B888F3E@phonefromhere.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed 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: Wed, 05 Oct 2011 02:35:58 -0000 On 9/30/2011 12:46 PM, I=C3=B1aki Baz Castillo wrote: > 2011/9/28 Tim Panton: >> I just want to ask folks to take a look at a proposal Neil Stratford w= rote 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 o= n 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 appr= opriate. > 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). Totally disagree. The API in that document can be used to build every=20 single VoIP application you can build with SIP *plus a bunch more*. This is like claiming that DirectSound is "just valid for a few specific=20 scenarios" when in fact it is a low-level audio API for Win32 systems=20 that can be used to build pretty much anything that wants to play sound. > 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). I think you're saying that the JS API should be some existing protocol=20 standard like SIP and SDP here, yes? It is much easier to discuss if we keep "the wire protocol" and "the JS=20 API" separate... and realize that just like my above Win32 example, a=20 "low level" JS API could in fact be used in conjunction with *any* wire=20 protocol (that you can send/receive within the browser context) plus=20 server behavior. This is also true of the "high level" JS API proposals... it is just=20 more annoying, as you need to do things like trick them into generating=20 an SDP offer, then decode it locally or send it to a server for=20 processing, and then kill that and start the actual connection you=20 wanted while lying to the browser about what the other end has claimed. I'd rather have the API that lets me do what I want directly. > > 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). Yes. And it would also be useful for people offering all types of=20 complex telephony services, including call transfer, parallel forking,=20 and the like... as well as all types of complex *non-telephony* RTC=20 applications, like games. Matthew Kaufman From matthew.kaufman@skype.net Tue Oct 4 19:39: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 D925E21F8B9D for ; Tue, 4 Oct 2011 19:39:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.665 X-Spam-Level: X-Spam-Status: No, score=-5.665 tagged_above=-999 required=5 tests=[AWL=0.933, 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 gvSCDnCFYoqi for ; Tue, 4 Oct 2011 19:39:23 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id 5715221F8B5C for ; Tue, 4 Oct 2011 19:39:21 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id 92BC716FD; Wed, 5 Oct 2011 04:42:27 +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=EwOU94RVHKk43LQefOjbrvE9rL4=; b=cPFLp+ovC L+PLI6jHmf63Xu+fACx7HfX4pM8eCUliQYreVmPrhSg6tEP91nL+o4F5tHGEH5y8 6XRERWtYbk3i9bAX3aBFLjhBYAYn2ln3/OmulTld+2tbqzwFA3wAnWIH97npgzZY F/N7FSRQtvl8HiyZmieYiZ/YUqNcbdo7js= 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=h0APliX22rk3hXYbqX9jH2flJovYeRvY9T4zdLsgsEp25rUE igyky7GWhv65xXKBZzyKw8K0kus/aF+NCIMS0w8gxY5Br+1DFGNjpBjetgAGxPxG KBTkiFk7gxfOdO4ekv8Oy4pgo5voCfpSOOtBBPdSVkrsMHySp4jKSmc3LSI= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id 912E57F6; Wed, 5 Oct 2011 04:42:27 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id 6D0863507097; Wed, 5 Oct 2011 04:42:27 +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 pdrhXDGiXm3u; Wed, 5 Oct 2011 04:42:25 +0200 (CEST) Received: from [10.10.155.2] (unknown [198.202.199.254]) by zimbra.skype.net (Postfix) with ESMTPSA id EFBA93506FFD; Wed, 5 Oct 2011 04:42:24 +0200 (CEST) Message-ID: <4E8BC3C7.4010003@skype.net> Date: Tue, 04 Oct 2011 19:41:11 -0700 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Ted Hardie References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------040706040308040406050808" Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Making progress on the signaling discussion (NB: Action items enclosed!) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 02:39:25 -0000 This is a multi-part message in MIME format. --------------040706040308040406050808 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 10/4/2011 5:06 PM, Ted Hardie wrote: > On Tue, Oct 4, 2011 at 3:32 PM, I=F1aki Baz Castillo > wrote: > > 2011/10/4 Ted Hardie >: > > At today's Chairs call, Cullen, Magnus and I had a discussion of > how to make > > progress on the signaling discussion. We feel the mailing list > discussion > > needs to have more concrete proposals in order to make progress, > and so > > we're putting forward the following: > > > > 1) If you plan to put forward a draft proposing a concrete > solution in this > > space, please send your name to the mailing list with that > intent by October > > 7th *THIS FRIDAY* > > Hi Ted, could you please explain what exactly are you looking for? = a > concrete signaling mechanism within rtcweb? something native in > browsers? something carried by HTTP/WebSocket? > > > Hi I=F1aki, > > The chairs don't currently detect consensus on how signaling will be=20 > handled for RTCWeb sessions. We don't want to circumscribe the=20 > solution space, but we do feel that there is a need to have concrete=20 > proposals, rather than broad statements like, "it shouldn't be in the=20 > component X". Concrete proposals for how it will be handled are the=20 > best way we see to make sure folks are coming to consensus on=20 > something they understand, rather than on rhetoric. See my earlier email. Concrete proposal is: This Working Group does not=20 produce *any* standard for what travels on the wire (as signaling)=20 between an RTC Web Browser and its associated Web Server. This Working=20 Group also does not at this time produce *any* standard for what travels=20 on the wire (as signaling) between two web servers that wish to have=20 interoperating communities of RTC Web Browsers, though the working group=20 *may* address this at a future time, noting that several existing=20 protocols are usable in the interim. > > > If so, I think that this should not be covered by rtcweb, which > instead should define a good API for dealing with SDP bodies (plain= or > XML), create some kind of JavaScript object for mantaining each > session status and information (negotiated streams, codecs, > local/remote address...). > > > If you would like to make a concrete proposal for how that JavaScript=20 > object is constructed, what it contains, and how it is shipped around,=20 > that would be great. Without a statement of what those details are,=20 > however, the chairs worry that people will argue (for and against)=20 > proposals that have not been made. > I believe that a concrete proposal for the JavaScript API and the=20 associated objects is out of scope for the IETF WG. Thus the details,=20 for the purpose of this working group, would be "this is out of scope". Matthew Kaufman --------------040706040308040406050808 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 10/4/2011 5:06 PM, Ted Hardie wrote:
On Tue, Oct 4, 2011 at 3:32 PM, Iñaki Baz Castillo <ibc@aliax.net> wrote:
2011/10/4 Ted Hardie <ted.ietf@gmail.com>:
> At today's Chairs call, Cullen, Magnus and I had a discussion of how to make
> progress on the signaling discussion.  We feel the mailing list discussion
> needs to have more concrete proposals in order to make progress, and so
> we're putting forward the following:
>
> 1) If you plan to put forward a draft proposing a concrete solution in this
> space, please send your name to the mailing list with that intent by October
> 7th *THIS FRIDAY*

Hi Ted, could you please explain what exactly are you looking for? a
concrete signaling mechanism within rtcweb? something native in
browsers? something carried by HTTP/WebSocket?


Hi Iñaki,

The chairs don't currently detect consensus on how signaling will be handled for RTCWeb sessions.  We don't want to circumscribe the solution space, but we do feel that there is a need to have concrete proposals, rather than broad statements like, "it shouldn't be in the component X".  Concrete proposals for how it will be handled are the best way we see to make sure folks are coming to consensus on something they understand, rather than on rhetoric.

See my earlier email. Concrete proposal is: This Working Group does not produce *any* standard for what travels on the wire (as signaling) between an RTC Web Browser and its associated Web Server. This Working Group also does not at this time produce *any* standard for what travels on the wire (as signaling) between two web servers that wish to have interoperating communities of RTC Web Browsers, though the working group *may* address this at a future time, noting that several existing protocols are usable in the interim.



 
If so, I think that this should not be covered by rtcweb, which
instead should define a good API for dealing with SDP bodies (plain or
XML), create some kind of JavaScript object for mantaining each
session status and information (negotiated streams, codecs,
local/remote address...).


If you would like to make a concrete proposal for how that JavaScript object is constructed, what it contains, and how it is shipped around, that would be great.   Without a statement of what those details are, however, the chairs worry that people will argue (for and against) proposals that have not been made. 


I believe that a concrete proposal for the JavaScript API and the associated objects is out of scope for the IETF WG. Thus the details, for the purpose of this working group, would be "this is out of scope".

Matthew Kaufman

--------------040706040308040406050808-- From matthew.kaufman@skype.net Tue Oct 4 19: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 4292221F8BDC for ; Tue, 4 Oct 2011 19:43:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.69 X-Spam-Level: X-Spam-Status: No, score=-5.69 tagged_above=-999 required=5 tests=[AWL=0.909, 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 0novXAtNWG+y for ; Tue, 4 Oct 2011 19:43:17 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id EECC921F8B13 for ; Tue, 4 Oct 2011 19:43:12 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id 40ED416F6; Wed, 5 Oct 2011 04:46: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=b1VcPRINERDpU7 DhER7KINtsQVY=; b=UWsYOP1lqHKte0Bk/2vUl0lmWkXdWTiEK8TBozF1N5qfXh Kbr2nkDajQxikGeLjrwB8UT0yY9wl22FyM6WvChHFWbL/edaSbqNvvwj8g3RkOrp g6S4tRzyjs+3WVDjZzRwGfkW+1QFQLLCIjSINBhck/ycBSnncjunGdBiI7Vfc= 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=D8X8qkA7C7axMjA3LIjIdD GmEZLM0H6Bi4P+xnvmcL/GRIdUV+J3qUomHHpbFjJD4KWtzDSMpTtpKMDDrCFcnz YgvB3NtnJVlC9fqZluWtZL0xdeeHk3MSnAK3qwUB50xK2ELUn9xKA/opgkCNN/3n TQxtERu2hYX+eT/NpWS+Q= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id 3C4A47F6; Wed, 5 Oct 2011 04:46:19 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id 1D2143506F2C; Wed, 5 Oct 2011 04:46: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 IWUqagA1YVBC; Wed, 5 Oct 2011 04:46:18 +0200 (CEST) Received: from [10.10.155.2] (unknown [198.202.199.254]) by zimbra.skype.net (Postfix) with ESMTPSA id C864F3506E4D; Wed, 5 Oct 2011 04:46:17 +0200 (CEST) Message-ID: <4E8BC4AF.30307@skype.net> Date: Tue, 04 Oct 2011 19:45:03 -0700 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Cullen Jennings References: , <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com>, <05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com>, <2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com>, <16880306-5B3A-4EFD-ADE4-1201138D9182@acmepacket.com>, <2E239D6FCD033C4BAF15F386A979BF510F137B@sonusinmail02.sonusnet.com>, <226C9800-9791-465A-B519-40935E2D135F@phonefromhere.com>, <4E8B1B86.2080805@jesup.org> In-Reply-To: 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: Wed, 05 Oct 2011 02:43:18 -0000 On 10/4/2011 3:56 PM, Cullen Jennings wrote: > What are the things you are thinking of that decided that PSTN > connectivity was not high on the list? Perhaps we can look at which > ones ended up being successful. The first one that comes to mind is TeamSpeak. Oh, and Xbox Live VoIP. Neither has PSTN connectivity and I think both fall into the "ended up being successful" camp. Matthew Kaufman From matthew.kaufman@skype.net Tue Oct 4 19:46: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 66AFA21F8BDC for ; Tue, 4 Oct 2011 19:46:25 -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 9v2O-9weorzt for ; Tue, 4 Oct 2011 19:46:24 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id A762F21F8B5C for ; Tue, 4 Oct 2011 19:46:24 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id 0908F16F6; Wed, 5 Oct 2011 04:49:30 +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=8psFImDN4vU/mP tyx6jMZS9Po+U=; b=vAllOgb0smyYtxVycPun4ggDWPvDyOC/Yti9FxmzyBjs0H W+dHBlzR7Kt49bfdPFL1S4I57+qoyH4TrEeIEw/nN8ik/0/E0/ESrBLRrNq72mGk sEx3JSIrPD/oOrIvypPsOK9yenEEEg1y453c/8265aX8Q9Q3eeOHUDMYB8jWE= 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=tFa+e7XATpEDVeE7FnhqNg SoaXrVQsP643B+O6XpobLRsO63N/VkWiZIG1/PGdf+nTiU+Rg5CVixieuycZP3Dk 2j7iQ00LG0kHsjeXC2sFW387m9hHrbVVoNhEXRwns6P9/1UCVJoyMkC1gmhzbglt yJPkfNDXV1F7LMjP0JnO4= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id 03FEF7F6; Wed, 5 Oct 2011 04:49:30 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id BFFD33506FFD; Wed, 5 Oct 2011 04:49:29 +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 GAe1M9eCv8xI; Wed, 5 Oct 2011 04:49:28 +0200 (CEST) Received: from [10.10.155.2] (unknown [198.202.199.254]) by zimbra.skype.net (Postfix) with ESMTPSA id 223223506E4D; Wed, 5 Oct 2011 04:49:27 +0200 (CEST) Message-ID: <4E8BC56E.40306@skype.net> Date: Tue, 04 Oct 2011 19:48:14 -0700 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Cullen Jennings References: <4E8B192E.80809@ericsson.com>, , , <37C37EE6-3D48-4C77-A025-3207F040572B@cisco.com> In-Reply-To: <37C37EE6-3D48-4C77-A025-3207F040572B@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Summary of ICE discussion X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 02:46:25 -0000 On 10/4/2011 3:40 PM, Cullen Jennings wrote: > Could you say more... I'm not following your logic. > > > On Oct 4, 2011, at 10:47 AM, Bernard Aboba wrote: > >> In particular, I'm concerned about vulnerabilities created by multiplexing >> audio and video on the same port. When that is done, the ICE procedure loses >> some of its DoS prevention properties. >> I think what he's concerned about is that a device might consent (using ICE) to receive audio and unexpectedly receive multiplexed video on the same RTP port. Not sure this really matters, as there's not much difference between low-frame-rate low-res video and 16-bit linear stereo PCM at 48 kHz (which might indeed be an audio codec you can choose). Matthew Kaufman From matthew.kaufman@skype.net Tue Oct 4 19: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 E78AD21F8C10 for ; Tue, 4 Oct 2011 19:49:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.735 X-Spam-Level: X-Spam-Status: No, score=-5.735 tagged_above=-999 required=5 tests=[AWL=0.864, 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 xDsBcMCrzfoR for ; Tue, 4 Oct 2011 19:49:23 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id E930B21F8C16 for ; Tue, 4 Oct 2011 19:49:22 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id 3993A16F6; Wed, 5 Oct 2011 04:52:29 +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=SP9ChRO/GQJ/Yx dnoxtPHsiGTfM=; b=qruIMMZ17qN7nibFg0LlqxOf8A+R7s3O7wtdkYYpUpQvC/ y4ByLsbYe16BV8bvd+F7mkjjPiUkEd1zTqtFyQPFqMSIJ0E4SOdl7nWESAXNqyoB PVG4999TwNoogNPOr99hSXvHMiuFKFp1g7AS+POh8CYFVAhB3xcWXqc+AhgV0= 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=k4eKkmUp8o/aTR54U/HjOH 7AaaVIYm8hz4KOEuJw+oqbc2oBJ6aw5/LQ9MNUSBDsXVS1zv/ahY4Qs4ky0/syu+ x9BqW9BpwHTbuc05sFGFIWZUFhuAbB5iBqq1VQ6tol+GiS68Nu2LTM2JMaOcEvx6 w1vEb+BbZUsq40km/tpTM= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id 382BC7F6; Wed, 5 Oct 2011 04:52:29 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id E47CE3506F2C; Wed, 5 Oct 2011 04:52: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 Z3LblZwkUHjH; Wed, 5 Oct 2011 04:52:28 +0200 (CEST) Received: from [10.10.155.2] (unknown [198.202.199.254]) by zimbra.skype.net (Postfix) with ESMTPSA id E30673506E4D; Wed, 5 Oct 2011 04:52:27 +0200 (CEST) Message-ID: <4E8BC621.3030105@skype.net> Date: Tue, 04 Oct 2011 19:51:13 -0700 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Magnus Westerlund References: <4E8B192E.80809@ericsson.com> In-Reply-To: <4E8B192E.80809@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Summary of ICE discussion X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 02:49:24 -0000 I believe this is a correct summary. Agree with Bernard that we need to ensure that the connectivity check as done by ICE doesn't have inadvertent effects on public STUN servers, however my understanding of how the ICE credential mechanism works leads me to believe that this isn't actually a problem, as long as we are clear about what "check succeeded" means when we tell browser vendors how to implement this. Matthew Kaufman From matthew.kaufman@skype.net Tue Oct 4 19:51:16 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8436221F8CBD for ; Tue, 4 Oct 2011 19:51:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.756 X-Spam-Level: X-Spam-Status: No, score=-5.756 tagged_above=-999 required=5 tests=[AWL=0.843, 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 uElTMisVgzjn for ; Tue, 4 Oct 2011 19:51:16 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id B027521F8C10 for ; Tue, 4 Oct 2011 19:50:46 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id 0472416F6; Wed, 5 Oct 2011 04:53:53 +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=4pFjXLyY6vQ37G tWc5eiNl4iNu0=; b=T8XuCVcQV3XxdEmGtnKukbNDCe3b2okajvBTUk6qP7M9b6 j0qMI5z2lYtkH3ZafNiKLVzzLGlR/lLHQy7A2kFKkGi3f+hbFt48cPH9NzqbE/GT hS8KPoqpm+cev8Jl1RfqxwQnQssTQajU26zec/0ija9CceeTOHRvIX0gWaGzY= 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=xPkb7iCyJl4DNa7f6ueEvy cV8Lx7YwLcge/JWvjViEbvnIz3qlDzyx8jEV5PZo7M6WmsKI/nT/U+4visBcqSEM BYsbLC/SKTA6XS9snH5VP05vJqVZk+1ZoEkWDPSmZF8MJ0abzvy8vhQZ6tLRrLB/ Axnn2z6nTh/n9QVPoPJys= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id 02D807F6; Wed, 5 Oct 2011 04:53:53 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id D9C843506F2C; Wed, 5 Oct 2011 04:53:52 +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 zT1jItY6-e5k; Wed, 5 Oct 2011 04:53:52 +0200 (CEST) Received: from [10.10.155.2] (unknown [198.202.199.254]) by zimbra.skype.net (Postfix) with ESMTPSA id 483FA3506E4D; Wed, 5 Oct 2011 04:53:51 +0200 (CEST) Message-ID: <4E8BC675.6060907@skype.net> Date: Tue, 04 Oct 2011 19:52:37 -0700 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Hadriel Kaplan References: <4E8B192E.80809@ericsson.com> <4E8B20BA.3080906@jesup.org> <7EE6A3A6-D628-4EF5-A1E2-FB78C9F8A498@acmepacket.com> In-Reply-To: <7EE6A3A6-D628-4EF5-A1E2-FB78C9F8A498@acmepacket.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Randell Jesup , "" Subject: Re: [rtcweb] Summary of ICE discussion X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 02:51:16 -0000 On 10/4/2011 9:24 AM, Hadriel Kaplan wrote: > requiring a more stringent JS trust model seems worthwhile to me. > Great idea. Already being discussed elsewhere. Out of scope for both of these groups except to note that *if* someone solves the JS trust issue, we might be able to relax the ICE requirement when running applications that are "trusted". I wouldn't be adverse to even saying just that in the requirements document that explains why ICE is needed. Matthew Kaufman From bernard_aboba@hotmail.com Tue Oct 4 20:11: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 7032E21F8B51 for ; Tue, 4 Oct 2011 20:11:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.194 X-Spam-Level: X-Spam-Status: No, score=-101.194 tagged_above=-999 required=5 tests=[AWL=0.009, 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 YGbFMLyP1Er6 for ; Tue, 4 Oct 2011 20:11:44 -0700 (PDT) Received: from snt0-omc4-s49.snt0.hotmail.com (snt0-omc4-s49.snt0.hotmail.com [65.54.51.100]) by ietfa.amsl.com (Postfix) with ESMTP id 047AC21F8B4F for ; Tue, 4 Oct 2011 20:11:43 -0700 (PDT) Received: from SNT0-EAS256 ([65.55.90.199]) by snt0-omc4-s49.snt0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 4 Oct 2011 20:14:50 -0700 X-Originating-IP: [166.205.142.131] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: References: <4E8B192E.80809@ericsson.com> <37C37EE6-3D48-4C77-A025-3207F040572B@cisco.com> <4E8BC56E.40306@skype.net> Content-Transfer-Encoding: quoted-printable From: Bernard Aboba Content-Type: text/plain; charset="us-ascii" In-Reply-To: <4E8BC56E.40306@skype.net> Date: Tue, 4 Oct 2011 20:14:44 -0700 To: Matthew Kaufman MIME-Version: 1.0 (iPhone Mail 8L1) X-OriginalArrivalTime: 05 Oct 2011 03:14:50.0560 (UTC) FILETIME=[F1BF6400:01CC830C] Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Summary of ICE discussion X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 03:11:44 -0000 Right, that's the attack I had in mind, but with high bandwidth video. On Oct 4, 2011, at 7:49 PM, "Matthew Kaufman" wr= ote: > On 10/4/2011 3:40 PM, Cullen Jennings wrote: >> Could you say more... I'm not following your logic. >>=20 >>=20 >> On Oct 4, 2011, at 10:47 AM, Bernard Aboba wrote: >>=20 >>> In particular, I'm concerned about vulnerabilities created by multiplexi= ng >>> audio and video on the same port. When that is done, the ICE procedure l= oses >>> some of its DoS prevention properties. >>>=20 >=20 > I think what he's concerned about is that a device might consent (using IC= E) to receive audio and unexpectedly receive multiplexed video on the same R= TP port. >=20 > Not sure this really matters, as there's not much difference between low-f= rame-rate low-res video and 16-bit linear stereo PCM at 48 kHz (which might i= ndeed be an audio codec you can choose). >=20 > Matthew Kaufman From roman@telurix.com Tue Oct 4 20:16: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 C279221F8B95 for ; Tue, 4 Oct 2011 20:16:29 -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 sm7pi6EscfAD for ; Tue, 4 Oct 2011 20:16:28 -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 B601A21F8B88 for ; Tue, 4 Oct 2011 20:16:23 -0700 (PDT) Received: by gyd12 with SMTP id 12so1390969gyd.31 for ; Tue, 04 Oct 2011 20:19:30 -0700 (PDT) Received: by 10.68.0.4 with SMTP id 4mr14574659pba.23.1317784769712; Tue, 04 Oct 2011 20:19: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 ki1sm2563296pbb.3.2011.10.04.20.19.28 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 04 Oct 2011 20:19:29 -0700 (PDT) Received: by pzk37 with SMTP id 37so3084957pzk.9 for ; Tue, 04 Oct 2011 20:19:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.33.130 with SMTP id r2mr13538893pbi.71.1317784768332; Tue, 04 Oct 2011 20:19:28 -0700 (PDT) Received: by 10.68.47.40 with HTTP; Tue, 4 Oct 2011 20:19:28 -0700 (PDT) In-Reply-To: <4E8BC0ED.2020001@skype.net> References: <545388B3-3189-4291-BD1D-52898B888F3E@phonefromhere.com> <4E8BC0ED.2020001@skype.net> Date: Tue, 4 Oct 2011 23:19:28 -0400 Message-ID: From: Roman Shpount To: Matthew Kaufman Content-Type: multipart/alternative; boundary=bcaec520f61101c4fe04ae84ad9f 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, 05 Oct 2011 03:16:29 -0000 --bcaec520f61101c4fe04ae84ad9f Content-Type: text/plain; charset=ISO-8859-1 On Tue, Oct 4, 2011 at 10:29 PM, Matthew Kaufman wrote: > > This stuff is exactly what you'll need to add yet more code to solve if you > try to bake SDP offer-answer into the browser to turn it 90% of the way into > a SIP phone. > > And exactly what you *don't* need browser code to solve if it is done > elsewhere (for instance, the server might be handling the entire SIP and SDP > exchange and resolve forking issues at that end without involving the client > at all.) > Let me rephrase my questions: 3. If I generate an offer using this API and then send it to the web server, which will deal with SIP end of things, and will get multiple answers in the same dialog, how do I process those answers via this API? What I need is an ability to provide an answer update to the connection. Should I just remove old streams and candidates and add a new ones? 4. Same thing with an offer that created multiple dialogs. I want to clone the connection and add streams and candidates to it. I don't think this is possible with the current API. Few new questions: 5. What is the priority order for generating candidates when multiple STUN/TURN servers are specified? How would this be affected if we also have proxies? I am not sure this is part of any specification so far and probably should be part of RTC spec defined by IETF 6. How do we deal with CODEC negotiated parameters? It is possible to have codec level parameter that needs to be negotiated via offer/answer exchange. There are also codec level parameters that are affected by stream level parameters (like iLBC mode=30 that only makes sense with ptime dividable by 30). Is it going to be implemented in JavaScript? This might not be the best idea, since this will require JavaScript to have a detailed knowledge about each codec implementation provided by the browser. For third party call control, it would be more robust to provide a way to return actual codec parameters selected by the browser so that they can be returned in the answer. _____________ Roman Shpount --bcaec520f61101c4fe04ae84ad9f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Oct 4, 2011 at 10:= 29 PM, Matthew Kaufman <matthew.kaufman@skype.net> wrote:

This stuff is exactly what you'll need to add yet more code to solve if= you try to bake SDP offer-answer into the browser to turn it 90% of the wa= y into a SIP phone.

And exactly what you *don't* need browser code to solve if it is done e= lsewhere (for instance, the server might be handling the entire SIP and SDP= exchange and resolve forking issues at that end without involving the clie= nt at all.)

Let me rephrase my questions:

3. If I generat= e an offer using this API and then send it to the web server, which will de= al with SIP end of things, and will get multiple answers in the same dialog= , how do I process those answers via this API? What I need is an ability to= provide an answer update to the connection. Should I just remove old strea= ms and candidates and add a new ones?

4. Same thing with an offer that created multiple dialogs. I want to cl= one the connection and add streams and candidates to it. I don't think = this is possible with the current API.

Few new questions:

5. What is the priority order for generating candidates when multiple STUN/= TURN servers are specified? How would this be affected if we also have prox= ies? I am not sure this is part of any specification so far and probably sh= ould be part of RTC spec defined by IETF

6. How do we deal with CODEC negotiated parameters? It is possible to h= ave codec level parameter that needs to be negotiated via offer/answer exch= ange. There are also codec level parameters that are affected by stream lev= el parameters (like iLBC mode=3D30 that only makes sense with ptime dividab= le by 30). Is it going to be implemented in JavaScript? This might not be t= he best idea, since this will require JavaScript to have a detailed knowled= ge about each codec implementation provided by the browser. For third party= call control, it would be more robust to provide a way to return actual co= dec parameters selected by the browser so that they can be returned in the = answer.
_____________
Roman Shpount


--bcaec520f61101c4fe04ae84ad9f-- From randell-ietf@jesup.org Tue Oct 4 20:17: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 0B0BD21F8BB0 for ; Tue, 4 Oct 2011 20:17:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.571 X-Spam-Level: X-Spam-Status: No, score=-2.571 tagged_above=-999 required=5 tests=[AWL=0.028, 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 4F9RkM3ubnsJ for ; Tue, 4 Oct 2011 20:17: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 872F421F8BAC for ; Tue, 4 Oct 2011 20:17:53 -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 1RBI2V-0004Q3-7v for rtcweb@ietf.org; Tue, 04 Oct 2011 22:20:59 -0500 Message-ID: <4E8BCC2B.6080907@jesup.org> Date: Tue, 04 Oct 2011 23:16: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: <4E8B192E.80809@ericsson.com> <4E8B20BA.3080906@jesup.org> <7EE6A3A6-D628-4EF5-A1E2-FB78C9F8A498@acmepacket.com> <4E8BC675.6060907@skype.net> In-Reply-To: <4E8BC675.6060907@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: Subject: Re: [rtcweb] Summary of ICE discussion X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 03:17:54 -0000 On 10/4/2011 10:52 PM, Matthew Kaufman wrote: > On 10/4/2011 9:24 AM, Hadriel Kaplan wrote: >> requiring a more stringent JS trust model seems worthwhile to me. >> > > Great idea. Already being discussed elsewhere. Out of scope for both > of these groups except to note that *if* someone solves the JS trust > issue, we might be able to relax the ICE requirement when running > applications that are "trusted". Right; pretty much the "Installed WebApp" model. > > I wouldn't be adverse to even saying just that in the requirements > document that explains why ICE is needed. I'll agree with this approach. (Just to verify: which of many possible places are you referring to it being discussed?) -- Randell Jesup randell-ietf@jesup.org From randell-ietf@jesup.org Tue Oct 4 21:07: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 6B66321F86AA for ; Tue, 4 Oct 2011 21:07:11 -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 FLlwxx67D28R for ; Tue, 4 Oct 2011 21:07:10 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id C51B821F869E for ; Tue, 4 Oct 2011 21:07:10 -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 1RBIoD-0002mp-5S for rtcweb@ietf.org; Tue, 04 Oct 2011 23:10:17 -0500 Message-ID: <4E8BD7B8.3080408@jesup.org> Date: Wed, 05 Oct 2011 00:06:16 -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>, <2E239D6FCD033C4BAF15F386A979BF510F137B@sonusinmail02.sonusnet.com>, <226C9800-9791-465A-B519-40935E2D135F@phonefromhere.com>, <4E8B1B86.2080805@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: Wed, 05 Oct 2011 04:07:11 -0000 On 10/4/2011 2:19 PM, Bernard Aboba wrote: > [BA] I think this is the main point. If we finish RTCWEB 1.0 > expeditiously, this will in all likelihood > spawn a number of browser-independent signaling libraries, as well as > developing a wealth of experience > with the limitations of RFCWEB 1.0, to inform future efforts. > > The alternative is to "load up the camel" until it collapses under the > weight of (largely irrelevant) use > cases. Since the realtime web has been around for over a decade, we have > a pretty good idea of what > native realtime capabilities would be used for -- and PSTN connectivity > has never been high on the list. Well, I'd say that's mildly debatable - VoIP companies chew a lot of bandwidth on the net, and it's almost all going to the PSTN - though it's not in browsers generally. Skype completes a lot of on-net calls - but they make a lot of money (almost all?) from PSTN calls. That said, I don't consider the Skypes of the world a problem here - they can and will roll their own. Same for PBX vendors I suppose, though they'll try to leverage more existing examples. I think there will be a lot of small-to-medium users adding chat, building games, etc, who care little or not at all about the PSTN. Those are the ones who I worry about; they wouldn't realize there are issues with glare (totally ignoring PSTN) or that forking can be complex. They want a simple, one-stop-shopping solution for adding voice/video/data to their sites and games, etc. Yes, people will build JS apps to provide that. I'm worried about the quality of those apps, and that the likely model will be the author downloads a random version when they develop their service, and they never update it. This is a real problem; it is a real problem today with other JS modules. Does this mean we *have* to bake in some sort of signalling? No, it doesn't. It is an _argument_ for providing some type of signalling as a baseline default; or if not, then for starting a project to provide that. Note that I said "baseline". I did *not* say "can handle all the intricacies of the PSTN well". It could be something far simpler than SIP or XMPP, etc, or it could be a very dumbed-down version of one. These small users (as noted) need something to provide the basics, and to handle certain complexities that simply arise from normal usage patterns and features (like forking). Being able to access the PSTN at all using this would be a plus - but it would not be critical in my mind. And, as I mentioned, it could be external JS - but then it has be more solid to start with. For these simple uses - say chat with other users on someones special-interest website, 2 and multiplayer gaming, etc - we should try to pull together the minimum things any app/service developer would need to be prepared for. I think any service that allows someone to log in from multiple devices has to handle forking in some manner. Glare is always possible. What else? I'd like to see simple conferencing. Perhaps the minimum is simple enough that it makes more sense to develop a new, very simple signalling JS module, and use it in examples. This would limit the downside from not updating. The advantage of basing it on something known is that the basics of all these protocols are well-understood. I'll paraphrase Harald (and many others in other contexts): make simple things simple, make complex things possible. > > Yes, this is critical. We need to finish it. I'd rather have it > > finished and a strong project to build a "standard" external JS library > > under way than to have the whole thing wait. But if I had my druthers > > (what the bleep are those, anyways?) I'd have an optional signaling > > protocol available. -- Randell Jesup randell-ietf@jesup.org From matthew.kaufman@skype.net Tue Oct 4 21:13:29 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEEE521F8B1C for ; Tue, 4 Oct 2011 21:13:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.776 X-Spam-Level: X-Spam-Status: No, score=-5.776 tagged_above=-999 required=5 tests=[AWL=0.823, 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 6BUaPJvBz-40 for ; Tue, 4 Oct 2011 21:13:28 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id 8317421F87C2 for ; Tue, 4 Oct 2011 21:13:28 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id CD65516F6; Wed, 5 Oct 2011 06:16:34 +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=oCgsnQBDgMmG+x NhV9QNX6+odkA=; b=Uh4j3dsaIk2NSGRMgbbUcwYZWqk/sXp/GV3NuikN6yCWul k0vzr4YzksiU6iJ45I13lt8+DGCoY0fO6FzLR+3DDT9Hq/aqHJ+kq1h85JQqpWUI 4n+4J9E+iJt7+NVsMnN9clUL70DPZuHW0wbbIoADgzRsDWXRzCtvaBVE7yIP4= 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=i9X/VDYpn9E+K6T4J8RL5X 6C9Zetf2bAY8LA0pY6itbue/rMEtRCyv5VF6GBWZFz6eLy+10QhzF9Gt0mUJoahR V0Tjf1KPDJSmFmLKJa5G9k+E5H0NHP1Cd+jUexVs18UUra2OSOLKrMZ6V8BteNLI BRxN3D9m4RQJ28i1k59EU= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id CBF267FC; Wed, 5 Oct 2011 06:16:34 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id A5E85350708A; Wed, 5 Oct 2011 06:16:34 +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 S6VxXDHfJ1Sg; Wed, 5 Oct 2011 06:16:34 +0200 (CEST) Received: from [10.10.155.2] (unknown [198.202.199.254]) by zimbra.skype.net (Postfix) with ESMTPSA id B97293506EF4; Wed, 5 Oct 2011 06:16:33 +0200 (CEST) Message-ID: <4E8BD9D7.6000203@skype.net> Date: Tue, 04 Oct 2011 21:15:19 -0700 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Randell Jesup References: <4E8B192E.80809@ericsson.com> <4E8B20BA.3080906@jesup.org> <7EE6A3A6-D628-4EF5-A1E2-FB78C9F8A498@acmepacket.com> <4E8BC675.6060907@skype.net> <4E8BCC2B.6080907@jesup.org> In-Reply-To: <4E8BCC2B.6080907@jesup.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Summary of ICE discussion X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 04:13:29 -0000 On 10/4/2011 8:16 PM, Randell Jesup wrote: > On 10/4/2011 10:52 PM, Matthew Kaufman wrote: >> On 10/4/2011 9:24 AM, Hadriel Kaplan wrote: >>> requiring a more stringent JS trust model seems worthwhile to me. >>> >> >> Great idea. Already being discussed elsewhere. Out of scope for both >> of these groups except to note that *if* someone solves the JS trust >> issue, we might be able to relax the ICE requirement when running >> applications that are "trusted". > > > Right; pretty much the "Installed WebApp" model. > >> >> I wouldn't be adverse to even saying just that in the requirements >> document that explains why ICE is needed. > > I'll agree with this approach. > > (Just to verify: which of many possible places are you referring to it > being discussed?) > I believe there will be a document produced by this WG that requires ICE and explains what security aspects it is addressing. That document would be the right place. Matthew Kaufman From matthew.kaufman@skype.net Tue Oct 4 21:23: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 800B121F8B9E for ; Tue, 4 Oct 2011 21:23:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.795 X-Spam-Level: X-Spam-Status: No, score=-5.795 tagged_above=-999 required=5 tests=[AWL=0.803, 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 Po2bKoPDnnfh for ; Tue, 4 Oct 2011 21:23:41 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id 2917D21F8B90 for ; Tue, 4 Oct 2011 21:23:41 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id 72A0716F6; Wed, 5 Oct 2011 06:26: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; s=mx; bh=N1feImp1//qiieIztYhcxkkCB4Q=; b=TEW7I4cwD yeetRitWaEXLFLbZD8U1Q1ufYNy6sj1x9rVN94VpjYFWmPZShFNdltp++RWZ4jJV 61OGkhekoK4AYgVyh1/22tiWCMh6xDW4SyHbsf1wwliznAsnj7mCide9MuHHQfE8 z+Qe1ukJufZkPuRNMuWRBBPfId9WFq8f78= 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=j2rxQsqOggC7HudPF9lCawvJCILwQ63c5Cqg6vD3eQIRZAX2 PAvoJUX5txXKpCUFKoP709NOGdndjBcn8VyZ/8IXcRCbfqaCxcnWdBOq9eQToTHR 2nYGCE7cPzsFMBd0wPo2p+cMiNwSyARC0OO+xM50C+BST/QxFkWPmYjbbJs= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id 680157FC; Wed, 5 Oct 2011 06:26:47 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id 443B635071FA; Wed, 5 Oct 2011 06:26: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 MpHXeBcdqibC; Wed, 5 Oct 2011 06:26:46 +0200 (CEST) Received: from [10.10.155.2] (unknown [198.202.199.254]) by zimbra.skype.net (Postfix) with ESMTPSA id 617273506EF4; Wed, 5 Oct 2011 06:26:45 +0200 (CEST) Message-ID: <4E8BDC3B.7000501@skype.net> Date: Tue, 04 Oct 2011 21:25:31 -0700 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Roman Shpount References: <545388B3-3189-4291-BD1D-52898B888F3E@phonefromhere.com> <4E8BC0ED.2020001@skype.net> In-Reply-To: Content-Type: multipart/alternative; boundary="------------020408080909010904050704" 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, 05 Oct 2011 04:23:42 -0000 This is a multi-part message in MIME format. --------------020408080909010904050704 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 10/4/2011 8:19 PM, Roman Shpount wrote: > > > On Tue, Oct 4, 2011 at 10:29 PM, Matthew Kaufman > > wrote: > > > This stuff is exactly what you'll need to add yet more code to > solve if you try to bake SDP offer-answer into the browser to turn > it 90% of the way into a SIP phone. > > And exactly what you *don't* need browser code to solve if it is > done elsewhere (for instance, the server might be handling the > entire SIP and SDP exchange and resolve forking issues at that end > without involving the client at all.) > > > Let me rephrase my questions: > > 3. If I generate an offer using this API and then send it to the web > server, which will deal with SIP end of things, and will get multiple > answers in the same dialog, how do I process those answers via this > API? What I need is an ability to provide an answer update to the > connection. Should I just remove old streams and candidates and add a > new ones? How about I rephrase? If I generate an offer by writing SDP code in C++ using Win32 APIs to allocate sockets and send and receive packets, and I send a SIP packet that gets multiple answers in the same dialog, how do I process those answers using the Win32 API? See how silly that sounds? Seriously though, if you need an additional local endpoint because of forking, you need to create a second connection object, which will then give you an onCandidates() callback, as I understand this API proposal. The other way to do it is to have the connection object be able to bind to multiple possible far endpoints, but that's not exactly what this API says, and it isn't clear that it is needed. (Because it isn't how other SIP devices use their network stacks to solve this problem either). > > 4. Same thing with an offer that created multiple dialogs. I want to > clone the connection and add streams and candidates to it. I don't > think this is possible with the current API. I don't see why you can't create a second connection object (or extend this API to allow cloning), and add streams and candidates to that connection object. Should be possible to add the same stream to two different connection objects, too. > > Few new questions: > > 5. What is the priority order for generating candidates when multiple > STUN/TURN servers are specified? How would this be affected if we also > have proxies? I am not sure this is part of any specification so far > and probably should be part of RTC spec defined by IETF Lots of ways to handle this... but yes, the current version of this proposed specification doesn't expose any sort of prioritization. > > 6. How do we deal with CODEC negotiated parameters? I believe that the codec parameters are exposed by the codec object, at least that's how I read this spec. > It is possible to have codec level parameter that needs to be > negotiated via offer/answer exchange. Maybe. Or maybe there's an offer-answer at the server that picks the right answer and then sends that down as a setting to the browser. > There are also codec level parameters that are affected by stream > level parameters (like iLBC mode=30 that only makes sense with ptime > dividable by 30). That's just a bug with how RTP works. > Is it going to be implemented in JavaScript? I suppose it might need to be, if you really need to select connection-level things to match codec-level things and vice versa. Or control it up at the server and then send the right settings down. > This might not be the best idea, since this will require JavaScript to > have a detailed knowledge about each codec implementation provided by > the browser. For third party call control, it would be more robust to > provide a way to return actual codec parameters selected by the > browser so that they can be returned in the answer. Except that we often don't want the codec parameters to be "selected by the browser". We want to know what the browser can do and just set them a particular way. I've already suggested that the format of the "detailed knowledge" can actually just reuse the parameter strings that are already defined for use in SDP. Matthew Kaufman --------------020408080909010904050704 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 10/4/2011 8:19 PM, Roman Shpount wrote:


On Tue, Oct 4, 2011 at 10:29 PM, Matthew Kaufman <matthew.kaufman@skype.net> wrote:

This stuff is exactly what you'll need to add yet more code to solve if you try to bake SDP offer-answer into the browser to turn it 90% of the way into a SIP phone.

And exactly what you *don't* need browser code to solve if it is done elsewhere (for instance, the server might be handling the entire SIP and SDP exchange and resolve forking issues at that end without involving the client at all.)

Let me rephrase my questions:

3. If I generate an offer using this API and then send it to the web server, which will deal with SIP end of things, and will get multiple answers in the same dialog, how do I process those answers via this API? What I need is an ability to provide an answer update to the connection. Should I just remove old streams and candidates and add a new ones?

How about I rephrase?

If I generate an offer by writing SDP code in C++ using Win32 APIs to allocate sockets and send and receive packets, and I send a SIP packet that gets multiple answers in the same dialog, how do I process those answers using the Win32 API? See how silly that sounds?

Seriously though, if you need an additional local endpoint because of forking, you need to create a second connection object, which will then give you an onCandidates() callback, as I understand this API proposal. The other way to do it is to have the connection object be able to bind to multiple possible far endpoints, but that's not exactly what this API says, and it isn't clear that it is needed. (Because it isn't how other SIP devices use their network stacks to solve this problem either).


4. Same thing with an offer that created multiple dialogs. I want to clone the connection and add streams and candidates to it. I don't think this is possible with the current API.

I don't see why you can't create a second connection object (or extend this API to allow cloning), and add streams and candidates to that connection object. Should be possible to add the same stream to two different connection objects, too.


Few new questions:

5. What is the priority order for generating candidates when multiple STUN/TURN servers are specified? How would this be affected if we also have proxies? I am not sure this is part of any specification so far and probably should be part of RTC spec defined by IETF

Lots of ways to handle this... but yes, the current version of this proposed specification doesn't expose any sort of prioritization.

6. How do we deal with CODEC negotiated parameters?

I believe that the codec parameters are exposed by the codec object, at least that's how I read this spec.

It is possible to have codec level parameter that needs to be negotiated via offer/answer exchange.

Maybe. Or maybe there's an offer-answer at the server that picks the right answer and then sends that down as a setting to the browser.

There are also codec level parameters that are affected by stream level parameters (like iLBC mode=30 that only makes sense with ptime dividable by 30).

That's just a bug with how RTP works.

Is it going to be implemented in JavaScript?

I suppose it might need to be, if you really need to select connection-level things to match codec-level things and vice versa. Or control it up at the server and then send the right settings down.

This might not be the best idea, since this will require JavaScript to have a detailed knowledge about each codec implementation provided by the browser. For third party call control, it would be more robust to provide a way to return actual codec parameters selected by the browser so that they can be returned in the answer.

Except that we often don't want the codec parameters to be "selected by the browser". We want to know what the browser can do and just set them a particular way.

I've already suggested that the format of the "detailed knowledge" can actually just reuse the parameter strings that are already defined for use in SDP.

Matthew Kaufman

--------------020408080909010904050704-- From matthew.kaufman@skype.net Tue Oct 4 21: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 D21DC21F8BBC for ; Tue, 4 Oct 2011 21:28:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.814 X-Spam-Level: X-Spam-Status: No, score=-5.814 tagged_above=-999 required=5 tests=[AWL=0.785, 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 gOumXavkuaNS for ; Tue, 4 Oct 2011 21:28:48 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id D01E821F8BB0 for ; Tue, 4 Oct 2011 21:28:47 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id 62A5216F6; Wed, 5 Oct 2011 06:31:53 +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=/ci6zo/XW6qV4W LIrhMrvrp3tEs=; b=GiXuFggNkMwAA7FdrGTwV3L1pVtdbWY09s8P5raMdz/Kb2 w/QtgBBfZHk9MXE8txBQT+LwweKCsM6fqplD2bQPZ9QDLIUKjmH2n0qAaBYdSzK1 GhSOdrzVHw7r8xZcp2gkOTHFdUnXQTiK180im4yDzPWNn38+2jCRVjwwBmTao= 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=XGfVk0THgilqcGrmd7td+x GBSU32VdUgkbnBS2jSyDFg5rLQ5OkLcqDiT1M1iAU5iLi7J7sgJ49JiJN3zYZEVq f/Kr3yVDn9mFA2fiUBeymR5lkkggC9NlHe33lhW3rZVdQNUKiWhofWdAIpdIqm75 qP6ITys+1AemYpbUYSDBQ= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id 60E9B7FC; Wed, 5 Oct 2011 06:31:53 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id 3A926350735C; Wed, 5 Oct 2011 06:31:53 +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 QhSaoAM74-9m; Wed, 5 Oct 2011 06:31:51 +0200 (CEST) Received: from [10.10.155.2] (unknown [198.202.199.254]) by zimbra.skype.net (Postfix) with ESMTPSA id 7239A3506EF4; Wed, 5 Oct 2011 06:31:51 +0200 (CEST) Message-ID: <4E8BDD6D.5030706@skype.net> Date: Tue, 04 Oct 2011 21:30:37 -0700 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 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>, <2E239D6FCD033C4BAF15F386A979BF510F137B@sonusinmail02.sonusnet.com>, <226C9800-9791-465A-B519-40935E2D135F@phonefromhere.com>, <4E8B1B86.2080805@jesup.org> <4E8BD7B8.3080408@jesup.org> In-Reply-To: <4E8BD7B8.3080408@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: Wed, 05 Oct 2011 04:28:48 -0000 On 10/4/2011 9:06 PM, Randell Jesup wrote: > On 10/4/2011 2:19 PM, Bernard Aboba wrote: >> [BA] I think this is the main point. If we finish RTCWEB 1.0 >> expeditiously, this will in all likelihood >> spawn a number of browser-independent signaling libraries, as well as >> developing a wealth of experience >> with the limitations of RFCWEB 1.0, to inform future efforts. >> >> The alternative is to "load up the camel" until it collapses under the >> weight of (largely irrelevant) use >> cases. Since the realtime web has been around for over a decade, we have >> a pretty good idea of what >> native realtime capabilities would be used for -- and PSTN connectivity >> has never been high on the list. > > Well, I'd say that's mildly debatable - VoIP companies chew a lot of > bandwidth on the net, and it's almost all going to the PSTN - though > it's not in browsers generally. Skype completes a lot of on-net calls > - but they make a lot of money (almost all?) from PSTN calls. > > That said, I don't consider the Skypes of the world a problem here - > they can and will roll their own. Same for PBX vendors I suppose, > though they'll try to leverage more existing examples. > > I think there will be a lot of small-to-medium users adding chat, > building games, etc, who care little or not at all about the PSTN. > Those are the ones who I worry about; they wouldn't realize there are > issues with glare (totally ignoring PSTN) or that forking can be > complex. They want a simple, one-stop-shopping solution for adding > voice/video/data to their sites and games, etc. Ok, so they don't know there's issues with glare or that forking is hard. Does that mean that we solve forking in the browser? > > Yes, people will build JS apps to provide that. I'm worried about the > quality of those apps, and that the likely model will be the author > downloads a random version when they develop their service, and they > never update it. This is a real problem; it is a real problem today > with other JS modules. It can also be really simple JS modules and most of the complexity up at the server. Or even more likely (see all the various mashups of the world already), simple JS modules and most of the complexity at a third party server that you use via its REST APIs. > > Does this mean we *have* to bake in some sort of signalling? No, it > doesn't. It is an _argument_ for providing some type of signalling as > a baseline default; or if not, then for starting a project to provide > that. > > Note that I said "baseline". I did *not* say "can handle all the > intricacies of the PSTN well". So does "baseline" include handling the fact that "forking is hard", or does baseline not address forking either? > It could be something far simpler than > SIP or XMPP, etc, or it could be a very dumbed-down version of one. > These small users (as noted) need something to provide the basics, and > to handle certain complexities that simply arise from normal usage > patterns and features (like forking). Being able to access the PSTN > at all using this would be a plus - but it would not be critical in my > mind. This still doesn't mean that the browser needs to become a SIP phone, any more than it needed a map rendering engine for Google Maps to exist or an IMAP client for Gmail to exist. > > And, as I mentioned, it could be external JS - but then it has be more > solid to start with. For these simple uses - say chat with other > users on someones special-interest website, 2 and multiplayer gaming, > etc - we should try to pull together the minimum things any > app/service developer would need to be prepared for. I think any > service that allows someone to log in from multiple devices has to > handle forking in some manner. Glare is always possible. What else? > I'd like to see simple conferencing. Perhaps the minimum is simple > enough that it makes more sense to develop a new, very simple > signalling JS module, and use it in examples. This would limit the > downside from not updating. Or create a good *platform* for building RTC apps and let the developers build things you've never imagined. I think that's a far better outcome than building a SIP phone into the browser and then discovering that most people don't want to just make phone calls. > > The advantage of basing it on something known is that the basics of > all these protocols are well-understood. > > I'll paraphrase Harald (and many others in other contexts): make > simple things simple, make complex things possible. The latter is far more important than the former. If making simple things simple makes complex things significantly harder or impossible, you're not building a platform for innovation. Matthew Kaufman From HKaplan@acmepacket.com Tue Oct 4 21:32: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 06D8421F8557 for ; Tue, 4 Oct 2011 21:32:39 -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 uFCSlFWnIj1t for ; Tue, 4 Oct 2011 21:32:38 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 25CE521F854F for ; Tue, 4 Oct 2011 21:32: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, 5 Oct 2011 00:35:43 -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; Wed, 5 Oct 2011 00:35:43 -0400 From: Hadriel Kaplan To: Ted Hardie Thread-Topic: [rtcweb] Making progress on the signaling discussion (NB: Action items enclosed!) Thread-Index: AQHMgxg9t26sU6mqcUiutAVu1kLdKQ== Date: Wed, 5 Oct 2011 04:35:42 +0000 Message-ID: <6F3520FE-BAB2-44C6-8286-33474F01D545@acmepacket.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [216.41.24.34] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <3A7F57BD2E8FD043A6EF15DF8F8FFE93@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [rtcweb] Making progress on the signaling discussion (NB: Action items enclosed!) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 04:32:39 -0000 The draft already exists, available here: http://www.ecma-international.org/publications/standards/Ecma-262.htm There are also lots of free tutorials about writing it, available here: http://www.google.com/search?q=3Djavascript There are even lots of books about it, available here: http://www.amazon.com/s/field-keywords=3Djavascript -hadriel On Oct 4, 2011, at 12:01 PM, Ted Hardie wrote: > At today's Chairs call, Cullen, Magnus and I had a discussion of how to m= ake progress on the signaling discussion. We feel the mailing list discuss= ion needs to have more concrete proposals in order to make progress, and so= we're putting forward the following: >=20 > 1) If you plan to put forward a draft proposing a concrete solution in th= is space, please send your name to the mailing list with that intent by Oct= ober 7th *THIS FRIDAY*. >=20 > 2) Please have a -00 draft out for discussion by October 14th (the follow= ing Friday). This is to allow for a discussion and update prior to the -01= deadlines. >=20 > 3) We will hold a conference call to discuss the drafts on October 21st (= the Friday after that). >=20 > Updates based on that discussion then have until the -01 drafts deadline = to be complete. >=20 > This is aggressive, but we feel we need to have at least -00s for the dif= ferent ideas in place in order to make real progress. >=20 > thanks, >=20 > Ted, Magnus, Cullen > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From randell-ietf@jesup.org Tue Oct 4 22:02: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 866D421F84BC for ; Tue, 4 Oct 2011 22:02:09 -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 UYL1Z71KyJlI for ; Tue, 4 Oct 2011 22:02: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 CE9E821F84AC for ; Tue, 4 Oct 2011 22:02: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 1RBJfP-0002ez-C4 for rtcweb@ietf.org; Wed, 05 Oct 2011 00:05:15 -0500 Message-ID: <4E8BE49B.6050202@jesup.org> Date: Wed, 05 Oct 2011 01:01:15 -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>, <2E239D6FCD033C4BAF15F386A979BF510F137B@sonusinmail02.sonusnet.com>, <226C9800-9791-465A-B519-40935E2D135F@phonefromhere.com>, <4E8B1B86.2080805@jesup.org> <4E8BD7B8.3080408@jesup.org> <4E8BDD6D.5030706@skype.net> In-Reply-To: <4E8BDD6D.5030706@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: 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: Wed, 05 Oct 2011 05:02:09 -0000 On 10/5/2011 12:30 AM, Matthew Kaufman wrote: > On 10/4/2011 9:06 PM, Randell Jesup wrote: >> I think there will be a lot of small-to-medium users adding chat, >> building games, etc, who care little or not at all about the PSTN. >> Those are the ones who I worry about; they wouldn't realize there are >> issues with glare (totally ignoring PSTN) or that forking can be >> complex. They want a simple, one-stop-shopping solution for adding >> voice/video/data to their sites and games, etc. > > Ok, so they don't know there's issues with glare or that forking is > hard. Does that mean that we solve forking in the browser? >> Does this mean we *have* to bake in some sort of signalling? No, it >> doesn't. It is an _argument_ for providing some type of signalling as >> a baseline default; or if not, then for starting a project to provide >> that. >> >> Note that I said "baseline". I did *not* say "can handle all the >> intricacies of the PSTN well". > > So does "baseline" include handling the fact that "forking is hard", or > does baseline not address forking either? If you want me to answer that question: yes, I'd include support for some sort of resolution of forking. Enough to avoid getting into trouble, only. >> It could be something far simpler than >> SIP or XMPP, etc, or it could be a very dumbed-down version of one. >> These small users (as noted) need something to provide the basics, and >> to handle certain complexities that simply arise from normal usage >> patterns and features (like forking). Being able to access the PSTN at >> all using this would be a plus - but it would not be critical in my mind. > > This still doesn't mean that the browser needs to become a SIP phone, > any more than it needed a map rendering engine for Google Maps to exist > or an IMAP client for Gmail to exist. I am in *no way* saying it needs to be a SIP phone. I'm saying "provide a simple-to-use basic signalling method which it totally optional to use, and which handles the basics needed of almost any signalling method (forking, glare, etc)". Nothing about phones, nothing about PSTN. We also don't ship browsers that consist of a canvas element and a JS interpreter, though you *could* build all websites that way (more or less), and some do (GMail and the like aren't far from it). But most site authors are glad they don't have to start with a bucket of rocks to build a castle *as their only option*. >> And, as I mentioned, it could be external JS - but then it has be more >> solid to start with. For these simple uses - say chat with other users >> on someones special-interest website, 2 and multiplayer gaming, etc - >> we should try to pull together the minimum things any app/service >> developer would need to be prepared for. I think any service that >> allows someone to log in from multiple devices has to handle forking >> in some manner. Glare is always possible. What else? I'd like to see >> simple conferencing. Perhaps the minimum is simple enough that it >> makes more sense to develop a new, very simple signalling JS module, >> and use it in examples. This would limit the downside from not updating. > > Or create a good *platform* for building RTC apps and let the developers > build things you've never imagined. I think that's a far better outcome > than building a SIP phone into the browser and then discovering that > most people don't want to just make phone calls. Again: I'm not suggesting "build in a SIP phone", and how does my proposal in any way tie the hands of someone who wants to build it themselves? >> The advantage of basing it on something known is that the basics of >> all these protocols are well-understood. >> >> I'll paraphrase Harald (and many others in other contexts): make >> simple things simple, make complex things possible. > > The latter is far more important than the former. If making simple > things simple makes complex things significantly harder or impossible, > you're not building a platform for innovation. Ok, but in this case I don't want to complicate the later - so you're addressing a point I'm not making. Please consider re-reading my posting with that in mind. -- Randell Jesup randell-ietf@jesup.org From pravindran@sonusnet.com Tue Oct 4 23:05:18 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40D8621F8B08 for ; Tue, 4 Oct 2011 23:05:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.423 X-Spam-Level: X-Spam-Status: No, score=-1.423 tagged_above=-999 required=5 tests=[AWL=-0.978, BAYES_00=-2.599, FRT_BELOW2=2.154] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m0fm8-9mHfhA for ; Tue, 4 Oct 2011 23:05:17 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 062B521F8B1A for ; Tue, 4 Oct 2011 23:05:16 -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 p95688g9006597; Wed, 5 Oct 2011 02:08:08 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail06.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 5 Oct 2011 02:07:35 -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: Wed, 5 Oct 2011 11:37:32 +0530 Message-ID: <2E239D6FCD033C4BAF15F386A979BF510F142C@sonusinmail02.sonusnet.com> In-Reply-To: <4E8B192E.80809@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] Summary of ICE discussion Thread-Index: AcyCorg6pM9PKEv5QH2os56S0Yz+CAAgYuQw References: <4E8B192E.80809@ericsson.com> From: "Ravindran Parthasarathi" To: "Magnus Westerlund" , X-OriginalArrivalTime: 05 Oct 2011 06:07:35.0334 (UTC) FILETIME=[13A26460:01CC8325] Subject: Re: [rtcweb] Summary of ICE discussion X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 06:05:18 -0000 In case user consent is the reason for ICE, ICE may not be right choice = because of the multiplexing RTP in RTCWeb and user may be consent for = audio and not for video which is not possible to indicate through ICE. = It is possible to achieve by having different streams for each media but = I strongly believe that it is not interesting topic for RTCWeb. I think that trust model with browser---RTCWeb server---browser for the = user consent with individual media stream works because browser user = trust RTCWeb server. I could think of offer/answer as user consent with = media stream mechanism because offer or answer indicates media port is = allocated in browser and listening for media from remote party, the = consent reaches remote browser through RTCWeb server. The advantage in = the model is that RTCWeb server shall have the policy to control media. = Please let me know your comments on this. The other reason like NAT & FW is not mandatory for intranet RTCWeb = applications. I have mentioned as part of = http://www.ietf.org/mail-archive/web/rtcweb/current/msg01619.html Thanks Partha >-----Original Message----- >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On = Behalf >Of Magnus Westerlund >Sent: Tuesday, October 04, 2011 8:03 PM >To: rtcweb@ietf.org >Subject: [rtcweb] Summary of ICE discussion > >WG, > >I have bellow tired to summarize the result of the ICE discussion. This >is intended as furthering this discussion and form a basis for going >forward in the consensus process. I do expect people that disagree with >my summary of the discussion to speak up. > >Major requirements > >- Need for data transmission consent for protocols using UDP as the >traffic receiver needs to consent to receiving the data > >- Perform NAT and FW traversal when ever needed > >- Support IPv4 to IPv6 transition > >Desired behavior: > >- Be interoperable with deployed legacy systems as SIP Trunk, PSTN >gateways, VoIP phones. > >WG chairs conclusion of discussion so far: > >- ICE is so far the only solution that provides the security goals and >have any legacy deployment. > >- ICE usage will require that STUN connectivity MUST have succeeded >prior to any data transmission to fulfill security goals. > > * The Browser will enforce this requirement to prevent being an = attack >vector in all cases. > >- If anyone can find a solution that fulfill the security goals and = have >improved legacy interoperability people would be interested in that >solution. So far RTCP has been discarded as insufficient. > >- Media Gateway can support a reduced functionality set from Full ICE > >Cheers > >Magnus Westerlund >as WG chair > >---------------------------------------------------------------------- >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 roman@telurix.com Tue Oct 4 23: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 B7D1321F8AB0 for ; Tue, 4 Oct 2011 23:18:55 -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.343, 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 uBmXfCU4LePO for ; Tue, 4 Oct 2011 23:18:54 -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 6BA0E21F86EE for ; Tue, 4 Oct 2011 23:18:54 -0700 (PDT) Received: by vws5 with SMTP id 5so1297035vws.31 for ; Tue, 04 Oct 2011 23:22:01 -0700 (PDT) Received: by 10.52.75.195 with SMTP id e3mr2201108vdw.299.1317795721206; Tue, 04 Oct 2011 23:22:01 -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 x19sm652016vdf.10.2011.10.04.23.22.00 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 04 Oct 2011 23:22:00 -0700 (PDT) Received: by vcbfo11 with SMTP id fo11so1301993vcb.31 for ; Tue, 04 Oct 2011 23:21:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.182.67 with SMTP id cb3mr593604vcb.58.1317795719764; Tue, 04 Oct 2011 23:21:59 -0700 (PDT) Received: by 10.220.178.74 with HTTP; Tue, 4 Oct 2011 23:21:59 -0700 (PDT) In-Reply-To: <4E8BDC3B.7000501@skype.net> References: <545388B3-3189-4291-BD1D-52898B888F3E@phonefromhere.com> <4E8BC0ED.2020001@skype.net> <4E8BDC3B.7000501@skype.net> Date: Wed, 5 Oct 2011 02:21:59 -0400 Message-ID: From: Roman Shpount To: Matthew Kaufman Content-Type: multipart/alternative; boundary=90e6ba53ad40c35c6004ae8739ce 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, 05 Oct 2011 06:18:56 -0000 --90e6ba53ad40c35c6004ae8739ce Content-Type: text/plain; charset=ISO-8859-1 On Wed, Oct 5, 2011 at 12:25 AM, Matthew Kaufman wrote: > How about I rephrase? > > If I generate an offer by writing SDP code in C++ using Win32 APIs to > allocate sockets and send and receive packets, and I send a SIP packet that > gets multiple answers in the same dialog, how do I process those answers > using the Win32 API? See how silly that sounds? > > Seriously though, if you need an additional local endpoint because of > forking, you need to create a second connection object, which will then give > you an onCandidates() callback, as I understand this API proposal. The other > way to do it is to have the connection object be able to bind to multiple > possible far endpoints, but that's not exactly what this API says, and it > isn't clear that it is needed. (Because it isn't how other SIP devices use > their network stacks to solve this problem either). > > I think you are completely missing the point: If I build similar thing using Win32 API, I would re-initialize codec and RTP states and re-do the ICE candidate selection based on the new answer. This particular API has methods to add and remove streams and candidates, but no method to start a re-negotiation. Don't assume something is silly just because you did not understand it. > I don't see why you can't create a second connection object (or extend this > API to allow cloning), and add streams and candidates to that connection > object. Should be possible to add the same stream to two different > connection objects, too. > > Each connection object has an associated local port on which it is listening for incoming media and ICE STUN messages. What I need is to be able to reuse the same port to connect to multiple different sets of remote candidates. Remote IP/port should be sufficient to disambiguate different streams. > > 6. How do we deal with CODEC negotiated parameters? > > > I believe that the codec parameters are exposed by the codec object, at > least that's how I read this spec. > > > It is possible to have codec level parameter that needs to be negotiated > via offer/answer exchange. > > > Maybe. Or maybe there's an offer-answer at the server that picks the right > answer and then sends that down as a setting to the browser. > > > There are also codec level parameters that are affected by stream level > parameters (like iLBC mode=30 that only makes sense with ptime dividable by > 30). > > > That's just a bug with how RTP works. > > > Is it going to be implemented in JavaScript? > > > I suppose it might need to be, if you really need to select > connection-level things to match codec-level things and vice versa. Or > control it up at the server and then send the right settings down. > > > This might not be the best idea, since this will require JavaScript to > have a detailed knowledge about each codec implementation provided by the > browser. For third party call control, it would be more robust to provide a > way to return actual codec parameters selected by the browser so that they > can be returned in the answer. > > > Except that we often don't want the codec parameters to be "selected by the > browser". We want to know what the browser can do and just set them a > particular way. > > I've already suggested that the format of the "detailed knowledge" can > actually just reuse the parameter strings that are already defined for use > in SDP. > > Once again, you are missing the point completely. Part of the problem here is that typically codec information in offer/answer exchange does not provide the list of all the codec level parameters supported by the codec. The fact that, for instance SILK implementation supports FEC or DTX does not have to be present in the offer to be present in the answer. This means Codec object will need to expose a more information then typically provided in SDP (ie all the supported codec parameters vs just the desired one). This means RTC will need to define fields for this object for each codec it will support and cannot simply reuse MMUSIC/PAYLOAD standards. This also brings about the whole new problem -- asymmetric codecs and codec parameters. There are a lot of valid use cases when you want to use different codecs in different directions (different hardware optimized codecs in different mobile devices). There are cases when different payload types are used for the same codecs in different directions (It can also be considered an RTP bug). You might want to use different video resolutions due to device camera and display limitations. You might want to use different codec bandwidths due to difference in up and down stream network capacity. There is no way to handle this now. I would suggest that the better model for third party call control or inbound call would be get the offer from remote side, process it on the server or in javascript, pass it to the RTC stack in the browser, get the answer from the RTC stack in the browser, process it (if needed) in javascript or on the server and send it to the remote side. Yet another codec negotiation deficiency that I see here is that you cannot specify multiple codecs. It is fairly typical to have audio codec, comfort noise codec, and DTMF to be used at the same time for a single stream. Final comment about the draft is that it is missing a lot of parameters about codecs. It is missing things like media type, transport type, clock rates, payload types, crypto attributes, etc. It would be interesting to see which attributes would end up in which of the objects. ______________ Roman Shpount --90e6ba53ad40c35c6004ae8739ce Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Oct 5, 2011 at 12:25 AM, Matthew Kau= fman <mat= thew.kaufman@skype.net> wrote:
=20 =20 =20
How about I rephrase?

If I generate an offer by writing SDP code in C++ using Win32 APIs to allocate sockets and send and receive packets, and I send a SIP packet that gets multiple answers in the same dialog, how do I process those answers using the Win32 API? See how silly that sounds?

Seriously though, if you need an additional local endpoint because of forking, you need to create a second connection object, which will then give you an onCandidates() callback, as I understand this API proposal. The other way to do it is to have the connection object be able to bind to multiple possible far endpoints, but that's not exactly what this API says, and it isn't clear that = it is needed. (Because it isn't how other SIP devices use their network stacks to solve this problem either).

=

I think you are completely missing the point: If I bu= ild similar thing using Win32 API, I would re-initialize codec and=A0 RTP s= tates and re-do the ICE candidate selection based on the new answer. This p= articular API has methods to add and remove streams and candidates, but no = method to start a re-negotiation. Don't assume something is silly just = because you did not understand it.
=A0
I don't see why you can't create = a second connection object (or extend this API to allow cloning), and add streams and candidates to that connection object. Should be possible to add the same stream to two different connection objects, too.


Each connection object has an associated local port = on which it is listening for incoming media and ICE STUN messages. What I n= eed is to be able to reuse the same port to connect to multiple different s= ets of remote candidates. Remote IP/port should be sufficient to disambigua= te different streams.

=A0

6. How do we deal with CODEC negotiated parameters?

I believe that the codec parameters are exposed by the codec object, at least that's how I read this spec.


It is possible to have codec level parameter = that needs to be negotiated via offer/answer exchange.

Maybe. Or maybe there's an offer-answer at the server that picks th= e right answer and then sends that down as a setting to the browser.


There are also codec level parameters that a= re affected by stream level parameters (like iLBC mode=3D30 that only makes sense with ptime dividable by 30).

That's just a bug with how RTP works.


Is it going to be implemented in JavaScript?=

I suppose it might need to be, if you really need to select connection-level things to match codec-level things and vice versa. Or control it up at the server and then send the right settings down.


This might not be the best idea, since this = will require JavaScript to have a detailed knowledge about each codec implementation provided by the browser. For third party call control, it would be more robust to provide a way to return actual codec parameters selected by the browser so that they can be returned in the answer.

Except that we often don't want the codec parameters to be "se= lected by the browser". We want to know what the browser can do and just set them a particular way.

I've already suggested that the format of the "detailed knowle= dge" can actually just reuse the parameter strings that are already defined for use in SDP.


Once again, you are missing the= point completely. Part of the problem here is that typically codec informa= tion in offer/answer exchange does not provide the list of all the codec le= vel parameters supported by the codec. The fact that, for instance SILK imp= lementation supports FEC or DTX does not have to be present in the offer to= be present in the answer. This means Codec object will need to expose a mo= re information then typically provided in SDP (ie all the supported codec p= arameters vs just the desired one). This means RTC will need to define fiel= ds for this object for each codec it will support and cannot simply reuse M= MUSIC/PAYLOAD standards.

This also brings about the whole new problem -- asymmetric codecs and c= odec parameters. There are a lot of valid use cases when you want to use di= fferent codecs in different directions (different hardware optimized codecs= in different mobile devices). There are cases when different payload types= are used for the same codecs in different directions (It can also be consi= dered an RTP bug). You might want to use different video resolutions due to= device camera and display limitations. You might want to use different cod= ec bandwidths due to difference in up and down stream network capacity. The= re is no way to handle this now. I would suggest that the better model for = third party call control or inbound call would be get the offer from remote= side, process it on the server or in javascript, pass it to the RTC stack = in the browser, get the answer from the RTC stack in the browser, process i= t (if needed) in javascript or on the server and send it to the remote side= .

Yet another codec negotiation deficiency that I see here is that you ca= nnot specify multiple codecs. It is fairly typical to have audio codec, com= fort noise codec, and DTMF to be used at the same time for a single stream.=

Final comment about the draft is that it is missing a lot of parameters= about codecs. It is missing things like media type, transport type, clock = rates, payload types, crypto attributes, etc. It would be interesting to se= e which attributes would end up in which of the objects.
______________
Roman Shpount
--90e6ba53ad40c35c6004ae8739ce-- From roman@telurix.com Tue Oct 4 23:31: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 7DD3421F8569 for ; Tue, 4 Oct 2011 23:31:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.64 X-Spam-Level: X-Spam-Status: No, score=-2.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_LOW=-1] Received: 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+vcRrycMiHL for ; Tue, 4 Oct 2011 23:31:56 -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 D446C21F8564 for ; Tue, 4 Oct 2011 23:31:55 -0700 (PDT) Received: by vws5 with SMTP id 5so1303150vws.31 for ; Tue, 04 Oct 2011 23:35:02 -0700 (PDT) Received: by 10.52.188.65 with SMTP id fy1mr2122034vdc.442.1317796502633; Tue, 04 Oct 2011 23:35:02 -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 v8sm650089vdg.22.2011.10.04.23.35.01 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 04 Oct 2011 23:35:02 -0700 (PDT) Received: by vcbfo11 with SMTP id fo11so1308517vcb.31 for ; Tue, 04 Oct 2011 23:35:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.36.203 with SMTP id s11mr1886087vdj.453.1317796501618; Tue, 04 Oct 2011 23:35:01 -0700 (PDT) Received: by 10.220.178.74 with HTTP; Tue, 4 Oct 2011 23:35:01 -0700 (PDT) In-Reply-To: <4E8BC56E.40306@skype.net> References: <4E8B192E.80809@ericsson.com> <37C37EE6-3D48-4C77-A025-3207F040572B@cisco.com> <4E8BC56E.40306@skype.net> Date: Wed, 5 Oct 2011 02:35:01 -0400 Message-ID: From: Roman Shpount To: Matthew Kaufman Content-Type: multipart/alternative; boundary=20cf3079ba2e5d81c404ae876856 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Summary of ICE discussion X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 06:31:56 -0000 --20cf3079ba2e5d81c404ae876856 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Oct 4, 2011 at 10:48 PM, Matthew Kaufman wrote: > I think what he's concerned about is that a device might consent (using > ICE) to receive audio and unexpectedly receive multiplexed video on the same > RTP port. > > Not sure this really matters, as there's not much difference between > low-frame-rate low-res video and 16-bit linear stereo PCM at 48 kHz (which > might indeed be an audio codec you can choose). > Since we already agreed that RTC end point does not need to interact with anything except other RTC end points, and everything outside RTC would just be extended to support it, why would not we add additional parameters to STUN connectivity check? We can add media types, rates, codecs and codec parameters to STUN request and let the end point only accept the connectivity check if the media matches what's expected to be sent to this IP/port. This will probably even work with existing ICE implementations, if we make these codec parameters comprehension-optional. _____________ Roman Shpount --20cf3079ba2e5d81c404ae876856 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Oct 4, 2011 at 10:48 PM, Matthew= Kaufman <matthew.kaufman@skype.net> wrote:
I think what he's concerned about is that a device might consent (using= ICE) to receive audio and unexpectedly receive multiplexed video on the sa= me RTP port.

Not sure this really matters, as there's not much difference between lo= w-frame-rate low-res video and 16-bit linear stereo PCM at 48 kHz (which mi= ght indeed be an audio codec you can choose).

Since we already agreed that RTC end point does not = need to interact with anything except other RTC end points, and everything = outside RTC would just be extended to support it, why would not we add addi= tional parameters to STUN connectivity check? We can add media types, rates= , codecs and codec parameters to STUN request and let the end point only ac= cept the connectivity check if the media matches what's expected to be = sent to this IP/port. This will probably even work with existing ICE implem= entations, if we make these codec parameters comprehension-optional.
_____________
Roman Shpount

--20cf3079ba2e5d81c404ae876856-- From pravindran@sonusnet.com Wed Oct 5 00:00:02 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D0B821F8AAA for ; Wed, 5 Oct 2011 00:00: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 SxSnr1wnmDQZ for ; Wed, 5 Oct 2011 00:00:01 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 99ADD21F8AAF for ; Wed, 5 Oct 2011 00:00:01 -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 p9573el3009919; Wed, 5 Oct 2011 03:03:40 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail05.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 5 Oct 2011 03:03:07 -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_01CC832C.D3F98BE8" Date: Wed, 5 Oct 2011 12:33:04 +0530 Message-ID: <2E239D6FCD033C4BAF15F386A979BF510F1450@sonusinmail02.sonusnet.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] Making progress on the signaling discussion (NB: Actionitems enclosed!) Thread-Index: AcyCruOHcWlrNpROT8Sx+TBJ63fzqAAe0Lqw References: From: "Ravindran Parthasarathi" To: "Ted Hardie" , X-OriginalArrivalTime: 05 Oct 2011 07:03:07.0423 (UTC) FILETIME=[D5B6D2F0:01CC832C] Subject: Re: [rtcweb] Making progress on the signaling discussion (NB: Actionitems enclosed!) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 07:00:02 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC832C.D3F98BE8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ted, Magnus, Cullen, =20 Could you please consider RTCWeb standard signaling protocol (http://tools.ietf.org/id/draft-partha-rtcweb-signaling-00.txt) draft as one of the proposal for this signaling discussion. =20 Thanks Partha =20 From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Ted Hardie Sent: Tuesday, October 04, 2011 9:31 PM To: rtcweb@ietf.org Subject: [rtcweb] Making progress on the signaling discussion (NB: Actionitems enclosed!) =20 At today's Chairs call, Cullen, Magnus and I had a discussion of how to make progress on the signaling discussion. We feel the mailing list discussion needs to have more concrete proposals in order to make progress, and so we're putting forward the following: 1) If you plan to put forward a draft proposing a concrete solution in this space, please send your name to the mailing list with that intent by October 7th *THIS FRIDAY*. 2) Please have a -00 draft out for discussion by October 14th (the following Friday). This is to allow for a discussion and update prior to the -01 deadlines. 3) We will hold a conference call to discuss the drafts on October 21st (the Friday after that). Updates based on that discussion then have until the -01 drafts deadline to be complete. This is aggressive, but we feel we need to have at least -00s for the different ideas in place in order to make real progress. thanks, Ted, Magnus, Cullen ------_=_NextPart_001_01CC832C.D3F98BE8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ted, Magnus, Cullen,

 

Could you please consider RTCWeb standard signaling =
protocol (ht=
tp://tools.ietf.org/id/draft-partha-rtcweb-signaling-00.txt) draft =
as one of the proposal for this signaling =
discussion.
 
Thanks
Partha

 

From:= = rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Ted Hardie
Sent: Tuesday, October 04, 2011 9:31 PM
To: rtcweb@ietf.org
Subject: [rtcweb] Making progress on the signaling discussion = (NB: Actionitems enclosed!)

 

At today's Chairs call, Cullen, Magnus and I had a discussion of how to make progress on the signaling discussion.  We = feel the mailing list discussion needs to have more concrete proposals in = order to make progress, and so we're putting forward the following:

1) If you plan to put forward a draft proposing a concrete solution in = this space, please send your name to the mailing list with that intent by = October 7th *THIS FRIDAY*.

2) Please have a -00 draft out for discussion by October 14th (the = following Friday).  This is to allow for a discussion and update prior to the = -01 deadlines.

3) We will hold a conference call to discuss the drafts on October 21st = (the Friday after that).

Updates based on that discussion then have until the -01 drafts deadline = to be complete.

This is aggressive, but we feel we need to have at least -00s for the = different ideas in place in order to make real progress.

thanks,

Ted, Magnus, Cullen

------_=_NextPart_001_01CC832C.D3F98BE8-- From magnus.westerlund@ericsson.com Wed Oct 5 00:56: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 8ADE321F8B33 for ; Wed, 5 Oct 2011 00:56:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.481 X-Spam-Level: X-Spam-Status: No, score=-106.481 tagged_above=-999 required=5 tests=[AWL=0.118, 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 6weinfFy6uJ4 for ; Wed, 5 Oct 2011 00:56: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 287C321F8A71 for ; Wed, 5 Oct 2011 00:56:29 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-3a-4e8c0e68f346 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.115.81]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 67.A5.20773.86E0C8E4; Wed, 5 Oct 2011 09:59:36 +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, 5 Oct 2011 09:59:13 +0200 Message-ID: <4E8C0E50.7050309@ericsson.com> Date: Wed, 5 Oct 2011 09:59:12 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4E8BBDDF.3010100@skype.net> In-Reply-To: <4E8BBDDF.3010100@skype.net> X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [rtcweb] Making progress on the signaling discussion (NB: Action items enclosed!) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 07:56:39 -0000 On 2011-10-05 04:15, Matthew Kaufman wrote: > On 10/4/2011 9:01 AM, Ted Hardie wrote: >> At today's Chairs call, Cullen, Magnus and I had a discussion of how >> to make progress on the signaling discussion. We feel the mailing >> list discussion needs to have more concrete proposals in order to make >> progress, and so we're putting forward the following: >> >> 1) If you plan to put forward a draft proposing a concrete solution in >> this space, please send your name to the mailing list with that intent >> by October 7th *THIS FRIDAY*. > > I'm going to nominate myself here. > >> >> 2) Please have a -00 draft out for discussion by October 14th (the >> following Friday). This is to allow for a discussion and update prior >> to the -01 deadlines. >> > > I believe that defining a signaling protocol between web browsers and > web servers for RTCWEB is out of scope, so I believe there is no draft > required... unless you really want a -00 draft that says "do nothing". > > I believe that defining a signaling protocol between web servers and > other web servers for RTCWEB federation is out for scope for "version > 1", so I believe it is not appropriate to submit a draft at this time... > unless you really want a -00 draft that says "do nothing for now, use > any of the existing protocols until then." > I think also this proposal do require an Internet draft which discusses the requirements put on the API. What of the underlying protocols that are this WG task needs to be exposed in different forms? My understanding of your idea is that you have both capabilities and knobs that can be set. I also believe it requires some state transitioning events. For example to kick of ICE negotiation between the peers when the right things has been set. Thus, I personally do see a need for draft from you that explains the details of how things are expected to work. I don't see you needing to define how the API should really look, but what the requirements on that API are based on your solutions. But without that your proposal is still not clear and open for a lot of interpretation. 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 Oct 5 01:06: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 A2A6021F8B51 for ; Wed, 5 Oct 2011 01:06:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.482 X-Spam-Level: X-Spam-Status: No, score=-106.482 tagged_above=-999 required=5 tests=[AWL=0.117, 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 8Uskey87VRyL for ; Wed, 5 Oct 2011 01:06: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 E18E521F8B42 for ; Wed, 5 Oct 2011 01:06:32 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-1a-4e8c10c3d1cc Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 2D.29.20773.3C01C8E4; Wed, 5 Oct 2011 10:09: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; Wed, 5 Oct 2011 10:09:33 +0200 Message-ID: <4E8C10BC.8090104@ericsson.com> Date: Wed, 5 Oct 2011 10:09:32 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Bernard Aboba References: <4E8B192E.80809@ericsson.com> <37C37EE6-3D48-4C77-A025-3207F040572B@cisco.com> <4E8BC56E.40306@skype.net> In-Reply-To: X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Summary of ICE discussion X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 08:06:38 -0000 Hi, good that my summary lets us move forward. A question on this attack. How common is it that these STUN servers use other ports than 3478? Would a rule about that port mitigate the issue, even if it could result in connectivity failures in cases where the NAT external port is 3478 by chance? In addition does these public servers use the username and password convention from ICE? Isn't that what prevents STUN server deployed for just determining your server reflexive candidate from actually respond correctly to a connectivity check? As ICE do concatenate one part generated by one peer with a part generated by the other peer I don't see this as an issue as long as the random username fragment is generated by the browser not the JS. 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 Oct 5 01:16: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 250D921F8AE1 for ; Wed, 5 Oct 2011 01:16:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.483 X-Spam-Level: X-Spam-Status: No, score=-106.483 tagged_above=-999 required=5 tests=[AWL=0.116, 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 jLEJCXwTjRwh for ; Wed, 5 Oct 2011 01:16:06 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 51DBA21F862F for ; Wed, 5 Oct 2011 01:16:05 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-e8-4e8c1300c540 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.115.81]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id B8.5C.20773.0031C8E4; Wed, 5 Oct 2011 10:19:13 +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, 5 Oct 2011 10:19:10 +0200 Message-ID: <4E8C12FD.5010007@ericsson.com> Date: Wed, 5 Oct 2011 10:19:09 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Ravindran Parthasarathi References: <4E8B192E.80809@ericsson.com> <2E239D6FCD033C4BAF15F386A979BF510F142C@sonusinmail02.sonusnet.com> In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF510F142C@sonusinmail02.sonusnet.com> X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Summary of ICE discussion X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 08:16:07 -0000 On 2011-10-05 08:07, Ravindran Parthasarathi wrote: > In case user consent is the reason for ICE, ICE may not be right > choice because of the multiplexing RTP in RTCWeb and user may be > consent for audio and not for video which is not possible to indicate > through ICE. It is possible to achieve by having different streams > for each media but I strongly believe that it is not interesting > topic for RTCWeb. No, it is not user consent, it is data transmission consent that is the issue here. > > I think that trust model with browser---RTCWeb server---browser for > the user consent with individual media stream works because browser > user trust RTCWeb server. I could think of offer/answer as user > consent with media stream mechanism because offer or answer indicates > media port is allocated in browser and listening for media from > remote party, the consent reaches remote browser through RTCWeb > server. The advantage in the model is that RTCWeb server shall have > the policy to control media. Please let me know your comments on > this. My interpretation is that several has disagreed with you on this model. I personally also disagree with this. There is a big difference between allowing a webservice access to my media devices, i.e. microphone and video as will expect it to perform a communication service where I at least see parts of that communication happening. However, the user has no way of verifying that of the media streams being setup by the web service that it in fact not in addition uses the users resources for a DoS attack. It is the destination of the media stream that needs to consent to the media delivery, not the siganlling node for it. Thus a path based media verification that ensures that information from the signalling and the media path agrees provides a reasonable but not perfect security against attacks. This is still vulnerable to attackers that have the capability of both running the web service and intercept and inject packets in the network on path between the web client and the target of the attack. > > The other reason like NAT & FW is not mandatory for intranet RTCWeb > applications. I have mentioned as part of > http://www.ietf.org/mail-archive/web/rtcweb/current/msg01619.html My interpretation of your statement was that it was disputed and that the disputing statement was not faulty. 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 Wed Oct 5 02:16: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 3A9D321F8B76 for ; Wed, 5 Oct 2011 02:16:48 -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.044, 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 B9lTWguwkoqq for ; Wed, 5 Oct 2011 02:16: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 5544021F8B72 for ; Wed, 5 Oct 2011 02:16:47 -0700 (PDT) Received: by vws5 with SMTP id 5so1399253vws.31 for ; Wed, 05 Oct 2011 02:19:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.89.177 with SMTP id bp17mr2071307vdb.447.1317806393302; Wed, 05 Oct 2011 02:19:53 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Wed, 5 Oct 2011 02:19:53 -0700 (PDT) In-Reply-To: References: Date: Wed, 5 Oct 2011 11:19:53 +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] Making progress on the signaling discussion (NB: Action items enclosed!) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 09:16:48 -0000 2011/10/5 Ted Hardie : > Hi I=C3=B1aki, > > The chairs don't currently detect consensus on how signaling will be hand= led > for RTCWeb sessions.=C2=A0 We don't want to circumscribe the solution spa= ce, but > we do feel that there is a need to have concrete proposals, rather than > broad statements like, "it shouldn't be in the component X".=C2=A0 Concre= te > proposals for how it will be handled are the best way we see to make sure > folks are coming to consensus on something they understand, rather than o= n > rhetoric. > > If you would like to make a concrete proposal for how that JavaScript obj= ect > is constructed, what it contains, and how it is shipped around, that woul= d > be great.=C2=A0=C2=A0 Without a statement of what those details are, howe= ver, the > chairs worry that people will argue (for and against) proposals that have > not been made. > > We await your electrons with great interest! Hi Ted, I'll very busy next days but next week I'll try to give something more useful. Anyhow, I think we must be careful here. Maybe somebody proposes a signaling mechanism that "works for him" but avoids others to build their own signaling (if just those requirements are included in rtcweb specs). For example, I've seen recently a proposal for SDP managing in which the client (the JS code in the browser) is a "stupid" element (sorry for the word) and asks the server (via HTTP) for all the stuf related to SDP. Maybe this could work for its specific use case, but IMHO we should not rely on SDP processing/validating/whatever in server side. We have now all the tools to make a web browser + JS code an intelligent element. The web page is not just a visual interface anymore. Realtime signaling (via WebSocket) and media (rtcweb) is already possible (or will be), and JavaScript allows building a real application in client side. In my case (SIP over WebSocket) the client, a JavaScript SIP stack, is a pure SIP client (which can also parse SDP bodies), and the "server" is in fact a *pure* SIP proxy implementing the WebSocket transport (along with UDP, TCP and so). The WS server (so the SIP proxy) does *nothing* special for clients on a web browser (it does not change the SDP, it does not behave as a SIP B2BUA, it just routes SIP messages). WebSocket is just a new SIP transport, nothing else. I will show it next week. So I strongly need that the rtcweb client (the web browser) is able to deal with SDP bodies (or JS objects mapping the information in a plain or XML SDP) and can make WebRTC calls via a standarized JS API to deal with SDP's and sessions. For example, let's suppose I'm the JavaScript custom code running in a browser and implementing SIP over WebSocket. Me (the JavaScript code) is speaking to the WebRTC JS API: - I receive a SIP INVITE from a peer and render it to my human user ("Bob is calling you, answer? reject?"). The human user accepts the call. - I've received an SDP body from the peer (in the incoming INVITE via WebSocket). WebRTC stack, please parse it and give me a JS object representing it: var remote_sdp =3D new WebRTC.SDP(string, "plain"); - I examine the SDP object and realize that the peer is offering audio and video. - Now please generate my SDP as a reply for the received SDP: var my_sdp =3D WebRTC.SDP.answerFor(remote_sdp); - ...but discard the video offered by the peer. my_sdp.removeStream("video"); - Now I need the plain representation of my SDP (to be included within the SIP 200 OK response): var my_plain_sdp =3D my_sdp.toPlain(); - I send the SIP 200 OK response via WebSocket. - Now start the real media session!: var session =3D new WebRTC.Session(my_sdp, remote_sdp); session.start(); - After a while I want to invite the peer to a video session (over the existing audio session). So first I add the video offer in my SDP object (it would also increment the sessid field in the SDP): my_sdp.addStream("video"); - Then regenerate my plain SDP to be included in a re-INVITE to be sent to the peer: var my_plain_sdp =3D my_sdp.toPlain(); - I get a 200 OK response with a new remote SDP, so parse it into a JS obje= ct: var remote_sdp =3D new WebRTC.SDP(string, "plain"); - I examine the remote SDP to tell my human user wheter the video session has been accepted by the peer or not. if (remote_sdp.hasStream("video")) alert("yeah! the peer accepted video!"); - And now tell the rtcweb stack to update the existing media session: session.update(my_sdp, remote_sdp); - Now I want to put on hold the call, so: my_sdp.putOnHold(); - Then regenerate my plain SDP to be included in a re-INVITE to be sent to the peer: var my_plain_sdp =3D my_sdp.toPlain() - ...and so on... NOTE: The above is just pseudo-code and of course must be terribly improved= . Said that, I think that stating the requirements for *any* signaling mechanism should be the key right now, rather than proposing specific signaling mechanism that "works for me and covers my specific needs (and I don't care about others)". IMHO defining the needs in the WebRTC API is the only important now (IMHO). Best regards. --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Wed Oct 5 02:23: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 E21CF21F8B7C for ; Wed, 5 Oct 2011 02:23:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.634 X-Spam-Level: X-Spam-Status: No, score=-2.634 tagged_above=-999 required=5 tests=[AWL=0.043, 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 3gLu9Zz0dslb for ; Wed, 5 Oct 2011 02:23:46 -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 4A5EC21F8B67 for ; Wed, 5 Oct 2011 02:23:46 -0700 (PDT) Received: by vcbfo11 with SMTP id fo11so1410093vcb.31 for ; Wed, 05 Oct 2011 02:26:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.120.12 with SMTP id b12mr646070vcr.111.1317806813575; Wed, 05 Oct 2011 02:26:53 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Wed, 5 Oct 2011 02:26:53 -0700 (PDT) In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF510F1450@sonusinmail02.sonusnet.com> References: <2E239D6FCD033C4BAF15F386A979BF510F1450@sonusinmail02.sonusnet.com> Date: Wed, 5 Oct 2011 11:26:53 +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] Making progress on the signaling discussion (NB: Actionitems enclosed!) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 09:23:47 -0000 2011/10/5 Ravindran Parthasarathi : > Ted, Magnus, Cullen, > > Could you please consider RTCWeb standard signaling protocol > (http://tools.ietf.org/id/draft-partha-rtcweb-signaling-00.txt) draft as = one > of the proposal for this signaling discussion. Partha, instead of re-suggesting your draft in different threads, please take the time to reply to the given rationale against your insistent proposal. Said that, your draft does NOT propose a signaling protocol, it just wants to *mandate* that SOME specific protocol MUST be implemented in all the rtcweb clients and servers. Please, forget that idea. There is an extended reply and rationale for any of your arguments. A web browser will not implement a native SIP or MEGACO stack, never (I hope). The WWW world cannot be converted into a telco business. Regards. --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Wed Oct 5 02:28: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 831BC21F8B77 for ; Wed, 5 Oct 2011 02:28:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.634 X-Spam-Level: X-Spam-Status: No, score=-2.634 tagged_above=-999 required=5 tests=[AWL=0.043, 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 wdy8ldnuknsM for ; Wed, 5 Oct 2011 02:28:29 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id E42D821F8A35 for ; Wed, 5 Oct 2011 02:28:28 -0700 (PDT) Received: by vcbfo11 with SMTP id fo11so1413267vcb.31 for ; Wed, 05 Oct 2011 02:31:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.89.177 with SMTP id bp17mr2079801vdb.447.1317807096258; Wed, 05 Oct 2011 02:31:36 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Wed, 5 Oct 2011 02:31:36 -0700 (PDT) In-Reply-To: <4E8BC0ED.2020001@skype.net> References: <545388B3-3189-4291-BD1D-52898B888F3E@phonefromhere.com> <4E8BC0ED.2020001@skype.net> Date: Wed, 5 Oct 2011 11:31: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: 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, 05 Oct 2011 09:28:29 -0000 2011/10/5 Matthew Kaufman : > This stuff is exactly what you'll need to add yet more code to solve if y= ou > try to bake SDP offer-answer into the browser to turn it 90% of the way i= nto > a SIP phone. > > And exactly what you *don't* need browser code to solve if it is done > elsewhere (for instance, the server might be handling the entire SIP and = SDP > exchange and resolve forking issues at that end without involving the cli= ent > at all.) No please. The client CAN be intelligent, and that is how SIP usually works (intelligence in endpoints rather than in servers). You can do that if you want (you can build a custom SIP<-->EasySimpleJsonProtocol gateway in server side), but please don't mandate it. Let me to deal with SDP's in client side (at JavaScript level), please. Others could choose what to do, but don't force me to create a ugly application protocol gateway just because some people prefer to make web clients as "simple as possible". Regards. --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Wed Oct 5 02: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 1664321F8A4B for ; Wed, 5 Oct 2011 02:37:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.634 X-Spam-Level: X-Spam-Status: No, score=-2.634 tagged_above=-999 required=5 tests=[AWL=0.043, 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 IKhqL+EJee9G for ; Wed, 5 Oct 2011 02:37:56 -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 6D89521F88B6 for ; Wed, 5 Oct 2011 02:37:56 -0700 (PDT) Received: by vws5 with SMTP id 5so1412713vws.31 for ; Wed, 05 Oct 2011 02:41:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.23.4 with SMTP id i4mr2051364vdf.514.1317807663754; Wed, 05 Oct 2011 02:41:03 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Wed, 5 Oct 2011 02:41:03 -0700 (PDT) In-Reply-To: <4E8BC2FC.2000809@skype.net> References: <545388B3-3189-4291-BD1D-52898B888F3E@phonefromhere.com> <4E8BC2FC.2000809@skype.net> Date: Wed, 5 Oct 2011 11:41:03 +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] 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, 05 Oct 2011 09:37:57 -0000 2011/10/5 Matthew Kaufman : >> =C2=A0That 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). > > I think you're saying that the JS API should be some existing protocol > standard like SIP and SDP here, yes? No, I've *never* tried to mandate a specific signaling protocol, never. I just what my choice to also be feasible, and that is SIP over WebSocket and full intelligence in client side (in the JS application). Others can use whatever they want. > It is much easier to discuss if we keep "the wire protocol" and "the JS A= PI" > separate... and realize that just like my above Win32 example, a "low lev= el" > JS API could in fact be used in conjunction with *any* wire protocol (tha= t > you can send/receive within the browser context) plus server behavior. That's a good approach. Please take a look to other thread in which I've suggested a pseudo-code showing a theorical WebRTC JS API. > This is also true of the "high level" JS API proposals... it is just more > annoying, as you need to do things like trick them into generating an SDP > offer, then decode it locally or send it to a server for processing, and > then kill that and start the actual connection you wanted while lying to = the > browser about what the other end has claimed. > > I'd rather have the API that lets me do what I want directly. Yes, most of the people assumes that the intelligence must be in the web server and can only assume some easy JSON message exchange between web client and server ("the client is stupid, the server is clever"). Ok, let me say that within next months (hopelly) we have: - Web browsers have powerful JavaScript stack for coding client application= s. - WebSocket for building realtime and bidirectional protocols. - RtcWeb for media sessions. So we have *all the tools* for creating a rich multimedia client application (as if it would be a Qt desktop application). Now, if you prefer to leave some logic processing into the web server, that's ok, but please let me using all the power of the client side. Regards. --=20 I=C3=B1aki Baz Castillo From neils@vipadia.com Wed Oct 5 02:49: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 E858321F8B73 for ; Wed, 5 Oct 2011 02:49:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8urAcDMWUCaf for ; Wed, 5 Oct 2011 02:49:42 -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 5246421F8B35 for ; Wed, 5 Oct 2011 02:49:42 -0700 (PDT) Received: by iaby26 with SMTP id y26so1990337iab.31 for ; Wed, 05 Oct 2011 02:52:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.45.17 with SMTP id c17mr3906052ibf.87.1317808369576; Wed, 05 Oct 2011 02:52:49 -0700 (PDT) Sender: neils@vipadia.com Received: by 10.231.200.146 with HTTP; Wed, 5 Oct 2011 02:52:49 -0700 (PDT) In-Reply-To: References: <545388B3-3189-4291-BD1D-52898B888F3E@phonefromhere.com> <4E8BC0ED.2020001@skype.net> Date: Wed, 5 Oct 2011 10:52:49 +0100 X-Google-Sender-Auth: YZYqYKZt2d-xgQ96_iWPMeuekts Message-ID: From: Neil Stratford To: rtcweb@ietf.org Content-Type: multipart/alternative; boundary=0015176f0b4cc02b5f04ae8a2b95 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, 05 Oct 2011 09:50:07 -0000 --0015176f0b4cc02b5f04ae8a2b95 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Oct 5, 2011 at 10:31 AM, I=F1aki Baz Castillo wrote= : > 2011/10/5 Matthew Kaufman : > > This stuff is exactly what you'll need to add yet more code to solve if > you > > try to bake SDP offer-answer into the browser to turn it 90% of the way > into > > a SIP phone. > > > > And exactly what you *don't* need browser code to solve if it is done > > elsewhere (for instance, the server might be handling the entire SIP an= d > SDP > > exchange and resolve forking issues at that end without involving the > client > > at all.) > > No please. The client CAN be intelligent, and that is how SIP usually > works (intelligence in endpoints rather than in servers). > > You can do that if you want (you can build a custom > SIP<-->EasySimpleJsonProtocol gateway in server side), but please > don't mandate it. Let me to deal with SDP's in client side (at > JavaScript level), please. Others could choose what to do, but don't > force me to create a ugly application protocol gateway just because > some people prefer to make web clients as "simple as possible". > I don't think that anyone is saying that we want to mandate a simple Json signalling protocol - just that you have the option of coding it all in javascript at the client side, or at the server side if you wanted to. The important thing in my view is not to bake SDP into the JS API with the browser in such a way that we can only build something that looks like SIP. By SDP 'client side at JavaScript level' are you proposing that the JS API accepts SDP directly as a parameter, or that you parse the SDP in JS and se= t the ICE connection and codecs up as appropriate? (Which is my preference.) --0015176f0b4cc02b5f04ae8a2b95 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Oct 5, 2011 at 10:31 AM, I=F1aki Baz Castillo <= ;ibc@aliax.net> wrote:
2011/10/5 Matthew Kaufman <= matthew.kaufman@skype.net>:
> This stuff is exactly what you'll need to add ye= t more code to solve if you
> try to bake SDP offer-answer into the browser to turn it 90% of the wa= y into
> a SIP phone.
>
> And exactly what you *don't* need browser code to solve if it is d= one
> elsewhere (for instance, the server might be handling the entire SIP a= nd SDP
> exchange and resolve forking issues at that end without involving the = client
> at all.)

No please. The client CAN be intelligent, and that is how SIP usually=
works (intelligence in endpoints rather than in servers).

You can do that if you want (you can build a custom
SIP<-->EasySimpleJsonProtocol gateway in server side), but please
don't mandate it. Let me to deal with SDP's in client side (at
JavaScript level), please. Others could choose what to do, but don't force me to create a ugly application protocol gateway just because
some people prefer to make web clients as "simple as possible".

I don't think that anyone is saying that we want to mandate a simple Js= on signalling protocol - just that you have the option of coding it all in = javascript at the client side, or at the server side if you wanted to. The = important thing in my view is not to bake SDP into the JS API with the brow= ser in such a way that we can only build something that looks like SIP.

By SDP 'client side at JavaScript level' are you proposing = that the JS API accepts SDP directly as a parameter, or that you parse the = SDP in JS and set the ICE connection and codecs up as appropriate? (Which i= s my preference.)=A0
--0015176f0b4cc02b5f04ae8a2b95-- From tim@phonefromhere.com Wed Oct 5 03:00: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 BA71721F8BB3 for ; Wed, 5 Oct 2011 03:00:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.401 X-Spam-Level: X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[AWL=-0.103, 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 h7miseaUQx1m for ; Wed, 5 Oct 2011 03:00:53 -0700 (PDT) Received: from zimbra.westhawk.co.uk (zimbra.westhawk.co.uk [192.67.4.167]) by ietfa.amsl.com (Postfix) with ESMTP id 0DF8D21F8BA4 for ; Wed, 5 Oct 2011 03:00:52 -0700 (PDT) Received: from [192.168.0.14] (unknown [93.89.81.113]) by zimbra.westhawk.co.uk (Postfix) with ESMTP id C8AB237A903; Wed, 5 Oct 2011 11:16:47 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-19-199418076 From: Tim Panton In-Reply-To: Date: Wed, 5 Oct 2011 11:03:54 +0100 Message-Id: <91623260-6A12-4737-8BA9-4D6B60FCD389@phonefromhere.com> References: To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Making progress on the signaling discussion (NB: Action items enclosed!) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 10:00:53 -0000 --Apple-Mail-19-199418076 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 5 Oct 2011, at 10:19, I=F1aki Baz Castillo wrote: > - Now please generate my SDP as a reply for the received SDP: >=20 > var my_sdp =3D WebRTC.SDP.answerFor(remote_sdp); >=20 > - ...but discard the video offered by the peer. >=20 > my_sdp.removeStream("video"); It seems to me that by calling WebRTC.SDP.answerFor() - getting the = native code to do the 'compatibility matching' you've lost quite a lot of influence = over the selection process. Lets say this is a conference app on an android phone - and lets say = that the phone supports h 261, h263 and h264 but only has hardware accel for h264 - the app's = screen layout is such that we only want a postage stamp of the remote user and a still image would = be preferable to a poorly rendered moving one (less distracting) . (so I'd like h264 or = nothing) How does the app express that set of preferences in your scenario? If the app gets all the capabilities data as JSON objects, it can make = decisions itself, eliminating the ones that don't fit the usecase even though they do = actually 'match'. That's why I'd like to see the matching and elimination done in = javascript, with the data presented in a JS friendly manner. It can then be converted to SDP for = sending over the=20 (web-socket) wire if needed. Tim. --Apple-Mail-19-199418076 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
- Now please = generate my SDP as a reply for the received SDP:

 var my_sdp = =3D WebRTC.SDP.answerFor(remote_sdp);

- ...but discard the video = offered by the = peer.

 my_sdp.removeStream("video");
=

It seems to me that by = calling WebRTC.SDP.answerFor() - getting the native = code
to do the 'compatibility matching' you've lost quite a = lot of influence over the selection process.
Lets say this is = a conference app on an android phone - and lets say that the phone = supports
h 261, h263 and h264 but only has hardware accel for = h264 - the app's screen layout is such that
we only want a = postage stamp of the remote user and a still image would be preferable = to a
poorly rendered moving one (less distracting) . (so I'd = like h264 or nothing)


How does = the app express that set of preferences in your = scenario?

If the app gets all the capabilities = data as JSON objects, it can make decisions = itself,
eliminating the ones that don't fit the usecase even = though they do actually 'match'.

That's why I'd = like to see the matching and elimination done in javascript, with the = data
presented in a JS friendly manner. It can then be = converted to SDP for sending over the 
(web-socket) wire = if = needed.

Tim.

= --Apple-Mail-19-199418076-- From ibc@aliax.net Wed Oct 5 03: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 D1B1121F84DF for ; Wed, 5 Oct 2011 03:06:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.634 X-Spam-Level: X-Spam-Status: No, score=-2.634 tagged_above=-999 required=5 tests=[AWL=0.043, 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 Q5-RH4PXA-tu for ; Wed, 5 Oct 2011 03:06: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 F166A21F8BE5 for ; Wed, 5 Oct 2011 03:06:50 -0700 (PDT) Received: by vcbfo11 with SMTP id fo11so1438515vcb.31 for ; Wed, 05 Oct 2011 03:09:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.186.134 with SMTP id fk6mr2034241vdc.380.1317809397877; Wed, 05 Oct 2011 03:09:57 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Wed, 5 Oct 2011 03:09:57 -0700 (PDT) In-Reply-To: <91623260-6A12-4737-8BA9-4D6B60FCD389@phonefromhere.com> References: <91623260-6A12-4737-8BA9-4D6B60FCD389@phonefromhere.com> Date: Wed, 5 Oct 2011 12:09:57 +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] Making progress on the signaling discussion (NB: Action items enclosed!) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 10:06:54 -0000 2011/10/5 Tim Panton : > On 5 Oct 2011, at 10:19, I=C3=B1aki Baz Castillo wrote: > > - Now please generate my SDP as a reply for the received SDP: > > =C2=A0var my_sdp =3D WebRTC.SDP.answerFor(remote_sdp); > > - ...but discard the video offered by the peer. > > =C2=A0my_sdp.removeStream("video"); > > It seems to me that by calling=C2=A0WebRTC.SDP.answerFor() - getting the = native > code > to do the 'compatibility matching' you've lost quite a lot of influence o= ver > the selection process. > Lets say this is a conference app on an android phone - and lets say that > the phone supports > h 261, h263 and h264 but only has hardware accel for h264 - the app's scr= een > layout is such that > we only want a postage stamp of the remote user and a still image would b= e > preferable to a > poorly rendered moving one (less distracting) . (so I'd like h264 or > nothing) > > How does the app express that set of preferences in your scenario? > If the app gets all the capabilities data as JSON objects, it can make > decisions itself, > eliminating the ones that don't fit the usecase even though they do actua= lly > 'match'. > That's why I'd like to see the matching and elimination done in javascrip= t, > with the data > presented in a JS friendly manner. It can then be converted to SDP for > sending over the > (web-socket) wire if needed. Hi Tim, honestly I didn't expect to define the full WebRTC JS API in 5 minutes while I was writting the mail :) Your points are perfectly valid and should indeed be covered. But I didn't want to be so explicit in my immature API suggestion. It was just an overview. Regards. --=20 I=C3=B1aki Baz Castillo From tim@phonefromhere.com Wed Oct 5 03:10: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 4152421F8B36 for ; Wed, 5 Oct 2011 03:10:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.396 X-Spam-Level: X-Spam-Status: No, score=-2.396 tagged_above=-999 required=5 tests=[AWL=-0.098, 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 ZDL1exCNURn0 for ; Wed, 5 Oct 2011 03:10: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 3C3DF21F8B0A for ; Wed, 5 Oct 2011 03:10:54 -0700 (PDT) Received: from [192.168.0.14] (unknown [93.89.81.113]) by zimbra.westhawk.co.uk (Postfix) with ESMTP id 7ADF237A903 for ; Wed, 5 Oct 2011 11:26:54 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-21-200025068 From: Tim Panton Resent-From: Tim Panton In-Reply-To: Date: Wed, 5 Oct 2011 11:13:04 +0100 Resent-Date: Wed, 5 Oct 2011 11:14:01 +0100 Message-Id: <5C27A46C-7090-452B-B253-AC1BEEEC76E2@phonefromhere.com> References: <91623260-6A12-4737-8BA9-4D6B60FCD389@phonefromhere.com> Resent-To: rtcweb@ietf.org To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= X-Mailer: Apple Mail (2.1084) Resent-Message-Id: <20111005102654.7ADF237A903@zimbra.westhawk.co.uk> Subject: Re: [rtcweb] Making progress on the signaling discussion (NB: Action items enclosed!) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 10:10:55 -0000 --Apple-Mail-21-200025068 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 5 Oct 2011, at 11:09, I=F1aki Baz Castillo wrote: >=20 >=20 > Hi Tim, honestly I didn't expect to define the full WebRTC JS API in 5 > minutes while I was writting the mail :) ;-) >=20 > Your points are perfectly valid and should indeed be covered. But I > didn't want to be so explicit in my immature API suggestion. It was > just an overview. I guess what I was getting at was the fact that the SDP seemed=20 central to the API - I'd like something more generic and javascript=20 friendly as the central concept. >=20 > Regards. >=20 > --=20 > I=F1aki Baz Castillo > --Apple-Mail-21-200025068 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1

On 5 Oct 2011, at = 11:09, I=F1aki Baz Castillo wrote:


Hi = Tim, honestly I didn't expect to define the full WebRTC JS API in = 5
minutes while I was writting the mail = :)

;-)


Your points are perfectly valid and should indeed = be covered. But I
didn't want to be so explicit in my immature API = suggestion. It was
just an = overview.

I guess what I was = getting at was the fact that the SDP seemed 
central to = the API - I'd like something more generic and = javascript 
friendly as the central = concept.



Regards.

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

= --Apple-Mail-21-200025068-- From tim@phonefromhere.com Wed Oct 5 03:26: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 0F91F21F8C0F for ; Wed, 5 Oct 2011 03:26:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.391 X-Spam-Level: X-Spam-Status: No, score=-2.391 tagged_above=-999 required=5 tests=[AWL=-0.093, 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 flowAoh+WWLH for ; Wed, 5 Oct 2011 03:26:10 -0700 (PDT) Received: from zimbra.westhawk.co.uk (zimbra.westhawk.co.uk [192.67.4.167]) by ietfa.amsl.com (Postfix) with ESMTP id 62BCD21F8B7C for ; Wed, 5 Oct 2011 03:26:10 -0700 (PDT) Received: from [192.168.0.14] (unknown [93.89.81.113]) by zimbra.westhawk.co.uk (Postfix) with ESMTP id 85FAB37A903; Wed, 5 Oct 2011 11:42:05 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-22-200935782 From: Tim Panton In-Reply-To: Date: Wed, 5 Oct 2011 11:29:12 +0100 Message-Id: <0EF30DF7-91D2-48A5-90BD-B7E7CA3C61E4@phonefromhere.com> References: <91623260-6A12-4737-8BA9-4D6B60FCD389@phonefromhere.com> To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Making progress on the signaling discussion (NB: Action items enclosed!) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 10:26:11 -0000 --Apple-Mail-22-200935782 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 5 Oct 2011, at 11:09, I=F1aki Baz Castillo wrote: >=20 >=20 > Hi Tim, honestly I didn't expect to define the full WebRTC JS API in 5 > minutes while I was writting the mail :) ;-) >=20 > Your points are perfectly valid and should indeed be covered. But I > didn't want to be so explicit in my immature API suggestion. It was > just an overview. I guess what I was getting at was the fact that the SDP seemed=20 central to the API - I'd like something more generic and javascript=20 friendly as the central concept. >=20 > Regards. >=20 > --=20 > I=F1aki Baz Castillo > --Apple-Mail-22-200935782 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1


Hi Tim, honestly I didn't = expect to define the full WebRTC JS API in 5
minutes while I was = writting the mail = :)

;-)


Your points are perfectly valid and should indeed = be covered. But I
didn't want to be so explicit in my immature API = suggestion. It was
just an = overview.

I guess what I was = getting at was the fact that the SDP seemed 
central to = the API - I'd like something more generic and = javascript 
friendly as the central = concept.



Regards.

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

= --Apple-Mail-22-200935782-- From ibc@aliax.net Wed Oct 5 03:37:08 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD22B21F8A7B for ; Wed, 5 Oct 2011 03:37:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.034 X-Spam-Level: X-Spam-Status: No, score=-2.034 tagged_above=-999 required=5 tests=[AWL=-0.557, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_24=0.6, J_CHICKENPOX_63=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 U1NCD3IuZ8DG for ; Wed, 5 Oct 2011 03:37:08 -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 06E0321F8726 for ; Wed, 5 Oct 2011 03:37:07 -0700 (PDT) Received: by vcbfo11 with SMTP id fo11so1458204vcb.31 for ; Wed, 05 Oct 2011 03:40:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.179.202 with SMTP id br10mr650809vcb.41.1317811215330; Wed, 05 Oct 2011 03:40:15 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Wed, 5 Oct 2011 03:40:15 -0700 (PDT) In-Reply-To: <0EF30DF7-91D2-48A5-90BD-B7E7CA3C61E4@phonefromhere.com> References: <91623260-6A12-4737-8BA9-4D6B60FCD389@phonefromhere.com> <0EF30DF7-91D2-48A5-90BD-B7E7CA3C61E4@phonefromhere.com> Date: Wed, 5 Oct 2011 12:40:15 +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] Making progress on the signaling discussion (NB: Action items enclosed!) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 10:37:09 -0000 2011/10/5 Tim Panton : >> Your points are perfectly valid and should indeed be covered. But I >> didn't want to be so explicit in my immature API suggestion. It was >> just an overview. > I guess what I was getting at was the fact that the SDP seemed > central to the API - I'd like something more generic and javascript > friendly as the central concept. Hi Tim. At the end you web application will receive (via the custom signaling) something "like" and SDP containing the media information offered/answered by the peer (when receiving or initiating a media session). This is: your web browser needs to know the remote IP:port, the media streams, supported codecs by the peer... At the end that looks like a SDP. And such "SDP" should be retrieved by your web application via some signaling protocol (on top of HTTP or WebSocket), and you will receive it as a JSON object, or XML, or whatever format. Then you will always need to parse such "like-SDP", obtain something like a WebRTC.SDP object, and use it for starting/answering a session. You can propose a different name, something like... "WebRTC.SessionDescription"? :) but the underlying concept is the same (IMHO). Regards. --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Wed Oct 5 03:37: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 E753121F8ADE for ; Wed, 5 Oct 2011 03:37:44 -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.044, 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 aZ5TDLwdAKlE for ; Wed, 5 Oct 2011 03:37: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 EA00321F877F for ; Wed, 5 Oct 2011 03:37:43 -0700 (PDT) Received: by vcbfo11 with SMTP id fo11so1458595vcb.31 for ; Wed, 05 Oct 2011 03:40:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.120.12 with SMTP id b12mr664767vcr.111.1317811251394; Wed, 05 Oct 2011 03:40:51 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Wed, 5 Oct 2011 03:40:51 -0700 (PDT) In-Reply-To: References: <91623260-6A12-4737-8BA9-4D6B60FCD389@phonefromhere.com> <0EF30DF7-91D2-48A5-90BD-B7E7CA3C61E4@phonefromhere.com> Date: Wed, 5 Oct 2011 12:40:51 +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] Making progress on the signaling discussion (NB: Action items enclosed!) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 10:37:45 -0000 2011/10/5 I=C3=B1aki Baz Castillo : > Hi Tim. At the end you web application will receive (via the custom > signaling) something "like" and SDP I meant "something like a SDP" --=20 I=C3=B1aki Baz Castillo From neils@vipadia.com Wed Oct 5 03:57: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 C60FB21F8A7A for ; Wed, 5 Oct 2011 03:57:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.9 X-Spam-Level: X-Spam-Status: No, score=-2.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] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CgYa4juzkb3m for ; Wed, 5 Oct 2011 03:57:05 -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 9733021F85F2 for ; Wed, 5 Oct 2011 03:57:05 -0700 (PDT) Received: by iaby26 with SMTP id y26so2061298iab.31 for ; Wed, 05 Oct 2011 04:00:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.0.133 with SMTP id 5mr4161840ibb.22.1317812412946; Wed, 05 Oct 2011 04:00:12 -0700 (PDT) Sender: neils@vipadia.com Received: by 10.231.200.146 with HTTP; Wed, 5 Oct 2011 04:00:12 -0700 (PDT) In-Reply-To: References: <545388B3-3189-4291-BD1D-52898B888F3E@phonefromhere.com> <4E8BC0ED.2020001@skype.net> <4E8BDC3B.7000501@skype.net> Date: Wed, 5 Oct 2011 12:00:12 +0100 X-Google-Sender-Auth: dJrE-cZgwQwgrBTypYfTZytVsCM Message-ID: From: Neil Stratford To: Roman Shpount Content-Type: multipart/alternative; boundary=0015177407b8c118ba04ae8b1c19 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, 05 Oct 2011 10:57:06 -0000 --0015177407b8c118ba04ae8b1c19 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Oct 5, 2011 at 7:21 AM, Roman Shpount wrote: > > On Wed, Oct 5, 2011 at 12:25 AM, Matthew Kaufman < > matthew.kaufman@skype.net> wrote: > >> How about I rephrase? >> >> If I generate an offer by writing SDP code in C++ using Win32 APIs to >> allocate sockets and send and receive packets, and I send a SIP packet that >> gets multiple answers in the same dialog, how do I process those answers >> using the Win32 API? See how silly that sounds? >> >> Seriously though, if you need an additional local endpoint because of >> forking, you need to create a second connection object, which will then give >> you an onCandidates() callback, as I understand this API proposal. The other >> way to do it is to have the connection object be able to bind to multiple >> possible far endpoints, but that's not exactly what this API says, and it >> isn't clear that it is needed. (Because it isn't how other SIP devices use >> their network stacks to solve this problem either). >> >> > I think you are completely missing the point: If I build similar thing > using Win32 API, I would re-initialize codec and RTP states and re-do the > ICE candidate selection based on the new answer. This particular API has > methods to add and remove streams and candidates, but no method to start a > re-negotiation. Don't assume something is silly just because you did not > understand it. > I'm sure if it is required we can add the ability to re-start ICE negotiation with a new set of farCandidates once the JS decides what to do as a result of the fork. (I'm not a great supporter of the need for forking, but if there are real use cases then lets add it.) ... Once again, you are missing the point completely. Part of the problem here > is that typically codec information in offer/answer exchange does not > provide the list of all the codec level parameters supported by the codec. > The fact that, for instance SILK implementation supports FEC or DTX does not > have to be present in the offer to be present in the answer. This means > Codec object will need to expose a more information then typically provided > in SDP (ie all the supported codec parameters vs just the desired one). This > means RTC will need to define fields for this object for each codec it will > support and cannot simply reuse MMUSIC/PAYLOAD standards. > I'm not sure I understand why this is such a problem. XMPP/Jingle defines it's own mapping, which is a common VoIP protocol that is widely supported. I'd much rather that the JS API is as expressive as possible in codec specific matters - for example even to the point of providing callbacks to the JS on certain codec level events, such as decoding a DTMF digit. > This also brings about the whole new problem -- asymmetric codecs and codec > parameters. There are a lot of valid use cases when you want to use > different codecs in different directions (different hardware optimized > codecs in different mobile devices). There are cases when different payload > types are used for the same codecs in different directions (It can also be > considered an RTP bug). You might want to use different video resolutions > due to device camera and display limitations. You might want to use > different codec bandwidths due to difference in up and down stream network > capacity. There is no way to handle this now. I would suggest that the > better model for third party call control or inbound call would be get the > offer from remote side, process it on the server or in javascript, pass it > to the RTC stack in the browser, get the answer from the RTC stack in the > browser, process it (if needed) in javascript or on the server and send it > to the remote side. > Again, if it's required I don't see why we can't support asymmetric codecs in the low level API. In my view a lot of this codec manipulation is much better controlled by the JS which has application specific knowledge about how to adapt to given situations than the browser itself. How would you signal to the browser to dynamically lower framerate rather than image size, or colour depth depending on the application use case? Giving the application direct control over codec parameters seems a better option. > Yet another codec negotiation deficiency that I see here is that you cannot > specify multiple codecs. It is fairly typical to have audio codec, comfort > noise codec, and DTMF to be used at the same time for a single stream. > Agreed - this is an oversight. Though I don't see any mention of DTMF in the current PeerConnection draft either. I would propose in the low level API that we add a DTMF codec with a callback on events and a function to transmit. How would you do this in the PeerConnection API? How would you specify to generate in-band DTMF on the ULAW codec rather than send an RFC2833 digit? > Final comment about the draft is that it is missing a lot of parameters > about codecs. It is missing things like media type, transport type, clock > rates, payload types, crypto attributes, etc. It would be interesting to see > which attributes would end up in which of the objects. Agreed. These all need to be added - if you have suggestions it would be great to include them. Neil --0015177407b8c118ba04ae8b1c19 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Oct 5, 2011 at 7:21 AM, Roman Shpount <roman@telurix.com<= /a>> wrote:

On Wed, Oct 5, 2011 at 12:= 25 AM, Matthew Kaufman <matthew.kaufman@skype.net> w= rote:
=20 =20 =20
How about I rephrase?

If I generate an offer by writing SDP code in C++ using Win32 APIs to allocate sockets and send and receive packets, and I send a SIP packet that gets multiple answers in the same dialog, how do I process those answers using the Win32 API? See how silly that sounds?

Seriously though, if you need an additional local endpoint because of forking, you need to create a second connection object, which will then give you an onCandidates() callback, as I understand this API proposal. The other way to do it is to have the connection object be able to bind to multiple possible far endpoints, but that's not exactly what this API says, and it isn't clear that = it is needed. (Because it isn't how other SIP devices use their network stacks to solve this problem either).

=

I think you are completely missing the point: If I build sim= ilar thing using Win32 API, I would re-initialize codec and=A0 RTP states a= nd re-do the ICE candidate selection based on the new answer. This particul= ar API has methods to add and remove streams and candidates, but no method = to start a re-negotiation. Don't assume something is silly just because= you did not understand it.

I'm sure if it is required= we can add the ability to re-start ICE negotiation with a new set of farCa= ndidates once the JS decides what to do as a result of the fork. (I'm n= ot a great supporter of the need for forking, but if there are real use cas= es then lets add it.)
=A0
...

= Once again, you are missing the point completely. Part of the problem here = is that typically codec information in offer/answer exchange does not provi= de the list of all the codec level parameters supported by the codec. The f= act that, for instance SILK implementation supports FEC or DTX does not hav= e to be present in the offer to be present in the answer. This means Codec = object will need to expose a more information then typically provided in SD= P (ie all the supported codec parameters vs just the desired one). This mea= ns RTC will need to define fields for this object for each codec it will su= pport and cannot simply reuse MMUSIC/PAYLOAD standards.

I'm not sure I understand why this is = such a problem. XMPP/Jingle defines it's own mapping, which is a common= VoIP protocol that is widely supported. I'd much rather that the JS AP= I is as expressive as possible in codec specific matters - for example even= to the point of providing callbacks to the JS on certain codec level event= s, such as decoding a DTMF digit.
=A0
This also brings about the wh= ole new problem -- asymmetric codecs and codec parameters. There are a lot = of valid use cases when you want to use different codecs in different direc= tions (different hardware optimized codecs in different mobile devices). Th= ere are cases when different payload types are used for the same codecs in = different directions (It can also be considered an RTP bug). You might want= to use different video resolutions due to device camera and display limita= tions. You might want to use different codec bandwidths due to difference i= n up and down stream network capacity. There is no way to handle this now. = I would suggest that the better model for third party call control or inbou= nd call would be get the offer from remote side, process it on the server o= r in javascript, pass it to the RTC stack in the browser, get the answer fr= om the RTC stack in the browser, process it (if needed) in javascript or on= the server and send it to the remote side.

Again, if it's required I don't se= e why we can't support asymmetric codecs in the low level API. In my vi= ew a lot of this codec manipulation is much better controlled by the JS whi= ch has application specific knowledge about how to adapt to given situation= s than the browser itself. How would you signal to the browser to dynamical= ly lower framerate rather than image size, or colour depth depending on the= application use case? Giving the application direct control over codec par= ameters seems a better option.
=A0
Yet another codec negotiation= deficiency that I see here is that you cannot specify multiple codecs. It = is fairly typical to have audio codec, comfort noise codec, and DTMF to be = used at the same time for a single stream.

Agreed - this is an oversight. Though I do= n't see any mention of DTMF in the current PeerConnection draft either.= I would propose in the low level API that we add a DTMF codec with a callb= ack on events and a function to transmit. How would you do this in the Peer= Connection API? How would you specify to generate in-band DTMF on the ULAW = codec rather than send an RFC2833 digit?
=A0
Final comment about the draft= is that it is missing a lot of parameters about codecs. It is missing thin= gs like media type, transport type, clock rates, payload types, crypto attr= ibutes, etc. It would be interesting to see which attributes would end up i= n which of the objects.=A0

Agreed. These all need to be added - if you have sugges= tions it would be great to include them.

Neil=A0
--0015177407b8c118ba04ae8b1c19-- From tim@phonefromhere.com Wed Oct 5 04:02: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 0DC1021F85D1 for ; Wed, 5 Oct 2011 04:02:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.787 X-Spam-Level: X-Spam-Status: No, score=-1.787 tagged_above=-999 required=5 tests=[AWL=-0.688, BAYES_00=-2.599, J_CHICKENPOX_24=0.6, J_CHICKENPOX_63=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 NrQiWpZo1KiK for ; Wed, 5 Oct 2011 04:02:17 -0700 (PDT) Received: from zimbra.westhawk.co.uk (zimbra.westhawk.co.uk [192.67.4.167]) by ietfa.amsl.com (Postfix) with ESMTP id 2247221F8515 for ; Wed, 5 Oct 2011 04:02:17 -0700 (PDT) Received: from [192.168.0.14] (unknown [93.89.81.113]) by zimbra.westhawk.co.uk (Postfix) with ESMTP id 5B1D037A903; Wed, 5 Oct 2011 12:18:12 +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: Wed, 5 Oct 2011 12:05:18 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <91623260-6A12-4737-8BA9-4D6B60FCD389@phonefromhere.com> <0EF30DF7-91D2-48A5-90BD-B7E7CA3C61E4@phonefromhere.com> To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Making progress on the signaling discussion (NB: Action items enclosed!) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 11:02:18 -0000 On 5 Oct 2011, at 11:40, I=F1aki Baz Castillo wrote: > 2011/10/5 Tim Panton : >>> Your points are perfectly valid and should indeed be covered. But I >>> didn't want to be so explicit in my immature API suggestion. It was >>> just an overview. >=20 >=20 >> I guess what I was getting at was the fact that the SDP seemed >> central to the API - I'd like something more generic and javascript >> friendly as the central concept. >=20 >=20 > Hi Tim. At the end you web application will receive (via the custom > signaling) something "like" and SDP containing the media information > offered/answered by the peer (when receiving or initiating a media > session). >=20 > This is: your web browser needs to know the remote IP:port, the media > streams, supported codecs by the peer... At the end that looks like a > SDP. And such "SDP" should be retrieved by your web application via > some signaling protocol (on top of HTTP or WebSocket), and you will > receive it as a JSON object, or XML, or whatever format. Agreed. We are now getting down to the format, I'd like to see the codec capabilities separated from the network ports , as to my mind they are orthogonal. SDP gets into all sorts of complexity with IPv6 (e.g. = happy eyeballs) partly because it intermixes the 2 things.=20 >=20 > Then you will always need to parse such "like-SDP", obtain something > like a WebRTC.SDP object, and use it for starting/answering a session. >=20 Yes, we will need that information to set up the session.=20 I'd like the format of that information to be one that I can easily manipulate it - selecting the relevant ports and codecs in javascript without actually needing to parse or use SDP or being limited to = offer-answer=20 semantics. > You can propose a different name, something like... > "WebRTC.SessionDescription"? :) > but the underlying concept is the same (IMHO). Yes, we are now discussing detail, but as they say, the devil is in the = detail ;-) >=20 > Regards. >=20 >=20 > --=20 > I=F1aki Baz Castillo > From harald@alvestrand.no Wed Oct 5 05:04: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 9E86921F8C8D for ; Wed, 5 Oct 2011 05:04:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.338 X-Spam-Level: X-Spam-Status: No, score=-108.338 tagged_above=-999 required=5 tests=[AWL=2.261, 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 Y1a5-wjViKVw for ; Wed, 5 Oct 2011 05:03:59 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id A1BDD21F8C45 for ; Wed, 5 Oct 2011 05:03:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id ADB7939E0A7 for ; Wed, 5 Oct 2011 14:07:06 +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 BSpLnqeDaBzM for ; Wed, 5 Oct 2011 14:07:06 +0200 (CEST) Received: from [172.16.41.139] (unknown [74.125.121.33]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 2743D39E048 for ; Wed, 5 Oct 2011 14:07:06 +0200 (CEST) Message-ID: <4E8C4868.8060509@alvestrand.no> Date: Wed, 05 Oct 2011 14:07:04 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4E8B192E.80809@ericsson.com> <4E8B20BA.3080906@jesup.org> In-Reply-To: <4E8B20BA.3080906@jesup.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Summary of ICE discussion X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 12:04:00 -0000 On 10/04/2011 05:05 PM, Randell Jesup wrote: > On 10/4/2011 10:33 AM, Magnus Westerlund wrote: >> > > I've been discussing some options on this with Cullen on the side. No > breakthroughs yet, though there may still be some hope. If there's > something there I'll post it soon, otherwise assume it didn't pan out. > > One observation about the security/attack-vector side of this: Any > objection that includes "if an attacker is in a MITM position they > could trick the rtcweb client into sending media" is an invalid > objection. A MITM attacker could inject or re-route any amount of > traffic they wanted already if they're in the media path. I'll also > note that an attacker could be in MITM on the signalling side or DNS, > but not MITM on the media/ICE routing; those are valid cases to > consider. And DNS poisoning doesn't require MITM. Concur that the first form of the objection is invalid without further description ... I would note that any proposed solution that allows the attacker to be MITM on the path for verification of acceptance-to-receive (such as a hypothetical RTCP-based mechanism where mechanisms exist to let RTCP use IP addresses completely independent of the RTP path) would make the MITM objection valid. (ouch. That was a convoluted sentence. Parse leniently!) > > From harald@alvestrand.no Wed Oct 5 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 CB52821F8CC0 for ; Wed, 5 Oct 2011 05:06:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.457 X-Spam-Level: X-Spam-Status: No, score=-108.457 tagged_above=-999 required=5 tests=[AWL=2.142, 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 4-61y3Q4jlJz for ; Wed, 5 Oct 2011 05:06:23 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id E9B4221F8CBF for ; Wed, 5 Oct 2011 05:06:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5CABE39E0A7; Wed, 5 Oct 2011 14:09: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 V1BDwhtPrQVf; Wed, 5 Oct 2011 14:09:29 +0200 (CEST) Received: from [172.16.41.139] (unknown [74.125.121.33]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 90CC939E048; Wed, 5 Oct 2011 14:09:29 +0200 (CEST) Message-ID: <4E8C48F8.5060001@alvestrand.no> Date: Wed, 05 Oct 2011 14:09:28 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: Colin Perkins References: <4E830E89.3050400@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] 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, 05 Oct 2011 12:06:23 -0000 On 10/04/2011 05:49 PM, Colin Perkins wrote: > Harald, > > On 28 Sep 2011, at 13:09, 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 minor editorial point: the 3rd bullet in section 7 suggests that SDP for new codecs is specified by MMUSIC. This is inaccurate: the SDP is done by PAYLOAD, as an algorithmic mapping from the parameters of the new media type. Suggest changing: > > 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 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 codecs, old > applications written before the codecs were specified should > automatically be able to use the new codecs where appropriate > with no changes to the JS applications. > > to > > 3. When a new codec is specified, and the media type parameters > for the new codec are specified in the PAYLOAD WG, no other > standardization would should be required for it to be possible to > use that in the web browsers. Adding new codecs which might have > new media type parameters should not change the APIs between the > browser and javascript application. As soon as the browsers > support the new codecs, old applications written before the codecs > were specified should automatically be able to use the new codecs > where appropriate with no changes to the JS applications. Will do. Thanks! > You might also want to add something like "The representation of codec names and their parameters in the web browsers must be algorithmically derivable from the media type name and parameters defined in the RTP payload format specification for the codec. This can be done by using the media type name and its parameters directly; by using the existing encoding of that name and parameters into SDP; or by defining an algorithmic mapping from the media type name and parameters onto a new signalling format". I'll leave this to drafts that discuss codec negotiation, I think. The PeerConnection proposal for an API has no need to represent names or parameters of codecs independent of their SDP form; other proposals, such as the "Low level API" currently being discussed in WEBRTC, would have such a need. From magnus.westerlund@ericsson.com Wed Oct 5 05:06: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 4893221F8CC0 for ; Wed, 5 Oct 2011 05:06:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.484 X-Spam-Level: X-Spam-Status: No, score=-106.484 tagged_above=-999 required=5 tests=[AWL=0.115, 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 UuNy1VYGoaIX for ; Wed, 5 Oct 2011 05:06:49 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 1CEA921F8CBF for ; Wed, 5 Oct 2011 05:06:48 -0700 (PDT) X-AuditID: c1b4fb3d-b7b1aae000001146-ce-4e8c652d76ba Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 31.46.04422.D256C8E4; Wed, 5 Oct 2011 16:09:52 +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, 5 Oct 2011 14:09:25 +0200 Message-ID: <4E8C48F2.6090502@ericsson.com> Date: Wed, 5 Oct 2011 14:09:22 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4E89C099.3000709@alvestrand.no> <4E89CBF1.8050207@alvestrand.no> In-Reply-To: <4E89CBF1.8050207@alvestrand.no> X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [rtcweb] Future requirement: RTC-Web apps must work through interface switching X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 12:06:50 -0000 Hi, (as individual) I would like to comment on two things around this with ICE restarts and what I believe Google Voice Talk does and its relation to the ICE spec. First of all I understand this being based on that the candidates are kept alive after the initial nomination so they are always ready. This is clearly allowed, but will definitely fail if the other part doesn't keep its ICE candidates alive, and do note that these might include TURN relay candidates also. Thus this practice is not without some resource consumption, even if it is only a STUN request every 15 seconds. Secondly, I understand that the alternative candidates are used without signaling to the other peer that the ICE connectivity checks and later nomination happens. This will not work for candidate pairs where the peer not having interface change happen to it is behind a middlebox with a address dependent filtering rule, i.e. practically all, unless the candidate pair hasn't be initially verified to work and kept alive without nomination due to lower priority for the whole call. Otherwise, this only works when both sides tries to use their candidates due to ICE restart signaling message or that the other peer also suspects path breakage and initiates an ICE restart implicitly based on lack of feedback and media traffic from peer. When it comes to handling interface changes in general. I do believe that we will need to support a signaled ICE restart. If not, the webapp can anyway emulate this at a higher resource consumption and likely longer media disruption by opening new peer connections. Cheers Magnus On 2011-10-03 16:51, Harald Alvestrand wrote: > On 10/03/2011 04:40 PM, Markus.Isomaki@nokia.com wrote: >> Hi Harald, >> >> Well, things may already be better than what I expected :) >> >>> The control channel needs to be reconnected too, of course, but >>> we're not so much in a hurry over that one. >> So you're not signaling anything at the point of the switch, but >> you have set two alternatives beforehand? In the mobile use case, >> the available interfaces come and go, so we can't offer all >> alternate candidates upfront. However, if we can keep the "old" >> interface up for a while after the "new" one appears, we can add >> the new candidate at that point. > Section 9 of RFC 5245 is the procedure for adding more candidates > during the call. It supports make-before-break: > > 9.1.1.1. ICE Restarts > > An agent MAY restart ICE processing for an existing media stream. > An ICE restart, as the name implies, will cause all previous states > of ICE processing to be flushed and checks to start anew. The only > difference between an ICE restart and a brand new media session is > that, during the restart, media can continue to be sent to the > previously validated pair. > >> This would be the so called make-before-break switch. The worst >> case is that we loose the old interface at the same time as new one >> comes available, so the new alternative can only be sent over the >> new interface AFTER the signaling has been reconnected. This would >> be break-before-make. If the underlying OS can handle multi-homing, >> we should in most cases only need the make-before-break type of >> switching. However, as we know, a device can run out of Wi-Fi >> coverate quite abruptly and it is not always clear that the >> cellular connectivity is fully up at that point. >> >> I don't know all nuances of ICE by heart, but is it so that the >> alternate candidates can be added in an offer at any point? In that >> case we should be able to cover most cases quite well. >> >> Markus >> >>> -----Original Message----- From: rtcweb-bounces@ietf.org >>> [mailto:rtcweb-bounces@ietf.org] On Behalf Of ext Harald >>> Alvestrand Sent: 03 October, 2011 17:03 To: rtcweb@ietf.org >>> Subject: Re: [rtcweb] Future requirement: RTC-Web apps must work >>> through interface switching >>> >>> The media channels in Google's ICE-based offerings (Google Talk >>> Video, Google Voice and Hangouts) all are able to survive an >>> interface change by utilizing the alternate candidate mechanisms >>> in ICE. >>> >>> Try this experiment: - Make sure your laptop has a working >>> wireless connection - Connect your laptop to wired Ethernet - Set >>> up a Google Talk Video call with someone - Yank out the Ethernet >>> cord >>> >>> If all goes well, you should see exactly how much of a break this >>> causes to the call in practice. (If the call disconnects, please >>> file a bug - I'm sure there are cases we don't handle well.) >>> >>> The control channel needs to be reconnected too, of course, but >>> we're not so much in a hurry over that one. -- 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 Oct 5 05:19: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 23F9321F8CA8 for ; Wed, 5 Oct 2011 05:19:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.563 X-Spam-Level: X-Spam-Status: No, score=-108.563 tagged_above=-999 required=5 tests=[AWL=2.035, 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 XUQ2WJ8U9M7Z for ; Wed, 5 Oct 2011 05:19:29 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id C5D1E21F8CA9 for ; Wed, 5 Oct 2011 05:19:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3B07439E0A7 for ; Wed, 5 Oct 2011 14:22: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 Yk9GShJdke8E for ; Wed, 5 Oct 2011 14:22:35 +0200 (CEST) Received: from [172.16.41.139] (unknown [74.125.121.33]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 5EB9439E048 for ; Wed, 5 Oct 2011 14:22:35 +0200 (CEST) Message-ID: <4E8C4C0A.4090408@alvestrand.no> Date: Wed, 05 Oct 2011 14:22:34 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4E8B192E.80809@ericsson.com>, In-Reply-To: Content-Type: multipart/alternative; boundary="------------060009060301060809050602" Subject: Re: [rtcweb] Summary of ICE discussion X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 12:19:31 -0000 This is a multi-part message in MIME format. --------------060009060301060809050602 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 10/04/2011 06:28 PM, Bernard Aboba wrote: > I think this is a good summary of where we are with respect to ICE, and > since there are no good alternatives on the table, it seems reasonable to > move on to the next step. > > IMHO, this would involve a more detailed analysis of the threats and what > needs to be done to resolve them. > > In particular, the statement "STUN Connectivity Check MUST have > succeeded" is > necessary but not sufficient. We need to get into a discussion of > the specific > conditions under which media can be sent, and what attacks are still > possible. .... > Also, it would be desirable to prevent a browser from sending much more > bandwidth than the receiver has consented to; however, because signaling > is largely opaque to the browser, it is not obvious (at least to me) > how to > prevent this. Note - at the moment, the PeerConnection proposal has a lot of the signalling happening within the browser. So the browser knows what bandwidths have been negotiated and so on, and can police accordingly. An implementation that followed the "low level" model and did negotiation in (untrusted) Javascript would have less insight. This helps less than it might - the messages are sent in the clear, and unprotected against intermediaries, and they have to be that way to enable signalling gateways to do their thing, so the browser has no way of verifying that a reply that comes back with the suggestion "let's send 100 Mbits/sec" was actually what the remote end consented to; a malevolent (or even just broken) signalling relay could easily change this parameter. I suspect that the solutions here may have to involve congestion control and slow start; for instance, ubiquitous, browser-policed support of a TMMBR-like mechanism where the recipient states what it's willing to receive over the RTCP channel would reduce the attack window of this particular attack to something that we might consider acceptable. Harald --------------060009060301060809050602 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 10/04/2011 06:28 PM, Bernard Aboba wrote:
I think this is a good summary of where we are with respect to ICE, and
since there are no good alternatives on the table, it seems reasonable to
move on to the next step.

IMHO, this would involve a more detailed analysis of the threats and what
needs to be done to resolve them.

In particular, the statement "STUN Connectivity Check MUST have succeeded" is
necessary but not sufficient.   We need to get into a discussion of the specific
conditions under which media can be sent, and what attacks are still
possible.
....
Also, it would be desirable to prevent a browser from sending much more
bandwidth than the receiver has consented to;  however, because signaling
is largely opaque to the browser, it is not obvious (at least to me) how to
prevent this.
Note - at the moment, the PeerConnection proposal has a lot of the signalling happening within the browser. So the browser knows what bandwidths have been negotiated and so on, and can police accordingly. An implementation that followed the "low level" model and did negotiation in (untrusted) Javascript would have less insight.

This helps less than it might - the messages are sent in the clear, and unprotected against intermediaries, and they have to be that way to enable signalling gateways to do their thing, so the browser has no way of verifying that a reply that comes back with the suggestion "let's send 100 Mbits/sec" was actually what the remote end consented to; a malevolent (or even just broken) signalling relay could easily change this parameter.

I suspect that the solutions here may have to involve congestion control and slow start; for instance, ubiquitous, browser-policed support of a TMMBR-like mechanism where the recipient states what it's willing to receive over the RTCP channel would reduce the attack window of this particular attack to something that we might consider acceptable.

                 Harald




--------------060009060301060809050602-- From harald@alvestrand.no Wed Oct 5 05:32: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 8A88E21F8B18 for ; Wed, 5 Oct 2011 05:32:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.361 X-Spam-Level: X-Spam-Status: No, score=-108.361 tagged_above=-999 required=5 tests=[AWL=1.638, 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 2HRuiRWClQd8 for ; Wed, 5 Oct 2011 05:32:53 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id D542621F8AFD for ; Wed, 5 Oct 2011 05:32:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6BA7239E0A7 for ; Wed, 5 Oct 2011 14:35: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 3MirKP2WE9O4 for ; Wed, 5 Oct 2011 14:35:53 +0200 (CEST) Received: from [172.16.41.139] (unknown [74.125.121.33]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 9D26939E048 for ; Wed, 5 Oct 2011 14:35:53 +0200 (CEST) Message-ID: <4E8C4F28.4070506@alvestrand.no> Date: Wed, 05 Oct 2011 14:35:52 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: rtcweb@ietf.org References: <91623260-6A12-4737-8BA9-4D6B60FCD389@phonefromhere.com> <0EF30DF7-91D2-48A5-90BD-B7E7CA3C61E4@phonefromhere.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [rtcweb] Making progress on the signaling discussion (NB: Action items enclosed!) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 12:32:53 -0000 On 10/05/2011 01:05 PM, Tim Panton wrote: > On 5 Oct 2011, at 11:40, Iaki Baz Castillo wrote: > >> 2011/10/5 Tim Panton: >>>> Your points are perfectly valid and should indeed be covered. But I >>>> didn't want to be so explicit in my immature API suggestion. It was >>>> just an overview. >> >>> I guess what I was getting at was the fact that the SDP seemed >>> central to the API - I'd like something more generic and javascript >>> friendly as the central concept. >> >> Hi Tim. At the end you web application will receive (via the custom >> signaling) something "like" and SDP containing the media information >> offered/answered by the peer (when receiving or initiating a media >> session). > > >> This is: your web browser needs to know the remote IP:port, the media >> streams, supported codecs by the peer... At the end that looks like a >> SDP. And such "SDP" should be retrieved by your web application via >> some signaling protocol (on top of HTTP or WebSocket), and you will >> receive it as a JSON object, or XML, or whatever format. > > Agreed. We are now getting down to the format, I'd like to see the > codec capabilities separated from the network ports , as to my mind they > are orthogonal. SDP gets into all sorts of complexity with IPv6 (e.g. happy eyeballs) > partly because it intermixes the 2 things. > Unfortunately the two things are tied together in nontrivial ways by our choice of RTP. The media engine has to generate RTP packets, which have to be marked with a specific payload type (negotiated between the endpoints to represent the codec), and have to have an SSRC and IP destination address put onto them that will cause the remote end to identify the RTP session (from IP address) and media stream (from SSRC) correctly; since PT values are only valid within a single RTP session, it follows that one cannot deduce the codec from the incoming packet without being party to the negotiation of IP addresses. I'm certain this can be represented in a cleaner way than SDP currently does it. But "orthogonal", if taken at face value, seems to hope for a more well structured world than is currently achievable. Harald From tim@phonefromhere.com Wed Oct 5 05: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 54A5F21F8C56 for ; Wed, 5 Oct 2011 05:43:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.208 X-Spam-Level: X-Spam-Status: No, score=-2.208 tagged_above=-999 required=5 tests=[AWL=-0.209, 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 SQ3Kfz-Um+9X for ; Wed, 5 Oct 2011 05:43:09 -0700 (PDT) Received: from zimbra.westhawk.co.uk (zimbra.westhawk.co.uk [192.67.4.167]) by ietfa.amsl.com (Postfix) with ESMTP id 998B521F8C53 for ; Wed, 5 Oct 2011 05:43:09 -0700 (PDT) Received: from [192.168.0.14] (unknown [93.89.81.113]) by zimbra.westhawk.co.uk (Postfix) with ESMTP id 1AD3D37A903; Wed, 5 Oct 2011 13:59:05 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Tim Panton In-Reply-To: <4E8C4F28.4070506@alvestrand.no> Date: Wed, 5 Oct 2011 13:46:11 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <7AB69748-DF24-4C3F-A302-56DDED2A5675@phonefromhere.com> References: <91623260-6A12-4737-8BA9-4D6B60FCD389@phonefromhere.com> <0EF30DF7-91D2-48A5-90BD-B7E7CA3C61E4@phonefromhere.com> <4E8C4F28.4070506@alvestrand.no> To: Harald Alvestrand X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Making progress on the signaling discussion (NB: Action items enclosed!) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 12:43:10 -0000 On 5 Oct 2011, at 13:35, Harald Alvestrand wrote: > On 10/05/2011 01:05 PM, Tim Panton wrote: >> On 5 Oct 2011, at 11:40, I=F1aki Baz Castillo wrote: >>=20 >>> 2011/10/5 Tim Panton: >>>>> Your points are perfectly valid and should indeed be covered. But = I >>>>> didn't want to be so explicit in my immature API suggestion. It = was >>>>> just an overview. >>>=20 >>>> I guess what I was getting at was the fact that the SDP seemed >>>> central to the API - I'd like something more generic and javascript >>>> friendly as the central concept. >>>=20 >>> Hi Tim. At the end you web application will receive (via the custom >>> signaling) something "like" and SDP containing the media information >>> offered/answered by the peer (when receiving or initiating a media >>> session). >>=20 >>=20 >>> This is: your web browser needs to know the remote IP:port, the = media >>> streams, supported codecs by the peer... At the end that looks like = a >>> SDP. And such "SDP" should be retrieved by your web application via >>> some signaling protocol (on top of HTTP or WebSocket), and you will >>> receive it as a JSON object, or XML, or whatever format. >>=20 >> Agreed. We are now getting down to the format, I'd like to see the >> codec capabilities separated from the network ports , as to my mind = they >> are orthogonal. SDP gets into all sorts of complexity with IPv6 (e.g. = happy eyeballs) >> partly because it intermixes the 2 things. >>=20 > Unfortunately the two things are tied together in nontrivial ways by = our choice of RTP. >=20 > The media engine has to generate RTP packets, which have to be marked = with a specific payload type (negotiated between the endpoints to = represent the codec), and have to have an SSRC and IP destination = address put onto them that will cause the remote end to identify the RTP = session (from IP address) and media stream (from SSRC) correctly; since = PT values are only valid within a single RTP session, it follows that = one cannot deduce the codec from the incoming packet without being party = to the negotiation of IP addresses. >=20 > I'm certain this can be represented in a cleaner way than SDP = currently does it. But "orthogonal", if taken at face value, seems to = hope for a more well structured world than is currently achievable. - ah, now you have dashed my hopeful optimism and made me sad ;-) Seriously - I think that they remain orthogonal during the _selection_ = process. It isn't until we actually _commit_ to a set of codecs/ports = etc that they become intertwined. I guess I'm hoping that we can hide that = from the Javascript coder without limiting the flexibility of the API we present them by delaying the inevitable complexity as long as = possible. Tim From stefan.lk.hakansson@ericsson.com Wed Oct 5 05:48: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 B205321F8D3D for ; Wed, 5 Oct 2011 05:48:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.328 X-Spam-Level: X-Spam-Status: No, score=-6.328 tagged_above=-999 required=5 tests=[AWL=-0.029, 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 s3KV3LAjlrdG for ; Wed, 5 Oct 2011 05:48: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 E170C21F8C36 for ; Wed, 5 Oct 2011 05:48:35 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-10-4e8c52dfa1ef Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 7B.68.20773.FD25C8E4; Wed, 5 Oct 2011 14:51:43 +0200 (CEST) Received: from [150.132.141.51] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.137.0; Wed, 5 Oct 2011 14:51:32 +0200 Message-ID: <4E8C52D3.70007@ericsson.com> Date: Wed, 5 Oct 2011 14:51:31 +0200 From: =?ISO-8859-1?Q?Stefan_H=E5kansson_LK?= User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <91623260-6A12-4737-8BA9-4D6B60FCD389@phonefromhere.com> In-Reply-To: <91623260-6A12-4737-8BA9-4D6B60FCD389@phonefromhere.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [rtcweb] Making progress on the signaling discussion (NB: Action items enclosed!) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 12:48:36 -0000 On 2011-10-05 12:03, Tim Panton wrote: > It seems to me that by calling WebRTC.SDP.answerFor() - getting the > native code > to do the 'compatibility matching' you've lost quite a lot of influence > over the selection process. > Lets say this is a conference app on an android phone - and lets say > that the phone supports > h 261, h263 and h264 but only has hardware accel for h264.... To me it seems that the browser (at least the one integrated by the device manufacturer) has a much greater chance of knowing what codecs are HW accelerated than the application - or do you expect a large database where device, version, OS-version, browser, browser version etc. is stored? My preference would rather be that the app hints (as Tim proposed in ), the browser proposes (by some kind of offer where the codecs are listed in preference order). If the offers are available to the application (for transport to the other end) it can override it there are objections. Stefan From tim@phonefromhere.com Wed Oct 5 06:22: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 71C9521F8A7A for ; Wed, 5 Oct 2011 06:22:21 -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 XICACQV515+O for ; Wed, 5 Oct 2011 06:22: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 EAF3421F8A6C for ; Wed, 5 Oct 2011 06:22:20 -0700 (PDT) Received: from [192.168.0.14] (unknown [93.89.81.113]) by zimbra.westhawk.co.uk (Postfix) with ESMTP id 78B7437A903; Wed, 5 Oct 2011 14:38:11 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Tim Panton In-Reply-To: <4E8C52D3.70007@ericsson.com> Date: Wed, 5 Oct 2011 14:25:17 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9567D766-8633-4446-9F07-318B1F45117D@phonefromhere.com> References: <91623260-6A12-4737-8BA9-4D6B60FCD389@phonefromhere.com> <4E8C52D3.70007@ericsson.com> To: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Making progress on the signaling discussion (NB: Action items enclosed!) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 13:22:21 -0000 On 5 Oct 2011, at 13:51, Stefan H=E5kansson LK wrote: > On 2011-10-05 12:03, Tim Panton wrote: >> It seems to me that by calling WebRTC.SDP.answerFor() - getting the >> native code >> to do the 'compatibility matching' you've lost quite a lot of = influence >> over the selection process. >> Lets say this is a conference app on an android phone - and lets say >> that the phone supports >> h 261, h263 and h264 but only has hardware accel for h264.... >=20 > To me it seems that the browser (at least the one integrated by the = device manufacturer) has a much greater chance of knowing what codecs = are HW accelerated than the application - or do you expect a large = database where device, version, OS-version, browser, browser version = etc. is stored? I'd expect the app to be able to query the browser - possibly a 'cpu = cost' field returned in the list of supported codecs ... >=20 > My preference would rather be that the app hints (as Tim proposed in = ), = the browser proposes (by some kind of offer where the codecs are listed = in preference order). If the offers are available to the application = (for transport to the other end) it can override it there are = objections. Which to my mind is putting the cart before the horse. The app (as the = representative of the user) should take the lead here, not be reduced to vetoing offers from the all-knowing browser. I know it is largely a = philosophical difference, but I think we risk being stuck in a mindset = derived from a world where the core had no access to the user and there was only a = single application, so the switch had to do the best it could without = any other input. Tim.=20 From stefan.lk.hakansson@ericsson.com Wed Oct 5 06:32: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 A880121F8C93 for ; Wed, 5 Oct 2011 06:32:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.327 X-Spam-Level: X-Spam-Status: No, score=-6.327 tagged_above=-999 required=5 tests=[AWL=-0.028, 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 uxtFmARzipbY for ; Wed, 5 Oct 2011 06:32: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 EBA0C21F8C85 for ; Wed, 5 Oct 2011 06:32:41 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-1a-4e8c5d359d65 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id F9.C6.20773.53D5C8E4; Wed, 5 Oct 2011 15:35:49 +0200 (CEST) Received: from [150.132.141.51] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.137.0; Wed, 5 Oct 2011 15:35:12 +0200 Message-ID: <4E8C5D0F.2030401@ericsson.com> Date: Wed, 5 Oct 2011 15:35:11 +0200 From: =?ISO-8859-1?Q?Stefan_H=E5kansson_LK?= User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Tim Panton References: <91623260-6A12-4737-8BA9-4D6B60FCD389@phonefromhere.com> <4E8C52D3.70007@ericsson.com> <9567D766-8633-4446-9F07-318B1F45117D@phonefromhere.com> In-Reply-To: <9567D766-8633-4446-9F07-318B1F45117D@phonefromhere.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Making progress on the signaling discussion (NB: Action items enclosed!) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 13:32:42 -0000 On 2011-10-05 15:25, Tim Panton wrote: > Which to my mind is putting the cart before the horse. The app (as the representative of the user)... I guess I see the User Agent representing the user, and the app representing the service provider...philosophical discussion :) From jonathan@vidyo.com Wed Oct 5 07:25: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 BF39721F8E04 for ; Wed, 5 Oct 2011 07:25:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.462 X-Spam-Level: X-Spam-Status: No, score=-2.462 tagged_above=-999 required=5 tests=[AWL=0.137, 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 61dUW8+RHuLW for ; Wed, 5 Oct 2011 07:25:18 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id 4720921F8DFE for ; Wed, 5 Oct 2011 07:25:18 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id ECF138BF1B9; Wed, 5 Oct 2011 10:28:25 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB015.mail.lan (unknown [10.110.2.1]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mxout.myoutlookonline.com (Postfix) with ESMTPS id 577BC8BF069; Wed, 5 Oct 2011 10:28:24 -0400 (EDT) Received: from BE235.mail.lan ([10.110.32.235]) by HUB015.mail.lan ([10.110.17.15]) with mapi; Wed, 5 Oct 2011 10:27:51 -0400 From: Jonathan Lennox To: Bernard Aboba , Matthew Kaufman Date: Wed, 5 Oct 2011 10:28:03 -0400 Thread-Topic: [rtcweb] Summary of ICE discussion Thread-Index: AcyDaBf7WyJ6QPMyRCqvtx9Eu6jUUAAAWXOQ Message-ID: References: <4E8B192E.80809@ericsson.com> <37C37EE6-3D48-4C77-A025-3207F040572B@cisco.com> <4E8BC56E.40306@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Summary of ICE discussion X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 14:25:18 -0000 Bernard Aboba wrote: > On Oct 4, 2011, at 7:49 PM, "Matthew Kaufman" = wrote: > > I think what he's concerned about is that a device might consent (using= ICE) to receive audio and unexpectedly receive multiplexed video on the sa= me RTP port. > > > > Not sure this really matters, as there's not much difference between lo= w-frame-rate low-res video and 16-bit linear stereo PCM at 48 kHz (which mi= ght indeed be an audio codec you can choose). > > Right, that's the attack I had in mind, but with high bandwidth video. This sounds to me like the congestion control mechanism needs to be part of= the browser-enforced security properties, and transported in a secure mann= er that an attacker can't spoof (which probably means over DTLS-SRT(C)P). Once congestion control has indicated that a receiver has consented to a ce= rtain bitrate, how an application choses to fill it isn't so important as a= security property. Sending a consenting peer (e.g.) 48 kHz L16 audio inst= ead of low-res video (or vice versa) would be kind of pointless, but not re= ally a DoS attack if the peer has already agreed to receive that much bandw= idth. --=20 Jonathan Lennox jonathan@vidyo.com From pravindran@sonusnet.com Wed Oct 5 07: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 3D9AD21F8AF7 for ; Wed, 5 Oct 2011 07:34:47 -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 YWlV01orb0sC for ; Wed, 5 Oct 2011 07: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 27F9C21F8CA9 for ; Wed, 5 Oct 2011 07:34:46 -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 p95EcKH6014721; Wed, 5 Oct 2011 10:38:20 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail07.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 5 Oct 2011 10:37:42 -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: Wed, 5 Oct 2011 20:07:39 +0530 Message-ID: <2E239D6FCD033C4BAF15F386A979BF510F14C0@sonusinmail02.sonusnet.com> In-Reply-To: <4E8C12FD.5010007@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] Summary of ICE discussion Thread-Index: AcyDN3onXBChTObjQmqkKm4vgz75PQAMS3Bg References: <4E8B192E.80809@ericsson.com> <2E239D6FCD033C4BAF15F386A979BF510F142C@sonusinmail02.sonusnet.com> <4E8C12FD.5010007@ericsson.com> From: "Ravindran Parthasarathi" To: "Magnus Westerlund" X-OriginalArrivalTime: 05 Oct 2011 14:37:42.0979 (UTC) FILETIME=[57366130:01CC836C] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Summary of ICE discussion X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 14:34:47 -0000 Hi Magnus, Thanks for the clarification about the issue in webserver based trust = model. I agree for ICE as there is no other known solution for user = consent in the proposed trust model. Still, data transmission consent is = an open item. Thanks Partha >-----Original Message----- >From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] >Sent: Wednesday, October 05, 2011 1:49 PM >To: Ravindran Parthasarathi >Cc: rtcweb@ietf.org >Subject: Re: [rtcweb] Summary of ICE discussion > >On 2011-10-05 08:07, Ravindran Parthasarathi wrote: >> In case user consent is the reason for ICE, ICE may not be right >> choice because of the multiplexing RTP in RTCWeb and user may be >> consent for audio and not for video which is not possible to indicate >> through ICE. It is possible to achieve by having different streams >> for each media but I strongly believe that it is not interesting >> topic for RTCWeb. > >No, it is not user consent, it is data transmission consent that is the >issue here. > >> >> I think that trust model with browser---RTCWeb server---browser for >> the user consent with individual media stream works because browser >> user trust RTCWeb server. I could think of offer/answer as user >> consent with media stream mechanism because offer or answer indicates >> media port is allocated in browser and listening for media from >> remote party, the consent reaches remote browser through RTCWeb >> server. The advantage in the model is that RTCWeb server shall have >> the policy to control media. Please let me know your comments on >> this. > > >My interpretation is that several has disagreed with you on this model. >I personally also disagree with this. There is a big difference between >allowing a webservice access to my media devices, i.e. microphone and >video as will expect it to perform a communication service where I at >least see parts of that communication happening. However, the user has >no way of verifying that of the media streams being setup by the web >service that it in fact not in addition uses the users resources for a >DoS attack. It is the destination of the media stream that needs to >consent to the media delivery, not the siganlling node for it. Thus a >path based media verification that ensures that information from the >signalling and the media path agrees provides a reasonable but not >perfect security against attacks. This is still vulnerable to attackers >that have the capability of both running the web service and intercept >and inject packets in the network on path between the web client and = the >target of the attack. > >> >> The other reason like NAT & FW is not mandatory for intranet RTCWeb >> applications. I have mentioned as part of >> http://www.ietf.org/mail-archive/web/rtcweb/current/msg01619.html > >My interpretation of your statement was that it was disputed and that >the disputing statement was not faulty. > >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 cb.list6@gmail.com Wed Oct 5 08:23: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 57FB421F8D86 for ; Wed, 5 Oct 2011 08:23:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.465 X-Spam-Level: X-Spam-Status: No, score=-3.465 tagged_above=-999 required=5 tests=[AWL=0.133, 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 9VAjX0NK6pnb for ; Wed, 5 Oct 2011 08:23:11 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2EB8F21F8D7F for ; Wed, 5 Oct 2011 08:23:11 -0700 (PDT) Received: by qadb12 with SMTP id b12so1683967qad.31 for ; Wed, 05 Oct 2011 08:26:19 -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=8O+g50a5v9U3G9bsO5LI4qsaeggQT+oLd6cl//TP8Qw=; b=lQzt5/GRkAOpWuVG1TSbxHelIGHa/CjmMT2Rs2lJaE8LclcQdQLy6bLw2esdWBky1o IAwYTDF0spbskEJWnADdMakGCcKavzdBrD33J6UcgQGMGWfNvYNwk0L8arRaM4hAQDRL LIE35GX4rMzyfz/J+Vu21MlOjZRE06f5Ttob0= MIME-Version: 1.0 Received: by 10.68.7.166 with SMTP id k6mr16091574pba.128.1317828378907; Wed, 05 Oct 2011 08:26:18 -0700 (PDT) Received: by 10.142.195.15 with HTTP; Wed, 5 Oct 2011 08:26:12 -0700 (PDT) Received: by 10.142.195.15 with HTTP; Wed, 5 Oct 2011 08:26:12 -0700 (PDT) In-Reply-To: <4E8BE49B.6050202@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> <2E239D6FCD033C4BAF15F386A979BF510F137B@sonusinmail02.sonusnet.com> <226C9800-9791-465A-B519-40935E2D135F@phonefromhere.com> <4E8B1B86.2080805@jesup.org> <4E8BD7B8.3080408@jesup.org> <4E8BDD6D.5030706@skype.net> <4E8BE49B.6050202@jesup.org> Date: Wed, 5 Oct 2011 08:26:12 -0700 Message-ID: From: Cameron Byrne To: Randell Jesup Content-Type: multipart/alternative; boundary=bcaec5215c816655bb04ae8ed46c 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: Wed, 05 Oct 2011 15:23:12 -0000 --bcaec5215c816655bb04ae8ed46c Content-Type: text/plain; charset=ISO-8859-1 On Oct 4, 2011 10:05 PM, "Randell Jesup" wrote: > > On 10/5/2011 12:30 AM, Matthew Kaufman wrote: >> >> On 10/4/2011 9:06 PM, Randell Jesup wrote: >>> >>> I think there will be a lot of small-to-medium users adding chat, >>> building games, etc, who care little or not at all about the PSTN. >>> Those are the ones who I worry about; they wouldn't realize there are >>> issues with glare (totally ignoring PSTN) or that forking can be >>> complex. They want a simple, one-stop-shopping solution for adding >>> voice/video/data to their sites and games, etc. >> >> >> Ok, so they don't know there's issues with glare or that forking is >> hard. Does that mean that we solve forking in the browser? > > >>> Does this mean we *have* to bake in some sort of signalling? No, it >>> doesn't. It is an _argument_ for providing some type of signalling as >>> a baseline default; or if not, then for starting a project to provide >>> that. >>> >>> Note that I said "baseline". I did *not* say "can handle all the >>> intricacies of the PSTN well". >> >> >> So does "baseline" include handling the fact that "forking is hard", or >> does baseline not address forking either? > > > If you want me to answer that question: yes, I'd include support for some sort of resolution of forking. Enough to avoid getting into trouble, only. > > >>> It could be something far simpler than >>> SIP or XMPP, etc, or it could be a very dumbed-down version of one. >>> These small users (as noted) need something to provide the basics, and >>> to handle certain complexities that simply arise from normal usage >>> patterns and features (like forking). Being able to access the PSTN at >>> all using this would be a plus - but it would not be critical in my mind. >> >> >> This still doesn't mean that the browser needs to become a SIP phone, >> any more than it needed a map rendering engine for Google Maps to exist >> or an IMAP client for Gmail to exist. > > > I am in *no way* saying it needs to be a SIP phone. I'm saying "provide a simple-to-use basic signalling method which it totally optional to use, and which handles the basics needed of almost any signalling method (forking, glare, etc)". Nothing about phones, nothing about PSTN. > > We also don't ship browsers that consist of a canvas element and a JS interpreter, though you *could* build all websites that way (more or less), and some do (GMail and the like aren't far from it). But most site authors are glad they don't have to start with a bucket of rocks to build a castle *as their only option*. > I agree with Randal here. Let's make simple things simple, which does not preclude making advanced and novel things possible. Cb > >>> And, as I mentioned, it could be external JS - but then it has be more >>> solid to start with. For these simple uses - say chat with other users >>> on someones special-interest website, 2 and multiplayer gaming, etc - >>> we should try to pull together the minimum things any app/service >>> developer would need to be prepared for. I think any service that >>> allows someone to log in from multiple devices has to handle forking >>> in some manner. Glare is always possible. What else? I'd like to see >>> simple conferencing. Perhaps the minimum is simple enough that it >>> makes more sense to develop a new, very simple signalling JS module, >>> and use it in examples. This would limit the downside from not updating. >> >> >> Or create a good *platform* for building RTC apps and let the developers >> build things you've never imagined. I think that's a far better outcome >> than building a SIP phone into the browser and then discovering that >> most people don't want to just make phone calls. > > > Again: I'm not suggesting "build in a SIP phone", and how does my proposal in any way tie the hands of someone who wants to build it themselves? > > >>> The advantage of basing it on something known is that the basics of >>> all these protocols are well-understood. >>> >>> I'll paraphrase Harald (and many others in other contexts): make >>> simple things simple, make complex things possible. >> >> >> The latter is far more important than the former. If making simple >> things simple makes complex things significantly harder or impossible, >> you're not building a platform for innovation. > > > Ok, but in this case I don't want to complicate the later - so you're addressing a point I'm not making. Please consider re-reading my posting with that in mind. > > > -- > Randell Jesup > randell-ietf@jesup.org > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --bcaec5215c816655bb04ae8ed46c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Oct 4, 2011 10:05 PM, "Randell Jesup" <randell-ietf@jesup.org> wrote:
>
> On 10/5/2011 12:30 AM, Matthew Kaufman wrote:
>>
>> On 10/4/2011 9:06 PM, Randell Jesup wrote:
>>>
>>> I think there will be a lot of small-to-medium users adding ch= at,
>>> building games, etc, who care little or not at all about the P= STN.
>>> Those are the ones who I worry about; they wouldn't realiz= e there are
>>> issues with glare (totally ignoring PSTN) or that forking can = be
>>> complex. They want a simple, one-stop-shopping solution for ad= ding
>>> voice/video/data to their sites and games, etc.
>>
>>
>> Ok, so they don't know there's issues with glare or that f= orking is
>> hard. Does that mean that we solve forking in the browser?
>
>
>>> Does this mean we *have* to bake in some sort of signalling? N= o, it
>>> doesn't. It is an _argument_ for providing some type of si= gnalling as
>>> a baseline default; or if not, then for starting a project to = provide
>>> that.
>>>
>>> Note that I said "baseline". I did *not* say "c= an handle all the
>>> intricacies of the PSTN well".
>>
>>
>> So does "baseline" include handling the fact that "= forking is hard", or
>> does baseline not address forking either?
>
>
> If you want me to answer that question: yes, I'd include support f= or some sort of resolution of forking. =A0Enough to avoid getting into trou= ble, only.
>
>
>>> It could be something far simpler than
>>> SIP or XMPP, etc, or it could be a very dumbed-down version of= one.
>>> These small users (as noted) need something to provide the bas= ics, and
>>> to handle certain complexities that simply arise from normal u= sage
>>> patterns and features (like forking). Being able to access the= PSTN at
>>> all using this would be a plus - but it would not be critical = in my mind.
>>
>>
>> This still doesn't mean that the browser needs to become a SIP= phone,
>> any more than it needed a map rendering engine for Google Maps to = exist
>> or an IMAP client for Gmail to exist.
>
>
> I am in *no way* saying it needs to be a SIP phone. =A0I'm saying = "provide a simple-to-use basic signalling method which it totally opti= onal to use, and which handles the basics needed of almost any signalling m= ethod (forking, glare, etc)". =A0Nothing about phones, nothing about P= STN.
>
> We also don't ship browsers that consist of a canvas element and a= JS interpreter, though you *could* build all websites that way (more or le= ss), and some do (GMail and the like aren't far from it). =A0But most s= ite authors are glad they don't have to start with a bucket of rocks to= build a castle *as their only option*.
>

I agree with Randal here. Let's make simple things simple, which doe= s not preclude making advanced and novel things possible.

Cb
>
>>> And, as I mentioned, it could be external JS - but then it has= be more
>>> solid to start with. For these simple uses - say chat with oth= er users
>>> on someones special-interest website, 2 and multiplayer gaming= , etc -
>>> we should try to pull together the minimum things any app/serv= ice
>>> developer would need to be prepared for. I think any service t= hat
>>> allows someone to log in from multiple devices has to handle f= orking
>>> in some manner. Glare is always possible. What else? I'd l= ike to see
>>> simple conferencing. Perhaps the minimum is simple enough that= it
>>> makes more sense to develop a new, very simple signalling JS m= odule,
>>> and use it in examples. This would limit the downside from not= updating.
>>
>>
>> Or create a good *platform* for building RTC apps and let the deve= lopers
>> build things you've never imagined. I think that's a far b= etter outcome
>> than building a SIP phone into the browser and then discovering th= at
>> most people don't want to just make phone calls.
>
>
> Again: I'm not suggesting "build in a SIP phone", and ho= w does my proposal in any way tie the hands of someone who wants to build i= t themselves?
>
>
>>> The advantage of basing it on something known is that the basi= cs of
>>> all these protocols are well-understood.
>>>
>>> I'll paraphrase Harald (and many others in other contexts)= : make
>>> simple things simple, make complex things possible.
>>
>>
>> The latter is far more important than the former. If making simple=
>> things simple makes complex things significantly harder or impossi= ble,
>> you're not building a platform for innovation.
>
>
> Ok, but in this case I don't want to complicate the later - so you= 're addressing a point I'm not making. =A0Please consider re-readin= g my posting with that in mind.
>
>
> --
> Randell Jesup
> randell-ietf@jesup.org >
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.i= etf.org/mailman/listinfo/rtcweb

--bcaec5215c816655bb04ae8ed46c-- From bernard_aboba@hotmail.com Wed Oct 5 08:32: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 3618221F8C73 for ; Wed, 5 Oct 2011 08:32:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.212 X-Spam-Level: X-Spam-Status: No, score=-102.212 tagged_above=-999 required=5 tests=[AWL=0.386, 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 qLkhPlNecFNJ for ; Wed, 5 Oct 2011 08:32:27 -0700 (PDT) Received: from blu0-omc3-s29.blu0.hotmail.com (blu0-omc3-s29.blu0.hotmail.com [65.55.116.104]) by ietfa.amsl.com (Postfix) with ESMTP id 4801A21F8C6C for ; Wed, 5 Oct 2011 08:32:27 -0700 (PDT) Received: from BLU152-W46 ([65.55.116.72]) by blu0-omc3-s29.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 5 Oct 2011 08:35:35 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_1e1433ff-eea4-48c0-945f-db2285b8be1d_" X-Originating-IP: [98.237.179.165] From: Bernard Aboba To: Magnus Westerlund Date: Wed, 5 Oct 2011 08:35:34 -0700 Importance: Normal In-Reply-To: <4E8C10BC.8090104@ericsson.com> References: <4E8B192E.80809@ericsson.com> <37C37EE6-3D48-4C77-A025-3207F040572B@cisco.com> <4E8BC56E.40306@skype.net> , <4E8C10BC.8090104@ericsson.com> MIME-Version: 1.0 X-OriginalArrivalTime: 05 Oct 2011 15:35:35.0706 (UTC) FILETIME=[6D1E77A0:01CC8374] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Summary of ICE discussion X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 15:32:28 -0000 --_1e1433ff-eea4-48c0-945f-db2285b8be1d_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable What I was trying to point out was that there are very specific conditions under which the browser will consider the STUN exchange to be "successful" = that will not be met by a public STUN server=2C which typically will not support= ICE extensions. If we articulate this=2C it would not be possible to DoS a pu= blic STUN server with *media*=2C which has been the bar we've been applying so far.=20 It should be understood that when the "answer" is not directly available to= the=20 offering browser=2C the STUN exchange is only able to verify the willingne= ss to receive on a particular IP address/port combination. Without multi-plex= ing=2C this should ensure that the receiver has consented to each media type. Assuming that we can satisfactorily handle "continuing consent" determinati= on=2C I'm not sure that we would need ICE extensions to address the issue. This seems like a slippery slope that could result in a continuing stream o= f ICE extensions. =20 IMHO=2C the "congestion control" problem is separable. Since it seems inevitable that RTCWeb implementations will support non-adaptive codecs=2C I don't believe we can rely on "congestion control" for DoS avoidance.=20 > Date: Wed=2C 5 Oct 2011 10:09:32 +0200 > From: magnus.westerlund@ericsson.com > To: bernard_aboba@hotmail.com > CC: matthew.kaufman@skype.net=3B rtcweb@ietf.org > Subject: Re: [rtcweb] Summary of ICE discussion >=20 > Hi=2C >=20 > good that my summary lets us move forward. >=20 > A question on this attack. How common is it that these STUN servers use > other ports than 3478? Would a rule about that port mitigate the issue=2C > even if it could result in connectivity failures in cases where the NAT > external port is 3478 by chance? >=20 > In addition does these public servers use the username and password > convention from ICE? Isn't that what prevents STUN server deployed for > just determining your server reflexive candidate from actually respond > correctly to a connectivity check? As ICE do concatenate one part > generated by one peer with a part generated by the other peer I don't > see this as an issue as long as the random username fragment is > generated by the browser not the JS. >=20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies=2C Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm=2C Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 = --_1e1433ff-eea4-48c0-945f-db2285b8be1d_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
What I was trying to point out was that there are very specific conditions<= br>under which the browser will consider the STUN exchange to be "successfu= l" that
will not be met by a public STUN server=2C which typically will = not support ICE
extensions. =3B =3B If we articulate this=2C it = would not be possible to DoS a public STUN
server with *media*=2C which = has been the bar we've been applying so far.

It should be understoo= d that when the "answer" is not directly available to the
offering brow= ser=2C =3B the STUN exchange is only able to verify the willingness
= to receive on a particular IP address/port combination. =3B Without mul= ti-plexing=2C
this should ensure that the receiver has consented to each= media type.
Assuming that we can satisfactorily handle "continuing cons= ent" determination=2C
I'm not sure that we would need ICE extensions to = address the issue.
This seems like a slippery slope that could result in= a continuing stream of
ICE extensions.  =3B

IMHO=2C the "co= ngestion control" problem is separable. =3B Since
it seems inevitabl= e that RTCWeb implementations will support
non-adaptive codecs=2C I don'= t believe we can rely on "congestion
control" for DoS avoidance.

>=3B Date: Wed=2C 5 Oct 2011 10:09:32 +0200
>=3B From: mag= nus.westerlund@ericsson.com
>=3B To: bernard_aboba@hotmail.com
>= =3B CC: matthew.kaufman@skype.net=3B rtcweb@ietf.org
>=3B Subject: Re:= [rtcweb] Summary of ICE discussion
>=3B
>=3B Hi=2C
>=3B >=3B good that my summary lets us move forward.
>=3B
>=3B A = question on this attack. How common is it that these STUN servers use
&g= t=3B other ports than 3478? Would a rule about that port mitigate the issue= =2C
>=3B even if it could result in connectivity failures in cases whe= re the NAT
>=3B external port is 3478 by chance?
>=3B
>=3B = In addition does these public servers use the username and password
>= =3B convention from ICE? Isn't that what prevents STUN server deployed for<= br>>=3B just determining your server reflexive candidate from actually re= spond
>=3B correctly to a connectivity check? As ICE do concatenate on= e part
>=3B generated by one peer with a part generated by the other p= eer I don't
>=3B see this as an issue as long as the random username f= ragment is
>=3B generated by the browser not the JS.
>=3B
>= =3B Cheers
>=3B
>=3B Magnus Westerlund
>=3B
>=3B ----= ------------------------------------------------------------------
>= =3B Multimedia Technologies=2C Ericsson Research EAB/TVM
>=3B --------= --------------------------------------------------------------
>=3B Er= icsson AB | Phone +46 10 7148287
>=3B F=E4r=F6gatan 6 = | Mobile +46 73 0949079
>=3B SE-164 80 Stockholm=2C Swe= den| mailto: magnus.westerlund@ericsson.com
>=3B ---------------------= -------------------------------------------------
>=3B
=
= --_1e1433ff-eea4-48c0-945f-db2285b8be1d_-- From harald@alvestrand.no Wed Oct 5 08:48: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 290FE21F8CEA for ; Wed, 5 Oct 2011 08:48:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.735 X-Spam-Level: X-Spam-Status: No, score=-108.735 tagged_above=-999 required=5 tests=[AWL=1.863, 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 NhZAzRE3gzq6 for ; Wed, 5 Oct 2011 08:48:18 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 0A3E421F8CF2 for ; Wed, 5 Oct 2011 08:48:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id DBE3A39E0A7 for ; Wed, 5 Oct 2011 17: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 RaDx3hmXxI4S for ; Wed, 5 Oct 2011 17:51:24 +0200 (CEST) Received: from [172.16.41.139] (unknown [74.125.121.33]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 7C25739E048 for ; Wed, 5 Oct 2011 17:51:24 +0200 (CEST) Message-ID: <4E8C7CFB.2060904@alvestrand.no> Date: Wed, 05 Oct 2011 17:51:23 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4E8B192E.80809@ericsson.com> <37C37EE6-3D48-4C77-A025-3207F040572B@cisco.com> <4E8BC56E.40306@skype.net> , <4E8C10BC.8090104@ericsson.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050601060406040002020309" Subject: Re: [rtcweb] Summary of ICE discussion X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 15:48:19 -0000 This is a multi-part message in MIME format. --------------050601060406040002020309 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit On 10/05/2011 05:35 PM, Bernard Aboba wrote: > What I was trying to point out was that there are very specific conditions > under which the browser will consider the STUN exchange to be > "successful" that > will not be met by a public STUN server, which typically will not > support ICE > extensions. If we articulate this, it would not be possible to DoS a > public STUN > server with *media*, which has been the bar we've been applying so far. Indeed, a public STUN server will not be configured with an username / password (RFC 5245 section 7.1.2.3), and thus its answers will not pass the ICE check for a correct MIC. > > It should be understood that when the "answer" is not directly > available to the > offering browser, the STUN exchange is only able to verify the > willingness > to receive on a particular IP address/port combination. Without > multi-plexing, > this should ensure that the receiver has consented to each media type. > Assuming that we can satisfactorily handle "continuing consent" > determination, > I'm not sure that we would need ICE extensions to address the issue. > This seems like a slippery slope that could result in a continuing > stream of > ICE extensions. > > IMHO, the "congestion control" problem is separable. Since > it seems inevitable that RTCWeb implementations will support > non-adaptive codecs, I don't believe we can rely on "congestion > control" for DoS avoidance. The control I was thinking of is that when a Javascript DoS attacker attempts to send media to a DoS victim at some significant traffic volume, the DoS victim can send back a TMMBR saying "I only want this much data" (where "this much" is a reasonable amount for the media types it's been expecting). That won't solve large scale DDoS attacks, of course, but at least it is pushback against the "I said yes to 32 Kbits and you hit me with 2 Mbits" attacks. > > > > Date: Wed, 5 Oct 2011 10:09:32 +0200 > > From: magnus.westerlund@ericsson.com > > To: bernard_aboba@hotmail.com > > CC: matthew.kaufman@skype.net; rtcweb@ietf.org > > Subject: Re: [rtcweb] Summary of ICE discussion > > > > Hi, > > > > good that my summary lets us move forward. > > > > A question on this attack. How common is it that these STUN servers use > > other ports than 3478? Would a rule about that port mitigate the issue, > > even if it could result in connectivity failures in cases where the NAT > > external port is 3478 by chance? > > > > In addition does these public servers use the username and password > > convention from ICE? Isn't that what prevents STUN server deployed for > > just determining your server reflexive candidate from actually respond > > correctly to a connectivity check? As ICE do concatenate one part > > generated by one peer with a part generated by the other peer I don't > > see this as an issue as long as the random username fragment is > > generated by the browser not the JS. > > > > 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 --------------050601060406040002020309 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 10/05/2011 05:35 PM, Bernard Aboba wrote:
What I was trying to point out was that there are very specific conditions
under which the browser will consider the STUN exchange to be "successful" that
will not be met by a public STUN server, which typically will not support ICE
extensions.   If we articulate this, it would not be possible to DoS a public STUN
server with *media*, which has been the bar we've been applying so far.
Indeed, a public STUN server will not be configured with an username / password (RFC 5245 section 7.1.2.3), and thus its answers will not pass the ICE check for a correct MIC.

It should be understood that when the "answer" is not directly available to the
offering browser,  the STUN exchange is only able to verify the willingness
to receive on a particular IP address/port combination.  Without multi-plexing,
this should ensure that the receiver has consented to each media type.
Assuming that we can satisfactorily handle "continuing consent" determination,
I'm not sure that we would need ICE extensions to address the issue.
This seems like a slippery slope that could result in a continuing stream of
ICE extensions.  

IMHO, the "congestion control" problem is separable.  Since
it seems inevitable that RTCWeb implementations will support
non-adaptive codecs, I don't believe we can rely on "congestion
control" for DoS avoidance.

The control I was thinking of is that when a Javascript DoS attacker attempts to send media to a DoS victim at some significant traffic volume, the DoS victim can send back a TMMBR saying "I only want this much data" (where "this much" is a reasonable amount for the media types it's been expecting). That won't solve large scale DDoS attacks, of course, but at least it is pushback against the "I said yes to 32 Kbits and you hit me with 2 Mbits" attacks.



> Date: Wed, 5 Oct 2011 10:09:32 +0200
> From: magnus.westerlund@ericsson.com
> To: bernard_aboba@hotmail.com
> CC: matthew.kaufman@skype.net; rtcweb@ietf.org
> Subject: Re: [rtcweb] Summary of ICE discussion
>
> Hi,
>
> good that my summary lets us move forward.
>
> A question on this attack. How common is it that these STUN servers use
> other ports than 3478? Would a rule about that port mitigate the issue,
> even if it could result in connectivity failures in cases where the NAT
> external port is 3478 by chance?
>
> In addition does these public servers use the username and password
> convention from ICE? Isn't that what prevents STUN server deployed for
> just determining your server reflexive candidate from actually respond
> correctly to a connectivity check? As ICE do concatenate one part
> generated by one peer with a part generated by the other peer I don't
> see this as an issue as long as the random username fragment is
> generated by the browser not the JS.
>
> Cheers
>
> Magnus Westerlund
>
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------
> Ericsson AB | Phone +46 10 7148287
> Färögatan 6 | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------
> 

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

--------------050601060406040002020309-- From ted.ietf@gmail.com Wed Oct 5 09: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 611B01F0C53 for ; Wed, 5 Oct 2011 09:39:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.508 X-Spam-Level: X-Spam-Status: No, score=-3.508 tagged_above=-999 required=5 tests=[AWL=0.090, 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 6L+kuj3zeHPM for ; Wed, 5 Oct 2011 09:39: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 57D181F0C48 for ; Wed, 5 Oct 2011 09:39:25 -0700 (PDT) Received: by gyd12 with SMTP id 12so2128337gyd.31 for ; Wed, 05 Oct 2011 09:42:33 -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=SWOBhNrP6XZOses6wFQwBRpQ0p7/JULLvdFLDVc5d1s=; b=xpNo8dcjkYHMgL/0yCsSYtTVGlgrR3uxrkTHOgyUW6FPtBZTZ9jztlUqjIM1z3OUT5 /csye4eQpox8ndlOY82b9ytmsIT4ytTsuDBkNv2eanKzxzVWDDEllNcmWvYTS1TaFLdD qLOXjkdFE2f6at+yb0kBwUHS/hIHEBvuxmmCI= MIME-Version: 1.0 Received: by 10.236.187.36 with SMTP id x24mr14674293yhm.74.1317832953543; Wed, 05 Oct 2011 09:42:33 -0700 (PDT) Received: by 10.236.105.169 with HTTP; Wed, 5 Oct 2011 09:42:33 -0700 (PDT) In-Reply-To: <4E8C0E50.7050309@ericsson.com> References: <4E8BBDDF.3010100@skype.net> <4E8C0E50.7050309@ericsson.com> Date: Wed, 5 Oct 2011 09:42:33 -0700 Message-ID: From: Ted Hardie To: Magnus Westerlund Content-Type: multipart/alternative; boundary=20cf303dd9d011bc9704ae8fe5cf Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Making progress on the signaling discussion (NB: Action items enclosed!) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 16:39:26 -0000 --20cf303dd9d011bc9704ae8fe5cf Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Oct 5, 2011 at 12:59 AM, Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > > > On 2011-10-05 04:15, Matthew Kaufman wrote: > > On 10/4/2011 9:01 AM, Ted Hardie wrote: > >> At today's Chairs call, Cullen, Magnus and I had a discussion of how > >> to make progress on the signaling discussion. We feel the mailing > >> list discussion needs to have more concrete proposals in order to make > >> progress, and so we're putting forward the following: > >> > >> 1) If you plan to put forward a draft proposing a concrete solution in > >> this space, please send your name to the mailing list with that intent > >> by October 7th *THIS FRIDAY*. > > > > I'm going to nominate myself here. > > > >> > >> 2) Please have a -00 draft out for discussion by October 14th (the > >> following Friday). This is to allow for a discussion and update prior > >> to the -01 deadlines. > >> > > > > I believe that defining a signaling protocol between web browsers and > > web servers for RTCWEB is out of scope, so I believe there is no draft > > required... unless you really want a -00 draft that says "do nothing". > > > > I believe that defining a signaling protocol between web servers and > > other web servers for RTCWEB federation is out for scope for "version > > 1", so I believe it is not appropriate to submit a draft at this time..= . > > unless you really want a -00 draft that says "do nothing for now, use > > any of the existing protocols until then." > > > > I think also this proposal do require an Internet draft which discusses > the requirements put on the API. What of the underlying protocols that > are this WG task needs to be exposed in different forms? > > I strongly agree with Magnus here. It's very easy for a statement saying that a standardized signaling protocol is out of scope to create presumptions about where data the proprietary signaling protocols use comes from, what its form is, the level of granularity it has, and how it is packaged. We need concrete proposals in order to evaluate whether the implications of that general statement are acceptable to the working group. regards, Ted > My understanding of your idea is that you have both capabilities and > knobs that can be set. I also believe it requires some state > transitioning events. For example to kick of ICE negotiation between the > peers when the right things has been set. > > Thus, I personally do see a need for draft from you that explains the > details of how things are expected to work. I don't see you needing to > define how the API should really look, but what the requirements on that > API are based on your solutions. But without that your proposal is still > not clear and open for a lot of interpretation. > > 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 > --20cf303dd9d011bc9704ae8fe5cf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Oct 5, 2011 at 12:59 AM, Magnus Westerlund <magnus.westerlund@ericsson.= com> wrote:


On 2011-10-05 04:15, Matthew Kaufman wrote:
> On 10/4/2011 9:01 AM, Ted Hardie wrote:
>> At today's Chairs call, Cullen, Magnus and I had a discussion = of how
>> to make progress on the signaling discussion. =A0We feel the maili= ng
>> list discussion needs to have more concrete proposals in order to = make
>> progress, and so we're putting forward the following:
>>
>> 1) If you plan to put forward a draft proposing a concrete solutio= n in
>> this space, please send your name to the mailing list with that in= tent
>> by October 7th *THIS FRIDAY*.
>
> I'm going to nominate myself here.
>
>>
>> 2) Please have a -00 draft out for discussion by October 14th (the=
>> following Friday). =A0This is to allow for a discussion and update= prior
>> to the -01 deadlines.
>>
>
> I believe that defining a signaling protocol between web browsers and<= br> > web servers for RTCWEB is out of scope, so I believe there is no draft=
> required... unless you really want a -00 draft that says "do noth= ing".
>
> I believe that defining a signaling protocol between web servers and > other web servers for RTCWEB federation is out for scope for "ver= sion
> 1", so I believe it is not appropriate to submit a draft at this = time...
> unless you really want a -00 draft that says "do nothing for now,= use
> any of the existing protocols until then."
>

I think also this proposal do require an Internet draft which discuss= es
the requirements put on the API. What of the underlying protocols that
are this WG task needs to be exposed in different forms?


I strongly agree with Magnus here.=A0 It's ve= ry easy for a statement saying that a standardized signaling protocol is ou= t of scope to create presumptions about where data the proprietary signalin= g protocols use comes from, what its form is, the level of granularity it h= as, and how it is packaged.=A0 We need concrete proposals in order to evalu= ate whether the implications of that general statement are acceptable to th= e working group.

regards,

Ted

=A0
My understanding of your idea is that you have both capabilities and
knobs that can be set. I also believe it requires some state
transitioning events. For example to kick of ICE negotiation between the peers when the right things has been set.

Thus, I personally do see a need for draft from you that explains the
details of how things are expected to work. I don't see you needing to<= br> define how the API should really look, but what the requirements on that API are based on your solutions. But without that your proposal is still not clear and open for a lot of interpretation.

Cheers

Magnus Westerlund

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

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

--20cf303dd9d011bc9704ae8fe5cf-- From ted.ietf@gmail.com Wed Oct 5 09: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 567B721F8C75 for ; Wed, 5 Oct 2011 09:41:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.509 X-Spam-Level: X-Spam-Status: No, score=-3.509 tagged_above=-999 required=5 tests=[AWL=0.089, 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 YO5V3J8azC1N for ; Wed, 5 Oct 2011 09:41:25 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6E28D21F8C72 for ; Wed, 5 Oct 2011 09:41:25 -0700 (PDT) Received: by ywm3 with SMTP id 3so2141386ywm.31 for ; Wed, 05 Oct 2011 09:44:33 -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=onJcYnlZ73P0X2hCTEHLXmHFLFyOdETAMfkqiBiGnas=; b=pZ5di7nBpn6SbhHzIP8M/a+LY9q0EUfAku5dxmKgYLsVFDkpsXGRoUFE4a05u4p9qR sMXWOA1gK+EPvHAQQjWmd6FU1TSqTUQoZ6XvhjfOEQT7z8BHtueC+DHt6HhUfmx5+nTv TYIGOD2Rd4b7+AxGK7tnBCi59ZTXgARYdkFJ0= MIME-Version: 1.0 Received: by 10.236.187.36 with SMTP id x24mr14686488yhm.74.1317833073634; Wed, 05 Oct 2011 09:44:33 -0700 (PDT) Received: by 10.236.105.169 with HTTP; Wed, 5 Oct 2011 09:44:33 -0700 (PDT) In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF510F1450@sonusinmail02.sonusnet.com> References: <2E239D6FCD033C4BAF15F386A979BF510F1450@sonusinmail02.sonusnet.com> Date: Wed, 5 Oct 2011 09:44:33 -0700 Message-ID: From: Ted Hardie To: Ravindran Parthasarathi Content-Type: multipart/alternative; boundary=20cf303dd9d03a2eed04ae8fec5c Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Making progress on the signaling discussion (NB: Actionitems enclosed!) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 16:41:26 -0000 --20cf303dd9d03a2eed04ae8fec5c Content-Type: text/plain; charset=ISO-8859-1 Hi Partha, We'd be happy to consider a signaling protocol proposal from you. Unfortunately, the current iteration of your draft does not contain a concrete proposal so much as a discussion of the advantages of a standardized signaling protocol. To make further progress, the chairs believe we need concrete proposals at this time. Please let us know if you would like to provide an update with a concrete proposal. thanks, Ted On Wed, Oct 5, 2011 at 12:03 AM, Ravindran Parthasarathi < pravindran@sonusnet.com> wrote: > Ted, Magnus, Cullen,**** > > ** ** > > Could you please consider RTCWeb standard signaling protocol (http://tools.ietf.org/id/draft-partha-rtcweb-signaling-00.txt) draft as one of the proposal for this signaling discussion.**** > > ** ** > > Thanks**** > > Partha**** > > ** ** > > *From:* rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] *On > Behalf Of *Ted Hardie > *Sent:* Tuesday, October 04, 2011 9:31 PM > *To:* rtcweb@ietf.org > *Subject:* [rtcweb] Making progress on the signaling discussion (NB: > Actionitems enclosed!)**** > > ** ** > > At today's Chairs call, Cullen, Magnus and I had a discussion of how to > make progress on the signaling discussion. We feel the mailing list > discussion needs to have more concrete proposals in order to make progress, > and so we're putting forward the following: > > 1) If you plan to put forward a draft proposing a concrete solution in this > space, please send your name to the mailing list with that intent by October > 7th *THIS FRIDAY*. > > 2) Please have a -00 draft out for discussion by October 14th (the > following Friday). This is to allow for a discussion and update prior to > the -01 deadlines. > > 3) We will hold a conference call to discuss the drafts on October 21st > (the Friday after that). > > Updates based on that discussion then have until the -01 drafts deadline to > be complete. > > This is aggressive, but we feel we need to have at least -00s for the > different ideas in place in order to make real progress. > > thanks, > > Ted, Magnus, Cullen**** > --20cf303dd9d03a2eed04ae8fec5c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Partha,

We'd be happy to consider a signaling protocol propos= al from you.=A0 Unfortunately, the current iteration of your draft does not= contain a concrete proposal so much as a discussion of the advantages of a= standardized signaling protocol.=A0=A0 To make further progress, the chair= s believe we need concrete proposals at this time.=A0 Please let us know if= you would like to provide an update with a concrete proposal.

thanks,

Ted

On Wed, Oct 5, 201= 1 at 12:03 AM, Ravindran Parthasarathi <pravindran@sonusnet.com> wrote:<= br>

Ted, = Magnus, Cullen,

=A0

Could you please consid=
er RTCWeb standard signaling protocol (http://tools.ietf.o=
rg/id/draft-partha-rtcweb-signaling-00.txt) draft as one of the proposa=
l for this signaling discussion.
=A0
Thanks=

Partha=
=

=A0

From:= rtcweb-bounces@ietf.org [mailto:rtcweb= -bounces@ietf.org] On Behalf Of Ted Hardie
Sent: Tuesday, October 04, 2011 9:31 PM
To: rtcweb@ietf= .org
Subject: [rtcweb] Making progress on the signaling discussion (NB: Actionitems enclosed!)

=A0

At today's Chairs call, Cullen, Magnus and I had= a discussion of how to make progress on the signaling discussion.=A0 We feel the mailing list discussion needs to have more concrete proposals in order = to make progress, and so we're putting forward the following:

1) If you plan to put forward a draft proposing a concrete solution in this space, please send your name to the mailing list with that intent by Octobe= r 7th *THIS FRIDAY*.

2) Please have a -00 draft out for discussion by October 14th (the followin= g Friday).=A0 This is to allow for a discussion and update prior to the -01 deadlines.

3) We will hold a conference call to discuss the drafts on October 21st (th= e Friday after that).

Updates based on that discussion then have until the -01 drafts deadline to= be complete.

This is aggressive, but we feel we need to have at least -00s for the diffe= rent ideas in place in order to make real progress.

thanks,

Ted, Magnus, Cullen


--20cf303dd9d03a2eed04ae8fec5c-- From dzonatas@gmail.com Wed Oct 5 09:41: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 1FF7021F8BAC for ; Wed, 5 Oct 2011 09:41:56 -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 3s8lgvAoFGYZ for ; Wed, 5 Oct 2011 09:41:55 -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 257AD21F8B88 for ; Wed, 5 Oct 2011 09:41:55 -0700 (PDT) Received: by vws5 with SMTP id 5so1880776vws.31 for ; Wed, 05 Oct 2011 09:45: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=DAIciA6LWCQ9U/6fV/mdXpb0aUpBpIZAkgtTnPwdDOY=; b=MA0vNcDLD0afD0Hl5Mu0y34DFUosxYCKoyv/NsbJvlKeP7za/ku96uINPPZBwx6e/8 CiZDBiT0192vZHJXdD3UBAnZmjGHnwQDd4s1jG9HB7PNkomaXLwLarvRRnEL7IImXA9z V45kfvZkPpsgkYFynsBtm2daAo270yCXPJjMs= Received: by 10.68.24.35 with SMTP id r3mr19508307pbf.116.1317833102822; Wed, 05 Oct 2011 09:45:02 -0700 (PDT) Received: from [192.168.0.50] (adsl-71-137-201-98.dsl.scrm01.pacbell.net. [71.137.201.98]) by mx.google.com with ESMTPS id d7sm9161244pbn.8.2011.10.05.09.45.00 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 05 Oct 2011 09:45:01 -0700 (PDT) Message-ID: <4E8C8899.4090104@gmail.com> Date: Wed, 05 Oct 2011 09:40:57 -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: <91623260-6A12-4737-8BA9-4D6B60FCD389@phonefromhere.com> <4E8C52D3.70007@ericsson.com> <9567D766-8633-4446-9F07-318B1F45117D@phonefromhere.com> <4E8C5D0F.2030401@ericsson.com> In-Reply-To: <4E8C5D0F.2030401@ericsson.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [rtcweb] Making progress on the signaling discussion (NB: Action items enclosed!) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 16:41:56 -0000 On 10/05/2011 06:35 AM, � wrote: > On 2011-10-05 15:25, Tim Panton wrote: >> Which to my mind is putting the cart before the horse. The app (as >> the representative of the user)... > I guess I see the User Agent representing the user, and the app > representing the service provider...philosophical discussion :) Yes, I rather consider the "agent" the remote end-point of the user such that presence of "user" and "agent" is not the same. The assumption they are the same is not practical, yet we've worked around it. The "User-Agent:" field is that cart, yet where/when did that ever really explain the horse (be at...)? (...I'm "avoiding" multi-headed discussion here in hopes to find clarity with SDP and spoken-for JS API). -- --- The wheel. From ted.ietf@gmail.com Wed Oct 5 09:43: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 40D3521F8C39 for ; Wed, 5 Oct 2011 09:43:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.361 X-Spam-Level: X-Spam-Status: No, score=-3.361 tagged_above=-999 required=5 tests=[AWL=-0.063, 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 xxYsY1c4f3ng for ; Wed, 5 Oct 2011 09:43:04 -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 9557F21F8C32 for ; Wed, 5 Oct 2011 09:42:57 -0700 (PDT) Received: by ggnk3 with SMTP id k3so1077336ggn.31 for ; Wed, 05 Oct 2011 09:46:04 -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=qZwrzsGLtwxBNgEAQhgNn4ZECeLPdG0HrJq1/MpJgfY=; b=KlyLvt6JULiHD/sKaZ5o7j62R4v0QibyU1OL3AfIM3Xih89IGLoGwOWKM6F68b9Xa2 utBXyd0baZk4M5HoRTrviBgDMGqMh7RD1x0SWKOZ5j2XUjIax/dszZeqRt7bwwME8B2z q0mL/CtuXS+gAhleN3QMT7ARisKS5ePLmgzic= MIME-Version: 1.0 Received: by 10.236.170.197 with SMTP id p45mr14598111yhl.108.1317833164843; Wed, 05 Oct 2011 09:46:04 -0700 (PDT) Received: by 10.236.105.169 with HTTP; Wed, 5 Oct 2011 09:46:04 -0700 (PDT) In-Reply-To: References: Date: Wed, 5 Oct 2011 09:46:04 -0700 Message-ID: From: Ted Hardie To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=20cf305b10e8a9e9b704ae8ff107 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Making progress on the signaling discussion (NB: Action items enclosed!) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 16:43:05 -0000 --20cf305b10e8a9e9b704ae8ff107 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Oct 5, 2011 at 2:19 AM, I=F1aki Baz Castillo wrote: > 2011/10/5 Ted Hardie : > > Hi I=F1aki, > > > > The chairs don't currently detect consensus on how signaling will be > handled > > for RTCWeb sessions. We don't want to circumscribe the solution space, > but > > we do feel that there is a need to have concrete proposals, rather than > > broad statements like, "it shouldn't be in the component X". Concrete > > proposals for how it will be handled are the best way we see to make su= re > > folks are coming to consensus on something they understand, rather than > on > > rhetoric. > > > > If you would like to make a concrete proposal for how that JavaScript > object > > is constructed, what it contains, and how it is shipped around, that > would > > be great. Without a statement of what those details are, however, the > > chairs worry that people will argue (for and against) proposals that ha= ve > > not been made. > > > > We await your electrons with great interest! > > > Hi Ted, I'll very busy next days but next week I'll try to give > something more useful. > > Sorry, but do you intend to provide a draft? It was hard for me to parse whether the statement above is a commitment or a statement that you don't have time. regards, Ted --20cf305b10e8a9e9b704ae8ff107 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Oct 5, 2011 at 2:19 AM, I=F1aki Baz Castillo = <ibc@aliax.net> wrote:
2011/10/5 Ted Hardie <ted.ietf@gma= il.com>:
> Hi I=F1aki,
>
> The chairs don't currently detect consensus on how signaling will = be handled
> for RTCWeb sessions.=A0 We don't want to circumscribe the solution= space, but
> we do feel that there is a need to have concrete proposals, rather tha= n
> broad statements like, "it shouldn't be in the component X&qu= ot;.=A0 Concrete
> proposals for how it will be handled are the best way we see to make s= ure
> folks are coming to consensus on something they understand, rather tha= n on
> rhetoric.
>
> If you would like to make a concrete proposal = for how that JavaScript object
> is constructed, what it contains, and how it is shipped around, that w= ould
> be great.=A0=A0 Without a statement of what those details are, however= , the
> chairs worry that people will argue (for and against) proposals that h= ave
> not been made.
>
> We await your electrons with great interest!


Hi Ted, I'll very busy next days but next week I'll try to gi= ve
something more useful.


Sorry, but do you intend to provide a draft?=A0 I= t was hard for me to parse whether the statement above is a commitment or a= statement that you don't have time.

regards,

Ted
=A0<= br>
--20cf305b10e8a9e9b704ae8ff107-- From ibc@aliax.net Wed Oct 5 10:00:02 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4870521F8C9D for ; Wed, 5 Oct 2011 10:00:02 -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.044, 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 LPMXbUOTpr0C for ; Wed, 5 Oct 2011 10:00:01 -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 8E7CD21F8C9B for ; Wed, 5 Oct 2011 10:00:01 -0700 (PDT) Received: by vws5 with SMTP id 5so1901578vws.31 for ; Wed, 05 Oct 2011 10:03:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.186.134 with SMTP id fk6mr2441469vdc.380.1317834189613; Wed, 05 Oct 2011 10:03:09 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Wed, 5 Oct 2011 10:03:09 -0700 (PDT) In-Reply-To: References: Date: Wed, 5 Oct 2011 19:03:09 +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] Making progress on the signaling discussion (NB: Action items enclosed!) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 17:00:02 -0000 2011/10/5 Ted Hardie : > Sorry, but do you intend to provide a draft?=C2=A0 It was hard for me to = parse > whether the statement above is a commitment or a statement that you don't > have time. Maybe not a draft, but a complete explanation and presentation of what we have working (SIP over WebSocket + JavaScript code implementing a SIP stack + SIP proxy implementing the WebSocket transport). And it just works. The draft is already done: http://tools.ietf.org/html/draft-ibc-rtcweb-sip-websocket-00 In fact it defines a concrete signaling protocol (well, not exactly as it uses pure SIP, but on top of WebSocket). Of course it aim is to be used with rtcweb for media sessions. --=20 I=C3=B1aki Baz Castillo From roman@telurix.com Wed Oct 5 10:17:53 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DC101F0C52 for ; Wed, 5 Oct 2011 10:17:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.647 X-Spam-Level: X-Spam-Status: No, score=-2.647 tagged_above=-999 required=5 tests=[AWL=0.329, 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 9dNE1oMGcfiP for ; Wed, 5 Oct 2011 10:17:52 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5E50321F8CB1 for ; Wed, 5 Oct 2011 10:17:47 -0700 (PDT) Received: by gyd12 with SMTP id 12so2169132gyd.31 for ; Wed, 05 Oct 2011 10:20:55 -0700 (PDT) Received: by 10.236.185.4 with SMTP id t4mr15029489yhm.121.1317835255592; Wed, 05 Oct 2011 10:20:55 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by mx.google.com with ESMTPS id n67sm3274696yhi.9.2011.10.05.10.20.53 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 05 Oct 2011 10:20:54 -0700 (PDT) Received: by qadb12 with SMTP id b12so1822374qad.31 for ; Wed, 05 Oct 2011 10:20:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.11.138 with SMTP id q10mr20081765pbb.37.1317835253291; Wed, 05 Oct 2011 10:20:53 -0700 (PDT) Received: by 10.68.47.40 with HTTP; Wed, 5 Oct 2011 10:20:50 -0700 (PDT) In-Reply-To: References: <545388B3-3189-4291-BD1D-52898B888F3E@phonefromhere.com> <4E8BC0ED.2020001@skype.net> <4E8BDC3B.7000501@skype.net> Date: Wed, 5 Oct 2011 13:20:50 -0400 Message-ID: From: Roman Shpount To: Neil Stratford Content-Type: multipart/alternative; boundary=bcaec5314ad12518de04ae906eee 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, 05 Oct 2011 17:17:53 -0000 --bcaec5314ad12518de04ae906eee Content-Type: text/plain; charset=ISO-8859-1 On Wed, Oct 5, 2011 at 7:00 AM, Neil Stratford wrote: > I'm not sure I understand why this is such a problem. XMPP/Jingle defines > it's own mapping, which is a common VoIP protocol that is widely supported. > I'd much rather that the JS API is as expressive as possible in codec > specific matters - for example even to the point of providing callbacks to > the JS on certain codec level events, such as decoding a DTMF digit. > > What we need is some way to expose all possible codec parameter combinations to JavaScript API. MMUSIC/PAYLOAD specifications for codec typically define CODEC parameters and how they are encoded in SDP/MIME content type, but they fall short of defining a way to list all the capabilities. For instance, there is no way for SILK codec to specify valid bit rates range for a given sampling rate. This means JavaScript would need intimate knowledge of each codec implementation in the browser in order to implement codec negotiation. If a different codec implementation is provided by the browser (for instance SILK codec that supports more restricted bit rates for the same sampling rate), JavaScript will not be able to produce valid negotiation results. As far as I can see, there are two possible solutions: better uniform description of codec capabilities to JavaScript API or delegating at least some portion of codec negotiation to actual codec implementation. Again, if it's required I don't see why we can't support asymmetric codecs > in the low level API. In my view a lot of this codec manipulation is much > better controlled by the JS which has application specific knowledge about > how to adapt to given situations than the browser itself. How would you > signal to the browser to dynamically lower framerate rather than image size, > or colour depth depending on the application use case? Giving the > application direct control over codec parameters seems a better option. > I believe in current API we provide one codec with one set of parameters to the API. We should at least be able to provide two codec groups -- one for transmit/another to receive, with two sets of parameters. Even if we handle all the negotiations in JavaScript, we should be able to provide the result for both directions to the stream (may be with default value for the second codec group to be the same as first since this is a much more common). ______________ Roman Shpount --bcaec5314ad12518de04ae906eee Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Oct 5, 2011 at 7:00 AM, Neil Stratfo= rd <neils@bel= ltower.co.uk> wrote:
I'm not sure I understand why this is such a= problem. XMPP/Jingle defines it's own mapping, which is a common VoIP = protocol that is widely supported. I'd much rather that the JS API is a= s expressive as possible in codec specific matters - for example even to th= e point of providing callbacks to the JS on certain codec level events, suc= h as decoding a DTMF digit.
=A0
What we need is some way to ex= pose all possible codec parameter combinations to JavaScript API. MMUSIC/PA= YLOAD specifications for codec typically define CODEC parameters and how th= ey are encoded in SDP/MIME content type, but they fall short of defining a = way to list all the capabilities. For instance, there is no way for SILK co= dec to specify valid bit rates range for a given sampling rate. This means = JavaScript would need intimate knowledge of each codec implementation in th= e browser in order to implement codec negotiation. If a different codec imp= lementation is provided by the browser (for instance SILK codec that suppor= ts more restricted bit rates for the same sampling rate), JavaScript will n= ot be able to produce valid negotiation results. As far as I can see, there= are two possible solutions: better uniform description of codec capabiliti= es to JavaScript API or delegating at least some portion of codec negotiati= on to actual codec implementation.

Again, if it's required I don't see why we can't support asymmetric c= odecs in=20 the low level API. In my view a lot of this codec manipulation is much=20 better controlled by the JS which has application specific knowledge=20 about how to adapt to given situations than the browser itself. How=20 would you signal to the browser to dynamically lower framerate rather=20 than image size, or colour depth depending on the application use case?=20 Giving the application direct control over codec parameters seems a=20 better option.

I believe in current API we provide one codec with one set of parameters to the API. We should at least be able to provide two codec groups --=20 one for transmit/another to receive, with two sets of parameters. Even=20 if we handle all the negotiations in JavaScript, we should be able to=20 provide the result for both directions to the stream (may be with=20 default value for the second codec group to be the same as first since=20 this is a much more common).
______________
Roman Shpount
--bcaec5314ad12518de04ae906eee-- From pravindran@sonusnet.com Wed Oct 5 10:43: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 659CA11E8081 for ; Wed, 5 Oct 2011 10:43:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.492 X-Spam-Level: X-Spam-Status: No, score=-2.492 tagged_above=-999 required=5 tests=[AWL=0.107, 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 fIlsMgvdaMjh for ; Wed, 5 Oct 2011 10:43:37 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 7B36911E8083 for ; Wed, 5 Oct 2011 10:43:37 -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 p95HlGQr009250; Wed, 5 Oct 2011 13:47:16 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail05.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 5 Oct 2011 13:46:43 -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, 5 Oct 2011 23:16:28 +0530 Message-ID: <2E239D6FCD033C4BAF15F386A979BF510F14CC@sonusinmail02.sonusnet.com> In-Reply-To: <4E8B1B86.2080805@jesup.org> 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: AcyCpIhSq89rXIcjSVuOMBmCF9FgBgA3/Jjw References: <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com><05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com><2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com><16880306-5B3A-4EFD-ADE4-1201138D9182@acmepacket.com><2E239D6FCD033C4BAF15F386A979BF510F137B@sonusinmail02.sonusnet.com><226C9800-9791-465A-B519-40935E2D135F@phonefromhere.com> <4E8B1B86.2080805@jesup.org> From: "Ravindran Parthasarathi" To: "Randell Jesup" , X-OriginalArrivalTime: 05 Oct 2011 17:46:43.0679 (UTC) FILETIME=[BECBDEF0:01CC8386] 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: Wed, 05 Oct 2011 17:43:38 -0000 Hi Randell/Tim, Please read inline. Thanks Partha >-----Original Message----- >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf >Of Randell Jesup >Sent: Tuesday, October 04, 2011 8:13 PM >To: rtcweb@ietf.org >Subject: Re: [rtcweb] RTCWeb default signaling protocol [was RE: About >defining a signaling protocol for WebRTC (or not)] > >On 10/4/2011 5:16 AM, Tim Panton wrote: >> Partha - here's a quick review of http://tools.ietf.org/html/draft- >partha-rtcweb-signaling-00 >> >> I'm not going to go through it line by line as I disagree with almost >all of it, so I >> focus on 2 key assumptions: >> >> Firstly -> >> >> Fig 1 is wrong - in the _huge_ majority of instances there will be >> only one web server in such a diagram. Federated services will only be >the minority case. > >Agreed. Agreed for the federated services. I will add another diagram with single server in the next revision > >> Secondly -> >> >> You assume that being compatible with a legacy protocol would be a >good thing, >> but don't examine why. >> I contend that there is no suitable legacy protocol and no advantage >would be conveyed by >> implementing one directly in a browser. I'll use SIP to illustrate my >point: >> >> The illusion is that there are lots of SIP devices that users are >itching to call from their browsers. There aren't. > It is not my argument. In case some of the draft sounds so, Please point it out and I will change >I agree, that is not a reason for any standard on signalling (though as >you say Partha didn't actually give a reason). If someone is building >an access-the-PSTN app (and they will), they can use or build a lib to >do so - though I'll also mention these fully-functional JS SIP/etc >libraries we presume don't exist yet and are a lot of work to write and >debug. A Skype can do so easily; a small PBX add-on company using >Asterisk not so much. Agreed > >I have a different argument: I want it to be *easy* for a website >author/app developer to add audio or video for their users. The >developers aren't experts on glare, forking, the intricacies of getting >offer-answer (or whatever) right, ad nauseum. If you ask them to >*design* their own protocol, they'll make a ton of 'rookie' mistakes. >And for added fun, they'll likely never correct them and in many cases >never understand why the bug is occasionally reported by their users. > Under Sec 4, first bullet convey the same above point. In case the bullet text is not clear, Please let me know. >A random example is forking - forking will happen (forward call to all >the devices the person logged in under) , and handling forking well >requires some thought and experience. > >The obvious answer is "those people shouldn't design a protocol (leave >that to the big guys), they should use a standard library."=20 It is the important point. Ok, great, >but: > >1) These don't exist yet (minor issue; one presumes they'll exist >"soon") >2) The quality and testing of these libraries is unlikely to equal that >of existing signalling stacks available freely for quite a while >3) Inaki's (sorry about the cedilla) point about "website-based >libraries can be updated more often than ones baked into a browser" is >valid, but it has a flip-side - the swarm of smaller users of webrtc are >likely to download a version of jSIP.js (or whatever) and are not likely >to actively track updates. My understanding is that this is rife in the >use of things like jquery - upgrading is time-consuming and risks >breakage, and requires QA. People grab one version and never change it >- while Firefox for example updates every 6 weeks. (He may have a >better argument with IE users, especially in business, but my point >still holds.) The larger, sophisticated users are more likely to >update, or debug problems when they occur, so I'm not worried about them >- and they can use jSIP.js regardless if there's a signalling protocol >in the browser. > >Point 3 is in ways the strongest point here, since I assume these >libraries will exist at some point. > >You'll note I'm not arguing for SIP here - I'm arguing that there are >valid reasons for easy default signalling *as and option*, especially >for the health of the "little guy" app/service developer who wants to >add RT media. My argument is also not for SIP. If we had a functional, debugged, standard JS protocol >that was free and we could figure a way for app developers to ease the >update process, it would undercut my argument - but we don't have that, >and we can't count on that, at least not for a while. It does not >*have* to be any existing signalling standard - though using one of >those is probably easiest, quickest (if the wars over whether/what >subside) and least error-prone. > > >> Conclusion -> >> >> So we should focus upon the most common use-case and not get >distracted into discussing >> what is at best an edge case. >> >> The risk of such a discussion (of a standard signalling protocol) is >that we will still be discussing it in 3 years time and each of the >browser makers will have implemented their own subtly different webRTC >solutions. > >Yes, this is critical. We need to finish it. I'd rather have it >finished and a strong project to build a "standard" external JS library >under way than to have the whole thing wait. But if I had my druthers >(what the bleep are those, anyways?) I'd have an optional signalling >protocol available. I agree with you. I listed some of the existing signaling protocol for the same reason which shall be integrated quickly. Most of the existing signaling protocol is stable by now because of the usage in other applications. > > >-- >Randell Jesup >randell-ietf@jesup.org > >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb From pravindran@sonusnet.com Wed Oct 5 10:47: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 7106411E8081 for ; Wed, 5 Oct 2011 10:47:24 -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.106, 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 LipBA2eSxyx7 for ; Wed, 5 Oct 2011 10:47:24 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id D1C0A21F8B37 for ; Wed, 5 Oct 2011 10:47:23 -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 p95Hp2Hn011762; Wed, 5 Oct 2011 13:51:02 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail07.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 5 Oct 2011 13:49:36 -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, 5 Oct 2011 23:19:19 +0530 Message-ID: <2E239D6FCD033C4BAF15F386A979BF510F14CD@sonusinmail02.sonusnet.com> In-Reply-To: <8584590C8D7DD141AA96D01920FC6C698C8A84ED@gbplmail03.genband.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: AQHMgqSHFvdI2T8mjE663dxgldXgIJVsU7aggAG03IA= References: <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com><05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com><2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com><16880306-5B3A-4EFD-ADE4-1201138D9182@acmepacket.com><2E239D6FCD033C4BAF15F386A979BF510F137B@sonusinmail02.sonusnet.com><226C9800-9791-465A-B519-40935E2D135F@phonefromhere.com><4E8B1B86.2080805@jesup.org> <8584590C8D7DD141AA96D01920FC6C698C8A84ED@gbplmail03.genband.com> From: "Ravindran Parthasarathi" To: "Jim McEachern" , "Randell Jesup" , X-OriginalArrivalTime: 05 Oct 2011 17:49:36.0515 (UTC) FILETIME=[25D08D30:01CC8387] 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: Wed, 05 Oct 2011 17:47:24 -0000 Hi Jim, For the given RTCWeb basic communication, if some other better signaling protocol exists, we will adopt for it.=20 Thanks Partha >-----Original Message----- >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf >Of Jim McEachern >Sent: Tuesday, October 04, 2011 9:29 PM >To: Randell Jesup; rtcweb@ietf.org >Subject: Re: [rtcweb] RTCWeb default signaling protocol [was RE:About >defining a signaling protocol for WebRTC (or not)] > >On Tue, Oct 4, 2011 at 10:43 AM, Randell Jesup >wrote: > >> I have a different argument: I want it to be *easy* for a website >> author/app developer to add audio or video for their users. The >> developers aren't experts on glare, forking, the intricacies of >> getting offer- answer (or whatever) right, ad nauseum. If you ask >> them to >> *design* their own protocol, they'll make a ton of 'rookie' mistakes. >> And for added fun, they'll likely never correct them and in many cases >> never understand why the bug is occasionally reported by their users. >> >> A random example is forking - forking will happen (forward call to all >> the devices the person logged in under) , and handling forking well >> requires some thought and experience. >> > >The problem with this argument is that it involves complex functionality >that would not be covered by basic SIP in the browser. >Are you proposing that the full SIP stack, with support for forking, >early media, etc. be built into all browsers? If yes, then we are >already at the bottom of the "slippery slope" that people fear. > If no, then the app developer will still need to deal with this >complexity. > >Am I missing something? > >Jim From pravindran@sonusnet.com Wed Oct 5 11:00: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 A451D11E808E for ; Wed, 5 Oct 2011 11:00:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[AWL=0.104, 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 6IKoiqVQeShw for ; Wed, 5 Oct 2011 11:00:17 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 5E89D11E8083 for ; Wed, 5 Oct 2011 11:00:17 -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 p95I3tgf019445; Wed, 5 Oct 2011 14:03:55 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail05.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 5 Oct 2011 14:03:22 -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_01CC8389.10553E17" Date: Wed, 5 Oct 2011 23:32:58 +0530 Message-ID: <2E239D6FCD033C4BAF15F386A979BF510F14CE@sonusinmail02.sonusnet.com> In-Reply-To: <4E8AC222.4050308@alvestrand.no> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] Review request for RTCWeb standard signaling protocol Thread-Index: AcyCbrTTtzCgiXjeQ22TtW1Iq/BXHwBGHX5g References: <2E239D6FCD033C4BAF15F386A979BF510F1367@sonusinmail02.sonusnet.com> <4E8AC222.4050308@alvestrand.no> From: "Ravindran Parthasarathi" To: "Harald Alvestrand" , X-OriginalArrivalTime: 05 Oct 2011 18:03:22.0463 (UTC) FILETIME=[121E36F0:01CC8389] Subject: Re: [rtcweb] Review request for RTCWeb standard 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: Wed, 05 Oct 2011 18:00:18 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC8389.10553E17 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Harald,=20 =20 Sec 3 & 4 of the draft deals with the need and advantages for standard signaling protocol. I understand your major concern is time. I think through and provided some solution as part of the draft =20 1) Sec 5: (RTCWeb Protocol requirement and design consideration) is added to come up with the thump rules for standard signaling rather than discussion different protocol 2) Sec 6: The list of existing signaling protocol is shown for eliminating the signaling protocol based on Sec 5 conclusion =20 In case time factor to solve this issue is the reason for rejecting this proposal , let us work for the better way to reduce the timeframe to achieve the result.=20 =20 Thanks Partha =20 From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Harald Alvestrand Sent: Tuesday, October 04, 2011 1:52 PM To: rtcweb@ietf.org Subject: Re: [rtcweb] Review request for RTCWeb standard signaling protocol =20 Ravindran, the core part of your document seems to me to be this list: The following Signaling protocols will qualify for becoming standard RTCWeb signaling protocol =20 1. Jingle 2. Websocket with SDP offer/answer 3. SIP 4. SIPLite [I-D.cbran-rtcweb-protocols ] 5. Websocket with custom XML 6. Megaco [RFC5125 ] 7. Websocket with SIP [I-D.ibc-rtcweb-sip-websocket ] 8. HTTP with custom XML 9. ??? =20 TBD: Pros and cons for each of the signaling mechanism has to be added My reading of your document is that you want the RTCWEB working group to pick exactly one of these alternatives, and insist that all conformant implementations of RTCWEB support this protocol. I disagree with: a) that this is needed b) that this is a good idea The reasons why it is not a good idea have been raised multiple times, and spending continued effort on trying to debate which of the alternatives you list above is "the best one" is distracting to our purpose of getting the RTCWEB protocol suite done. I do not support pursuing your suggested direction of work in this working group. Harald On 10/03/2011 04:41 PM, Ravindran Parthasarathi wrote:=20 Hi all, =20 RTCWeb standard signaling protocol (http://tools.ietf.org/html/draft-partha-rtcweb-signaling-00) draft list the need for standard signaling protocol between RTCWeb client (browser) and RTCWeb server and the possible signaling protocol for the same. This draft is written based on http://www.ietf.org/mail-archive/web/rtcweb/current/msg01172.html mail thread discussion. Could you please provide your valuable comments. =20 Thanks Partha =20 -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 Sent: Monday, October 03, 2011 7:56 PM To: Ravindran Parthasarathi Cc: Ravindran Parthasarathi Subject: New Version Notification for draft-partha-rtcweb-signaling-00.txt =20 A new version of I-D, draft-partha-rtcweb-signaling-00.txt has been successfully submitted by Parthasarathi Ravindran and posted to the IETF repository. =20 Filename: draft-partha-rtcweb-signaling Revision: 00 Title: RTCWeb standard signaling protocol Creation date: 2011-10-03 WG ID: Individual Submission Number of pages: 8 =20 Abstract: The standardization of Real time communication between browsers is to provide the infrastructure for audio, video, text communication using standard interface so that interoperable communication can be established between any compatible browsers. RTCWeb specific Javascript API will be provided by browsers for developing real-time web application. It is possible to develop signaling protocol like Session Initiation Protocol (SIP) or Jingle or websocket extension or custom-made signaling protocol in Javascript. There are lots of issues in Javascript based signaling protocol. This document list the need for standard signaling protocol between RTCWeb client (browser) and RTCWeb server and possible signaling protocol for the same. =20 =20 =20 =20 The IETF Secretariat _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb =20 =20 ------_=_NextPart_001_01CC8389.10553E17 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Harald,

 

Sec 3 & 4 of the draft deals with the need and = advantages for standard signaling protocol. I understand your major concern is = time. I think through and provided some solution as part of the = draft

 

1)      Sec 5:  (RTCWeb Protocol requirement and design consideration) is added to come up with the thump rules for standard = signaling rather than discussion different protocol

2)      Sec 6:  The list of existing signaling protocol is = shown for eliminating the signaling protocol based on Sec 5 = conclusion

 

In case time factor to solve this issue is the reason for rejecting this proposal , let us work for the better way to reduce the timeframe to achieve the result.

 

Thanks

Partha

 

From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Harald = Alvestrand
Sent: Tuesday, October 04, 2011 1:52 PM
To: rtcweb@ietf.org
Subject: Re: [rtcweb] Review request for RTCWeb standard = signaling protocol

 

Ravindran,

the core part of your document seems to me to be this list:


   The following Signaling =
protocols will qualify for becoming standard
   RTCWeb signaling =
protocol
 
   1.  =
Jingle
   2.  Websocket with SDP =
offer/answer
   3.  =
SIP
   4.  SIPLite [I-D.cbran-rtcweb-protocols]
   5.  Websocket with custom =
XML
   6.  Megaco [RFC5125]
   7.  Websocket with SIP [I-D.ibc-rtcweb-sip-websocket]=

   8.  HTTP with custom =
XML
   9.  =
???
 
   TBD: Pros and cons for each of =
the signaling mechanism has to be
   added


My reading of your document is that you want the RTCWEB working group to = pick exactly one of these alternatives, and insist that all conformant implementations of RTCWEB support this protocol.

I disagree with:

a) that this is needed
b) that this is a good idea

The reasons why it is not a good idea have been raised multiple times, = and spending continued effort on trying to debate which of the alternatives = you list above is "the best one" is distracting to our purpose of = getting the RTCWEB protocol suite done.

I do not support pursuing your suggested direction of work in this = working group.

            &= nbsp;        Harald





On 10/03/2011 04:41 PM, Ravindran Parthasarathi wrote: 

Hi all,
 
RTCWeb =
standard signaling protocol (http=
://tools.ietf.org/html/draft-partha-rtcweb-signaling-00) draft list =
the need for standard signaling protocol between RTCWeb client (browser) =
and RTCWeb server and the possible signaling protocol for the same. This =
draft is written based on http://www.ietf.org/mail-archive/web/rtcweb/current/msg01172.html =
mail thread discussion. Could you please provide your valuable =
comments.
 
Thanks
Partha
 
---=
--Original Message-----
From: internet-drafts@ietf.org =
[mailto:internet-drafts@ietf.org<=
/a>] 
Sent: Monday, October 03, 2011 7:56 =
PM
To: Ravindran =
Parthasarathi
Cc: Ravindran =
Parthasarathi
Subject: New Version Notification for =
draft-partha-rtcweb-signaling-00.txt
 
A new version of I-D, draft-partha-rtcweb-signaling-00.txt =
has been successfully submitted by Parthasarathi Ravindran and posted to =
the IETF =
repository.
 
Filename:&nb=
sp;     =
draft-partha-rtcweb-signaling
Revision:  &=
nbsp;   =
00
Title:        =
 RTCWeb standard signaling protocol
Creation date:  =
2011-10-03
WG =
ID:         Individual =
Submission
Number of pages: =
8
 
Abstract:
   The standardization of Real time communication =
between browsers is to
   provide the =
infrastructure for audio, video, text communication =
using
   standard interface so that =
interoperable communication can be
   =
established between any compatible browsers.  RTCWeb =
specific
   Javascript API will be =
provided by browsers for developing =
real-time
   web application.  It is =
possible to develop signaling protocol =
like
   Session Initiation Protocol (SIP) =
or Jingle or websocket extension or
   =
custom-made signaling protocol in Javascript.  There are lots =
of
   issues in Javascript based =
signaling protocol.  This document =
list
   the need for standard signaling =
protocol between RTCWeb client
   =
(browser) and RTCWeb server and possible signaling protocol for =
the
   =
same.
 
   =
            &=
nbsp;           &n=
bsp;           &nb=
sp;           &nbs=
p;            =
;            =
      =

 
 
=

The IETF =
Secretariat
________________________________________=
_______
rtcweb mailing list
rtcweb@ietf.org
=
https://www.ietf.or=
g/mailman/listinfo/rtcweb
 


 
------_=_NextPart_001_01CC8389.10553E17-- From tasveren@sonusnet.com Wed Oct 5 11:30: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 579551F0C5F for ; Wed, 5 Oct 2011 11:30:44 -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 PIvKdNR6lPUp for ; Wed, 5 Oct 2011 11:30:41 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id C059621F8CE9 for ; Wed, 5 Oct 2011 11:30:40 -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 p95IYJ8q007598; Wed, 5 Oct 2011 14:34:19 -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_01CC838C.75CF5716" Date: Wed, 5 Oct 2011 14:27:37 -0400 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E703CC78FF@sonusmail04.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: AcyDcyXMiNUNaOm7T9aS8icNuCRzkgAFstKg References: <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com><05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com><2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com><16880306-5B3A-4EFD-ADE4-1201138D9182@acmepacket.com><2E239D6FCD033C4BAF15F386A979BF510F137B@sonusinmail02.sonusnet.com><226C9800-9791-465A-B519-40935E2D135F@phonefromhere.com><4E8B1B86.2080805@jesup.org><4E8BD7B8.3080408@jesup.org> <4E8BDD6D.5030706@skype.net><4E8BE49B.6050202@jesup.org> From: "Asveren, Tolga" To: "Cameron Byrne" , "Randell Jesup" 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: Wed, 05 Oct 2011 18:30:44 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC838C.75CF5716 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Making things simple/accessible to a wide range of programmers is a good idea but then does this mean that a signaling protocol (even a simple one) should be baked in the browser? For example, if I have a webserver allowing people to play Battleships and want to add voice support for players, why do I need to use SIP (or something as complex as it)? What I am interested in would be limited to two-party simple voice communication (no forking, no renegotiation, no early media, no reliable responses etc....). A simple signaling protocol between JS and WebServer should be good enough AFAICS. There could be some JS libraries built for this purpose and one can use whichever one prefers (or develop its own). Arguing about potential issues with a JS SIP library in the context of simple use cases does not sound fair to me for this reason. The requirement of simplicity for the no-signaling-protocol-in the-browser approach would be: Keep the API exposing media related information/attributes as simple as possible (but no simpler). =20 One could argue that the definition of "simple" includes things I excluded above, e.g. forking. To me, simple means things similar to the use case above but I doubt there is consensus on that. =20 Thanks, Tolga =20 ________________________________ From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Cameron Byrne Sent: Wednesday, October 05, 2011 11:26 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 On Oct 4, 2011 10:05 PM, "Randell Jesup" wrote: > > On 10/5/2011 12:30 AM, Matthew Kaufman wrote: >> >> On 10/4/2011 9:06 PM, Randell Jesup wrote: >>> >>> I think there will be a lot of small-to-medium users adding chat, >>> building games, etc, who care little or not at all about the PSTN. >>> Those are the ones who I worry about; they wouldn't realize there are >>> issues with glare (totally ignoring PSTN) or that forking can be >>> complex. They want a simple, one-stop-shopping solution for adding >>> voice/video/data to their sites and games, etc. >> >> >> Ok, so they don't know there's issues with glare or that forking is >> hard. Does that mean that we solve forking in the browser? > > >>> Does this mean we *have* to bake in some sort of signalling? No, it >>> doesn't. It is an _argument_ for providing some type of signalling as >>> a baseline default; or if not, then for starting a project to provide >>> that. >>> >>> Note that I said "baseline". I did *not* say "can handle all the >>> intricacies of the PSTN well". >> >> >> So does "baseline" include handling the fact that "forking is hard", or >> does baseline not address forking either? > > > If you want me to answer that question: yes, I'd include support for some sort of resolution of forking. Enough to avoid getting into trouble, only. > > >>> It could be something far simpler than >>> SIP or XMPP, etc, or it could be a very dumbed-down version of one. >>> These small users (as noted) need something to provide the basics, and >>> to handle certain complexities that simply arise from normal usage >>> patterns and features (like forking). Being able to access the PSTN at >>> all using this would be a plus - but it would not be critical in my mind. >> >> >> This still doesn't mean that the browser needs to become a SIP phone, >> any more than it needed a map rendering engine for Google Maps to exist >> or an IMAP client for Gmail to exist. > > > I am in *no way* saying it needs to be a SIP phone. I'm saying "provide a simple-to-use basic signalling method which it totally optional to use, and which handles the basics needed of almost any signalling method (forking, glare, etc)". Nothing about phones, nothing about PSTN. > > We also don't ship browsers that consist of a canvas element and a JS interpreter, though you *could* build all websites that way (more or less), and some do (GMail and the like aren't far from it). But most site authors are glad they don't have to start with a bucket of rocks to build a castle *as their only option*. > I agree with Randal here. Let's make simple things simple, which does not preclude making advanced and novel things possible. Cb > >>> And, as I mentioned, it could be external JS - but then it has be more >>> solid to start with. For these simple uses - say chat with other users >>> on someones special-interest website, 2 and multiplayer gaming, etc - >>> we should try to pull together the minimum things any app/service >>> developer would need to be prepared for. I think any service that >>> allows someone to log in from multiple devices has to handle forking >>> in some manner. Glare is always possible. What else? I'd like to see >>> simple conferencing. Perhaps the minimum is simple enough that it >>> makes more sense to develop a new, very simple signalling JS module, >>> and use it in examples. This would limit the downside from not updating. >> >> >> Or create a good *platform* for building RTC apps and let the developers >> build things you've never imagined. I think that's a far better outcome >> than building a SIP phone into the browser and then discovering that >> most people don't want to just make phone calls. > > > Again: I'm not suggesting "build in a SIP phone", and how does my proposal in any way tie the hands of someone who wants to build it themselves? > > >>> The advantage of basing it on something known is that the basics of >>> all these protocols are well-understood. >>> >>> I'll paraphrase Harald (and many others in other contexts): make >>> simple things simple, make complex things possible. >> >> >> The latter is far more important than the former. If making simple >> things simple makes complex things significantly harder or impossible, >> you're not building a platform for innovation. > > > Ok, but in this case I don't want to complicate the later - so you're addressing a point I'm not making. Please consider re-reading my posting with that in mind. > > > --=20 > Randell Jesup > randell-ietf@jesup.org > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb ------_=_NextPart_001_01CC838C.75CF5716 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Making things simple/accessible to = a wide range of programmers is a good idea but then does this mean that a = signaling protocol (even a simple one) should be baked in the browser? For example, if I = have a webserver allowing people to play Battleships and want to add voice = support for players, why do I need to use SIP (or something as complex as it)? What = I am interested in would be limited to two-party simple voice communication = (no forking, no renegotiation, no early media, no reliable responses = etc….). A simple signaling protocol between JS and WebServer should be good enough = AFAICS. There could be some JS libraries built for this purpose and one can use whichever one prefers (or develop its own). Arguing about potential = issues with a JS SIP library in the context of simple use cases does not sound fair = to me for this reason. The requirement of simplicity for the = no-signaling-protocol-in the-browser approach would be: Keep the API exposing media related information/attributes as simple as possible (but no = simpler).

 

One could argue that the definition = of “simple” includes things I excluded above, e.g. forking. To me, simple means = things similar to the use case above but I doubt there is consensus on = that.

 

Thanks,

=

Tolga

 

From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Cameron Byrne
Sent: Wednesday, October = 05, 2011 11:26 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)]

 


On Oct 4, 2011 10:05 PM, "Randell Jesup" <randell-ietf@jesup.org> = wrote:
>
> On 10/5/2011 12:30 AM, Matthew Kaufman wrote:
>>
>> On 10/4/2011 9:06 PM, Randell Jesup wrote:
>>>
>>> I think there will be a lot of small-to-medium users adding = chat,
>>> building games, etc, who care little or not at all about = the PSTN.
>>> Those are the ones who I worry about; they wouldn't realize = there are
>>> issues with glare (totally ignoring PSTN) or that forking = can be
>>> complex. They want a simple, one-stop-shopping solution for = adding
>>> voice/video/data to their sites and games, etc.
>>
>>
>> Ok, so they don't know there's issues with glare or that = forking is
>> hard. Does that mean that we solve forking in the browser?
>
>
>>> Does this mean we *have* to bake in some sort of = signalling? No, it
>>> doesn't. It is an _argument_ for providing some type of = signalling as
>>> a baseline default; or if not, then for starting a project = to provide
>>> that.
>>>
>>> Note that I said "baseline". I did *not* say = "can handle all the
>>> intricacies of the PSTN well".
>>
>>
>> So does "baseline" include handling the fact that "forking is hard", or
>> does baseline not address forking either?
>
>
> If you want me to answer that question: yes, I'd include support = for some sort of resolution of forking.  Enough to avoid getting into = trouble, only.
>
>
>>> It could be something far simpler than
>>> SIP or XMPP, etc, or it could be a very dumbed-down version = of one.
>>> These small users (as noted) need something to provide the = basics, and
>>> to handle certain complexities that simply arise from = normal usage
>>> patterns and features (like forking). Being able to access = the PSTN at
>>> all using this would be a plus - but it would not be = critical in my mind.
>>
>>
>> This still doesn't mean that the browser needs to become a SIP = phone,
>> any more than it needed a map rendering engine for Google Maps = to exist
>> or an IMAP client for Gmail to exist.
>
>
> I am in *no way* saying it needs to be a SIP phone.  I'm = saying "provide a simple-to-use basic signalling method which it totally = optional to use, and which handles the basics needed of almost any signalling = method (forking, glare, etc)".  Nothing about phones, nothing about = PSTN.
>
> We also don't ship browsers that consist of a canvas element and a = JS interpreter, though you *could* build all websites that way (more or = less), and some do (GMail and the like aren't far from it).  But most site = authors are glad they don't have to start with a bucket of rocks to build a = castle *as their only option*.
>

I agree with Randal here. Let's make simple things simple, which does not = preclude making advanced and novel things possible.

Cb
>
>>> And, as I mentioned, it could be external JS - but then it = has be more
>>> solid to start with. For these simple uses - say chat with = other users
>>> on someones special-interest website, 2 and multiplayer = gaming, etc -
>>> we should try to pull together the minimum things any = app/service
>>> developer would need to be prepared for. I think any = service that
>>> allows someone to log in from multiple devices has to = handle forking
>>> in some manner. Glare is always possible. What else? I'd = like to see
>>> simple conferencing. Perhaps the minimum is simple enough = that it
>>> makes more sense to develop a new, very simple signalling = JS module,
>>> and use it in examples. This would limit the downside from = not updating.
>>
>>
>> Or create a good *platform* for building RTC apps and let the developers
>> build things you've never imagined. I think that's a far better outcome
>> than building a SIP phone into the browser and then discovering = that
>> most people don't want to just make phone calls.
>
>
> Again: I'm not suggesting "build in a SIP phone", and how = does my proposal in any way tie the hands of someone who wants to build it themselves?
>
>
>>> The advantage of basing it on something known is that the = basics of
>>> all these protocols are well-understood.
>>>
>>> I'll paraphrase Harald (and many others in other contexts): = make
>>> simple things simple, make complex things possible.
>>
>>
>> The latter is far more important than the former. If making = simple
>> things simple makes complex things significantly harder or = impossible,
>> you're not building a platform for innovation.
>
>
> Ok, but in this case I don't want to complicate the later - so = you're addressing a point I'm not making.  Please consider re-reading my = posting with that in mind.
>
>
> --
> Randell Jesup
> randell-ietf@jesup.org
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.or= g/mailman/listinfo/rtcweb

------_=_NextPart_001_01CC838C.75CF5716-- From pravindran@sonusnet.com Wed Oct 5 11:34: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 C3DAE21F8CEE for ; Wed, 5 Oct 2011 11:34:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[AWL=0.103, 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 0vXG37+NrwNo for ; Wed, 5 Oct 2011 11:34:40 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id AA20B21F8BEE for ; Wed, 5 Oct 2011 11:34:32 -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 p95IcDgQ010268; Wed, 5 Oct 2011 14:38:13 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail07.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 5 Oct 2011 14:37:08 -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_01CC838D.C7D27D1D" Date: Thu, 6 Oct 2011 00:06:30 +0530 Message-ID: <2E239D6FCD033C4BAF15F386A979BF510F14CF@sonusinmail02.sonusnet.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] Making progress on the signaling discussion (NB: Actionitems enclosed!) Thread-Index: AcyDfhJQVBYuL0p7Sr2gx70Q5ZxaWQAC8NyA References: <2E239D6FCD033C4BAF15F386A979BF510F1450@sonusinmail02.sonusnet.com> From: "Ravindran Parthasarathi" To: "Ted Hardie" X-OriginalArrivalTime: 05 Oct 2011 18:37:08.0559 (UTC) FILETIME=[C9C3EDF0:01CC838D] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Making progress on the signaling discussion (NB: Actionitems enclosed!) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 18:34:42 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC838D.C7D27D1D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ted, =20 Thanks for providing the opportunity to present my draft. =20 The main advantage of having standard signaling protocol are 1) Easy RTCWeb app development by non-real-time Web developer. 2) Better performance compare to JS based signaling =20 Sec 3 (Issues without RTCWeb standard signaling protocol) and Sec 4 (Standard RTCWeb signaling protocol advantages) are added to explain the need for standard signaling protocol. My intention of sec 3 & sec 4 to indicate that the weakness of "nothing" as a protocol and also to indicate standard signaling protocol does not stop custom made signaling protocol. I understand from the review comments that the text in these section has to be revised for clarity . Also few points which I received as part of the draft review comment has to be added. Please let me know in case you wish to see any specific point in these sections.=20 =20 I completely understand the "time to market" need for the RTCWeb specification and also "n" of difference of opinion starting from "nothing" to n number of variant of "standard signaling protocol". I have mentioned the list of existing signaling protocol in sec 6 to select by which the time to develop the signaling protocol will be avoided and also most of the existing protocol would have matured by now. Also, I have added sec 5 of the draft to provide the strong technical requirement of RTCWeb signaling which helps to select the protocol in sec 6. Please let me know in case more concrete way to solve this issue. =20 Thanks Partha =20 From: Ted Hardie [mailto:ted.ietf@gmail.com]=20 Sent: Wednesday, October 05, 2011 10:15 PM To: Ravindran Parthasarathi Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Making progress on the signaling discussion (NB: Actionitems enclosed!) =20 Hi Partha, We'd be happy to consider a signaling protocol proposal from you. Unfortunately, the current iteration of your draft does not contain a concrete proposal so much as a discussion of the advantages of a standardized signaling protocol. To make further progress, the chairs believe we need concrete proposals at this time. Please let us know if you would like to provide an update with a concrete proposal. thanks, Ted On Wed, Oct 5, 2011 at 12:03 AM, Ravindran Parthasarathi wrote: Ted, Magnus, Cullen, =20 Could you please consider RTCWeb standard signaling protocol (http://tools.ietf.org/id/draft-partha-rtcweb-signaling-00.txt) draft as one of the proposal for this signaling discussion. =20 Thanks Partha =20 From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Ted Hardie Sent: Tuesday, October 04, 2011 9:31 PM To: rtcweb@ietf.org Subject: [rtcweb] Making progress on the signaling discussion (NB: Actionitems enclosed!) =20 At today's Chairs call, Cullen, Magnus and I had a discussion of how to make progress on the signaling discussion. We feel the mailing list discussion needs to have more concrete proposals in order to make progress, and so we're putting forward the following: 1) If you plan to put forward a draft proposing a concrete solution in this space, please send your name to the mailing list with that intent by October 7th *THIS FRIDAY*. 2) Please have a -00 draft out for discussion by October 14th (the following Friday). This is to allow for a discussion and update prior to the -01 deadlines. 3) We will hold a conference call to discuss the drafts on October 21st (the Friday after that). Updates based on that discussion then have until the -01 drafts deadline to be complete. This is aggressive, but we feel we need to have at least -00s for the different ideas in place in order to make real progress. thanks, Ted, Magnus, Cullen =20 ------_=_NextPart_001_01CC838D.C7D27D1D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Ted,

 

Thanks for providing the opportunity to present my = draft.

 

The main advantage of having standard signaling protocol = are

1)      Easy RTCWeb app development by non-real-time Web = developer.

2)      Better performance compare to JS based = signaling

 

Sec 3 (Issues without RTCWeb standard signaling protocol) = and Sec 4 (Standard RTCWeb signaling protocol advantages) are added to = explain the need for standard signaling protocol. My intention of sec 3 & sec 4 = to indicate that the weakness of “nothing” as a protocol and = also to indicate standard signaling protocol does not stop custom made signaling protocol.  I understand from the review comments that the text in = these section has to be revised for clarity . Also few points which I received = as part of the draft review comment has to be added. Please let me know in = case you wish to see any specific point in these sections. =

 

I completely understand the “time to market” = need for the RTCWeb specification and also “n” of difference of = opinion starting from “nothing” to n number of variant of = “standard signaling protocol”. I have mentioned the list of existing = signaling protocol  in sec 6 to select by which the time to develop the = signaling protocol will be avoided and also most of the existing protocol would have = matured by now. Also, I have added sec 5 of the draft to provide the strong = technical requirement of RTCWeb signaling which helps to select the protocol in = sec 6. Please let me know in case more concrete way to solve this = issue.

 

Thanks

Partha

 

From:= Ted Hardie [mailto:ted.ietf@gmail.com]
Sent: Wednesday, October 05, 2011 10:15 PM
To: Ravindran Parthasarathi
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Making progress on the signaling discussion = (NB: Actionitems enclosed!)

 

Hi Partha,

We'd be happy to consider a signaling protocol proposal from you.  Unfortunately, the current iteration of your draft does not contain a = concrete proposal so much as a discussion of the advantages of a standardized = signaling protocol.   To make further progress, the chairs believe we = need concrete proposals at this time.  Please let us know if you would = like to provide an update with a concrete proposal.

thanks,

Ted

On Wed, Oct 5, 2011 at 12:03 AM, Ravindran = Parthasarathi <pravindran@sonusnet.com> wrote:

Ted, Magnus, = Cullen,

 

Could you please =
consider RTCWeb standard signaling protocol (http://tools.ietf.org/id/draft-partha-rtcweb-signaling-=
00.txt) draft as one of the proposal for this signaling =
discussion.
 
ThanksPartha

 

From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Ted Hardie
Sent: Tuesday, October 04, 2011 9:31 PM
To: rtcweb@ietf.org
Subject: [rtcweb] Making progress on the signaling discussion = (NB: Actionitems enclosed!)

 <= /o:p>

At today's Chairs call, Cullen, Magnus and I had a discussion of how to = make progress on the signaling discussion.  We feel the mailing list = discussion needs to have more concrete proposals in order to make progress, and so = we're putting forward the following:

1) If you plan to put forward a draft proposing a concrete solution in = this space, please send your name to the mailing list with that intent by = October 7th *THIS FRIDAY*.

2) Please have a -00 draft out for discussion by October 14th (the = following Friday).  This is to allow for a discussion and update prior to the = -01 deadlines.

3) We will hold a conference call to discuss the drafts on October 21st = (the Friday after that).

Updates based on that discussion then have until the -01 drafts deadline = to be complete.

This is aggressive, but we feel we need to have at least -00s for the = different ideas in place in order to make real progress.

thanks,

Ted, Magnus, Cullen

 

------_=_NextPart_001_01CC838D.C7D27D1D-- From fluffy@cisco.com Wed Oct 5 12:39: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 35A8F11E80C9 for ; Wed, 5 Oct 2011 12:39:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.024 X-Spam-Level: X-Spam-Status: No, score=-103.024 tagged_above=-999 required=5 tests=[AWL=-0.425, 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 m01k+c1E50YU for ; Wed, 5 Oct 2011 12:39:05 -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 A3A7A11E80C2 for ; Wed, 5 Oct 2011 12:39:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=1073; q=dns/txt; s=iport; t=1317843734; x=1319053334; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=k8GoRrMqK1eGX5JjZ9yn4sIIkGDEDaniCrXEwfkZ3Og=; b=CMzgPQ8ZDl9JkYvGHmTmJng65SKMaTZWAUq2WUsGUTcDuTfJInu3KPTZ yjdoFih/Fk9x61KcT10Zvbum5ZAG9u7DxTc9kRTEKe19gP+VEOeSd83EK FILbS5SRAxxRQERngUd+acaaLADTrR8/pixL4b3U3T6YxNS/NiKZhdRKX E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAM2xjE6rRDoH/2dsb2JhbABCqBeBBYFTAQEBAQIBEgEnPwULCxguVwYTIodbmSUBnhWGSGEEh3yLcYUnjDw X-IronPort-AV: E=Sophos;i="4.68,493,1312156800"; d="scan'208";a="6131565" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 05 Oct 2011 19:42:14 +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 p95JgDbp020810; Wed, 5 Oct 2011 19:42:13 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: Date: Wed, 5 Oct 2011 13:42:13 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E8B192E.80809@ericsson.com> <37C37EE6-3D48-4C77-A025-3207F040572B@cisco.com> <4E8BC56E.40306@skype.net> To: Bernard Aboba X-Mailer: Apple Mail (2.1084) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Summary of ICE discussion X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 19:39:06 -0000 Thanks On Oct 4, 2011, at 9:14 PM, Bernard Aboba wrote: > Right, that's the attack I had in mind, but with high bandwidth video. >=20 >=20 >=20 > On Oct 4, 2011, at 7:49 PM, "Matthew Kaufman" = wrote: >=20 >> On 10/4/2011 3:40 PM, Cullen Jennings wrote: >>> Could you say more... I'm not following your logic. >>>=20 >>>=20 >>> On Oct 4, 2011, at 10:47 AM, Bernard Aboba wrote: >>>=20 >>>> In particular, I'm concerned about vulnerabilities created by = multiplexing >>>> audio and video on the same port. When that is done, the ICE = procedure loses >>>> some of its DoS prevention properties. >>>>=20 >>=20 >> I think what he's concerned about is that a device might consent = (using ICE) to receive audio and unexpectedly receive multiplexed video = on the same RTP port. >>=20 >> Not sure this really matters, as there's not much difference between = low-frame-rate low-res video and 16-bit linear stereo PCM at 48 kHz = (which might indeed be an audio codec you can choose). >>=20 >> Matthew Kaufman From fluffy@cisco.com Wed Oct 5 14:03: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 5CCCB11E8103 for ; Wed, 5 Oct 2011 14:03:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.021 X-Spam-Level: X-Spam-Status: No, score=-103.021 tagged_above=-999 required=5 tests=[AWL=-0.422, 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 vnulDprJN3nc for ; Wed, 5 Oct 2011 14:03: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 334E811E8094 for ; Wed, 5 Oct 2011 14:03:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=2316; q=dns/txt; s=iport; t=1317848799; x=1319058399; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=fFOiWo6EZHSsl89Iu5Hr3nsFEpPAMjtgN1n5M7jmnxg=; b=iIJXeQKldhRiyPZ232e17SpH+87ezCC7DydQP61Kc08YUnRvtLo4wAM/ 9p7oO/+nfXQL7bXdr5Ga/dU0KzqWodngBh2wABF4gOxJoHnhBKtg5vahf uyJIU50DPG1mQnuDj809PB0rZnqT3/BzxDW/hoGUQI0on7y1FjhV7JwlN k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAKjFjE6rRDoH/2dsb2JhbABCqBqBBYFTAQEBAQIBAQEBDwFUBwsQCw4KLicwBhMih1sGmGoBnhaGSGEEh3yLcYUnjDw X-IronPort-AV: E=Sophos;i="4.68,493,1312156800"; d="scan'208";a="6148310" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 05 Oct 2011 21:06:39 +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 p95L6cR4004364; Wed, 5 Oct 2011 21:06:38 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Cullen Jennings In-Reply-To: <05B54E0C-B867-4D7F-825D-2E008E69B07F@acmepacket.com> Date: Wed, 5 Oct 2011 15:06:38 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <8FDA4100-55AA-4B84-A6F9-057742FFBB49@cisco.com> References: <4E80984A.903@skype.net> <4E809EE6.2050702@skype.net> <53C72381-DC23-4A6A-944C-B418791876B0@cisco.com> <05B54E0C-B867-4D7F-825D-2E008E69B07F@acmepacket.com> To: Hadriel Kaplan 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, 05 Oct 2011 21:03:31 -0000 On Sep 29, 2011, at 3:59 PM, Hadriel Kaplan wrote: >=20 > 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). I have this weird feeling we have had this conversation before but I'm a = bit skeptical. What processor are you running SHA-1 on and how many STUN = requests per second do you think might be reasonable for carrier grade = box (whatever "Carrier Grade" is :-). The implementation I have been = involved with, the SHA-1 is a drop in the bucket compared to the overall = processing to setup a new call.=20 >=20 > That's one of the things we've been arguing about in MMUSIC as being a = problem 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 justify 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 IETF. :( >=20 > -hadriel >=20 >=20 > On Sep 28, 2011, at 12:18 PM, I=F1aki Baz Castillo wrote: >=20 >> 2011/9/28 Cullen Jennings : >>> 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 >> 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 >=20 From paul.hoffman@vpnc.org Tue Oct 4 15: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 A54F221F8F1E for ; Tue, 4 Oct 2011 15:59:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.028, 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 Zd89hQCut3XH for ; Tue, 4 Oct 2011 15:59:49 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 6BDA321F8E11 for ; Tue, 4 Oct 2011 15:59:41 -0700 (PDT) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p94N2g8V087421 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 4 Oct 2011 16:02:43 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <4CEEC8BB-FC3D-4424-A2D6-D5F96E3DDBDE@cisco.com> Date: Tue, 4 Oct 2011 16:02:42 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E8B192E.80809@ericsson.com>, <4CEEC8BB-FC3D-4424-A2D6-D5F96E3DDBDE@cisco.com> To: rtcweb@ietf.org X-Mailer: Apple Mail (2.1244.3) X-Mailman-Approved-At: Wed, 05 Oct 2011 14:27:31 -0700 Subject: Re: [rtcweb] Summary of ICE discussion X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 22:59:49 -0000 On Oct 4, 2011, at 3:40 PM, Cullen Jennings wrote: > Paul Hoffman (CC'd) might have some interesting stats about operating = a public STUN server.=20 - Ran stunserver.org for a while because Cullen and Rohan thought it = might be interesting. - My ISP (a friend) complained about the traffic. We could see huge = amounts, even though no one had asked. - I transferred the domain to Cullen to run. - A year after I turned off stun at the IP address that stunserver.org = used to run on, the ISP's firewall says that the port gets *much* more = traffic than vpnc.org and imc.org combined web and mail. Note that on = the stunserver.org web page, we explicitly said that people should put = our domain name in, not the IP address. This is all traffic that is = getting no reply. Conclusion: STUN is probably riper for tragedy of the commons than other = protocols due to negligent developers who don't care if their clients = keep hitting dead servers. --Paul Hoffman From magnus.westerlund@ericsson.com Thu Oct 6 01:18: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 315EE21F8C19 for ; Thu, 6 Oct 2011 01:18:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.334 X-Spam-Level: X-Spam-Status: No, score=-106.334 tagged_above=-999 required=5 tests=[AWL=-0.035, 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 zkfrYr-bS7Z6 for ; Thu, 6 Oct 2011 01:18: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 4F78821F8C12 for ; Thu, 6 Oct 2011 01:18:41 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-15-4e8d651eb23f Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.115.90]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 90.43.20773.E156D8E4; Thu, 6 Oct 2011 10:21: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; Thu, 6 Oct 2011 10:21:30 +0200 Message-ID: <4E8D6507.8000707@ericsson.com> Date: Thu, 6 Oct 2011 10:21:27 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= References: In-Reply-To: X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Making progress on the signaling discussion (NB: Action items enclosed!) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2011 08:18:42 -0000 On 2011-10-05 19:03, Iñaki Baz Castillo wrote: > 2011/10/5 Ted Hardie : >> Sorry, but do you intend to provide a draft? It was hard for me to parse >> whether the statement above is a commitment or a statement that you don't >> have time. > > Maybe not a draft, but a complete explanation and presentation of what > we have working (SIP over WebSocket + JavaScript code implementing a > SIP stack + SIP proxy implementing the WebSocket transport). And it > just works. > > The draft is already done: > > http://tools.ietf.org/html/draft-ibc-rtcweb-sip-websocket-00 > > In fact it defines a concrete signaling protocol (well, not exactly as > it uses pure SIP, but on top of WebSocket). Of course it aim is to be > used with rtcweb for media sessions. > Iñaki, could you please clarify your intention of your proposal? My interpretation of your draft is that it is a description of how you can deploy SIP implemented in JS over websocket. Thus enabling SIP interworking when needed by having the JS SIP stack convert regular SIP with SDP into interactions with the WEBRTC API. Thus your proposal really is primarily an argument that you don't need SIP implemented in the browser, as long as the API allows the JS to create SIP with SDP messages. Thus I would interpret this as something that could work both over something similar to the current PeerConnection API proposals and a more low level API. Where PeerConnection likely is less work as it does provide the SDP that in most cases don't need modifications. Is this a correct interpretation and thus your draft is an extension that simplifies life for the people who like SIP interworking by getting the SIP functionality into the end-point rather than a gateway? Or is it something else? If it is the first I don't see your proposal as complete proposal for how signaling for RTCWEB, as you still need APIs to something in some form and with possibly certain semantics that interact with the SIP in JS implementation. To clarify, what I see the question for the WG is how the signalling model for RTCWEB session establishment is intended to work. Thus the drafts intended for answering this needs to be focused on describing a signalling model. 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 Markus.Isomaki@nokia.com Thu Oct 6 06:02: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 3465F21F8B51 for ; Thu, 6 Oct 2011 06:02:01 -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=[AWL=0.350, 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 NYgOpDFfPO-1 for ; Thu, 6 Oct 2011 06:02:00 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 3E13021F87D9 for ; Thu, 6 Oct 2011 06:01:59 -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 p96D4985010897; Thu, 6 Oct 2011 16:04:42 +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); Thu, 6 Oct 2011 16:04:27 +0300 Received: from 008-AM1MMR1-006.mgdnok.nokia.com (65.54.30.61) by NOK-am1MHUB-02.mgdnok.nokia.com (65.54.30.6) with Microsoft SMTP Server (TLS) id 8.2.255.0; Thu, 6 Oct 2011 15:04:25 +0200 Received: from 008-AM1MPN1-043.mgdnok.nokia.com ([169.254.3.167]) by 008-AM1MMR1-006.mgdnok.nokia.com ([65.54.30.61]) with mapi id 14.01.0339.002; Thu, 6 Oct 2011 15:04:24 +0200 From: To: , Thread-Topic: [rtcweb] Future requirement: RTC-Web apps must work through interface switching Thread-Index: AcyBw8LOCbj0Q27JT3eGKgpYq050b///6k8A//sjheA= Date: Thu, 6 Oct 2011 13:04:23 +0000 Message-ID: References: <4E89AD52.5000402@ericsson.com> In-Reply-To: <4E89AD52.5000402@ericsson.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 06 Oct 2011 13:04:27.0207 (UTC) FILETIME=[7A491570:01CC8428] X-Nokia-AV: Clean Subject: Re: [rtcweb] Future requirement: RTC-Web apps must work through interface switching X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2011 13:02:01 -0000 Hi Stefan, Stefan H=E5kansson wrote: > >in terms of use case and reqs, do you see anything missing if you look at >requirements/>, >section 4.2.3? > >In terms of technology I thought ICE would be able to handle this. > I agree ICE has the mechanisms to handle it to some extent, as new candidat= es can be added on-the-fly, e.g. when a device gets a new IP address via a = newly connected interface. I guess the minimum requirement is that the enti= ty generationg the ICE signaling messages needs to be able to learn about t= he existence of the new candidates immediately, so it can generate the new = ICE "offer". I'm not sure where this is supposed to happen, but if it is th= e JS app that sends the "offers", there is a requirement that there needs t= o be an event in the API indicating that the set of local candidates has ch= anged. Markus=20 >On 10/03/2011 01:58 PM, Markus.Isomaki@nokia.com wrote: >> Hi all, >> >> There is one important requirement, which may not be critical today, but= will >most likely be in the future. >> >> We can assume RTC-Web to be supported in devices like tablets, pads or >smartphones, that people carry around. We can also assume that when such >devices are carried around, their point of attachement to the Internet wil= l >change, even so that the type of access network will change, typically >between something like HSPA/LTE and Wi-Fi. Today this will always mean a >change of IP address as well. In the future we may have technologies such = as >(Proxy)Mobile IP in use that will provide IP address preservation, but we = can't >really count on that. >> >> How does this relate to RTC-Web? Interface switching usually happens >> at the discretion of the OS or some kind of connection manager. The >> browser or the web application environment has no control over it. At >> best it, or the JS application running within, can get some kind of >> signal of such event happening. For TCP-based client-server things >> (HTTP, Websocket) it is possible to react to this by re-establishing >> the lost TCP connections and state on top of them. This is indeed what >> many (native) apps are able to do today. There can be some smarter >> ways in the pipeline as well, such as multipath TCP, which would make >> the process of "transitioning" a TCP connection from one interface/IP >> to another potentially transparent to the application. But with >> peer-to-peer and interactive real-time, things get more complicated. >> It may of course be that the switching happens due to a sudden loss of >> coverage and is so slow, that voice or video calls are broken anyway. >> However, in many cases th > e >> old interface can be up while the new one is being established, and in >principle the total loss of connectivity can be avoided. In such scenarios= it >would be realistically possible to update the ongoing real-time sessions t= o a >new IP address and port, if there were some kind of end-to-end or server- >assisted mechanism for it. Even a cut of 1-2 seconds would not be as bad a= s a >total loss of the session. >> >> What does this mean in terms of requirements? >> - The first-order requirement is that the browser and/or the JS app, >whoever needs to act, has to be able to get events of interface switching = in >the same way as native apps can. If it were only the browser who was >required to get them, we could set standards aside, and declare that the >browser does this as any other app. But if it is the JS app that needs to = do >something, then we may need something new as a JS API. I have no clue at >the moment if the JS apps can learn about this kind of events. And this is >clearly not a RTC-Web specific requirement, but a generic one. I do know t= hat >browsers or HTTP libraries can re-send requests etc. based on IP address >change, but I don't know what a JS Websocket client can do, if anything. >> - The second requirement is that the media related APIs and transport >protocols (RTP) have to be flexible enough, that they can at least be exte= nded >to work so that they do not assume that the session is forever bound to a >certain IP address/port in either end. How this affects the system depends= on >what is actually standardized, for instance if the SDP offer/answer model = is >included or not. But on the generic level it could be something like this: >> - If the browser/JS app receives signaling/offer from its peer that >peer's RTP/UDP IP address/port has changed, it has to be able to set these >through the media API and re-run STUN checks or whatever is required at th= at >point. This has to be work so that the media session can be otherwise >continued, after the process is completed. >> - If the browser/JS app receives an event that its own IP address/port >has changed (or is about to change), it has to be able to re-initialize th= e >RTP/UDP accordingly, re-establish its "signaling connection and state" wit= h its >webserver, notify the peer about the change, and re-run STUN checks etc. a= s >needed. >> >> This sounds quite complicated so it may be that we don't want to add thi= s as >a Day 1 requirement for RTC-Web. But I believe we should try to design the >APIs and protocols in such a way that this kind of thing can be added late= r on. >There could be other ways too, like MPRTP >(http://datatracker.ietf.org/doc/draft-singh-avtcore-mprtp/), we could loo= k >at. >> >> I suppose the less we standardize about the signaling and offer/answer, = the >easier it might be to support these kinds of things as add-on. But whateve= r we >standardize, please keep the interface and IP address change in mind. The >outcome could be that we declare that transport (MPTCP, MPRTP) has to deal >with it, but eventually I think this will have to work one way or the othe= r. >> >> Regards, >> Markus >> _______________________________________________ >> 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 Markus.Isomaki@nokia.com Thu Oct 6 06:18: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 A570721F8B43 for ; Thu, 6 Oct 2011 06:18:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.781 X-Spam-Level: X-Spam-Status: No, score=-2.781 tagged_above=-999 required=5 tests=[AWL=-0.182, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k7ZN8Y9+ExID for ; Thu, 6 Oct 2011 06:18:10 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 6AFD921F8B30 for ; Thu, 6 Oct 2011 06:18:10 -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 p96DKrYn028944; Thu, 6 Oct 2011 16:21:16 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 6 Oct 2011 16:20:04 +0300 Received: from 008-AM1MMR1-001.mgdnok.nokia.com (65.54.30.56) by NOK-am1MHUB-01.mgdnok.nokia.com (65.54.30.5) with Microsoft SMTP Server (TLS) id 8.2.255.0; Thu, 6 Oct 2011 15:20:03 +0200 Received: from 008-AM1MPN1-043.mgdnok.nokia.com ([169.254.3.167]) by 008-AM1MMR1-001.mgdnok.nokia.com ([65.54.30.56]) with mapi id 14.01.0339.002; Thu, 6 Oct 2011 15:20:03 +0200 From: To: , Thread-Topic: [rtcweb] Future requirement: RTC-Web apps must work through interface switching Thread-Index: AcyBw8LOCbj0Q27JT3eGKgpYq050bwAAKV6AAAUGtUD//+VQgIAC914A//48VBA= Date: Thu, 6 Oct 2011 13:20:01 +0000 Message-ID: References: <4E89C099.3000709@alvestrand.no> <4E89CBF1.8050207@alvestrand.no> <4E8C48F2.6090502@ericsson.com> In-Reply-To: <4E8C48F2.6090502@ericsson.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 06 Oct 2011 13:20:04.0342 (UTC) FILETIME=[A8DC8960:01CC842A] X-Nokia-AV: Clean Subject: Re: [rtcweb] Future requirement: RTC-Web apps must work through interface switching X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2011 13:18:11 -0000 Hi Magnus, Magnus Westerlund wrote: > >Hi, >(as individual) > >I would like to comment on two things around this with ICE restarts and wh= at I >believe Google Voice Talk does and its relation to the ICE spec. > >First of all I understand this being based on that the candidates are kept= alive >after the initial nomination so they are always ready. This is clearly all= owed, >but will definitely fail if the other part doesn't keep its ICE candidates= alive, >and do note that these might include TURN relay candidates also. Thus this >practice is not without some resource consumption, even if it is only a ST= UN >request every 15 seconds. > I agree that keeping candidates alive for an interface that is otherwise on= stand-by is costly. For instance, if the media flows over Wi-Fi, but the d= evice would like to keep the cellular interface candidates alive in case th= e user steps out of Wi-Fi coverage, it will be about double the radio power= consumption. But there are some situations where doing this smartly might = make sense.=20 >Secondly, I understand that the alternative candidates are used without >signaling to the other peer that the ICE connectivity checks and later >nomination happens. This will not work for candidate pairs where the peer >not having interface change happen to it is behind a middlebox with a addr= ess >dependent filtering rule, i.e. practically all, unless the candidate pair = hasn't be >initially verified to work and kept alive without nomination due to lower >priority for the whole call.=20 Right.=20 >Otherwise, this only works when both sides tries to >use their candidates due to ICE restart signaling message or that the othe= r >peer also suspects path breakage and initiates an ICE restart implicitly b= ased >on lack of feedback and media traffic from peer. > >When it comes to handling interface changes in general. I do believe that = we >will need to support a signaled ICE restart. If not, the webapp can anyway >emulate this at a higher resource consumption and likely longer media >disruption by opening new peer connections. > Agree. It seems there is some flexibility how to do this, as long as the JS= app just gets an event about the connectivity changes. So this seems to be= the minimum thing needed. >Cheers > >Magnus > Markus >On 2011-10-03 16:51, Harald Alvestrand wrote: >> On 10/03/2011 04:40 PM, Markus.Isomaki@nokia.com wrote: >>> Hi Harald, >>> >>> Well, things may already be better than what I expected :) >>> >>>> The control channel needs to be reconnected too, of course, but >>>> we're not so much in a hurry over that one. >>> So you're not signaling anything at the point of the switch, but you >>> have set two alternatives beforehand? In the mobile use case, the >>> available interfaces come and go, so we can't offer all alternate >>> candidates upfront. However, if we can keep the "old" >>> interface up for a while after the "new" one appears, we can add the >>> new candidate at that point. >> Section 9 of RFC 5245 is the procedure for adding more candidates >> during the call. It supports make-before-break: >> >> 9.1.1.1. ICE Restarts >> >> An agent MAY restart ICE processing for an existing media stream. >> An ICE restart, as the name implies, will cause all previous states of >> ICE processing to be flushed and checks to start anew. The only >> difference between an ICE restart and a brand new media session is >> that, during the restart, media can continue to be sent to the >> previously validated pair. >> >>> This would be the so called make-before-break switch. The worst case >>> is that we loose the old interface at the same time as new one comes >>> available, so the new alternative can only be sent over the new >>> interface AFTER the signaling has been reconnected. This would be >>> break-before-make. If the underlying OS can handle multi-homing, we >>> should in most cases only need the make-before-break type of >>> switching. However, as we know, a device can run out of Wi-Fi >>> coverate quite abruptly and it is not always clear that the cellular >>> connectivity is fully up at that point. >>> >>> I don't know all nuances of ICE by heart, but is it so that the >>> alternate candidates can be added in an offer at any point? In that >>> case we should be able to cover most cases quite well. >>> >>> Markus >>> >>>> -----Original Message----- From: rtcweb-bounces@ietf.org >>>> [mailto:rtcweb-bounces@ietf.org] On Behalf Of ext Harald Alvestrand >>>> Sent: 03 October, 2011 17:03 To: rtcweb@ietf.org >>>> Subject: Re: [rtcweb] Future requirement: RTC-Web apps must work >>>> through interface switching >>>> >>>> The media channels in Google's ICE-based offerings (Google Talk >>>> Video, Google Voice and Hangouts) all are able to survive an >>>> interface change by utilizing the alternate candidate mechanisms in >>>> ICE. >>>> >>>> Try this experiment: - Make sure your laptop has a working wireless >>>> connection - Connect your laptop to wired Ethernet - Set up a Google >>>> Talk Video call with someone - Yank out the Ethernet cord >>>> >>>> If all goes well, you should see exactly how much of a break this >>>> causes to the call in practice. (If the call disconnects, please >>>> file a bug - I'm sure there are cases we don't handle well.) >>>> >>>> The control channel needs to be reconnected too, of course, but >>>> we're not so much in a hurry over that one. > > >-- > >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 stefan.lk.hakansson@ericsson.com Thu Oct 6 06:45: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 0BD8221F8B4A for ; Thu, 6 Oct 2011 06:45:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.327 X-Spam-Level: X-Spam-Status: No, score=-6.327 tagged_above=-999 required=5 tests=[AWL=-0.028, 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 0GXqzxHxRBdl for ; Thu, 6 Oct 2011 06:45: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 BAFCC21F8B3E for ; Thu, 6 Oct 2011 06:45:27 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-ba-4e8db1b5824a Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 28.77.20773.5B1BD8E4; Thu, 6 Oct 2011 15:48:37 +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, 6 Oct 2011 15:48:22 +0200 Message-ID: <4E8DB1A5.1000800@ericsson.com> Date: Thu, 6 Oct 2011 15:48:21 +0200 From: =?ISO-8859-1?Q?Stefan_H=E5kansson?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110922 Lightning/1.0b2 Thunderbird/3.1.15 MIME-Version: 1.0 To: "Markus.Isomaki@nokia.com" References: <4E89AD52.5000402@ericsson.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Future requirement: RTC-Web apps must work through interface switching X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2011 13:45:29 -0000 On 10/06/2011 03:04 PM, Markus.Isomaki@nokia.com wrote: > Hi Stefan, > > Stefan Hkansson wrote: >> >> in terms of use case and reqs, do you see anything missing if you >> look at >> > requirements/>, section 4.2.3? >> >> In terms of technology I thought ICE would be able to handle this. >> > > I agree ICE has the mechanisms to handle it to some extent, as new > candidates can be added on-the-fly, e.g. when a device gets a new IP > address via a newly connected interface. I guess the minimum > requirement is that the entity generationg the ICE signaling messages > needs to be able to learn about the existence of the new candidates > immediately, so it can generate the new ICE "offer". I'm not sure > where this is supposed to happen, but if it is the JS app that sends > the "offers", there is a requirement that there needs to be an event > in the API indicating that the set of local candidates has changed. I agree. For the time being, the requirement is on a higher level - and quite badly phrased (I'm to blame): "It MUST be possible to move from one network interface to another one" I think it can be better put, and later when the model is decided it can be broken down (e.g to an event in the API). Stefan > > Markus > > >> On 10/03/2011 01:58 PM, Markus.Isomaki@nokia.com wrote: >>> Hi all, >>> >>> There is one important requirement, which may not be critical >>> today, but will >> most likely be in the future. >>> >>> We can assume RTC-Web to be supported in devices like tablets, >>> pads or >> smartphones, that people carry around. We can also assume that when >> such devices are carried around, their point of attachement to the >> Internet will change, even so that the type of access network will >> change, typically between something like HSPA/LTE and Wi-Fi. Today >> this will always mean a change of IP address as well. In the future >> we may have technologies such as (Proxy)Mobile IP in use that will >> provide IP address preservation, but we can't really count on >> that. >>> >>> How does this relate to RTC-Web? Interface switching usually >>> happens at the discretion of the OS or some kind of connection >>> manager. The browser or the web application environment has no >>> control over it. At best it, or the JS application running >>> within, can get some kind of signal of such event happening. For >>> TCP-based client-server things (HTTP, Websocket) it is possible >>> to react to this by re-establishing the lost TCP connections and >>> state on top of them. This is indeed what many (native) apps are >>> able to do today. There can be some smarter ways in the pipeline >>> as well, such as multipath TCP, which would make the process of >>> "transitioning" a TCP connection from one interface/IP to another >>> potentially transparent to the application. But with peer-to-peer >>> and interactive real-time, things get more complicated. It may of >>> course be that the switching happens due to a sudden loss of >>> coverage and is so slow, that voice or video calls are broken >>> anyway. However, in many cases th >> e >>> old interface can be up while the new one is being established, >>> and in >> principle the total loss of connectivity can be avoided. In such >> scenarios it would be realistically possible to update the ongoing >> real-time sessions to a new IP address and port, if there were some >> kind of end-to-end or server- assisted mechanism for it. Even a cut >> of 1-2 seconds would not be as bad as a total loss of the session. >>> >>> What does this mean in terms of requirements? - The first-order >>> requirement is that the browser and/or the JS app, >> whoever needs to act, has to be able to get events of interface >> switching in the same way as native apps can. If it were only the >> browser who was required to get them, we could set standards aside, >> and declare that the browser does this as any other app. But if it >> is the JS app that needs to do something, then we may need >> something new as a JS API. I have no clue at the moment if the JS >> apps can learn about this kind of events. And this is clearly not a >> RTC-Web specific requirement, but a generic one. I do know that >> browsers or HTTP libraries can re-send requests etc. based on IP >> address change, but I don't know what a JS Websocket client can do, >> if anything. >>> - The second requirement is that the media related APIs and >>> transport >> protocols (RTP) have to be flexible enough, that they can at least >> be extended to work so that they do not assume that the session is >> forever bound to a certain IP address/port in either end. How this >> affects the system depends on what is actually standardized, for >> instance if the SDP offer/answer model is included or not. But on >> the generic level it could be something like this: >>> - If the browser/JS app receives signaling/offer from its peer >>> that >> peer's RTP/UDP IP address/port has changed, it has to be able to >> set these through the media API and re-run STUN checks or whatever >> is required at that point. This has to be work so that the media >> session can be otherwise continued, after the process is >> completed. >>> - If the browser/JS app receives an event that its own IP >>> address/port >> has changed (or is about to change), it has to be able to >> re-initialize the RTP/UDP accordingly, re-establish its "signaling >> connection and state" with its webserver, notify the peer about the >> change, and re-run STUN checks etc. as needed. >>> >>> This sounds quite complicated so it may be that we don't want to >>> add this as >> a Day 1 requirement for RTC-Web. But I believe we should try to >> design the APIs and protocols in such a way that this kind of thing >> can be added later on. There could be other ways too, like MPRTP >> (http://datatracker.ietf.org/doc/draft-singh-avtcore-mprtp/), we >> could look at. >>> >>> I suppose the less we standardize about the signaling and >>> offer/answer, the >> easier it might be to support these kinds of things as add-on. But >> whatever we standardize, please keep the interface and IP address >> change in mind. The outcome could be that we declare that transport >> (MPTCP, MPRTP) has to deal with it, but eventually I think this >> will have to work one way or the other. >>> >>> Regards, Markus _______________________________________________ >>> rtcweb mailing list rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >> >> >> _______________________________________________ rtcweb mailing >> list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From randell-ietf@jesup.org Thu Oct 6 08: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 3469321F8BDB for ; Thu, 6 Oct 2011 08:33:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.573 X-Spam-Level: X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=0.026, 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 qnNhcUwSqgur for ; Thu, 6 Oct 2011 08:33: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 F19B421F8BA9 for ; Thu, 6 Oct 2011 08:33: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 1RBpzm-0006wM-Tt; Thu, 06 Oct 2011 10:36:27 -0500 Message-ID: <4E8DCA06.5060506@jesup.org> Date: Thu, 06 Oct 2011 11:32:22 -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: Harald Alvestrand , "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] Congestion Control 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, 06 Oct 2011 15:33:18 -0000 Situation: We have a UDP connection, either direct or via a TURN server. On that UDP connection, we've negotiated DTLS. We're running multiple RTP streams in both directions using DTLS-SRTP. We also are running multiple data channels, both reliable and unreliable, over DTLS (perhaps UDP-DTLS-SCTP). We want to congestion-control all the network data, preferably in as unified fashion as possible. Google disclosed an algorithm for doing "predictive" bottleneck-buffer queue-length sensing based on packet arrival times compared to RTP timestamps. Their algorithm should work well in most cases on a single channel, but with multiple channels there may be inequities and hunting, plus the application may want to have input into which streams get the available bits. I propose an extended version of Google's algorithm, based around computing the available bandwidth and buffer-fullness across either all the media channels, or the media channels and the data channels. Constraints/assumptions: 1) variable number of media streams (SSRCs), audio and/or video 2) The streams may use different timestamp sample rates 3) The streams may have timestamp rates that are not synchronized; i.e. they may drift both relative to NTP and to each other. 4) Media streams may start and stop at any point 5) Audio streams may use DTX/VAD and so have gaps in sending 6) Video streams may use variable frame rates 7) Video streams may have major variation in bandwidth from frame to frame (iframes, motion or lack thereof, etc). 8) All media streams in a direction might be inactive or in DTX/VAD at any given time, for an indeterminate period 9) Media streams will have limits on their ability to adjust bandwidth use. In some cases a renegotiation of streams and/or codecs may be required to meet the limitations of the bottleneck. 10) If the other end doesn't implement this congestion control mechanism we must adapt bandwidth based on normal RTCP Goals: (roughly in order of importance) 1) Consistently low-delay Note that we don't say "staying within bandwidth" here; the goal is the end-user experience (delay& loss), not the mechanism affecting delay and loss (bandwidth). 2) Low but not necessarily 0 loss. 3) Good use of available bandwidth (within 'fair-share' bounds). 4) Rapid adaptation to changes in bandwidth available 5) Good startup pattern 6) Stable algorithm; few bad "corner cases" and quick recovery from them. 7) Good performance in the face of true random loss. 8) Good performance/recovery when the browser is active (or another browser on the same access/bottleneck link). 9) Bandwidth must be controlled to the level of not allowing the JS app to use it in a denial-of-service attack. The general algorithm is to take each incoming packet from each SSRC source; convert the timestamp to an estimated (source) NTP time it was sent at, including compensation for clock drift rates; and then using the stream of source packets, sizes, and time of sending estimate the slope of the incoming rate compared to the sending rate. Effectively, we consider all the media packets to be one, big stream using an algorithm effectively similar to Google's, giving us more data points. The merged packets will look rather more like a video stream with a collection of small and large packets than an audio stream. To communicate the bandwidth available, we have two main options: 1) run the algorithm on the recipient side, and send the target value to the sender in the equivalent of TMMBR. (We can't use normal TMMBR since that's for one SSRC, and we want it to apply to all SSRCs being sent.) 2) collect and process the arrival data, and communicate to the sender the slope of the line, the incoming bitrate, number of packets, and loss rate (anything else?). The sender will calculate how it should respond. Both of these require a new RTCP feedback message, though the first is very closely associated with TMMBR. I've had good experiences in the past with case #2. Concerns: Stability of this merged stream is a concern; we'll need to do some good real-world and simulated tests (see Testing below). Startup: There are issues both with starting too low (quality is poor at the start and takes a while to get better), and with starting too high (you immediately can get into a delay situation and have to go into recovery). In general, starting too low is better than starting too high, as when we ramp up past the bottleneck we will not be too far over the limit and so recovery will be easier. In general, the bottleneck link is often upstream, though this is moderating as high-bandwidth broadband becomes more common. Options include: a) Start at fixed value b) Start at N% below the value from the last call with this person (probably requires the App to help here) c) Start at N% below the value from the last call with anyone d) Have the other side tell us the rate they successfully received in the last call. Start the call at the lower of the last-call reception rate from the far end or our last-call sending rate, minus n% e) probe bandwidth at or before the start of the call using a packet train 'a' will be quite sub-optimal for most cases, though if the value is low enough it won't be over-bandwidth. Some applications (games, etc) may want to limit the starting bandwidth to avoid negative interactions with other dataflows. 'b' has a problem that if the last call had a much higher bottleneck bandwidth (especially on the remote downstream), the new call may be over-bandwidth, perhaps badly. This won't be the norm, but may happen especially with mobile/wifi at either end. 'c' has a problem that if the last callee had a much higher bottleneck bandwidth (especially on the remote downstream), the new call may be over-bandwidth, perhaps badly. If the caller's upstream bandwidth is high compared to typical downstream bandwidth, then the likelihood of starting over-bandwidth is high. 'd' has the advantage of selecting an appropriate value regardless of whether the bottleneck is on upstream or downstream. The downside of 'd' is that the bottlenecks may have changed since the last call in which case we may start over-bandwidth. The historical data could be transferred via pre-call signalling. 'e' allows direct measurement of the current call bottlenecks. However 'e' can be misled if a mid-call router that isn't the bottleneck buffers the packet train while housekeeping or doing other operations and then releases them (it can collapse the signal from an earlier bottleneck). It would need to be combined with starting on the low side until a valid measurement is completed. Single measurements are imprecise with packet trains. Also, we need to consider the impact on other existing PeerConnections - for example, when you add a new person to a full-mesh conference, you'll want to start their bandwidth at about 1/Nth of the former total outgoing bandwidth, and reduce the outgoing bandwidth of those other channels to provide the bandwidth for the new participant. Obviously there is no obvious perfect solution, and combinations of solutions may give the best overall experience. In this situation, it makes sense to leave the actual choice up to the implementations or even the application, and make sure that they have the information needed to make the choice, such as the last-call bandwidth from the other end. (I don't believe that information would be a privacy leakage of any note.) Data channels: If we use SCTP-DTLS-UDP, we can rely on SCTP's congestion-control, perhaps modified to "play nice" with the media streams, and to have some amount of known priority relative to them. (For example, if the media streams need to back off and the data streams are using a consistent amount of data, it could reduce the amount or rate data is sent.) We also could pre-allocate some amount of bandwidth to data, and so long as it's not using it media could. Note that SCTP's congestion control is supposed to be in some manner pluggable, so we could modify/replace it fairly easily. Worst case: it acts as a separate, TCP-friendly flow we compete with. If we have to use TCP-over-UDP, then that will be congestion-controlled for each individual flow, but the non-reliable channels will need separate congestion control. Simplest would be to add RTP-like timestamps to the non-reliable data channels so they could pulled into the framework of the RTP channels as if they were bursty RTP data. Even if the data flows are separately congestion controlled, in many uses they will be non-continuous flows (discrete messages as opposed to data or file transfers). These sorts of channels have different needs and different impacts on the media channels from continuous flows: they're bursty; low delay is important (especially on the initial packet for a burst, which is often the only packet), and without a steady stream congestion control will have little effect - and will have little impact on the media flows. For small bursts of data traffic, the "right" solution may be to simply ignore them up to some limit, and above that limit start to subtract the data channel usage from the available bandwidth for variable-rate encoders. The problem here will be defining "small". This will need to be tested and simulated so we know the impacts of different data usage patterns. I'll throw a straw-man proposal out there: if the increase in data usage over the last 1/2 second is below 20% of the total estimated channel bandwidth, no adjustment to the media channels shall be done, and normal congestion control mechanisms will be allowed to operate with no interference. Above that value, the media channels if possible will be adjusted down in bandwidth by some amount related to the increase in data channel bandwidth. The reason for using the increase in bandwidth here is that for steady flows, normal congestion control should operate well; the problem is when you have a spike in bandwidth use - the latency in reaction may be longer than the duration of the burst, and hurt end-to-end delay in the meantime. So when there's a sudden jump in data bandwidth, you temporarily offset media down to keep delay and buffering under control. You could also increase media bitrates if a steady flow suddenly drops, though normal congestion control mechanisms should use the now-available bandwidth quickly on their own. JS Interface: We need to tell the application about bandwidth changes, and give it the option of making choices, both in the allocation of bits among the various streams of data, and of the actual streams themselves (adding or shutting down streams, or switching modes (mono/stereo, codecs possibly, etc)). If the application doesn't care to make a choice we'll do it for them. We'll also want the JS application to be able to affect the congestion-control status of the data channels, so it could take bits from the data channels without engendering a tug-of-war and temporary over-bandwidth/buffering. There are inherent delays to some of these actions by the app, and in an over-bandwidth case we need to reduce bandwidth *now*, so we may want to have the "I'm over-bandwidth" case start by automatically reducing bandwidth if possible, and inform the JS app of the reduction and let it rebalance or change the details or nature of the call. We could use some good straw-men proposals for an API here to the JS code. Security comes in slightly here in the avoidance-of-DoS issue. If we reduce bandwidth on a notification from the far side first, then tell the app, then even if the app goes rogue and hikes the bandwidth instead of dropping it we'll just cut it back again. We may need some extra levers and limits, but I think this is all handleable. Testing: We'll want to experiment with both real-world packet traces and with simulated scenarios, since as an active algorithm pure network traces only go so far when testing. We need to test with cross traffic on our side of the bottleneck going to the far side, traffic that stays on our side or stays on the other side, with appearance of new bottleneck nodes, with route changes in mid-call, interface changes, wireless, wireless-in-motion going into and out-of good signal range, competing traffic hosted by the same browser, etc. Extensions: Can we generalize this to provide guidance when we're receiving connections from multiple sources? This would be gated on knowing if the bottleneck is in a "shared" section of the path or not. (*Usually* bottlenecks are on upstream, but that might be changing.) -- Randell Jesup randell-ietf@jesup.org From csp@csperkins.org Thu Oct 6 15:08: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 0E4F11F0C6D for ; Thu, 6 Oct 2011 15:08:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.556 X-Spam-Level: X-Spam-Status: No, score=-103.556 tagged_above=-999 required=5 tests=[AWL=0.042, 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 FO6I2pzo0LBQ for ; Thu, 6 Oct 2011 15:08:12 -0700 (PDT) Received: from anchor-msapost-1.mail.demon.net (anchor-msapost-1.mail.demon.net [195.173.77.164]) by ietfa.amsl.com (Postfix) with ESMTP id CE5891F0C3B for ; Thu, 6 Oct 2011 15:08:11 -0700 (PDT) Received: from starkperkins.demon.co.uk ([80.176.158.71] helo=[192.168.0.30]) by anchor-post-1.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1RBw9y-0002Hc-i5; Thu, 06 Oct 2011 22:11:22 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-1047-329465388 From: Colin Perkins In-Reply-To: Date: Thu, 6 Oct 2011 23:11:21 +0100 Message-Id: <7F79D20D-42DF-49D0-8D2F-A11ACE3A87C8@csperkins.org> References: <545388B3-3189-4291-BD1D-52898B888F3E@phonefromhere.com> <4E8BC0ED.2020001@skype.net> <4E8BDC3B.7000501@skype.net> To: Roman Shpount X-Mailer: Apple Mail (2.1084) 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: Thu, 06 Oct 2011 22:08:13 -0000 --Apple-Mail-1047-329465388 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 5 Oct 2011, at 18:20, Roman Shpount wrote: > On Wed, Oct 5, 2011 at 7:00 AM, Neil Stratford = wrote: > I'm not sure I understand why this is such a problem. XMPP/Jingle = defines it's own mapping, which is a common VoIP protocol that is widely = supported. I'd much rather that the JS API is as expressive as possible = in codec specific matters - for example even to the point of providing = callbacks to the JS on certain codec level events, such as decoding a = DTMF digit. > =20 > What we need is some way to expose all possible codec parameter = combinations to JavaScript API. MMUSIC/PAYLOAD specifications for codec = typically define CODEC parameters and how they are encoded in SDP/MIME = content type, but they fall short of defining a way to list all the = capabilities. I'm not convinced that exposing all possible codec parameter = combinations is an appropriate goal. There is simply too much = flexibility present with many of the codecs, especially in combination, = for the signalling to be reasonable if all the flexibility is exposed. = Better, I think, for the browser to expose a set of known-reasonable = combinations, and parameter ranges, from which the most appropriate = choice is picked. > For instance, there is no way for SILK codec to specify valid bit = rates range for a given sampling rate. This means JavaScript would need = intimate knowledge of each codec implementation in the browser in order = to implement codec negotiation. If a different codec implementation is = provided by the browser (for instance SILK codec that supports more = restricted bit rates for the same sampling rate), JavaScript will not be = able to produce valid negotiation results. As far as I can see, there = are two possible solutions: better uniform description of codec = capabilities to JavaScript API or delegating at least some portion of = codec negotiation to actual codec implementation. >=20 > Again, if it's required I don't see why we can't support asymmetric = codecs in the low level API. In my view a lot of this codec manipulation = is much better controlled by the JS which has application specific = knowledge about how to adapt to given situations than the browser = itself. How would you signal to the browser to dynamically lower = framerate rather than image size, or colour depth depending on the = application use case? Giving the application direct control over codec = parameters seems a better option. >=20 > I believe in current API we provide one codec with one set of = parameters to the API. We should at least be able to provide two codec = groups -- one for transmit/another to receive, with two sets of = parameters. Even if we handle all the negotiations in JavaScript, we = should be able to provide the result for both directions to the stream = (may be with default value for the second codec group to be the same as = first since this is a much more common). > ______________ > Roman Shpount > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --=20 Colin Perkins http://csperkins.org/ --Apple-Mail-1047-329465388 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Wed, = Oct 5, 2011 at 7:00 AM, Neil Stratford <neils@belltower.co.uk>= wrote:
I'm not sure I understand why this is such a = problem. XMPP/Jingle defines it's own mapping, which is a common VoIP = protocol that is widely supported. I'd much rather that the JS API is as = expressive as possible in codec specific matters - for example even to = the point of providing callbacks to the JS on certain codec level = events, such as decoding a DTMF digit.
 
What we need is some way = to expose all possible codec parameter combinations to JavaScript API. = MMUSIC/PAYLOAD specifications for codec typically define CODEC = parameters and how they are encoded in SDP/MIME content type, but they = fall short of defining a way to list all the capabilities. =

I'm not convinced that exposing all = possible codec parameter combinations is an appropriate goal. There is = simply too much flexibility present with many of the codecs, especially = in combination, for the signalling to be reasonable if all the = flexibility is exposed. Better, I think, for the browser to expose a set = of known-reasonable combinations, and parameter ranges, from which the = most appropriate choice is picked.

For = instance, there is no way for SILK codec to specify valid bit rates = range for a given sampling rate. This means JavaScript would need = intimate knowledge of each codec implementation in the browser in order = to implement codec negotiation. If a different codec implementation is = provided by the browser (for instance SILK codec that supports more = restricted bit rates for the same sampling rate), JavaScript will not be = able to produce valid negotiation results. As far as I can see, there = are two possible solutions: better uniform description of codec = capabilities to JavaScript API or delegating at least some portion of = codec negotiation to actual codec implementation.

Again, if it's required I don't see why we can't support asymmetric codecs in=20= the low level API. In my view a lot of this codec manipulation is much=20= better controlled by the JS which has application specific knowledge=20 about how to adapt to given situations than the browser itself. How=20 would you signal to the browser to dynamically lower framerate rather=20 than image size, or colour depth depending on the application use case?=20= Giving the application direct control over codec parameters seems a=20 better option.

I believe in current API we provide one codec with one set of parameters to the API. We should at least be able to provide two codec groups --=20= one for transmit/another to receive, with two sets of parameters. Even=20= if we handle all the negotiations in JavaScript, we should be able to=20 provide the result for both directions to the stream (may be with=20 default value for the second codec group to be the same as first since=20= this is a much more common).
______________
Roman = Shpount
_______________________________________________
rtcweb mailing = list
rtcweb@ietf.org
https://www.ietf.or= g/mailman/listinfo/rtcweb



-- 
Colin Perkins



= --Apple-Mail-1047-329465388-- From wes@mti-systems.com Thu Oct 6 15:44: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 DC4FB21F8BAB for ; Thu, 6 Oct 2011 15:44:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T9ha7zbq48q6 for ; Thu, 6 Oct 2011 15:44:27 -0700 (PDT) Received: from omr6.networksolutionsemail.com (omr6.networksolutionsemail.com [205.178.146.56]) by ietfa.amsl.com (Postfix) with ESMTP id 4B1C721F8BA9 for ; Thu, 6 Oct 2011 15:44:27 -0700 (PDT) Received: from cm-omr8 (mail.networksolutionsemail.com [205.178.146.50]) by omr6.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id p96MlZPT011345 for ; Thu, 6 Oct 2011 18:47:38 -0400 Authentication-Results: cm-omr8 smtp.user=wes@mti-systems.com; auth=pass (PLAIN) X-Authenticated-UID: wes@mti-systems.com Received: from [184.244.4.16] ([184.244.4.16:45538] helo=[68.245.171.115]) by cm-omr8 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id CF/DA-24569-4003E8E4; Thu, 06 Oct 2011 18:47:35 -0400 Message-ID: <4E8E3005.3090307@mti-systems.com> Date: Thu, 06 Oct 2011 18:47:33 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4E8DCA06.5060506@jesup.org> In-Reply-To: <4E8DCA06.5060506@jesup.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Congestion Control 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, 06 Oct 2011 22:44:29 -0000 On 10/6/2011 11:32 AM, Randell Jesup wrote: > > Data channels: > > If we use SCTP-DTLS-UDP, we can rely on SCTP's congestion-control, perhaps > modified to "play nice" with the media streams, and to have some amount of > known priority relative to them. (For example, if the media streams need > to back off and the data streams are using a consistent amount of data, it > could reduce the amount or rate data is sent.) We also could pre-allocate > some amount of bandwidth to data, and so long as it's not using it media > could. Note that SCTP's congestion control is supposed to be in some > manner pluggable, so we could modify/replace it fairly easily. > > Worst case: it acts as a separate, TCP-friendly flow we compete with. > > If we have to use TCP-over-UDP, then that will be congestion-controlled for > each individual flow, but the non-reliable channels will need separate > congestion control. Simplest would be to add RTP-like timestamps to the > non-reliable data channels so they could pulled into the framework of the > RTP channels as if they were bursty RTP data. > > ... > > JS Interface: > > We need to tell the application about bandwidth changes, and give it the > option of making choices, both in the allocation of bits among the various > streams of data, and of the actual streams themselves (adding or shutting > down streams, or switching modes (mono/stereo, codecs possibly, etc)). If > the application doesn't care to make a choice we'll do it for them. We'll > also want the JS application to be able to affect the congestion-control > status of the data channels, so it could take bits from the data channels > without engendering a tug-of-war and temporary over-bandwidth/buffering. > I can't claim to fully understand the intended architecture from the description in this email, but something struck me as odd when in one breath it seems like data is flowing over TCP or SCTP (layered over UDP) and in another there's a separate algorithm (the Google one, or some modification) running for estimating bandwidth. Those seem mutually exclusive to me, unless I completely misunderstand the goal (which is entirely possible). Reporting changes to the application is another matter with its own challenges in either case, since the way the application responds will limit what the CC can do afterwards (without additional probing). If running TCP or SCTP, the congestion window (cwnd) and RTT should be sufficient to convey the available bandwidth at a point in time. If anything lower is reported to the app, the cwnd will never open up because it will be application-limited, and if anything higher is reported, it will build up a queue in the sender that won't be drained any faster than the cwnd allows. -- Wes Eddy MTI Systems From randell-ietf@jesup.org Thu Oct 6 16:13: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 AD28D21F877F for ; Thu, 6 Oct 2011 16:13:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.573 X-Spam-Level: X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=0.026, 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 qH8r9cSXGl1M for ; Thu, 6 Oct 2011 16:13:00 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 2A4C021F86EE for ; Thu, 6 Oct 2011 16:12:56 -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 1RBxAe-00019x-N3 for rtcweb@ietf.org; Thu, 06 Oct 2011 18:16:08 -0500 Message-ID: <4E8E35C4.3000509@jesup.org> Date: Thu, 06 Oct 2011 19:12: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: rtcweb@ietf.org References: <4E8DCA06.5060506@jesup.org> <4E8E3005.3090307@mti-systems.com> In-Reply-To: <4E8E3005.3090307@mti-systems.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] Congestion Control 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, 06 Oct 2011 23:13:00 -0000 Comments inline On 10/6/2011 6:47 PM, Wesley Eddy wrote: > On 10/6/2011 11:32 AM, Randell Jesup wrote: >> >> Data channels: >> >> If we use SCTP-DTLS-UDP, we can rely on SCTP's congestion-control, >> perhaps >> modified to "play nice" with the media streams, and to have some >> amount of >> known priority relative to them. (For example, if the media streams need >> to back off and the data streams are using a consistent amount of >> data, it >> could reduce the amount or rate data is sent.) We also could pre-allocate >> some amount of bandwidth to data, and so long as it's not using it media >> could. Note that SCTP's congestion control is supposed to be in some >> manner pluggable, so we could modify/replace it fairly easily. >> >> Worst case: it acts as a separate, TCP-friendly flow we compete with. >> >> If we have to use TCP-over-UDP, then that will be >> congestion-controlled for >> each individual flow, but the non-reliable channels will need separate >> congestion control. Simplest would be to add RTP-like timestamps to the >> non-reliable data channels so they could pulled into the framework of the >> RTP channels as if they were bursty RTP data. > > > > ... >> >> JS Interface: >> >> We need to tell the application about bandwidth changes, and give it the >> option of making choices, both in the allocation of bits among the >> various >> streams of data, and of the actual streams themselves (adding or shutting >> down streams, or switching modes (mono/stereo, codecs possibly, etc)). If >> the application doesn't care to make a choice we'll do it for them. We'll >> also want the JS application to be able to affect the congestion-control >> status of the data channels, so it could take bits from the data channels >> without engendering a tug-of-war and temporary over-bandwidth/buffering. >> > > > I can't claim to fully understand the intended architecture from the > description in this email, but something struck me as odd when in one > breath it seems like data is flowing over TCP or SCTP (layered over > UDP) and in another there's a separate algorithm (the Google one, or > some modification) running for estimating bandwidth. Those seem > mutually exclusive to me, unless I completely misunderstand the goal > (which is entirely possible). Well, I should note that the Google algorithm primarily estimates the buffer state of the bottleneck router, which indirectly is correlated to the bandwidth available at that instant. And TCP & the default SCTP congestion control are loss-based AIMD algorithms, so at any point may have a view of available bandwidth that is inflated (due to bufferbloat) or too low (in recovery from a loss event(s)). The fallback/simplest model would be to just consider the data channels under SCTP and the media channels to be separate flows, and let them fight for bandwidth as normal. If we can make them work together or at least be respectful of each other to avoid "fighting", that would be better. The app may be able to help us by indicated the type of data to be transferred and the relative priority of it. (Background file transfers might stick to a small percentage of the bandwidth unless bandwidth is very high; a game may give priority to one stream of data over both media and other data streams - it's unclear currently if we'll be able to support that, but it would be nice.) > Reporting changes to the application is another matter with its own > challenges in either case, since the way the application responds will > limit what the CC can do afterwards (without additional probing). > > If running TCP or SCTP, the congestion window (cwnd) and RTT should be > sufficient to convey the available bandwidth at a point in time. If > anything lower is reported to the app, the cwnd will never open up > because it will be application-limited, and if anything higher is > reported, it will build up a queue in the sender that won't be > drained any faster than the cwnd allows. Don't forget that we normally will have a media channel active, and if video is being sent (and to a lesser extent audio, especially if we're using Opus) that media channel is adaptive and can adapt upwards to find the limits of bandwidth. Involving the app is so that, if it wants, it can make more global decisions like "drop the second video stream", or "reduce the resolution", or "drop stereo", or "drop audio to narrowband to save bits for video". Decisions like that are tough or impossible for webrtc to make on it's own because it doesn't have the context of the application to guide it. That said, the interface and parameters and style for interacting with the JS app is the thing this posting is weakest on, since I'm not well-versed in the common API paradigms that JS app developers expect, and I'd love proposals for how we expose these choices and information to the app. -- Randell Jesup randell-ietf@jesup.org From ibc@aliax.net Thu Oct 6 18:46: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 0AC131F0C49 for ; Thu, 6 Oct 2011 18:46:17 -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.044, 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 snZNR7wVIPfl for ; Thu, 6 Oct 2011 18:46: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 486A31F0C47 for ; Thu, 6 Oct 2011 18:46:16 -0700 (PDT) Received: by vcbfo11 with SMTP id fo11so3443301vcb.31 for ; Thu, 06 Oct 2011 18:49:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.35.34 with SMTP id e2mr541514vdj.52.1317952167034; Thu, 06 Oct 2011 18:49:27 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Thu, 6 Oct 2011 18:49:26 -0700 (PDT) In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF510F14CE@sonusinmail02.sonusnet.com> References: <2E239D6FCD033C4BAF15F386A979BF510F1367@sonusinmail02.sonusnet.com> <4E8AC222.4050308@alvestrand.no> <2E239D6FCD033C4BAF15F386A979BF510F14CE@sonusinmail02.sonusnet.com> Date: Fri, 7 Oct 2011 03:49:26 +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] Review request for RTCWeb standard 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: Fri, 07 Oct 2011 01:46:17 -0000 2011/10/5 Ravindran Parthasarathi : > Sec 3 & 4 of the draft deals with the need and advantages for standard > signaling protocol. No >I understand your major concern is time. No, it's the proposal itself. Just you want it. > I think through > and provided some solution as part of the draft The solution is forgetting your wrong idea and stop ignoring replyins and rationale given to your *insistent* proposal. > 1)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Sec 5: =C2=A0(RTCWeb Protocol requiremen= t and design consideration) is > added to come up with the thump rules for standard signaling rather than > discussion different protocol And it's wrong (I will not repeat the arguments again). > 2)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Sec 6:=C2=A0 The list of existing signal= ing protocol is shown for > eliminating the signaling protocol based on Sec 5 conclusion Yes, let's use MEGACO, or H323, or ISUP. > In case time factor to solve this issue is the reason for rejecting this > proposal , let us work for the better way to reduce the timeframe to achi= eve > the result. That's not the point. --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Thu Oct 6 18: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 2C81A21F8B98 for ; Thu, 6 Oct 2011 18:54:19 -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.044, 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 1JVPCRlsWtvb for ; Thu, 6 Oct 2011 18:54:18 -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 7FA3221F8B95 for ; Thu, 6 Oct 2011 18:54:18 -0700 (PDT) Received: by vws5 with SMTP id 5so3451541vws.31 for ; Thu, 06 Oct 2011 18:57:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.184.103 with SMTP id et7mr570836vdc.35.1317952650465; Thu, 06 Oct 2011 18:57:30 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Thu, 6 Oct 2011 18:57:30 -0700 (PDT) In-Reply-To: <4E8D6507.8000707@ericsson.com> References: <4E8D6507.8000707@ericsson.com> Date: Fri, 7 Oct 2011 03:57:30 +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] Making progress on the signaling discussion (NB: Action items enclosed!) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2011 01:54:19 -0000 2011/10/6 Magnus Westerlund : > My interpretation of your draft is that it is a description of how you > can deploy SIP implemented in JS over websocket. Yes. > Thus enabling SIP > interworking when needed by having the JS SIP stack convert regular SIP > with SDP into interactions with the WEBRTC API. Yes. > Thus your proposal > really is primarily an argument that you don't need SIP implemented in > the browser, Of course, I don't want a SIP native stack in the browser, never. > as long as the API allows the JS to create SIP with SDP > messages. Not exactly. We generate the SIP messages in JS (without using a RTCweb API at all). We just need a RTCweb API to create a SDP object (maybe a JS object) so then I can generate the plain SDP using JavaScript (and XMPP/Jingle folks would generate a XML SDP). And we just need some way to tell the RTCweb stack from JS: "hey, I've received this SDP and I need you to tell me what do you think about it, parse it please, or ask me to previously convert it into a specific JS object and then I pass it to you". > Thus I would interpret this as something that could work both > over something similar to the current PeerConnection API proposals and a > more low level API. Where PeerConnection likely is less work as it does > provide the SDP that in most cases don't need modifications. Right. But this could occur regardless the signaling protocol chosen by each web application. At the end, Alice will receive (via HTTP/WebSocket) something like a SDP from Bob, and Alice must deal with that with the help of a JS RTCweb API. > Is this a correct interpretation and thus your draft is an extension > that simplifies life for the people who like SIP interworking by getting > the SIP functionality into the end-point rather than a gateway? Sure :) > Or is it something else? No, it's exactly that. > If it is the first I don't see your proposal as complete proposal for > how signaling for RTCWEB, as you still need APIs to something in some > form and with possibly certain semantics that interact with the SIP in > JS implementation. You are right. It's just a signaling proposal (not to make a standard signaling, not at all, but just a signaling example, in this case pure SIP). > To clarify, what I see the question for the WG is how the signalling > model for RTCWEB session establishment is intended to work. Thus the > drafts intended for answering this needs to be focused on describing a > signalling model. Yes, agreed. Regards. PS: SIP over WebSocket just works fine. A demonstration next week. --=20 I=C3=B1aki Baz Castillo From pravindran@sonusnet.com Thu Oct 6 23:09: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 D2D0621F85F2 for ; Thu, 6 Oct 2011 23:09:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.346 X-Spam-Level: X-Spam-Status: No, score=-2.346 tagged_above=-999 required=5 tests=[AWL=-0.047, 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 qWCqn5d3420V for ; Thu, 6 Oct 2011 23:09:43 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id ACBB421F8558 for ; Thu, 6 Oct 2011 23:09:42 -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 p976DOBL007870; Fri, 7 Oct 2011 02:13:24 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail05.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 7 Oct 2011 02:05: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="utf-8" Content-Transfer-Encoding: base64 Date: Fri, 7 Oct 2011 11:35:53 +0530 Message-ID: <2E239D6FCD033C4BAF15F386A979BF510F14FD@sonusinmail02.sonusnet.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] Review request for RTCWeb standard signaling protocol Thread-Index: AcyEk1tYliVhCpEoRA+pJSdigoRQKQAIPeyA References: <2E239D6FCD033C4BAF15F386A979BF510F1367@sonusinmail02.sonusnet.com><4E8AC222.4050308@alvestrand.no><2E239D6FCD033C4BAF15F386A979BF510F14CE@sonusinmail02.sonusnet.com> From: "Ravindran Parthasarathi" To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= X-OriginalArrivalTime: 07 Oct 2011 06:05:56.0962 (UTC) FILETIME=[2DD38420:01CC84B7] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Review request for RTCWeb standard 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: Fri, 07 Oct 2011 06:09:44 -0000 SW5ha2ksDQoNCkkgdW5kZXJzdGFuZCB0aGF0IHlvdSBkb24ndCB3YW50IGFueSBzaWduYWxpbmcg cHJvdG9jb2wgZm9yIFJUQ1dlYiAgdG8gYmUgc3RhbmRhcmRpemVkLiBJJ20gc3Ryb25nIGJlbGll dmVyIG9mICJzb21ldGhpbmcgaXMgYmV0dGVyIHRoYW4gbm90aGluZyIuIEFsc28sIE15IHN0YW5k YXJkIHNpZ25hbGluZyBwcm90b2NvbCBwcm9wb3NhbCBpcyBuZXZlciBhIGhpbmRyYW5jZSB0byB5 b3VyIGlubm92YXRpdmUgY3VzdG9tLWJ1aWxkIHNpZ25hbGluZyBwcm90b2NvbCAoU0lQIG92ZXIg d2Vic29ja2V0KSBkZXZlbG9wbWVudCBhbmQgdGhlIHN0YW5kYXJkIHNpZ25hbGluZyBwcm90b2Nv bCBpcyBub3QgbWVhbnQgZm9yIHlvdSBpbiBjYXNlIHlvdSBhcmUgYnVpbGRpbmcgY3VzdG9tLWJ1 aWxkIHNpZ25hbGluZyBwcm90b2NvbC4gDQoNCkZyb20gdGhlIFJUQ3dlYiBjbGllbnQgcHJvZ3Jh bW1lciBwZXJzcGVjdGl2ZSwgdGhlcmUgd2lsbCBiZSBhbiBzZXQgb2YgQVBJIGZvciBidWlsZGlu ZyBjdXN0b20gYnVpbGQgc2lnbmFsaW5nIGFuZCBhbm90aGVyIHRvcCBsZXZlbCBBUEkgd2hpY2gg aXMgYmFzZWQgb24gcHJvcG9zZWQgc3RhbmRhcmQgc2lnbmFsaW5nLiBJIGNvdWxkIG5vdCB1bmRl cnN0YW5kIHdoeSBhcmUgeW91IHNvIGFnYWluc3QgdGhlIHN0YW5kYXJkaXphdGlvbiBvZiB0aGUg c2lnbmFsaW5nIHByb3RvY29sLiANCg0KVGhhbmtzDQpQYXJ0aGEgIA0KDQo+LS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj5Gcm9tOiBJw7Fha2kgQmF6IENhc3RpbGxvIFttYWlsdG86aWJjQGFs aWF4Lm5ldF0NCj5TZW50OiBGcmlkYXksIE9jdG9iZXIgMDcsIDIwMTEgNzoxOSBBTQ0KPlRvOiBS YXZpbmRyYW4gUGFydGhhc2FyYXRoaQ0KPkNjOiBIYXJhbGQgQWx2ZXN0cmFuZDsgcnRjd2ViQGll dGYub3JnDQo+U3ViamVjdDogUmU6IFtydGN3ZWJdIFJldmlldyByZXF1ZXN0IGZvciBSVENXZWIg c3RhbmRhcmQgc2lnbmFsaW5nDQo+cHJvdG9jb2wNCj4NCj4yMDExLzEwLzUgUmF2aW5kcmFuIFBh cnRoYXNhcmF0aGkgPHByYXZpbmRyYW5Ac29udXNuZXQuY29tPjoNCj4+IFNlYyAzICYgNCBvZiB0 aGUgZHJhZnQgZGVhbHMgd2l0aCB0aGUgbmVlZCBhbmQgYWR2YW50YWdlcyBmb3Igc3RhbmRhcmQN Cj4+IHNpZ25hbGluZyBwcm90b2NvbC4NCj4NCj5Obw0KPg0KPg0KPj5JIHVuZGVyc3RhbmQgeW91 ciBtYWpvciBjb25jZXJuIGlzIHRpbWUuDQo+DQo+Tm8sIGl0J3MgdGhlIHByb3Bvc2FsIGl0c2Vs Zi4gSnVzdCB5b3Ugd2FudCBpdC4NCj4NCj4NCj4+IEkgdGhpbmsgdGhyb3VnaA0KPj4gYW5kIHBy b3ZpZGVkIHNvbWUgc29sdXRpb24gYXMgcGFydCBvZiB0aGUgZHJhZnQNCj4NCj5UaGUgc29sdXRp b24gaXMgZm9yZ2V0dGluZyB5b3VyIHdyb25nIGlkZWEgYW5kIHN0b3AgaWdub3JpbmcgcmVwbHlp bnMNCj5hbmQgcmF0aW9uYWxlIGdpdmVuIHRvIHlvdXIgKmluc2lzdGVudCogcHJvcG9zYWwuDQo+ DQo+DQo+DQo+PiAxKcKgwqDCoMKgwqAgU2VjIDU6IMKgKFJUQ1dlYiBQcm90b2NvbCByZXF1aXJl bWVudCBhbmQgZGVzaWduIGNvbnNpZGVyYXRpb24pDQo+aXMNCj4+IGFkZGVkIHRvIGNvbWUgdXAg d2l0aCB0aGUgdGh1bXAgcnVsZXMgZm9yIHN0YW5kYXJkIHNpZ25hbGluZyByYXRoZXINCj50aGFu DQo+PiBkaXNjdXNzaW9uIGRpZmZlcmVudCBwcm90b2NvbA0KPg0KPkFuZCBpdCdzIHdyb25nIChJ IHdpbGwgbm90IHJlcGVhdCB0aGUgYXJndW1lbnRzIGFnYWluKS4NCj4NCj4NCj4+IDIpwqDCoMKg wqDCoCBTZWMgNjrCoCBUaGUgbGlzdCBvZiBleGlzdGluZyBzaWduYWxpbmcgcHJvdG9jb2wgaXMg c2hvd24gZm9yDQo+PiBlbGltaW5hdGluZyB0aGUgc2lnbmFsaW5nIHByb3RvY29sIGJhc2VkIG9u IFNlYyA1IGNvbmNsdXNpb24NCj4NCj5ZZXMsIGxldCdzIHVzZSBNRUdBQ08sIG9yIEgzMjMsIG9y IElTVVAuDQo+DQo+DQo+PiBJbiBjYXNlIHRpbWUgZmFjdG9yIHRvIHNvbHZlIHRoaXMgaXNzdWUg aXMgdGhlIHJlYXNvbiBmb3IgcmVqZWN0aW5nDQo+dGhpcw0KPj4gcHJvcG9zYWwgLCBsZXQgdXMg d29yayBmb3IgdGhlIGJldHRlciB3YXkgdG8gcmVkdWNlIHRoZSB0aW1lZnJhbWUgdG8NCj5hY2hp ZXZlDQo+PiB0aGUgcmVzdWx0Lg0KPg0KPlRoYXQncyBub3QgdGhlIHBvaW50Lg0KPg0KPg0KPi0t DQo+ScOxYWtpIEJheiBDYXN0aWxsbw0KPjxpYmNAYWxpYXgubmV0Pg0K From tim@phonefromhere.com Fri Oct 7 03:20: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 D997D21F8AF7 for ; Fri, 7 Oct 2011 03:20:39 -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.102, 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 TO2wrueeooPH for ; Fri, 7 Oct 2011 03:20: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 E297021F8AB9 for ; Fri, 7 Oct 2011 03:20:34 -0700 (PDT) Received: from [192.168.0.14] (unknown [93.89.81.113]) by zimbra.westhawk.co.uk (Postfix) with ESMTP id 0B49F37A903; Fri, 7 Oct 2011 11:36:35 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Tim Panton In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF510F14FD@sonusinmail02.sonusnet.com> Date: Fri, 7 Oct 2011 11:23:41 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <393F1888-F834-4DAE-B6B1-1C5D35EE3292@phonefromhere.com> References: <2E239D6FCD033C4BAF15F386A979BF510F1367@sonusinmail02.sonusnet.com><4E8AC222.4050308@alvestrand.no><2E239D6FCD033C4BAF15F386A979BF510F14CE@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF510F14FD@sonusinmail02.sonusnet.com> To: Ravindran Parthasarathi X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Review request for RTCWeb standard 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: Fri, 07 Oct 2011 10:20:40 -0000 On 7 Oct 2011, at 07:05, Ravindran Parthasarathi wrote: > Inaki, >=20 > I understand that you don't want any signaling protocol for RTCWeb to = be standardized. I'm strong believer of "something is better than = nothing". Also, My standard signaling protocol proposal is never a = hindrance to your innovative custom-build signaling protocol (SIP over = websocket) development and the standard signaling protocol is not meant = for you in case you are building custom-build signaling protocol.=20 >=20 > =46rom the RTCweb client programmer perspective, there will be an set = of API for building custom build signaling and another top level API = which is based on proposed standard signaling. I could not understand = why are you so against the standardization of the signaling protocol.=20 Because it is a distraction. It is unnecessary, the advantages don't = outweigh the disadvantages. It isn't essential to the success of this effort and would slow us down = by _years_ debating the details. Even if we could magically all instantly agree to use (say) RFC 5456 as = the standard (*) , it would then immediately impact the=20 core effort, the temptation to add features and helper methods to the = core media API that suited the 'standard' signalling protocol would be irresistible. Pretty soon we'd find we had a media layer that = could _only_ work well through the standard signalling protocol. Tim. (*) In my view no one of the currently available signalling protocols = are suitable for this effort. They were all designed with=20 a totally different set of constraints to the ones faced by rtcweb.=20 T.= From samu60@gmail.com Fri Oct 7 03:27: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 B8B7F21F8A6C for ; Fri, 7 Oct 2011 03:27:34 -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 3My8FSHrN88E for ; Fri, 7 Oct 2011 03:27:34 -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 B84A421F88B6 for ; Fri, 7 Oct 2011 03:27:33 -0700 (PDT) Received: by qyk32 with SMTP id 32so346961qyk.10 for ; Fri, 07 Oct 2011 03:30:46 -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=GjZ/9kyY24ZHSjQV7eKoe+xwfpX9HqX8ivzDTr9QNYc=; b=YGgYA0gqwTIp04NgK20c+4aUfBdvn2rcbGB8eQuOs24ElcEwFluQOvmhclmfV7wKvk eFky4sMRJUoB5Tzav9+U9ombgJJtBg+n8GfvnLM5lTa5awOrNWHa6lz0x0EHH1MQdXVT DzAj/w4BuUcYL6hq9oTj6pyUQTkLLyl9D0rDM= MIME-Version: 1.0 Received: by 10.229.241.135 with SMTP id le7mr1388669qcb.149.1317983444981; Fri, 07 Oct 2011 03:30:44 -0700 (PDT) Received: by 10.229.40.68 with HTTP; Fri, 7 Oct 2011 03:30:44 -0700 (PDT) In-Reply-To: <393F1888-F834-4DAE-B6B1-1C5D35EE3292@phonefromhere.com> References: <2E239D6FCD033C4BAF15F386A979BF510F1367@sonusinmail02.sonusnet.com> <4E8AC222.4050308@alvestrand.no> <2E239D6FCD033C4BAF15F386A979BF510F14CE@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF510F14FD@sonusinmail02.sonusnet.com> <393F1888-F834-4DAE-B6B1-1C5D35EE3292@phonefromhere.com> Date: Fri, 7 Oct 2011 12:30:44 +0200 Message-ID: From: samuel To: Tim Panton Content-Type: multipart/alternative; boundary=001485ea86b60ed67a04aeb2efc8 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Review request for RTCWeb standard 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: Fri, 07 Oct 2011 10:27:34 -0000 --001485ea86b60ed67a04aeb2efc8 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all, The point I=F1aki is pushing forward is crucial, as Tim also stated, becaus= e it will save us the burden of implementing another protocol, the marketing fight between protocols (do you want another SIP vs. H323 "war"?) Please, don't reinvent the wheel, keep it simple. Best regards, Samuel On 7 October 2011 12:23, Tim Panton wrote: > > On 7 Oct 2011, at 07:05, Ravindran Parthasarathi wrote: > > > Inaki, > > > > I understand that you don't want any signaling protocol for RTCWeb to = be > standardized. I'm strong believer of "something is better than nothing". > Also, My standard signaling protocol proposal is never a hindrance to you= r > innovative custom-build signaling protocol (SIP over websocket) developme= nt > and the standard signaling protocol is not meant for you in case you are > building custom-build signaling protocol. > > > > From the RTCweb client programmer perspective, there will be an set of > API for building custom build signaling and another top level API which i= s > based on proposed standard signaling. I could not understand why are you = so > against the standardization of the signaling protocol. > > Because it is a distraction. It is unnecessary, the advantages don't > outweigh the disadvantages. > > It isn't essential to the success of this effort and would slow us down b= y > _years_ debating the details. > > Even if we could magically all instantly agree to use (say) RFC 5456 as t= he > standard (*) , it would then immediately impact the > core effort, the temptation to add features and helper methods to the cor= e > media API that suited the 'standard' signalling protocol > would be irresistible. Pretty soon we'd find we had a media layer that > could _only_ work well through the standard signalling protocol. > > Tim. > > (*) In my view no one of the currently available signalling protocols are > suitable for this effort. They were all designed with > a totally different set of constraints to the ones faced by rtcweb. > > T. > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --001485ea86b60ed67a04aeb2efc8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all,

The point I=F1aki is pushing forward is crucial, as Tim also= stated, because it will save us the burden of implementing another protoco= l, the marketing fight between protocols (do you want another SIP vs. H323 = "war"?) Please, don't reinvent the wheel, keep it simple.

Best regards,

Samuel

On 7 Octo= ber 2011 12:23, Tim Panton <tim@phonefromhere.com> wrote:

On 7 Oct 2011, at 07:05, Ravindran Parthasarathi wrote:

> Inaki,
>
> I understand that you don't want any signaling protocol for RTCWeb= =A0to be standardized. I'm strong believer of "something is bette= r than nothing". Also, My standard signaling protocol proposal is neve= r a hindrance to your innovative custom-build signaling protocol (SIP over = websocket) development and the standard signaling protocol is not meant for= you in case you are building custom-build signaling protocol.
>
> From the RTCweb client programmer perspective, there will be an set of= API for building custom build signaling and another top level API which is= based on proposed standard signaling. I could not understand why are you s= o against the standardization of the signaling protocol.

Because it is a distraction. It is unnecessary, the advantages don= 9;t outweigh the disadvantages.

It isn't essential to the success of this effort and would slow us down= by _years_ debating the details.

Even if we could magically all instantly agree to use (say) RFC 5456 as the= standard (*) , it would then immediately impact the
core effort, the temptation to add features and helper methods to the core = media API that suited the 'standard' signalling protocol
would be irresistible. Pretty soon we'd find we had a media layer that = could _only_ work well through the standard signalling protocol.

Tim.

(*) In my view no one of the currently available signalling protocols are s= uitable for this effort. They were all designed with
a totally different set of constraints to the ones faced by rtcweb.

T.
__________________________________= _____________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb

--001485ea86b60ed67a04aeb2efc8-- From pravindran@sonusnet.com Fri Oct 7 03: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 B949021F84DC for ; Fri, 7 Oct 2011 03:37:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[AWL=0.103, 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 2pWdTRxj+Ib8 for ; Fri, 7 Oct 2011 03:37:21 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id C011721F84D9 for ; Fri, 7 Oct 2011 03:37:20 -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 p97Af3ke020368; Fri, 7 Oct 2011 06:41:03 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail07.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 7 Oct 2011 06:36: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_01CC84DC.F5ED0B41" Date: Fri, 7 Oct 2011 16:06:22 +0530 Message-ID: <2E239D6FCD033C4BAF15F386A979BF510F152B@sonusinmail02.sonusnet.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] Review request for RTCWeb standard signaling protocol Thread-Index: AcyE3C+SnY6tf2ujRza4OzYU8jzKwgAAHS6g References: <2E239D6FCD033C4BAF15F386A979BF510F1367@sonusinmail02.sonusnet.com><4E8AC222.4050308@alvestrand.no><2E239D6FCD033C4BAF15F386A979BF510F14CE@sonusinmail02.sonusnet.com><2E239D6FCD033C4BAF15F386A979BF510F14FD@sonusinmail02.sonusnet.com><393F1888-F834-4DAE-B6B1-1C5D35EE3292@phonefromhere.com> From: "Ravindran Parthasarathi" To: "samuel" , "Tim Panton" X-OriginalArrivalTime: 07 Oct 2011 10:36:27.0201 (UTC) FILETIME=[F7CD7310:01CC84DC] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Review request for RTCWeb standard 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: Fri, 07 Oct 2011 10:37:21 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC84DC.F5ED0B41 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Tim, =20 Your argument is "Time to market" RTCWeb compliance and few folks = already mentioned about it and also proposing to develop the new = protocol. =20 At this moment, I don't think that there is a need for developing new = signaling protocol for RTCweb. IMO, The argument may be which is best = suitable rather than none of the protocol is suitable.=20 =20 Sam, =20 In case your proposal is not to invent new protocol for RTCWeb = signaling. Please look at my draft which is in the same line. =20 Thanks Partha =20 From: samuel [mailto:samu60@gmail.com]=20 Sent: Friday, October 07, 2011 4:01 PM To: Tim Panton Cc: Ravindran Parthasarathi; rtcweb@ietf.org Subject: Re: [rtcweb] Review request for RTCWeb standard signaling = protocol =20 Hi all, The point I=F1aki is pushing forward is crucial, as Tim also stated, = because it will save us the burden of implementing another protocol, the = marketing fight between protocols (do you want another SIP vs. H323 = "war"?) Please, don't reinvent the wheel, keep it simple. Best regards, Samuel On 7 October 2011 12:23, Tim Panton wrote: On 7 Oct 2011, at 07:05, Ravindran Parthasarathi wrote: > Inaki, > > I understand that you don't want any signaling protocol for RTCWeb to = be standardized. I'm strong believer of "something is better than = nothing". Also, My standard signaling protocol proposal is never a = hindrance to your innovative custom-build signaling protocol (SIP over = websocket) development and the standard signaling protocol is not meant = for you in case you are building custom-build signaling protocol. > > From the RTCweb client programmer perspective, there will be an set of = API for building custom build signaling and another top level API which = is based on proposed standard signaling. I could not understand why are = you so against the standardization of the signaling protocol. Because it is a distraction. It is unnecessary, the advantages don't = outweigh the disadvantages. It isn't essential to the success of this effort and would slow us down = by _years_ debating the details. Even if we could magically all instantly agree to use (say) RFC 5456 as = the standard (*) , it would then immediately impact the core effort, the temptation to add features and helper methods to the = core media API that suited the 'standard' signalling protocol would be irresistible. Pretty soon we'd find we had a media layer that = could _only_ work well through the standard signalling protocol. Tim. (*) In my view no one of the currently available signalling protocols = are suitable for this effort. They were all designed with a totally different set of constraints to the ones faced by rtcweb. T. _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb =20 ------_=_NextPart_001_01CC84DC.F5ED0B41 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Tim,

 

Your argument is "Time to market" = RTCWeb compliance and few folks already mentioned about it and also proposing = to develop the new protocol.

 

At this moment, I don't think that there is a = need for developing new signaling protocol for RTCweb. IMO, The argument may be = which is best suitable rather than none of the protocol is suitable. =

 

Sam,

 

In case your proposal is not to invent new = protocol for RTCWeb signaling.=A0 Please look at my draft which is in the same = line.

 

Thanks

Partha

 

From:= samuel [mailto:samu60@gmail.com]
Sent: Friday, October 07, 2011 4:01 PM
To: Tim Panton
Cc: Ravindran Parthasarathi; rtcweb@ietf.org
Subject: Re: [rtcweb] Review request for RTCWeb standard = signaling protocol

 

Hi all,

The point I=F1aki is pushing forward is crucial, as Tim also stated, = because it will save us the burden of implementing another protocol, the marketing = fight between protocols (do you want another SIP vs. H323 "war"?) = Please, don't reinvent the wheel, keep it simple.

Best regards,

Samuel

On 7 October 2011 12:23, Tim Panton <tim@phonefromhere.com> = wrote:


On 7 Oct 2011, at 07:05, Ravindran Parthasarathi wrote:

> Inaki,
>
> I understand that you don't want any signaling protocol for RTCWeb  to be standardized. I'm strong believer of "something is = better than nothing". Also, My standard signaling protocol proposal is never a hindrance to your innovative custom-build signaling protocol (SIP over websocket) development and the standard signaling protocol is not meant = for you in case you are building custom-build signaling protocol.
>
> From the RTCweb client programmer perspective, there will be an set = of API for building custom build signaling and another top level API which is = based on proposed standard signaling. I could not understand why are you so = against the standardization of the signaling protocol.

Because it is a distraction. It is unnecessary, the advantages don't outweigh the disadvantages.

It isn't essential to the success of this effort and would slow us down = by _years_ debating the details.

Even if we could magically all instantly agree to use (say) RFC 5456 as = the standard (*) , it would then immediately impact the
core effort, the temptation to add features and helper methods to the = core media API that suited the 'standard' signalling protocol
would be irresistible. Pretty soon we'd find we had a media layer that = could _only_ work well through the standard signalling protocol.

Tim.

(*) In my view no one of the currently available signalling protocols = are suitable for this effort. They were all designed with
a totally different set of constraints to the ones faced by rtcweb.

T.

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

 

------_=_NextPart_001_01CC84DC.F5ED0B41-- From keith.drage@alcatel-lucent.com Fri Oct 7 03:43: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 B581A21F8A35 for ; Fri, 7 Oct 2011 03:43:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.853 X-Spam-Level: X-Spam-Status: No, score=-105.853 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 y5ADrYkgwVyr for ; Fri, 7 Oct 2011 03:43:19 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [62.23.212.57]) by ietfa.amsl.com (Postfix) with ESMTP id 4CA9B21F88B6 for ; Fri, 7 Oct 2011 03:43:16 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p97AiU13006424 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 7 Oct 2011 12:46:26 +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, 7 Oct 2011 12:46:19 +0200 From: "DRAGE, Keith (Keith)" To: =?iso-8859-1?Q?Stefan_H=E5kansson?= , "Markus.Isomaki@nokia.com" Date: Fri, 7 Oct 2011 12:46:17 +0200 Thread-Topic: [rtcweb] Future requirement: RTC-Web apps must work through interface switching Thread-Index: AcyELrJcJEPtOXbTSYyDYS5GDAfcqgArzqLw Message-ID: References: <4E89AD52.5000402@ericsson.com> <4E8DB1A5.1000800@ericsson.com> In-Reply-To: <4E8DB1A5.1000800@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-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Future requirement: RTC-Web apps must work through interface switching X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2011 10:43:21 -0000 > I agree. For the time being, the requirement is on a higher=20 > level - and quite badly phrased (I'm to blame): > "It MUST be possible to move from one network interface to=20 > another one" > I think it can be better put, and later when the model is=20 > decided it can be broken down (e.g to an event in the API). > When people end up phrasing something as "It MUST be possible... " what t= hey normally mean is: "The mechanism MUST support ..." Rather than "Implementations MUST support ..." Or, else some form of use requirement. But choose which you want. Regards Keith=20 > -----Original Message----- > From: rtcweb-bounces@ietf.org=20 > [mailto:rtcweb-bounces@ietf.org] On Behalf Of Stefan H=E5kansson > Sent: 06 October 2011 14:48 > To: Markus.Isomaki@nokia.com > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] Future requirement: RTC-Web apps must=20 > work through interface switching >=20 > On 10/06/2011 03:04 PM, Markus.Isomaki@nokia.com wrote: > > Hi Stefan, > > > > Stefan H=E5kansson wrote: > >> > >> in terms of use case and reqs, do you see anything missing if you=20 > >> look at > >> >> requirements/>, section 4.2.3? > >> > >> In terms of technology I thought ICE would be able to handle this. > >> > > > > I agree ICE has the mechanisms to handle it to some extent, as new=20 > > candidates can be added on-the-fly, e.g. when a device gets=20 > a new IP=20 > > address via a newly connected interface. I guess the minimum=20 > > requirement is that the entity generationg the ICE=20 > signaling messages=20 > > needs to be able to learn about the existence of the new candidates=20 > > immediately, so it can generate the new ICE "offer". I'm not sure=20 > > where this is supposed to happen, but if it is the JS app=20 > that sends=20 > > the "offers", there is a requirement that there needs to be=20 > an event=20 > > in the API indicating that the set of local candidates has changed. >=20 > I agree. For the time being, the requirement is on a higher=20 > level - and quite badly phrased (I'm to blame): > "It MUST be possible to move from one network interface to=20 > another one" > I think it can be better put, and later when the model is=20 > decided it can be broken down (e.g to an event in the API). >=20 > Stefan >=20 > > > > Markus > > > > > >> On 10/03/2011 01:58 PM, Markus.Isomaki@nokia.com wrote: > >>> Hi all, > >>> > >>> There is one important requirement, which may not be=20 > critical today,=20 > >>> but will > >> most likely be in the future. > >>> > >>> We can assume RTC-Web to be supported in devices like=20 > tablets, pads=20 > >>> or > >> smartphones, that people carry around. We can also assume=20 > that when=20 > >> such devices are carried around, their point of attachement to the=20 > >> Internet will change, even so that the type of access network will=20 > >> change, typically between something like HSPA/LTE and Wi-Fi. Today=20 > >> this will always mean a change of IP address as well. In=20 > the future=20 > >> we may have technologies such as (Proxy)Mobile IP in use that will=20 > >> provide IP address preservation, but we can't really count on that. > >>> > >>> How does this relate to RTC-Web? Interface switching=20 > usually happens=20 > >>> at the discretion of the OS or some kind of connection=20 > manager. The=20 > >>> browser or the web application environment has no control=20 > over it.=20 > >>> At best it, or the JS application running within, can get=20 > some kind=20 > >>> of signal of such event happening. For TCP-based client-server=20 > >>> things (HTTP, Websocket) it is possible to react to this by=20 > >>> re-establishing the lost TCP connections and state on top=20 > of them.=20 > >>> This is indeed what many (native) apps are able to do=20 > today. There=20 > >>> can be some smarter ways in the pipeline as well, such as=20 > multipath=20 > >>> TCP, which would make the process of "transitioning" a TCP=20 > >>> connection from one interface/IP to another potentially=20 > transparent=20 > >>> to the application. But with peer-to-peer and interactive=20 > real-time,=20 > >>> things get more complicated. It may of course be that the=20 > switching=20 > >>> happens due to a sudden loss of coverage and is so slow,=20 > that voice=20 > >>> or video calls are broken anyway. However, in many cases th > >> e > >>> old interface can be up while the new one is being=20 > established, and=20 > >>> in > >> principle the total loss of connectivity can be avoided. In such=20 > >> scenarios it would be realistically possible to update the ongoing=20 > >> real-time sessions to a new IP address and port, if there=20 > were some=20 > >> kind of end-to-end or server- assisted mechanism for it.=20 > Even a cut=20 > >> of 1-2 seconds would not be as bad as a total loss of the session. > >>> > >>> What does this mean in terms of requirements? - The first-order=20 > >>> requirement is that the browser and/or the JS app, > >> whoever needs to act, has to be able to get events of interface=20 > >> switching in the same way as native apps can. If it were only the=20 > >> browser who was required to get them, we could set=20 > standards aside,=20 > >> and declare that the browser does this as any other app.=20 > But if it is=20 > >> the JS app that needs to do something, then we may need=20 > something new=20 > >> as a JS API. I have no clue at the moment if the JS apps can learn=20 > >> about this kind of events. And this is clearly not a=20 > RTC-Web specific=20 > >> requirement, but a generic one. I do know that browsers or HTTP=20 > >> libraries can re-send requests etc. based on IP address=20 > change, but I=20 > >> don't know what a JS Websocket client can do, if anything. > >>> - The second requirement is that the media related APIs and=20 > >>> transport > >> protocols (RTP) have to be flexible enough, that they can=20 > at least be=20 > >> extended to work so that they do not assume that the session is=20 > >> forever bound to a certain IP address/port in either end. How this=20 > >> affects the system depends on what is actually standardized, for=20 > >> instance if the SDP offer/answer model is included or not.=20 > But on the=20 > >> generic level it could be something like this: > >>> - If the browser/JS app receives signaling/offer from its=20 > peer that > >> peer's RTP/UDP IP address/port has changed, it has to be=20 > able to set=20 > >> these through the media API and re-run STUN checks or whatever is=20 > >> required at that point. This has to be work so that the=20 > media session=20 > >> can be otherwise continued, after the process is completed. > >>> - If the browser/JS app receives an event that its own IP=20 > >>> address/port > >> has changed (or is about to change), it has to be able to=20 > >> re-initialize the RTP/UDP accordingly, re-establish its "signaling=20 > >> connection and state" with its webserver, notify the peer=20 > about the=20 > >> change, and re-run STUN checks etc. as needed. > >>> > >>> This sounds quite complicated so it may be that we don't=20 > want to add=20 > >>> this as > >> a Day 1 requirement for RTC-Web. But I believe we should try to=20 > >> design the APIs and protocols in such a way that this kind=20 > of thing=20 > >> can be added later on. There could be other ways too, like MPRTP=20 > >> (http://datatracker.ietf.org/doc/draft-singh-avtcore-mprtp/), we=20 > >> could look at. > >>> > >>> I suppose the less we standardize about the signaling and=20 > >>> offer/answer, the > >> easier it might be to support these kinds of things as add-on. But=20 > >> whatever we standardize, please keep the interface and IP address=20 > >> change in mind. The outcome could be that we declare that=20 > transport=20 > >> (MPTCP, MPRTP) has to deal with it, but eventually I think=20 > this will=20 > >> have to work one way or the other. > >>> > >>> Regards, Markus _______________________________________________ > >>> rtcweb mailing list rtcweb@ietf.org > >>> https://www.ietf.org/mailman/listinfo/rtcweb > >> > >> > >> _______________________________________________ rtcweb=20 > mailing list=20 > >> rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > = From ibc@aliax.net Fri Oct 7 03: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 74EB821F8AD3 for ; Fri, 7 Oct 2011 03:46:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.333 X-Spam-Level: X-Spam-Status: No, score=-2.333 tagged_above=-999 required=5 tests=[AWL=-0.256, 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 3HusW6tvSqts for ; Fri, 7 Oct 2011 03:46: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 DC1F621F891D for ; Fri, 7 Oct 2011 03:46:15 -0700 (PDT) Received: by vws5 with SMTP id 5so3726381vws.31 for ; Fri, 07 Oct 2011 03:49:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.35.34 with SMTP id e2mr1933594vdj.52.1317984568867; Fri, 07 Oct 2011 03:49:28 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Fri, 7 Oct 2011 03:49:28 -0700 (PDT) In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF510F152B@sonusinmail02.sonusnet.com> References: <2E239D6FCD033C4BAF15F386A979BF510F1367@sonusinmail02.sonusnet.com> <4E8AC222.4050308@alvestrand.no> <2E239D6FCD033C4BAF15F386A979BF510F14CE@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF510F14FD@sonusinmail02.sonusnet.com> <393F1888-F834-4DAE-B6B1-1C5D35EE3292@phonefromhere.com> <2E239D6FCD033C4BAF15F386A979BF510F152B@sonusinmail02.sonusnet.com> Date: Fri, 7 Oct 2011 12:49:28 +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] Review request for RTCWeb standard 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: Fri, 07 Oct 2011 10:46:16 -0000 2011/10/7 Ravindran Parthasarathi : > Your argument is "Time to market" RTCWeb compliance and few folks already > mentioned about it and also proposing to develop the new protocol. And *lot* of folks already mentioned that your proposal is bad for WebRTC, but you don't say that. You still continue ignoring arguments and persons you cannot reply. Tim's argument is not just about "Time to market". Anyone reading his mail would also read the third paragraph (which you intentionally ignore now, of course, as you always do). > At this moment, I don't think that there is a need for developing new > signaling protocol for RTCweb. IMO, The argument may be which is best > suitable rather than none of the protocol is suitable. Please, don't try to distract this WG for achieving your goals. There is not, and there will not be, a discussion/debate about which one is the "best default and *mandatory* signaling protocol". > In case your proposal is not to invent new protocol for RTCWeb signaling. > Please look at my draft which is in the same line. Sure, your draft is just any of your mails copy&pasted into a draft. --=20 I=C3=B1aki Baz Castillo From pravindran@sonusnet.com Fri Oct 7 03:48: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 35F2921F8B07 for ; Fri, 7 Oct 2011 03:48:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.047 X-Spam-Level: X-Spam-Status: No, score=-2.047 tagged_above=-999 required=5 tests=[AWL=-0.348, BAYES_00=-2.599, J_CHICKENPOX_46=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 3tj33VGL5ND6 for ; Fri, 7 Oct 2011 03:48:34 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 5F81421F8B00 for ; Fri, 7 Oct 2011 03:48:34 -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 p97AqJCr027358; Fri, 7 Oct 2011 06:52:19 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail04.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 7 Oct 2011 06:51:39 -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: Fri, 7 Oct 2011 16:21:36 +0530 Message-ID: <2E239D6FCD033C4BAF15F386A979BF510F152D@sonusinmail02.sonusnet.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] Review request for RTCWeb standard signaling protocol Thread-Index: AcyE3swqNGgbPZS6RO2Ek/94xJaBugAAD5eQ References: <2E239D6FCD033C4BAF15F386A979BF510F1367@sonusinmail02.sonusnet.com><4E8AC222.4050308@alvestrand.no><2E239D6FCD033C4BAF15F386A979BF510F14CE@sonusinmail02.sonusnet.com><2E239D6FCD033C4BAF15F386A979BF510F14FD@sonusinmail02.sonusnet.com><393F1888-F834-4DAE-B6B1-1C5D35EE3292@phonefromhere.com><2E239D6FCD033C4BAF15F386A979BF510F152B@sonusinmail02.sonusnet.com> From: "Ravindran Parthasarathi" To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= X-OriginalArrivalTime: 07 Oct 2011 10:51:39.0700 (UTC) FILETIME=[17B1BF40:01CC84DF] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Review request for RTCWeb standard 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: Fri, 07 Oct 2011 10:48:35 -0000 TGV0IHVzIGRlYmF0ZSBvbiB0aGUgUlRDV2ViIHNpZ25hbGluZyBtZWV0aW5nDQoNClRoYW5rcw0K UGFydGhhDQoNCj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPkZyb206IEnDsWFraSBCYXog Q2FzdGlsbG8gW21haWx0bzppYmNAYWxpYXgubmV0XQ0KPlNlbnQ6IEZyaWRheSwgT2N0b2JlciAw NywgMjAxMSA0OjE5IFBNDQo+VG86IFJhdmluZHJhbiBQYXJ0aGFzYXJhdGhpDQo+Q2M6IHNhbXVl bDsgVGltIFBhbnRvbjsgcnRjd2ViQGlldGYub3JnDQo+U3ViamVjdDogUmU6IFtydGN3ZWJdIFJl dmlldyByZXF1ZXN0IGZvciBSVENXZWIgc3RhbmRhcmQgc2lnbmFsaW5nDQo+cHJvdG9jb2wNCj4N Cj4yMDExLzEwLzcgUmF2aW5kcmFuIFBhcnRoYXNhcmF0aGkgPHByYXZpbmRyYW5Ac29udXNuZXQu Y29tPjoNCj4+IFlvdXIgYXJndW1lbnQgaXMgIlRpbWUgdG8gbWFya2V0IiBSVENXZWIgY29tcGxp YW5jZSBhbmQgZmV3IGZvbGtzDQo+YWxyZWFkeQ0KPj4gbWVudGlvbmVkIGFib3V0IGl0IGFuZCBh bHNvIHByb3Bvc2luZyB0byBkZXZlbG9wIHRoZSBuZXcgcHJvdG9jb2wuDQo+DQo+QW5kICpsb3Qq IG9mIGZvbGtzIGFscmVhZHkgbWVudGlvbmVkIHRoYXQgeW91ciBwcm9wb3NhbCBpcyBiYWQgZm9y DQo+V2ViUlRDLCBidXQgeW91IGRvbid0IHNheSB0aGF0LiBZb3Ugc3RpbGwgY29udGludWUgaWdu b3JpbmcgYXJndW1lbnRzDQo+YW5kIHBlcnNvbnMgeW91IGNhbm5vdCByZXBseS4gVGltJ3MgYXJn dW1lbnQgaXMgbm90IGp1c3QgYWJvdXQgIlRpbWUNCj50byBtYXJrZXQiLiBBbnlvbmUgcmVhZGlu ZyBoaXMgbWFpbCB3b3VsZCBhbHNvIHJlYWQgdGhlIHRoaXJkDQo+cGFyYWdyYXBoICh3aGljaCB5 b3UgaW50ZW50aW9uYWxseSBpZ25vcmUgbm93LCBvZiBjb3Vyc2UsIGFzIHlvdQ0KPmFsd2F5cyBk bykuDQo+DQo+DQo+DQo+PiBBdCB0aGlzIG1vbWVudCwgSSBkb24ndCB0aGluayB0aGF0IHRoZXJl IGlzIGEgbmVlZCBmb3IgZGV2ZWxvcGluZyBuZXcNCj4+IHNpZ25hbGluZyBwcm90b2NvbCBmb3Ig UlRDd2ViLiBJTU8sIFRoZSBhcmd1bWVudCBtYXkgYmUgd2hpY2ggaXMgYmVzdA0KPj4gc3VpdGFi bGUgcmF0aGVyIHRoYW4gbm9uZSBvZiB0aGUgcHJvdG9jb2wgaXMgc3VpdGFibGUuDQo+DQo+UGxl YXNlLCBkb24ndCB0cnkgdG8gZGlzdHJhY3QgdGhpcyBXRyBmb3IgYWNoaWV2aW5nIHlvdXIgZ29h bHMuIFRoZXJlDQo+aXMgbm90LCBhbmQgdGhlcmUgd2lsbCBub3QgYmUsIGEgZGlzY3Vzc2lvbi9k ZWJhdGUgYWJvdXQgd2hpY2ggb25lIGlzDQo+dGhlICJiZXN0IGRlZmF1bHQgYW5kICptYW5kYXRv cnkqIHNpZ25hbGluZyBwcm90b2NvbCIuDQo+DQo+DQo+DQo+PiBJbiBjYXNlIHlvdXIgcHJvcG9z YWwgaXMgbm90IHRvIGludmVudCBuZXcgcHJvdG9jb2wgZm9yIFJUQ1dlYg0KPnNpZ25hbGluZy4N Cj4+IFBsZWFzZSBsb29rIGF0IG15IGRyYWZ0IHdoaWNoIGlzIGluIHRoZSBzYW1lIGxpbmUuDQo+ DQo+U3VyZSwgeW91ciBkcmFmdCBpcyBqdXN0IGFueSBvZiB5b3VyIG1haWxzIGNvcHkmcGFzdGVk IGludG8gYSBkcmFmdC4NCj4NCj4NCj4NCj4tLQ0KPknDsWFraSBCYXogQ2FzdGlsbG8NCj48aWJj QGFsaWF4Lm5ldD4NCg== From Markus.Isomaki@nokia.com Fri Oct 7 03:59: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 2E4C521F8B59 for ; Fri, 7 Oct 2011 03:59:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, J_CHICKENPOX_46=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 55yW4ZzY0gh9 for ; Fri, 7 Oct 2011 03:59:11 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 6081621F8B2E for ; Fri, 7 Oct 2011 03:59:11 -0700 (PDT) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-sa01.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p97B26GX019090; Fri, 7 Oct 2011 14:02:22 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 7 Oct 2011 14:02:19 +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; Fri, 7 Oct 2011 13:02:18 +0200 Received: from 008-AM1MPN1-043.mgdnok.nokia.com ([169.254.3.167]) by 008-AM1MMR1-001.mgdnok.nokia.com ([65.54.30.56]) with mapi id 14.01.0339.002; Fri, 7 Oct 2011 13:02:18 +0200 From: To: , Thread-Topic: [rtcweb] Review request for RTCWeb standard signaling protocol Thread-Index: AcyB2M8p5Sh3naz7SPaFx9XGCjJhjQAABSnAACFBTgAARpW+AABClSQAAAj02IAACQDpgAAAPwgAAAAyXgAAAHUgAAAAExIAAARDZCA= Date: Fri, 7 Oct 2011 11:02:17 +0000 Message-ID: References: <2E239D6FCD033C4BAF15F386A979BF510F1367@sonusinmail02.sonusnet.com><4E8AC222.4050308@alvestrand.no><2E239D6FCD033C4BAF15F386A979BF510F14CE@sonusinmail02.sonusnet.com><2E239D6FCD033C4BAF15F386A979BF510F14FD@sonusinmail02.sonusnet.com><393F1888-F834-4DAE-B6B1-1C5D35EE3292@phonefromhere.com><2E239D6FCD033C4BAF15F386A979BF510F152B@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF510F152D@sonusinmail02.sonusnet.com> In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF510F152D@sonusinmail02.sonusnet.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.21.75.16] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 07 Oct 2011 11:02:19.0329 (UTC) FILETIME=[94F16310:01CC84E0] X-Nokia-AV: Clean Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Review request for RTCWeb standard 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: Fri, 07 Oct 2011 10:59:12 -0000 SGksDQoNClJhdmluZHJhbiBQYXJ0aGFzYXJhdGhpDQo+DQo+TGV0IHVzIGRlYmF0ZSBvbiB0aGUg UlRDV2ViIHNpZ25hbGluZyBtZWV0aW5nDQo+DQoNCkknZCByYXRoZXIgaG9wZSB3ZSBjb3VsZCBz dG9wIHNwZW5kaW5nIGN5Y2xlcyBvbiB0aGlzIHBhcnRpY3VsYXIgZGViYXRlLiBNeSByZWFkIG9u IHRoZSBsaXN0IGlzIHRoYXQgdGhlcmUgaXMgcHJldHR5IHN0cm9uZyBjb25jZW5zdXMgb24gdGhh dCB3ZSB3aWxsICpub3QqIHBpY2sgYW5kIHN0YW5kYXJkaXplIGEgc2luZ2xlIGNvbXBsZXRlICJz aWduYWxpbmcgcHJvdG9jb2wiIChzdWNoIGFzIFNJUCBvciBYTVBQL0ppbmdsZSkgZm9yIFJUQy1X ZWIuIFRoaXMgaXMgb2YgY291cnNlIHVwIHRvIHRoZSBjaGFpcnMgdG8gZGV0ZXJtaW5lLg0KDQpN YXJrdXMNCg0KPg0KPj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj5Gcm9tOiBJw7Fha2kg QmF6IENhc3RpbGxvIFttYWlsdG86aWJjQGFsaWF4Lm5ldF0NCj4+U2VudDogRnJpZGF5LCBPY3Rv YmVyIDA3LCAyMDExIDQ6MTkgUE0NCj4+VG86IFJhdmluZHJhbiBQYXJ0aGFzYXJhdGhpDQo+PkNj OiBzYW11ZWw7IFRpbSBQYW50b247IHJ0Y3dlYkBpZXRmLm9yZw0KPj5TdWJqZWN0OiBSZTogW3J0 Y3dlYl0gUmV2aWV3IHJlcXVlc3QgZm9yIFJUQ1dlYiBzdGFuZGFyZCBzaWduYWxpbmcNCj4+cHJv dG9jb2wNCj4+DQo+PjIwMTEvMTAvNyBSYXZpbmRyYW4gUGFydGhhc2FyYXRoaSA8cHJhdmluZHJh bkBzb251c25ldC5jb20+Og0KPj4+IFlvdXIgYXJndW1lbnQgaXMgIlRpbWUgdG8gbWFya2V0IiBS VENXZWIgY29tcGxpYW5jZSBhbmQgZmV3IGZvbGtzDQo+PmFscmVhZHkNCj4+PiBtZW50aW9uZWQg YWJvdXQgaXQgYW5kIGFsc28gcHJvcG9zaW5nIHRvIGRldmVsb3AgdGhlIG5ldyBwcm90b2NvbC4N Cj4+DQo+PkFuZCAqbG90KiBvZiBmb2xrcyBhbHJlYWR5IG1lbnRpb25lZCB0aGF0IHlvdXIgcHJv cG9zYWwgaXMgYmFkIGZvcg0KPj5XZWJSVEMsIGJ1dCB5b3UgZG9uJ3Qgc2F5IHRoYXQuIFlvdSBz dGlsbCBjb250aW51ZSBpZ25vcmluZyBhcmd1bWVudHMNCj4+YW5kIHBlcnNvbnMgeW91IGNhbm5v dCByZXBseS4gVGltJ3MgYXJndW1lbnQgaXMgbm90IGp1c3QgYWJvdXQgIlRpbWUgdG8NCj4+bWFy a2V0Ii4gQW55b25lIHJlYWRpbmcgaGlzIG1haWwgd291bGQgYWxzbyByZWFkIHRoZSB0aGlyZCBw YXJhZ3JhcGgNCj4+KHdoaWNoIHlvdSBpbnRlbnRpb25hbGx5IGlnbm9yZSBub3csIG9mIGNvdXJz ZSwgYXMgeW91IGFsd2F5cyBkbykuDQo+Pg0KPj4NCj4+DQo+Pj4gQXQgdGhpcyBtb21lbnQsIEkg ZG9uJ3QgdGhpbmsgdGhhdCB0aGVyZSBpcyBhIG5lZWQgZm9yIGRldmVsb3BpbmcgbmV3DQo+Pj4g c2lnbmFsaW5nIHByb3RvY29sIGZvciBSVEN3ZWIuIElNTywgVGhlIGFyZ3VtZW50IG1heSBiZSB3 aGljaCBpcyBiZXN0DQo+Pj4gc3VpdGFibGUgcmF0aGVyIHRoYW4gbm9uZSBvZiB0aGUgcHJvdG9j b2wgaXMgc3VpdGFibGUuDQo+Pg0KPj5QbGVhc2UsIGRvbid0IHRyeSB0byBkaXN0cmFjdCB0aGlz IFdHIGZvciBhY2hpZXZpbmcgeW91ciBnb2Fscy4gVGhlcmUNCj4+aXMgbm90LCBhbmQgdGhlcmUg d2lsbCBub3QgYmUsIGEgZGlzY3Vzc2lvbi9kZWJhdGUgYWJvdXQgd2hpY2ggb25lIGlzDQo+PnRo ZSAiYmVzdCBkZWZhdWx0IGFuZCAqbWFuZGF0b3J5KiBzaWduYWxpbmcgcHJvdG9jb2wiLg0KPj4N Cj4+DQo+Pg0KPj4+IEluIGNhc2UgeW91ciBwcm9wb3NhbCBpcyBub3QgdG8gaW52ZW50IG5ldyBw cm90b2NvbCBmb3IgUlRDV2ViDQo+PnNpZ25hbGluZy4NCj4+PiBQbGVhc2UgbG9vayBhdCBteSBk cmFmdCB3aGljaCBpcyBpbiB0aGUgc2FtZSBsaW5lLg0KPj4NCj4+U3VyZSwgeW91ciBkcmFmdCBp cyBqdXN0IGFueSBvZiB5b3VyIG1haWxzIGNvcHkmcGFzdGVkIGludG8gYSBkcmFmdC4NCj4+DQo+ Pg0KPj4NCj4+LS0NCj4+ScOxYWtpIEJheiBDYXN0aWxsbw0KPj48aWJjQGFsaWF4Lm5ldD4NCj5f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPnJ0Y3dlYiBt YWlsaW5nIGxpc3QNCj5ydGN3ZWJAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3J0Y3dlYg0K From neils@vipadia.com Fri Oct 7 04:13: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 6C1AF21F8B2E for ; Fri, 7 Oct 2011 04:13:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.926 X-Spam-Level: X-Spam-Status: No, score=-2.926 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dE4KGnB7gEUY for ; Fri, 7 Oct 2011 04:13:42 -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 CE22121F8B31 for ; Fri, 7 Oct 2011 04:13:42 -0700 (PDT) Received: by iaby26 with SMTP id y26so4992219iab.31 for ; Fri, 07 Oct 2011 04:16:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.148.198 with SMTP id s6mr12120749icv.56.1317986214791; Fri, 07 Oct 2011 04:16:54 -0700 (PDT) Sender: neils@vipadia.com Received: by 10.231.200.146 with HTTP; Fri, 7 Oct 2011 04:16:54 -0700 (PDT) In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF510F152B@sonusinmail02.sonusnet.com> References: <2E239D6FCD033C4BAF15F386A979BF510F1367@sonusinmail02.sonusnet.com> <4E8AC222.4050308@alvestrand.no> <2E239D6FCD033C4BAF15F386A979BF510F14CE@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF510F14FD@sonusinmail02.sonusnet.com> <393F1888-F834-4DAE-B6B1-1C5D35EE3292@phonefromhere.com> <2E239D6FCD033C4BAF15F386A979BF510F152B@sonusinmail02.sonusnet.com> Date: Fri, 7 Oct 2011 12:16:54 +0100 X-Google-Sender-Auth: JiZ2fdxMiAfntTn_towKil8MWns Message-ID: From: Neil Stratford To: Ravindran Parthasarathi Content-Type: multipart/alternative; boundary=90e6ba1efe0a26cb8104aeb3948e Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Review request for RTCWeb standard 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: Fri, 07 Oct 2011 11:13:43 -0000 --90e6ba1efe0a26cb8104aeb3948e Content-Type: text/plain; charset=ISO-8859-1 On Fri, Oct 7, 2011 at 11:36 AM, Ravindran Parthasarathi < pravindran@sonusnet.com> wrote: > At this moment, I don't think that there is a need for developing new > signaling protocol for RTCweb. IMO, The argument may be which is best > suitable rather than none of the protocol is suitable. > In my view the only option for a standardised signalling protocol for RTCweb *would* be something entirely new that met the specific needs of the environment. If we did go down the hypothetical new standard protocol route (which I really think we shouldn't) my requirements would be: - No server side infrastructure (SIP proxies etc) to maintain or configure. - No special understanding in the server side web application beyond discovering peer identities you might want to communicate with. Which would lead to something looking like a browser maintained peer to peer network, at which point we are re-inventing the web, which sounds like something beyond this group. So I strongly support not picking a default and instead encourage some innovation at the javascript level. Neil --90e6ba1efe0a26cb8104aeb3948e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Oct 7, 2011 at 11:36 AM, Ravindran Parthasarathi = <pravindran@sonusnet.com&= gt; wrote:

At this moment, I don't think that there is a need for developing new signaling protocol for RTCweb. IMO, The argument may be whic= h is best suitable rather than none of the protocol is suitable.

=
In my view the only option for a standardised signalling = protocol for RTCweb *would* be something entirely new that met the specific= needs of the environment.=A0

If we did go down the hypothetical new standard protoco= l route (which I really think we shouldn't) my requirements would be:
- No server side infrastructure (SIP proxies etc) to maintain or c= onfigure.
- No special understanding in the server side web application beyond d= iscovering peer identities you might want to communicate with.
Which would lead to something looking like a browser maintaine= d peer to peer network, at which point we are re-inventing the web, which s= ounds like something beyond this group. So I strongly support not picking a= default and instead encourage some innovation at the javascript level.

Neil

--90e6ba1efe0a26cb8104aeb3948e-- From pravindran@sonusnet.com Fri Oct 7 04: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 8A80021F8AE1 for ; Fri, 7 Oct 2011 04:41:24 -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 8wdBfTO7Ng+a for ; Fri, 7 Oct 2011 04:41:23 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id ADBF521F8ADC for ; Fri, 7 Oct 2011 04:41:23 -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 p97Bj6A5029238; Fri, 7 Oct 2011 07:45:07 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail07.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 7 Oct 2011 07:40: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_01CC84E5.ECC3BC89" Date: Fri, 7 Oct 2011 17:10:33 +0530 Message-ID: <2E239D6FCD033C4BAF15F386A979BF510F1532@sonusinmail02.sonusnet.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] Review request for RTCWeb standard signaling protocol Thread-Index: AcyE4qD5UD7fvzOgSPm3DPa/g76PuAAAsrMQ References: <2E239D6FCD033C4BAF15F386A979BF510F1367@sonusinmail02.sonusnet.com><4E8AC222.4050308@alvestrand.no><2E239D6FCD033C4BAF15F386A979BF510F14CE@sonusinmail02.sonusnet.com><2E239D6FCD033C4BAF15F386A979BF510F14FD@sonusinmail02.sonusnet.com><393F1888-F834-4DAE-B6B1-1C5D35EE3292@phonefromhere.com><2E239D6FCD033C4BAF15F386A979BF510F152B@sonusinmail02.sonusnet.com> From: "Ravindran Parthasarathi" To: "Neil Stratford" X-OriginalArrivalTime: 07 Oct 2011 11:40:37.0395 (UTC) FILETIME=[EEB26E30:01CC84E5] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Review request for RTCWeb standard 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: Fri, 07 Oct 2011 11:41:24 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC84E5.ECC3BC89 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Neil, =20 =20 In my view the only option for a standardised signaling protocol for RTCweb *would* be something entirely new that met the specific needs of the environment.=20 =20 Browser to browser real time communication is no different from other real-time communication apart from the existing web infrastructure. In case your argument is to use the existing web infrastructure like websocket, I agree with you. =20 But in case it is not the reason, Could you please list the reason for new signaling protocol requirement .=20 =20 Thanks Partha =20 From: neils@vipadia.com [mailto:neils@vipadia.com] On Behalf Of Neil Stratford Sent: Friday, October 07, 2011 4:47 PM To: Ravindran Parthasarathi Cc: samuel; Tim Panton; rtcweb@ietf.org Subject: Re: [rtcweb] Review request for RTCWeb standard signaling protocol =20 On Fri, Oct 7, 2011 at 11:36 AM, Ravindran Parthasarathi wrote: At this moment, I don't think that there is a need for developing new signaling protocol for RTCweb. IMO, The argument may be which is best suitable rather than none of the protocol is suitable. In my view the only option for a standardised signalling protocol for RTCweb *would* be something entirely new that met the specific needs of the environment.=20 =20 If we did go down the hypothetical new standard protocol route (which I really think we shouldn't) my requirements would be: - No server side infrastructure (SIP proxies etc) to maintain or configure. - No special understanding in the server side web application beyond discovering peer identities you might want to communicate with. =20 Which would lead to something looking like a browser maintained peer to peer network, at which point we are re-inventing the web, which sounds like something beyond this group. So I strongly support not picking a default and instead encourage some innovation at the javascript level. =20 Neil =20 ------_=_NextPart_001_01CC84E5.ECC3BC89 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Neil,

 

<snip>

In my view the only option for a standardised = signaling protocol for RTCweb *would* be something entirely new that met the specific needs = of the environment. 

</snip>

 

Browser to browser real time communication is no = different from other real-time communication apart from the existing web = infrastructure. In case your argument is to use the existing web infrastructure like = websocket, I agree with you.

 

But in case it is not the reason, Could you please list = the reason for new signaling protocol requirement .

 

Thanks

Partha

 

From:= = neils@vipadia.com [mailto:neils@vipadia.com] On Behalf Of Neil Stratford
Sent: Friday, October 07, 2011 4:47 PM
To: Ravindran Parthasarathi
Cc: samuel; Tim Panton; rtcweb@ietf.org
Subject: Re: [rtcweb] Review request for RTCWeb standard = signaling protocol

 

On Fri, Oct 7, 2011 at 11:36 AM, Ravindran = Parthasarathi <pravindran@sonusnet.com> = wrote:

At this moment, I don't think that there is a need for developing new signaling protocol for RTCweb. IMO, The argument may be which is best = suitable rather than none of the protocol is suitable.

In my view the only option for a standardised = signalling protocol for RTCweb *would* be something entirely new that met the = specific needs of the environment. 

 

If we did go down the hypothetical new standard = protocol route (which I really think we shouldn't) my requirements would = be:

- No server side infrastructure (SIP proxies etc) = to maintain or configure.

- No special understanding in the server side web application beyond discovering peer identities you might want to = communicate with.

 

Which would lead to something looking like a = browser maintained peer to peer network, at which point we are re-inventing the = web, which sounds like something beyond this group. So I strongly support not picking a default and instead encourage some innovation at the = javascript level.

 

Neil

 

------_=_NextPart_001_01CC84E5.ECC3BC89-- From neils@vipadia.com Fri Oct 7 04:50: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 7D95221F8B35 for ; Fri, 7 Oct 2011 04:50:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.938 X-Spam-Level: X-Spam-Status: No, score=-2.938 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vKo40HOmAgFf for ; Fri, 7 Oct 2011 04:50:38 -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 C7DF221F8AE1 for ; Fri, 7 Oct 2011 04:50:38 -0700 (PDT) Received: by iaby26 with SMTP id y26so5029632iab.31 for ; Fri, 07 Oct 2011 04:53:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.46.66 with SMTP id i2mr3147938ibf.0.1317988431999; Fri, 07 Oct 2011 04:53:51 -0700 (PDT) Sender: neils@vipadia.com Received: by 10.231.200.146 with HTTP; Fri, 7 Oct 2011 04:53:51 -0700 (PDT) In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF510F1532@sonusinmail02.sonusnet.com> References: <2E239D6FCD033C4BAF15F386A979BF510F1367@sonusinmail02.sonusnet.com> <4E8AC222.4050308@alvestrand.no> <2E239D6FCD033C4BAF15F386A979BF510F14CE@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF510F14FD@sonusinmail02.sonusnet.com> <393F1888-F834-4DAE-B6B1-1C5D35EE3292@phonefromhere.com> <2E239D6FCD033C4BAF15F386A979BF510F152B@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF510F1532@sonusinmail02.sonusnet.com> Date: Fri, 7 Oct 2011 12:53:51 +0100 X-Google-Sender-Auth: 2piANS5nxWQv2UaRiDagJco4Dcg Message-ID: From: Neil Stratford To: Ravindran Parthasarathi Content-Type: multipart/alternative; boundary=001517740aba4eb4ea04aeb41827 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Review request for RTCWeb standard 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: Fri, 07 Oct 2011 11:50:39 -0000 --001517740aba4eb4ea04aeb41827 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Oct 7, 2011 at 12:40 PM, Ravindran Parthasarathi < pravindran@sonusnet.com> wrote: > Browser to browser real time communication is no different from other > real-time communication apart from the existing web infrastructure. In case > your argument is to use the existing web infrastructure like websocket, I > agree with you. > It is different to traditional RTC - we have a javascript execution engine intimately tied in to every client. This completely changes the solution space. > ** > > But in case it is not the reason, Could you please list the reason for new > signaling protocol requirement . > I already listed them: > **** > > ** > > - No server side infrastructure (SIP proxies etc) to maintain or configure. > **** > > - No special understanding in the server side web application beyond > discovering peer identities you might want to communicate with. > My argument is that if we want the ultimate goal of simplicity for end user web developers then we should minimise everything they have to touch - and that includes removing any requirement for server side infrastructure beyond the basic bare minimum, which would mean no SIP proxies, no websocket servers etc etc. But as I said, we don't need to standardise a protocol at all, so we shouldn't. If we are lucky we'll see a whole spectrum of solutions. Neil --001517740aba4eb4ea04aeb41827 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Oct 7, 2011 at 12:40 PM, Ravindran Parthasarathi = <pravindran@sonusnet.com&= gt; wrote:

Brows= er to browser real time communication is no different from other real-time communication apart from the existing web infrastructure. I= n case your argument is to use the existing web infrastructure like websocket= , I agree with you.


It i= s different to traditional RTC - we have a javascript execution engine inti= mately tied in to every client. This completely changes the solution space.=
=A0

But i= n case it is not the reason, Could you please list the reason for new signaling protocol requirement .


I already listed them:=A0

=A0

- No server side infrastructure (SIP proxies etc) to maintain or configure.

- No special understanding in the server side web application beyond discovering peer identities you might want to communicat= e with.


My argument is that if we want the ultimate goal of simplicity for= end user web developers then we should minimise everything they have to to= uch - and that includes removing any requirement for server side infrastruc= ture beyond the basic bare minimum, which would mean no SIP proxies, no web= socket servers etc etc.

But as I said, we don't need to standardise a proto= col at all, so we shouldn't. If we are lucky we'll see a whole spec= trum of solutions.

Neil
--001517740aba4eb4ea04aeb41827-- From ibc@aliax.net Fri Oct 7 05: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 C7E1F21F8B06 for ; Fri, 7 Oct 2011 05:27:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[AWL=0.045, 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 zurXfIUUD2K4 for ; Fri, 7 Oct 2011 05:27:52 -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 357E821F8B05 for ; Fri, 7 Oct 2011 05:27:52 -0700 (PDT) Received: by vcbfo11 with SMTP id fo11so3802306vcb.31 for ; Fri, 07 Oct 2011 05:31:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.120.12 with SMTP id b12mr558335vcr.111.1317990665301; Fri, 07 Oct 2011 05:31:05 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Fri, 7 Oct 2011 05:31:05 -0700 (PDT) In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF510F1532@sonusinmail02.sonusnet.com> References: <2E239D6FCD033C4BAF15F386A979BF510F1367@sonusinmail02.sonusnet.com> <4E8AC222.4050308@alvestrand.no> <2E239D6FCD033C4BAF15F386A979BF510F14CE@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF510F14FD@sonusinmail02.sonusnet.com> <393F1888-F834-4DAE-B6B1-1C5D35EE3292@phonefromhere.com> <2E239D6FCD033C4BAF15F386A979BF510F152B@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF510F1532@sonusinmail02.sonusnet.com> Date: Fri, 7 Oct 2011 14:31:05 +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] Review request for RTCWeb standard 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: Fri, 07 Oct 2011 12:27:52 -0000 2011/10/7 Ravindran Parthasarathi : > Browser to browser real time communication is no different from other > real-time communication apart from the existing web infrastructure. In ca= se > your argument is to use the existing web infrastructure like websocket, I > agree with you. > > But in case it is not the reason, Could you please list the reason for ne= w > signaling protocol requirement . Ravindran, could you please read the entire mails? Neil crearly said at the end of his mail: "So I strongly support not picking a default and instead encourage some innovation at the javascript level." Do you read the "strongly" word? --=20 I=C3=B1aki Baz Castillo From tim@phonefromhere.com Fri Oct 7 05:37:25 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4124221F8B19 for ; Fri, 7 Oct 2011 05:37:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.5 X-Spam-Level: X-Spam-Status: No, score=-2.5 tagged_above=-999 required=5 tests=[AWL=0.098, 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 0A9uLynaD9Up for ; Fri, 7 Oct 2011 05:37: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 A04A321F85B9 for ; Fri, 7 Oct 2011 05:37:20 -0700 (PDT) Received: from [192.168.0.14] (unknown [93.89.81.113]) by zimbra.westhawk.co.uk (Postfix) with ESMTP id 51D7437A903; Fri, 7 Oct 2011 13:53:21 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-11-381611972 From: Tim Panton In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF510F152B@sonusinmail02.sonusnet.com> Date: Fri, 7 Oct 2011 13:40:28 +0100 Message-Id: References: <2E239D6FCD033C4BAF15F386A979BF510F1367@sonusinmail02.sonusnet.com><4E8AC222.4050308@alvestrand.no><2E239D6FCD033C4BAF15F386A979BF510F14CE@sonusinmail02.sonusnet.com><2E239D6FCD033C4BAF15F386A979BF510F14FD@sonusinmail02.sonusnet.com><393F1888-F834-4DAE-B6B1-1C5D35EE3292@phonefromhere.com> <2E239D6FCD033C4BAF15F386A979BF510F152B@sonusinmail02.sonusnet.com> To: Ravindran Parthasarathi X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Review request for RTCWeb standard 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: Fri, 07 Oct 2011 12:37:25 -0000 --Apple-Mail-11-381611972 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 If you had the curtesy to actually read what I'd written, you would have = seen that I made 3 arguments. Just to reinforce my point about the un-suitability of existing = protocols, I've now worked on 4 web-rtc like projects, using 4 different pre-existing protocols (XMPP, SIP, = IAX2, proprietary), so I have quite a bit experience on which to base my remarks. They all = worked ok in the problem space we used them in (which is why we selected each of them for their = respective projects), but no one protocol would have done the job for all the projects.=20 Premature standardisation is the enemy of innovation - to coin a phrase.=20= This isn't a sunset market, it is a new dawn, we should standardize as = little as we possibly can. You can choose not to agree with my opinions, but please don't = mis-represent my remarks. Tim. On 7 Oct 2011, at 11:36, Ravindran Parthasarathi wrote: > Tim, > =20 > Your argument is "Time to market" RTCWeb compliance and few folks = already mentioned about it and also proposing to develop the new = protocol. > =20 > At this moment, I don't think that there is a need for developing new = signaling protocol for RTCweb. IMO, The argument may be which is best = suitable rather than none of the protocol is suitable. > =20 > Sam, > =20 > In case your proposal is not to invent new protocol for RTCWeb = signaling. Please look at my draft which is in the same line. > =20 > Thanks > Partha > =20 > From: samuel [mailto:samu60@gmail.com]=20 > Sent: Friday, October 07, 2011 4:01 PM > To: Tim Panton > Cc: Ravindran Parthasarathi; rtcweb@ietf.org > Subject: Re: [rtcweb] Review request for RTCWeb standard signaling = protocol > =20 > Hi all, >=20 > The point I=F1aki is pushing forward is crucial, as Tim also stated, = because it will save us the burden of implementing another protocol, the = marketing fight between protocols (do you want another SIP vs. H323 = "war"?) Please, don't reinvent the wheel, keep it simple. >=20 > Best regards, >=20 > Samuel >=20 > On 7 October 2011 12:23, Tim Panton wrote: >=20 > On 7 Oct 2011, at 07:05, Ravindran Parthasarathi wrote: >=20 > > Inaki, > > > > I understand that you don't want any signaling protocol for RTCWeb = to be standardized. I'm strong believer of "something is better than = nothing". Also, My standard signaling protocol proposal is never a = hindrance to your innovative custom-build signaling protocol (SIP over = websocket) development and the standard signaling protocol is not meant = for you in case you are building custom-build signaling protocol. > > > > =46rom the RTCweb client programmer perspective, there will be an = set of API for building custom build signaling and another top level API = which is based on proposed standard signaling. I could not understand = why are you so against the standardization of the signaling protocol. >=20 > Because it is a distraction. It is unnecessary, the advantages don't = outweigh the disadvantages. >=20 > It isn't essential to the success of this effort and would slow us = down by _years_ debating the details. >=20 > Even if we could magically all instantly agree to use (say) RFC 5456 = as the standard (*) , it would then immediately impact the > core effort, the temptation to add features and helper methods to the = core media API that suited the 'standard' signalling protocol > would be irresistible. Pretty soon we'd find we had a media layer that = could _only_ work well through the standard signalling protocol. >=20 > Tim. >=20 > (*) In my view no one of the currently available signalling protocols = are suitable for this effort. They were all designed with > a totally different set of constraints to the ones faced by rtcweb. >=20 > T. > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > =20 --Apple-Mail-11-381611972 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 If you had the curtesy to actually read what I'd = written, you would have seen that I made 3 = arguments.

Just to reinforce my point about the = un-suitability of existing protocols, I've now worked on 4 = web-rtc
like projects, using 4 different pre-existing = protocols (XMPP, SIP, IAX2, proprietary),
so I have quite a = bit experience on which to base my remarks. They all worked ok in the = problem
space we used them in (which is why we selected each = of them for their respective projects),
but no one protocol = would have done the job for all the = projects. 

Premature standardisation is = the enemy of innovation - to coin a phrase. 
This isn't a = sunset market, it is a new dawn, we should standardize as little as we = possibly can.

You can choose not to agree with = my opinions, but please don't mis-represent my = remarks.

Tim.

= On 7 Oct 2011, at 11:36, Ravindran Parthasarathi wrote:

Tim,
Your argument is "Time to market" RTCWeb = compliance and few folks already mentioned about it and also proposing = to develop the new protocol.
 
At = this moment, I don't think that there is a need for developing new = signaling protocol for RTCweb. IMO, The argument may be which is best = suitable rather than none of the protocol is = suitable.
 
Sam,
In case your proposal is not to invent new = protocol for RTCWeb signaling.  Please look at my draft which is in = the same line.
 
Partha
 
 samuel = [mailto:samu60@gmail.com] 
Sent: Friday, October 07, 2011 = 4:01 PM
To: Tim = Panton
Cc: Ravindran = Parthasarathi; rtcweb@ietf.org
Subject: Re: [rtcweb] Review request = for RTCWeb standard signaling = protocol
Hi = all,

The point I=F1aki is pushing forward is crucial, as Tim also = stated, because it will save us the burden of implementing another = protocol, the marketing fight between protocols (do you want another SIP = vs. H323 "war"?) Please, don't reinvent the wheel, keep it = simple.

Best regards,

Samuel

On 7 October 2011 12:23, Tim Panton <tim@phonefromhere.com> = wrote:


On 7 Oct = 2011, at 07:05, Ravindran Parthasarathi wrote:

> = Inaki,
>
> I understand that you don't want any signaling = protocol for RTCWeb  to be standardized. I'm strong believer of = "something is better than nothing". Also, My standard signaling protocol = proposal is never a hindrance to your innovative custom-build signaling = protocol (SIP over websocket) development and the standard signaling = protocol is not meant for you in case you are building custom-build = signaling protocol.
>
> =46rom the RTCweb client programmer = perspective, there will be an set of API for building custom build = signaling and another top level API which is based on proposed standard = signaling. I could not understand why are you so against the = standardization of the signaling protocol.

Because it is a distraction. It is unnecessary, the = advantages don't outweigh the disadvantages.

It isn't essential = to the success of this effort and would slow us down by _years_ debating = the details.

Even if we could magically all instantly agree to = use (say) RFC 5456 as the standard (*) , it would then immediately = impact the
core effort, the temptation to add features and helper = methods to the core media API that suited the 'standard' signalling = protocol
would be irresistible. Pretty soon we'd find we had a media = layer that could _only_ work well through the standard signalling = protocol.

Tim.

(*) In my view no one of the currently = available signalling protocols are suitable for this effort. They were = all designed with
a totally different set of constraints to the ones = faced by rtcweb.
rtcweb@ietf.org
" Thread-Topic: [rtcweb] Review request for RTCWeb standard signaling protocol Thread-Index: AQHMhSH3WAYm6sWfE0aVzRoo8GFJXQ== Date: Fri, 7 Oct 2011 18:50:22 +0000 Message-ID: <1636CB96-8B00-4387-8ED2-9B74EB818E45@acmepacket.com> References: <2E239D6FCD033C4BAF15F386A979BF510F1367@sonusinmail02.sonusnet.com> <4E8AC222.4050308@alvestrand.no> <2E239D6FCD033C4BAF15F386A979BF510F14CE@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF510F14FD@sonusinmail02.sonusnet.com> <393F1888-F834-4DAE-B6B1-1C5D35EE3292@phonefromhere.com> <2E239D6FCD033C4BAF15F386A979BF510F152B@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: [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= Subject: Re: [rtcweb] Review request for RTCWeb standard 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: Fri, 07 Oct 2011 18:47:11 -0000 Neil makes an excellent point which has only been briefly brought up but sh= ould be made more explicit: picking a standard signaling protocol for the B= rowser to implement is only half the problem - the other half of the proble= m is the Web Server has to implement it too, tie it into a location databas= e, possibly with authentication and authorization policy rules, and whateve= r else the specific Web application needs. There is no "20 lines of code" solution once you realize that. It may be 2= 0 lines of JavaScript, but that's only part of the problem/solution. In fa= ct, the most likely way to get to 20 lines of code for the Web Server owner= is for him/her to use a public JS library for signaling which is paired wi= th a web server module written for that specific JS library. -hadriel On Oct 7, 2011, at 7:16 AM, Neil Stratford wrote: >=20 > If we did go down the hypothetical new standard protocol route (which I r= eally think we shouldn't) my requirements would be: > - No server side infrastructure (SIP proxies etc) to maintain or configur= e. > - No special understanding in the server side web application beyond disc= overing peer identities you might want to communicate with. >=20 > Which would lead to something looking like a browser maintained peer to p= eer network, at which point we are re-inventing the web, which sounds like = something beyond this group. So I strongly support not picking a default an= d instead encourage some innovation at the javascript level. >=20 > Neil >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From bernard_aboba@hotmail.com Fri Oct 7 11:59: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 726EA21F8BC4 for ; Fri, 7 Oct 2011 11:59:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.543 X-Spam-Level: X-Spam-Status: No, score=-102.543 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UPtenWW9Ynnv for ; Fri, 7 Oct 2011 11:59:09 -0700 (PDT) Received: from blu0-omc4-s24.blu0.hotmail.com (blu0-omc4-s24.blu0.hotmail.com [65.55.111.163]) by ietfa.amsl.com (Postfix) with ESMTP id 39CB421F8678 for ; Fri, 7 Oct 2011 11:59:08 -0700 (PDT) Received: from BLU152-W31 ([65.55.111.135]) by blu0-omc4-s24.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 7 Oct 2011 12:02:22 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_f976257a-5d7f-41c2-8324-4834c9454a4a_" X-Originating-IP: [131.107.0.117] From: Bernard Aboba To: , Date: Fri, 7 Oct 2011 12:02:21 -0700 Importance: Normal In-Reply-To: <4E8E35C4.3000509@jesup.org> References: <4E8DCA06.5060506@jesup.org> <4E8E3005.3090307@mti-systems.com>,<4E8E35C4.3000509@jesup.org> MIME-Version: 1.0 X-OriginalArrivalTime: 07 Oct 2011 19:02:22.0425 (UTC) FILETIME=[A4ED0C90:01CC8523] Subject: Re: [rtcweb] Congestion Control 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: Fri, 07 Oct 2011 18:59:10 -0000 --_f976257a-5d7f-41c2-8324-4834c9454a4a_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > > I can't claim to fully understand the intended architecture from the > > description in this email=2C but something struck me as odd when in one > > breath it seems like data is flowing over TCP or SCTP (layered over > > UDP) and in another there's a separate algorithm (the Google one=2C or > > some modification) running for estimating bandwidth. Those seem > > mutually exclusive to me=2C unless I completely misunderstand the goal > > (which is entirely possible). [BA] In practice=2C I think the concern is largely over UDP-based traffic.= =20 For TCP or SCTP traffic=2C the native congestion control mechanisms should be sufficient.=20 > The fallback/simplest model would be to just consider the data channels=20 > under SCTP and the media channels to be separate flows=2C and let them=20 > fight for bandwidth as normal. [BA] There are multiple concerns here. One was about DoS attacks=2C which was about having the recipient confirm the desired bandwidth. That's=20 what Harald mentioned. The other issue is congestion control/codec adaptation (e.g. responding to RFC 3714 concerns). While I understand the need for this on the datagram channel=2C with respect to congestion control of RTP traffic=2C wo= n't adaptation be codec-specific? If the codec doesn't adapt (e.g. G.711) or does so based on RTCP feedback=2C how would an additional congestion control mechanism work? =20 > If we can make them work together or at least be respectful of each=20 > other to avoid "fighting"=2C that would be better. =20 > > The app may be able to help us by indicated the type of data to be transf= erred and the relative=20 > priority of it. (Background file transfers might stick to a small=20 > percentage of the bandwidth unless bandwidth is very high=3B a game may=20 > give priority to one stream of data over both media and other data=20 > streams - it's unclear currently if we'll be able to support that=2C but= =20 > it would be nice.) [BA] Agree. For example=2C if we're talking about a high-twitch game=2C=20 you might want different behavior than for one where the datagram channel needs more reliability. =20 > Reporting changes to the application is another matter with its own > challenges in either case=2C since the way the application responds will > limit what the CC can do afterwards (without additional probing). [BA] Yes. =20 > Don't forget that we normally will have a media channel active=2C and if= =20 > video is being sent (and to a lesser extent audio=2C especially if we're= =20 > using Opus) that media channel is adaptive and can adapt upwards to find= =20 > the limits of bandwidth.=20 [BA] Yes=2C it can but today that adaption is typically based on RTCP=2C ri= ght? > Decisions like that are tough or impossible for webrtc to make on it's=20 > own because it doesn't have the context of the application to guide it. [BA] The problem is that handling the events correctly will also probably b= e outside the capability of your average application developer. So enabling reasonable things to happen by default is probably a practical requirement.= =20 > That said=2C the interface and parameters and style for interacting with= =20 > the JS app is the thing this posting is weakest on=2C since I'm not=20 > well-versed in the common API paradigms that JS app developers expect=2C= =20 > and I'd love proposals for how we expose these choices and information=20 > to the app. [BA] The problem in my mind is whether we're really expecting RTCWEB Codecs do something with the additional information provided.=20 = --_f976257a-5d7f-41c2-8324-4834c9454a4a_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

>=3B >=3B I can't claim to fully understand the intended archi= tecture from the
>=3B >=3B description in this email=2C but somethin= g struck me as odd when in one
>=3B >=3B breath it seems like data i= s flowing over TCP or SCTP (layered over
>=3B >=3B UDP) and in anoth= er there's a separate algorithm (the Google one=2C or
>=3B >=3B some= modification) running for estimating bandwidth. Those seem
>=3B >= =3B mutually exclusive to me=2C unless I completely misunderstand the goal<= br>>=3B >=3B (which is entirely possible).

[BA] In practice=2C I= think the concern is largely over UDP-based traffic.
For TCP or SCTP&n= bsp=3B traffic=2C the native congestion control mechanisms should
be suf= ficient.

>=3B The fallback/simplest model would be to just consid= er the data channels
>=3B under SCTP and the media channels to be sep= arate flows=2C and let them
>=3B fight for bandwidth as normal.
[BA] There are multiple concerns here. =3B One was about DoS attacks= =2C which
was about having the recipient confirm the desired bandwidth.&= nbsp=3B That's
what Harald mentioned.

The other issue is congest= ion control/codec adaptation (e.g. responding
to RFC 3714 concerns).&nbs= p=3B =3B While I understand the need for this on the
datagram channe= l=2C with respect to congestion control of RTP traffic=2C won't
adaptati= on be codec-specific? =3B If the codec doesn't adapt (e.g. G.711) ordoes so based on RTCP feedback=2C how would an additional congestion
co= ntrol mechanism work? =3B

>=3B If we can make them work toget= her or at least be respectful of each
>=3B other to avoid "fighting"= =2C that would be better. =3B
>=3B
>=3B The app may be able to help us by indicated the type of data to be t= ransferred and the relative
>=3B priority of it. (Background file tr= ansfers might stick to a small
>=3B percentage of the bandwidth unles= s bandwidth is very high=3B a game may
>=3B give priority to one stre= am of data over both media and other data
>=3B streams - it's unclear= currently if we'll be able to support that=2C but
>=3B it would be n= ice.)

[BA] Agree. For example=2C if we're talking about a high-twitc= h game=2C
you might want different behavior than for one where the data= gram
channel needs more reliability. =3B

>=3B Reporting ch= anges to the application is another matter with its own
>=3B challenge= s in either case=2C since the way the application responds will
>=3B l= imit what the CC can do afterwards (without additional probing).

[BA= ] Yes. =3B


>=3B Don't forget that we normally will have a= media channel active=2C and if
>=3B video is being sent (and to a le= sser extent audio=2C especially if we're
>=3B using Opus) that media = channel is adaptive and can adapt upwards to find
>=3B the limits of = bandwidth.

[BA] Yes=2C it can but today that adaption is typically = based on RTCP=2C right?

>=3B Decisions like that are tough or impo= ssible for webrtc to make on it's
>=3B own because it doesn't have th= e context of the application to guide it.

[BA] The problem is that h= andling the events correctly will also probably be
outside the capabilit= y of your average application developer. =3B So enabling
reasonable = things to happen by default is probably a practical requirement.

&g= t=3B That said=2C the interface and parameters and style for interacting wi= th
>=3B the JS app is the thing this posting is weakest on=2C since I= 'm not
>=3B well-versed in the common API paradigms that JS app devel= opers expect=2C
>=3B and I'd love proposals for how we expose these c= hoices and information
>=3B to the app.

[BA] The problem in my=  =3B mind is whether we're really expecting RTCWEB
Codecs do somethi= ng with the additional information provided.
= --_f976257a-5d7f-41c2-8324-4834c9454a4a_-- From csp@csperkins.org Fri Oct 7 12:09: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 27D7821F8BEC for ; Fri, 7 Oct 2011 12:09:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.558 X-Spam-Level: X-Spam-Status: No, score=-103.558 tagged_above=-999 required=5 tests=[AWL=0.041, 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 yYiPEFL2eVoz for ; Fri, 7 Oct 2011 12:09:05 -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 AA2EE21F86A0 for ; Fri, 7 Oct 2011 12:09:04 -0700 (PDT) Received: from starkperkins.demon.co.uk ([80.176.158.71] helo=[192.168.0.30]) by lon1-post-2.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1RCFq9-000205-bI; Fri, 07 Oct 2011 19:12:13 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Colin Perkins In-Reply-To: <4E8DCA06.5060506@jesup.org> Date: Fri, 7 Oct 2011 20:12:13 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E8DCA06.5060506@jesup.org> To: Randell Jesup X-Mailer: Apple Mail (2.1084) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Congestion Control 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: Fri, 07 Oct 2011 19:09:06 -0000 [inline] On 6 Oct 2011, at 16:32, Randell Jesup wrote: ... > Startup: >=20 > There are issues both with starting too low (quality is poor at the = start > and takes a while to get better), and with starting too high (you > immediately can get into a delay situation and have to go into = recovery). > In general, starting too low is better than starting too high, as when = we > ramp up past the bottleneck we will not be too far over the limit and = so > recovery will be easier. In general, the bottleneck link is often > upstream, though this is moderating as high-bandwidth broadband = becomes > more common. >=20 > Options include: > a) Start at fixed value > b) Start at N% below the value from the last call with this person > (probably requires the App to help here) > c) Start at N% below the value from the last call with anyone > d) Have the other side tell us the rate they successfully received in = the > last call. Start the call at the lower of the last-call reception > rate from the far end or our last-call sending rate, minus n% > e) probe bandwidth at or before the start of the call using a packet > train >=20 > 'a' will be quite sub-optimal for most cases, though if the value is > low enough it won't be over-bandwidth. Some applications (games, etc) > may want to limit the starting bandwidth to avoid negative = interactions > with other dataflows. >=20 > 'b' has a problem that if the last call had a much higher bottleneck > bandwidth (especially on the remote downstream), the new call may be > over-bandwidth, perhaps badly. This won't be the norm, but may happen > especially with mobile/wifi at either end. >=20 > 'c' has a problem that if the last callee had a much higher bottleneck > bandwidth (especially on the remote downstream), the new call may be > over-bandwidth, perhaps badly. If the caller's upstream bandwidth is = high > compared to typical downstream bandwidth, then the likelihood of = starting > over-bandwidth is high. >=20 > 'd' has the advantage of selecting an appropriate value regardless of > whether the bottleneck is on upstream or downstream. The downside of = 'd' > is that the bottlenecks may have changed since the last call in which = case > we may start over-bandwidth. The historical data could be transferred > via pre-call signalling. >=20 > 'e' allows direct measurement of the current call bottlenecks. = However 'e' > can be misled if a mid-call router that isn't the bottleneck buffers = the > packet train while housekeeping or doing other operations and then = releases > them (it can collapse the signal from an earlier bottleneck). It = would > need to be combined with starting on the low side until a valid = measurement > is completed. Single measurements are imprecise with packet trains. For a new call, the only safe approach for the network would seem to be = option (a), starting at a low rate, followed by a fairly rapid increase = in rate to find the safe operating point (i.e., mirroring TCP slow start = in concept, if not in detail). The low rate would be chosen to support = the voice channel, presumably, so the call is useful immediately, but = might then take several RTTs to ramp up to a high enough rate for video = to be usable. An initial delay on the video is not an ideal user = experience, but I don't see it as being especially problematic provided = the voice channel is usable immediately, and we don't seem to have safe = options for avoiding it. Using a packet pair/train to get an estimate of the available bandwidth = is appealing, but I'm unconvinced it's accurate enough to be reliable. = We've done packet pair measurements to residential links that show = extremely inaccurate (high) bandwidth estimates in many cases, so I = wouldn't trust that as an initial sending rate. Using a longer packet = train would improve accuracy, but at the cost of loading the path, and = potentially disrupting any traffic sharing the path. I'm not sure such a = bandwidth estimate is that worthwhile if it delays/disrupts the start of = the voice channel. When restarting a previously application limited flow after some short = pause in transmission (e.g., the centralised video mixer scenario, where = only the active speaker sends video to the mixer), then I'm much more = comfortable with restarting at or near the previous rate, provided = there's been no indication that the path has changed. The rationale here = is that you've had some recent indication that the path can support the = rate, but with a new connection, even if to someone you've previously = spoken with, there's much less of a guarantee that the available = bandwidth is consistent with the previous observation. > Also, we need to consider the impact on other existing PeerConnections = - > for example, when you add a new person to a full-mesh conference, = you'll want > to start their bandwidth at about 1/Nth of the former total outgoing > bandwidth, and reduce the outgoing bandwidth of those other channels = to > provide the bandwidth for the new participant. >=20 > Obviously there is no obvious perfect solution, and combinations of > solutions may give the best overall experience. In this situation, it > makes sense to leave the actual choice up to the implementations or = even > the application, and make sure that they have the information needed = to > make the choice, such as the last-call bandwidth from the other end. > (I don't believe that information would be a privacy leakage of any = note.) >=20 >=20 > Data channels: >=20 > If we use SCTP-DTLS-UDP, we can rely on SCTP's congestion-control, = perhaps > modified to "play nice" with the media streams, and to have some = amount of > known priority relative to them. (For example, if the media streams = need > to back off and the data streams are using a consistent amount of = data, it > could reduce the amount or rate data is sent.) We also could = pre-allocate > some amount of bandwidth to data, and so long as it's not using it = media > could. Note that SCTP's congestion control is supposed to be in some > manner pluggable, so we could modify/replace it fairly easily. >=20 > Worst case: it acts as a separate, TCP-friendly flow we compete with. >=20 > If we have to use TCP-over-UDP, then that will be = congestion-controlled for > each individual flow, but the non-reliable channels will need separate > congestion control. Simplest would be to add RTP-like timestamps to = the > non-reliable data channels so they could pulled into the framework of = the > RTP channels as if they were bursty RTP data. >=20 > Even if the data flows are separately congestion controlled, in many = uses > they will be non-continuous flows (discrete messages as opposed to = data or > file transfers). These sorts of channels have different needs and > different impacts on the media channels from continuous flows: they're > bursty; low delay is important (especially on the initial packet for a > burst, which is often the only packet), and without a steady stream > congestion control will have little effect - and will have little = impact on > the media flows. For small bursts of data traffic, the "right" = solution > may be to simply ignore them up to some limit, and above that limit = start > to subtract the data channel usage from the available bandwidth for > variable-rate encoders. >=20 > The problem here will be defining "small". This will need to be = tested and > simulated so we know the impacts of different data usage patterns. = I'll > throw a straw-man proposal out there: if the increase in data usage = over > the last 1/2 second is below 20% of the total estimated channel = bandwidth, > no adjustment to the media channels shall be done, and normal = congestion > control mechanisms will be allowed to operate with no interference. = Above > that value, the media channels if possible will be adjusted down in > bandwidth by some amount related to the increase in data channel = bandwidth. >=20 > The reason for using the increase in bandwidth here is that for steady > flows, normal congestion control should operate well; the problem is = when > you have a spike in bandwidth use - the latency in reaction may be = longer > than the duration of the burst, and hurt end-to-end delay in the = meantime. > So when there's a sudden jump in data bandwidth, you temporarily = offset > media down to keep delay and buffering under control. You could also > increase media bitrates if a steady flow suddenly drops, though normal > congestion control mechanisms should use the now-available bandwidth > quickly on their own. Is there some way of measuring the spare queueing capacity of the path, = perhaps by periodic probing? To define "small" in a way that's = meaningful to the path, we'd be looking at a burst that can be queued in = the network without causing excessive delay or queue overflow/loss. = Using "1/2 second" or "20%" seems too arbitrary.=20 > JS Interface: >=20 > We need to tell the application about bandwidth changes, and give it = the > option of making choices, both in the allocation of bits among the = various > streams of data, and of the actual streams themselves (adding or = shutting > down streams, or switching modes (mono/stereo, codecs possibly, etc)). = If > the application doesn't care to make a choice we'll do it for them. = We'll > also want the JS application to be able to affect the = congestion-control > status of the data channels, so it could take bits from the data = channels > without engendering a tug-of-war and temporary = over-bandwidth/buffering. >=20 > There are inherent delays to some of these actions by the app, and in = an > over-bandwidth case we need to reduce bandwidth *now*, so we may want = to > have the "I'm over-bandwidth" case start by automatically reducing > bandwidth if possible, and inform the JS app of the reduction and let = it > rebalance or change the details or nature of the call. >=20 > We could use some good straw-men proposals for an API here to the JS = code. The right model might be for the application to communicate policy for = how to adapt, which the browser then implements. Putting Javascript in = the congestion control loop is a concern because of the slow response, = which runs the risk of causing oscillation. If we can let the browser = run the rate adaption mechanism that's more likely to be stable, and = leave the slower Javascript to make the decision about adaptation = policy. --=20 Colin Perkins http://csperkins.org/ From kpfleming@digium.com Fri Oct 7 12: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 4478621F8C4E for ; Fri, 7 Oct 2011 12:46:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.081 X-Spam-Level: X-Spam-Status: No, score=-106.081 tagged_above=-999 required=5 tests=[AWL=-0.482, BAYES_00=-2.599, J_BACKHAIR_43=1, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u3k926fk9leo for ; Fri, 7 Oct 2011 12:46:51 -0700 (PDT) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by ietfa.amsl.com (Postfix) with ESMTP id 485E221F8BDB for ; Fri, 7 Oct 2011 12:46:51 -0700 (PDT) Received: from zimbra.digium.internal ([10.24.55.203] helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1RCGQm-00087f-Jz for rtcweb@ietf.org; Fri, 07 Oct 2011 14:50:04 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id 94BF81A2006 for ; Fri, 7 Oct 2011 14:50:04 -0500 (CDT) Received: from zimbra.hsv.digium.com ([127.0.0.1]) by localhost (zimbra.hsv.digium.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KLPB+UpWN0Vx for ; Fri, 7 Oct 2011 14:50:04 -0500 (CDT) Received: from [10.24.250.46] (unknown [10.24.250.46]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id F08941A2001 for ; Fri, 7 Oct 2011 14:50:03 -0500 (CDT) Message-ID: <4E8F57EB.8030504@digium.com> Date: Fri, 07 Oct 2011 14:50:03 -0500 From: "Kevin P. Fleming" Organization: Digium, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110922 Thunderbird/3.1.15 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: 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, 07 Oct 2011 19:46:52 -0000 On 09/16/2011 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? (resurrecting this old thread) Regardless of the signaling protocol in use, it seems unlikely to me=20 that a web application developer is going to want to be *involved* in=20 the call signaling itself; they are going to pass that responsibility=20 over to some existing code/library/server/system (which could mean just=20 shuttling SIP messages back and forth between WebSocket connections and=20 UDP connections). If this assumption is true, then the web application developer who wants=20 to achieve the result you describe above is going to choose a SIP=20 library/server that allows them access to the call states and other=20 pieces of information that they need, in preference to those who don't=20 make that information available. I can't imagine that a practical=20 solution would be to choose a SIP library/server that handles the calls=20 in an 'opaque' fashion but then build a web application that is required=20 to snoop on all the signaling to be able to monitor activity. --=20 Kevin P. Fleming Digium, Inc. | Director of Software Technologies Jabber: kfleming@digium.com | SIP: kpfleming@digium.com | Skype: kpflemin= g 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at www.digium.com & www.asterisk.org From randell-ietf@jesup.org Fri Oct 7 14:08: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 B149021F8C44 for ; Fri, 7 Oct 2011 14:08:43 -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.026, 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 Pmc3ni8M3Hys for ; Fri, 7 Oct 2011 14:08: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 0DD0D21F8C32 for ; Fri, 7 Oct 2011 14:08:42 -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 1RCHi0-0003Wn-Rh for rtcweb@ietf.org; Fri, 07 Oct 2011 16:11:56 -0500 Message-ID: <4E8F6A26.6020407@jesup.org> Date: Fri, 07 Oct 2011 17:07:50 -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: <4E8DCA06.5060506@jesup.org> <4E8E3005.3090307@mti-systems.com>, <4E8E35C4.3000509@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] Congestion Control 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: Fri, 07 Oct 2011 21:08:43 -0000 On 10/7/2011 3:02 PM, Bernard Aboba wrote: > > The fallback/simplest model would be to just consider the data channels > > under SCTP and the media channels to be separate flows, and let them > > fight for bandwidth as normal. > > [BA] There are multiple concerns here. One was about DoS attacks, which > was about having the recipient confirm the desired bandwidth. That's > what Harald mentioned. > > The other issue is congestion control/codec adaptation (e.g. responding > to RFC 3714 concerns). While I understand the need for this on the > datagram channel, with respect to congestion control of RTP traffic, won't > adaptation be codec-specific? If the codec doesn't adapt (e.g. G.711) or > does so based on RTCP feedback, how would an additional congestion > control mechanism work? This (this proposal) is the mechanism which will tell the sender to adapt their codec settings (video encoder bitrate, etc). > > Don't forget that we normally will have a media channel active, and if > > video is being sent (and to a lesser extent audio, especially if we're > > using Opus) that media channel is adaptive and can adapt upwards to find > > the limits of bandwidth. > > [BA] Yes, it can but today that adaption is typically based on RTCP, right? Not on traditional SR/RR RTCP sub-packets, but on AVPF Feedback messages; either a variant of TMMBR (if we do all the bandwidth calculations in the client), or a message where we feed back cooked arrival statistics to the sender via a new Feedback message. If we don't get this info from the receiver we'll fall back to classic RR/SR-based adaptation, which sucks. Doable, but sucks (especially if you only get a report average every 5 seconds). > > Decisions like that are tough or impossible for webrtc to make on it's > > own because it doesn't have the context of the application to guide it. > > [BA] The problem is that handling the events correctly will also probably be > outside the capability of your average application developer. So enabling > reasonable things to happen by default is probably a practical requirement. We'll definitely supply or apply defaults, and if the application doesn't choose we'll handle it for them. We may have some hinting to guide our default adaptation (relative priorities). > > That said, the interface and parameters and style for interacting with > > the JS app is the thing this posting is weakest on, since I'm not > > well-versed in the common API paradigms that JS app developers expect, > > and I'd love proposals for how we expose these choices and information > > to the app. > > [BA] The problem in my mind is whether we're really expecting RTCWEB > Codecs do something with the additional information provided. You should read Harald's draft for the base algorithm that we'll be modifying to provide this. The base algorithm is from a very good class of low-delay congestion control algorithms, based on bottleneck router bufferstate sensing: http://www.ietf.org/id/draft-alvestrand-rtcweb-congestion-00.txt -- Randell Jesup randell-ietf@jesup.org From randell-ietf@jesup.org Fri Oct 7 14:38: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 45F2921F8BF4 for ; Fri, 7 Oct 2011 14:38:25 -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 y3WzCZwF6Qam for ; Fri, 7 Oct 2011 14:38: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 1B09521F8BF0 for ; Fri, 7 Oct 2011 14:38: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 1RCIAk-0008FJ-DA for rtcweb@ietf.org; Fri, 07 Oct 2011 16:41:38 -0500 Message-ID: <4E8F711B.3050808@jesup.org> Date: Fri, 07 Oct 2011 17:37:31 -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: <4E8DCA06.5060506@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] Congestion Control 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: Fri, 07 Oct 2011 21:38:25 -0000 On 10/7/2011 3:12 PM, Colin Perkins wrote: > [inline] > > On 6 Oct 2011, at 16:32, Randell Jesup wrote: > ... >> Startup: >> >> There are issues both with starting too low (quality is poor at the start >> and takes a while to get better), and with starting too high (you >> immediately can get into a delay situation and have to go into recovery). >> In general, starting too low is better than starting too high, as when we >> ramp up past the bottleneck we will not be too far over the limit and so >> recovery will be easier. In general, the bottleneck link is often >> upstream, though this is moderating as high-bandwidth broadband becomes >> more common. >> >> Options include: >> a) Start at fixed value >> b) Start at N% below the value from the last call with this person >> (probably requires the App to help here) >> c) Start at N% below the value from the last call with anyone >> d) Have the other side tell us the rate they successfully received in the >> last call. Start the call at the lower of the last-call reception >> rate from the far end or our last-call sending rate, minus n% >> e) probe bandwidth at or before the start of the call using a packet >> train >> >> 'a' will be quite sub-optimal for most cases, though if the value is >> low enough it won't be over-bandwidth. Some applications (games, etc) >> may want to limit the starting bandwidth to avoid negative interactions >> with other dataflows. >> >> 'b' has a problem that if the last call had a much higher bottleneck >> bandwidth (especially on the remote downstream), the new call may be >> over-bandwidth, perhaps badly. This won't be the norm, but may happen >> especially with mobile/wifi at either end. >> >> 'c' has a problem that if the last callee had a much higher bottleneck >> bandwidth (especially on the remote downstream), the new call may be >> over-bandwidth, perhaps badly. If the caller's upstream bandwidth is high >> compared to typical downstream bandwidth, then the likelihood of starting >> over-bandwidth is high. >> >> 'd' has the advantage of selecting an appropriate value regardless of >> whether the bottleneck is on upstream or downstream. The downside of 'd' >> is that the bottlenecks may have changed since the last call in which case >> we may start over-bandwidth. The historical data could be transferred >> via pre-call signalling. >> >> 'e' allows direct measurement of the current call bottlenecks. However 'e' >> can be misled if a mid-call router that isn't the bottleneck buffers the >> packet train while housekeeping or doing other operations and then releases >> them (it can collapse the signal from an earlier bottleneck). It would >> need to be combined with starting on the low side until a valid measurement >> is completed. Single measurements are imprecise with packet trains. > For a new call, the only safe approach for the network would seem to be option (a), starting at a low rate, followed by a fairly rapid increase in rate to find the safe operating point (i.e., mirroring TCP slow start in concept, if not in detail). The low rate would be chosen to support the voice channel, presumably, so the call is useful immediately, but might then take several RTTs to ramp up to a high enough rate for video to be usable. An initial delay on the video is not an ideal user experience, but I don't see it as being especially problematic provided the voice channel is usable immediately, and we don't seem to have safe options for avoiding it. I understand your concern, and agree one should start "low" - but I also feel that for many applications and many users, this would be an over-conservatism that would seriously degrade a very important point in a communication. That initial "answer" behavior had a big impact on the user experience and in the end, utility to the user. In "most" calls (I'd guess for residential desktop browsers >95%, laptops >70% though much more variable) the bottleneck will be the same or similar to the last call - the local upstream, which is fairly constant. There are users and use-cases where this consistency will not apply - mobile laptop users (when away from desk/office), tablet/handsets. I will note that in most of these cases the change in bottleneck will tend to be less than 2x, so major changes in bandwidth will be fairly uncommon. (You can get a hint on this by checking for external IP address changes!) In most videophones and soft clients that I've looked at, they have a configured bitrate set by the user and either start at that bitrate, or start at a fraction of that bitrate. At WorldGate, we started at a sliding percentage of the configured bandwidth - a higher percentage at low bandwidths, and down to 50% of configured at high bandwidths, combined (as you suggest) with a much higher ramp-up rate (and faster/further cut-back on problems) for the first seconds of the call. These things, taken together, make we want to be a bit more aggressive at using history, and perhaps also use the recent N calls' variance in bottleneck rate as a guide (if they're all good at higher rates, start at 50 or 60% of the average; if there's a lot of variance (laptop moving around) use not the last call, but perhaps the lowest quartile or 10th minus 10 or 20%. Also - this is something that I strongly feel should not be normative. This is guidance and I do feel that there is a place for the application to provide input and/or user preference here. I think we *should* provide guidance and defaults. > Using a packet pair/train to get an estimate of the available bandwidth is appealing, but I'm unconvinced it's accurate enough to be reliable. We've done packet pair measurements to residential links that show extremely inaccurate (high) bandwidth estimates in many cases, so I wouldn't trust that as an initial sending rate. Using a longer packet train would improve accuracy, but at the cost of loading the path, and potentially disrupting any traffic sharing the path. I'm not sure such a bandwidth estimate is that worthwhile if it delays/disrupts the start of the voice channel. I am likewise leery of packet trains, especially short start-of-call trains. They're interesting, but as you mention they don't seem reliable enough. > When restarting a previously application limited flow after some short pause in transmission (e.g., the centralised video mixer scenario, where only the active speaker sends video to the mixer), then I'm much more comfortable with restarting at or near the previous rate, provided there's been no indication that the path has changed. The rationale here is that you've had some recent indication that the path can support the rate, but with a new connection, even if to someone you've previously spoken with, there's much less of a guarantee that the available bandwidth is consistent with the previous observation. Agreed. >> Even if the data flows are separately congestion controlled, in many uses >> they will be non-continuous flows (discrete messages as opposed to data or >> file transfers). These sorts of channels have different needs and >> different impacts on the media channels from continuous flows: they're >> bursty; low delay is important (especially on the initial packet for a >> burst, which is often the only packet), and without a steady stream >> congestion control will have little effect - and will have little impact on >> the media flows. For small bursts of data traffic, the "right" solution >> may be to simply ignore them up to some limit, and above that limit start >> to subtract the data channel usage from the available bandwidth for >> variable-rate encoders. >> >> The problem here will be defining "small". This will need to be tested and >> simulated so we know the impacts of different data usage patterns. I'll >> throw a straw-man proposal out there: if the increase in data usage over >> the last 1/2 second is below 20% of the total estimated channel bandwidth, >> no adjustment to the media channels shall be done, and normal congestion >> control mechanisms will be allowed to operate with no interference. Above >> that value, the media channels if possible will be adjusted down in >> bandwidth by some amount related to the increase in data channel bandwidth. >> >> The reason for using the increase in bandwidth here is that for steady >> flows, normal congestion control should operate well; the problem is when >> you have a spike in bandwidth use - the latency in reaction may be longer >> than the duration of the burst, and hurt end-to-end delay in the meantime. >> So when there's a sudden jump in data bandwidth, you temporarily offset >> media down to keep delay and buffering under control. You could also >> increase media bitrates if a steady flow suddenly drops, though normal >> congestion control mechanisms should use the now-available bandwidth >> quickly on their own. > Is there some way of measuring the spare queueing capacity of the path, perhaps by periodic probing? To define "small" in a way that's meaningful to the path, we'd be looking at a burst that can be queued in the network without causing excessive delay or queue overflow/loss. Using "1/2 second" or "20%" seems too arbitrary. It may be possible to use naturally-occuring bursts (or slightly artificially-contrived bursts) to probe the channel. For example, periodic or error-recovery iframes amount to a fairly large burst of large packets; measuring the dispersion at the reception end may will give you a reasonable estimate of unused bandwidth. (I'll note that if you don't have access to the raw network interface this might be a little noisier). >> JS Interface: >> >> We need to tell the application about bandwidth changes, and give it the >> option of making choices, both in the allocation of bits among the various >> streams of data, and of the actual streams themselves (adding or shutting >> down streams, or switching modes (mono/stereo, codecs possibly, etc)). If >> the application doesn't care to make a choice we'll do it for them. We'll >> also want the JS application to be able to affect the congestion-control >> status of the data channels, so it could take bits from the data channels >> without engendering a tug-of-war and temporary over-bandwidth/buffering. >> >> There are inherent delays to some of these actions by the app, and in an >> over-bandwidth case we need to reduce bandwidth *now*, so we may want to >> have the "I'm over-bandwidth" case start by automatically reducing >> bandwidth if possible, and inform the JS app of the reduction and let it >> rebalance or change the details or nature of the call. >> >> We could use some good straw-men proposals for an API here to the JS code. > The right model might be for the application to communicate policy for how to adapt, which the browser then implements. Putting Javascript in the congestion control loop is a concern because of the slow response, which runs the risk of causing oscillation. If we can let the browser run the rate adaption mechanism that's more likely to be stable, and leave the slower Javascript to make the decision about adaptation policy. Agreed, though some of the adaptations have to occur at the application level (turning off channels, which may involve UI changes, etc). That was why I suggested we adapt using defaults (and any hints given ("policy" in your post)), and then inform the JS app of the change and allow it to rebalance or re-allocate the BW usage, or to change the already-made decisions. This helps guarantee we have working defaults and response speed. I fear if we try to push all that logic down into the media code it becomes too complex, because you have to anticipate any way an application might want to react, and provide it (and test it). -- Randell Jesup randell-ietf@jesup.org From fluffy@cisco.com Fri Oct 7 15:11: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 7FC5E21F8BF8 for ; Fri, 7 Oct 2011 15:11:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.015 X-Spam-Level: X-Spam-Status: No, score=-103.015 tagged_above=-999 required=5 tests=[AWL=-0.416, 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 Ne2ASsnyzLTP for ; Fri, 7 Oct 2011 15:11:02 -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 D5C2C21F8BF7 for ; Fri, 7 Oct 2011 15:11:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=1352; q=dns/txt; s=iport; t=1318025657; x=1319235257; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=ogrUBLGNQHdXedNYXzS1NK1OsfGDGMEuOFmb+R6qYzc=; b=j8apuK2CVjHTY7Ock3Dsig9+qLQkBQNScFYwRjdMu/eVzWKh2p3DyzAH ygm961z0E+jEnzrlyaOMPAk3QN64wbNST6ZoITto18pPwoWjgM4Uq2eds iYtHUMpjAkmWxRSpk7xPPPfG7fQpenMu+ykbTDQMTZYvEsmbI+aP82Sww o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAO14j06rRDoI/2dsb2JhbABEqBiBBYFTAQEBAwESAScuBgsFCwtGVwYuB4dcmVcBnjKGT2EEh32LcoUojD8 X-IronPort-AV: E=Sophos;i="4.68,504,1312156800"; d="scan'208";a="6612813" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 07 Oct 2011 22:14:17 +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 p97MEGCD028772; Fri, 7 Oct 2011 22:14:17 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: Date: Fri, 7 Oct 2011 16:14:16 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <777F0250-BB18-4F0D-82FD-629FA6B76E48@cisco.com> References: To: Ted Hardie X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Making progress on the signaling discussion (NB: Action items enclosed!) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2011 22:11:03 -0000 Hi Ted,=20 I do plan to submit a signaling draft before next friday. The draft will = based on figuring out what the minimal thing is we need to have wrapped = around SDP to be able to implement offer/answer in a way that meets our = uses cases.=20 Cullen On Oct 4, 2011, at 10:01 AM, Ted Hardie wrote: > At today's Chairs call, Cullen, Magnus and I had a discussion of how = to make progress on the signaling discussion. We feel the mailing list = discussion needs to have more concrete proposals in order to make = progress, and so we're putting forward the following: >=20 > 1) If you plan to put forward a draft proposing a concrete solution in = this space, please send your name to the mailing list with that intent = by October 7th *THIS FRIDAY*. >=20 > 2) Please have a -00 draft out for discussion by October 14th (the = following Friday). This is to allow for a discussion and update prior = to the -01 deadlines. >=20 > 3) We will hold a conference call to discuss the drafts on October = 21st (the Friday after that). >=20 > Updates based on that discussion then have until the -01 drafts = deadline to be complete. >=20 > This is aggressive, but we feel we need to have at least -00s for the = different ideas in place in order to make real progress. >=20 > thanks, >=20 > Ted, Magnus, Cullen From jmillan@aliax.net Sat Oct 8 01: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 654C521F8B45 for ; Sat, 8 Oct 2011 01:59:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.07 X-Spam-Level: X-Spam-Status: No, score=-2.07 tagged_above=-999 required=5 tests=[AWL=-0.393, 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 sX5kN9j0sqRO for ; Sat, 8 Oct 2011 01:59: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 AF81B21F8B36 for ; Sat, 8 Oct 2011 01:59:28 -0700 (PDT) Received: by iaby26 with SMTP id y26so6244837iab.31 for ; Sat, 08 Oct 2011 02:02:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.5.73 with SMTP id 9mr2784896ibu.60.1318064562557; Sat, 08 Oct 2011 02:02:42 -0700 (PDT) Received: by 10.231.36.201 with HTTP; Sat, 8 Oct 2011 02:02:42 -0700 (PDT) In-Reply-To: <4E8F57EB.8030504@digium.com> References: <4E8F57EB.8030504@digium.com> Date: Sat, 8 Oct 2011 11:02:42 +0200 Message-ID: From: =?ISO-8859-1?Q?Jos=E9_Luis_Mill=E1n?= To: "Kevin P. Fleming" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org 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: Sat, 08 Oct 2011 08:59:29 -0000 Kevin, 2011/10/7 Kevin P. Fleming : > On 09/16/2011 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? > > (resurrecting this old thread) > > Regardless of the signaling protocol in use, it seems unlikely to me that= a > web application developer is going to want to be *involved* in the call > signaling itself; they are going to pass that responsibility over to some > existing code/library/server/system (which could mean just shuttling SIP > messages back and forth between WebSocket connections and UDP connections= ). > > If this assumption is true, then the web application developer who wants = to > achieve the result you describe above is going to choose a SIP > library/server that allows them access to the call states and other piece= s > of information that they need, in preference to those who don't make that > information available. I can't imagine that a practical solution would be= to > choose a SIP library/server that handles the calls in an 'opaque' fashion > but then build a web application that is required to snoop on all the > signaling to be able to monitor activity. > Web developers have to use well defined APIs so they don't need to know how the underlaying protocol works. Instead, they rely on the API methods and information to achieve what I=F1aki is stating. > -- > Kevin P. Fleming > Digium, Inc. | Director of Software Technologies > Jabber: kfleming@digium.com | SIP: kpfleming@digium.com | Skype: kpflemin= g > 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA > Check us out at www.digium.com & www.asterisk.org > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From saul@ag-projects.com Sat Oct 8 02:05: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 E8F7321F8B13 for ; Sat, 8 Oct 2011 02:05:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qvy6MfuQjTie for ; Sat, 8 Oct 2011 02:05:49 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 690EC21F8AAC for ; Sat, 8 Oct 2011 02:05:49 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id AC9FAB01B8; Sat, 8 Oct 2011 11:09:03 +0200 (CEST) Received: from [192.168.1.134] (235.4.222.87.dynamic.jazztel.es [87.222.4.235]) by mail.sipthor.net (Postfix) with ESMTPSA id 00A12B0057; Sat, 8 Oct 2011 11:09:02 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Saul Ibarra Corretge In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF510F14CD@sonusinmail02.sonusnet.com> Date: Sat, 8 Oct 2011 11:09:03 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6CD854E0-7E8E-49C5-B320-659365860A1A@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><2E239D6FCD033C4BAF15F386A979BF510F137B@sonusinmail02.sonusnet.com><226C9800-9791-465A-B519-40935E2D135F@phonefromhere.com><4E8B1B86.2080805@jesup.org> <8584590C8D7DD141AA96D01920FC6C698C8A84ED@gbplmail03.genband.com> <2E239D6FCD033C4BAF15F386A979BF510F14CD@sonusinmail02.sonusnet.com> To: Ravindran Parthasarathi 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: Sat, 08 Oct 2011 09:05:50 -0000 On Oct 5, 2011, at 7:49 PM, Ravindran Parthasarathi wrote: > Hi Jim, >=20 > For the given RTCWeb basic communication, if some other better = signaling > protocol exists, we will adopt for it.=20 >=20 And who will judge if protocol X is "better" than protocol Y? In what = context? Under what assumptions? I don't this this is the right = direction. --=20 Sa=FAl Ibarra Corretg=E9 AG Projects From saul@ag-projects.com Sat Oct 8 02: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 27B2B21F8B27 for ; Sat, 8 Oct 2011 02:15:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1puwSyOXx3IX for ; Sat, 8 Oct 2011 02:15:29 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 5B84821F8B2D for ; Sat, 8 Oct 2011 02:15:29 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id DF4EEB01B8; Sat, 8 Oct 2011 11:18:44 +0200 (CEST) Received: from [192.168.1.134] (235.4.222.87.dynamic.jazztel.es [87.222.4.235]) by mail.sipthor.net (Postfix) with ESMTPSA id 9EEECB019E; Sat, 8 Oct 2011 11:18:43 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Saul Ibarra Corretge In-Reply-To: <7F79D20D-42DF-49D0-8D2F-A11ACE3A87C8@csperkins.org> Date: Sat, 8 Oct 2011 11:18:43 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <545388B3-3189-4291-BD1D-52898B888F3E@phonefromhere.com> <4E8BC0ED.2020001@skype.net> <4E8BDC3B.7000501@skype.net> <7F79D20D-42DF-49D0-8D2F-A11ACE3A87C8@csperkins.org> To: Colin Perkins X-Mailer: Apple Mail (2.1084) 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, 08 Oct 2011 09:15:30 -0000 On Oct 7, 2011, at 12:11 AM, Colin Perkins wrote: > On 5 Oct 2011, at 18:20, Roman Shpount wrote: >> On Wed, Oct 5, 2011 at 7:00 AM, Neil Stratford = wrote: >> I'm not sure I understand why this is such a problem. XMPP/Jingle = defines it's own mapping, which is a common VoIP protocol that is widely = supported. I'd much rather that the JS API is as expressive as possible = in codec specific matters - for example even to the point of providing = callbacks to the JS on certain codec level events, such as decoding a = DTMF digit. >> =20 >> What we need is some way to expose all possible codec parameter = combinations to JavaScript API. MMUSIC/PAYLOAD specifications for codec = typically define CODEC parameters and how they are encoded in SDP/MIME = content type, but they fall short of defining a way to list all the = capabilities. >=20 > I'm not convinced that exposing all possible codec parameter = combinations is an appropriate goal. There is simply too much = flexibility present with many of the codecs, especially in combination, = for the signalling to be reasonable if all the flexibility is exposed. = Better, I think, for the browser to expose a set of known-reasonable = combinations, and parameter ranges, from which the most appropriate = choice is picked. Maybe capabilities could be expressed in terms of "codecs" and = "profiles". A profile is a set of properties attached to a codec under a = given name, lets say codec H264 with "HD" profile or "SD" profile. = Having the ability to make a custom profile would be nice, for those who = need/want to have a more fine grained control over it. --=20 Sa=FAl Ibarra Corretg=E9 AG Projects From saul@ag-projects.com Sat Oct 8 02:27: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 39CF921F8AFD for ; Sat, 8 Oct 2011 02:27:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V7bus6Ko-3+O for ; Sat, 8 Oct 2011 02:27:38 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 8F48E21F85A7 for ; Sat, 8 Oct 2011 02:27:38 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 286DFB01B8; Sat, 8 Oct 2011 11:30:53 +0200 (CEST) Received: from [192.168.1.134] (235.4.222.87.dynamic.jazztel.es [87.222.4.235]) by mail.sipthor.net (Postfix) with ESMTPSA id BEE28B019E; Sat, 8 Oct 2011 11:30:52 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Saul Ibarra Corretge In-Reply-To: Date: Sat, 8 Oct 2011 11:30:51 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <91986BEB-B85F-483D-A1DA-46236B2592D9@ag-projects.com> References: <2E239D6FCD033C4BAF15F386A979BF510F1367@sonusinmail02.sonusnet.com> <4E8AC222.4050308@alvestrand.no> <2E239D6FCD033C4BAF15F386A979BF510F14CE@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF510F14FD@sonusinmail02.sonusnet.com> <393F1888-F834-4DAE-B6B1-1C5D35EE3292@phonefromhere.com> <2E239D6FCD033C4BAF15F386A979BF510F152B@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF510F1532@sonusinmail02.sonusnet.com> To: Neil Stratford X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Review request for RTCWeb standard 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: Sat, 08 Oct 2011 09:27:39 -0000 On Oct 7, 2011, at 1:53 PM, Neil Stratford wrote: > On Fri, Oct 7, 2011 at 12:40 PM, Ravindran Parthasarathi = wrote: > Browser to browser real time communication is no different from other = real-time communication apart from the existing web infrastructure. In = case your argument is to use the existing web infrastructure like = websocket, I agree with you. >=20 >=20 > It is different to traditional RTC - we have a javascript execution = engine intimately tied in to every client. This completely changes the = solution space. > =20 >=20 > But in case it is not the reason, Could you please list the reason for = new signaling protocol requirement . >=20 >=20 > I already listed them:=20 >=20 > =20 >=20 > - No server side infrastructure (SIP proxies etc) to maintain or = configure. >=20 > - No special understanding in the server side web application beyond = discovering peer identities you might want to communicate with. >=20 >=20 Looks like some zeroconf style thing, it could be an interesting thing = to explore. Do you have any ideas on how the discovery would work over = the Internet? --=20 Sa=FAl Ibarra Corretg=E9 AG Projects From neils@vipadia.com Sat Oct 8 06: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 80EB321F8C0C for ; Sat, 8 Oct 2011 06:30:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.946 X-Spam-Level: X-Spam-Status: No, score=-2.946 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oq0bKGSthQSX for ; Sat, 8 Oct 2011 06:30: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 BB02E21F8BB0 for ; Sat, 8 Oct 2011 06:30:56 -0700 (PDT) Received: by iaby26 with SMTP id y26so6498556iab.31 for ; Sat, 08 Oct 2011 06:34:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.24.96 with SMTP id u32mr4994884ibb.61.1318080852787; Sat, 08 Oct 2011 06:34:12 -0700 (PDT) Sender: neils@vipadia.com Received: by 10.231.200.146 with HTTP; Sat, 8 Oct 2011 06:34:12 -0700 (PDT) In-Reply-To: <91986BEB-B85F-483D-A1DA-46236B2592D9@ag-projects.com> References: <2E239D6FCD033C4BAF15F386A979BF510F1367@sonusinmail02.sonusnet.com> <4E8AC222.4050308@alvestrand.no> <2E239D6FCD033C4BAF15F386A979BF510F14CE@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF510F14FD@sonusinmail02.sonusnet.com> <393F1888-F834-4DAE-B6B1-1C5D35EE3292@phonefromhere.com> <2E239D6FCD033C4BAF15F386A979BF510F152B@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF510F1532@sonusinmail02.sonusnet.com> <91986BEB-B85F-483D-A1DA-46236B2592D9@ag-projects.com> Date: Sat, 8 Oct 2011 14:34:12 +0100 X-Google-Sender-Auth: wWSJ4MD_T2o4XRJqHL1DyJGYWJY Message-ID: From: Neil Stratford To: Saul Ibarra Corretge Content-Type: multipart/alternative; boundary=0015177414280400b004aec99d70 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Review request for RTCWeb standard 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: Sat, 08 Oct 2011 13:30:57 -0000 --0015177414280400b004aec99d70 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Oct 8, 2011 at 10:30 AM, Saul Ibarra Corretge wrote: > > On Oct 7, 2011, at 1:53 PM, Neil Stratford wrote: > > - No server side infrastructure (SIP proxies etc) to maintain or > configure. > > > > - No special understanding in the server side web application beyond > discovering peer identities you might want to communicate with. > > Looks like some zeroconf style thing, it could be an interesting thing to > explore. Do you have any ideas on how the discovery would work over the > Internet? I imagine a signalling protocol such as this would look a lot like p2psip, though there is something interesting about baking a p2p overlay network into the browser and exposing it through an API that could then be used to build all kinds of services in javascript, including p2p SIP signalling for RTC. The great thing about *not* defining a signalling protocol is that we are free to experiment with signalling in all kinds of ways. --0015177414280400b004aec99d70 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sat, Oct 8, 2011 at 10:30 AM, Saul Ibarra Corretge <= ;saul@ag-projects.com> wrote:

On Oct 7, 2011, at 1:53 PM, Neil Stratford wrote:
> - No server side = infrastructure (SIP proxies etc) to maintain or configure.
>
> - No special understanding in the server side web application beyond d= iscovering peer identities you might want to communicate with.

Looks like some zeroconf style thing, it could be an interesting thin= g to explore. Do you have any ideas on how the discovery would work over th= e Internet?

I imagine a signalling protocol= such as this would look a lot like p2psip, though there is something inter= esting about baking a p2p overlay network into the browser and exposing it = through an API that could then be used to build all kinds of services in ja= vascript, including p2p SIP signalling for RTC.

The great thing about *not* defining a signalling proto= col is that we are free to experiment with signalling in all kinds of ways.=
--0015177414280400b004aec99d70-- From saul@ag-projects.com Sat Oct 8 06:43: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 8688B21F8AED for ; Sat, 8 Oct 2011 06:43:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id brYCIbIJgsiQ for ; Sat, 8 Oct 2011 06:43:01 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id D98DB21F8ACC for ; Sat, 8 Oct 2011 06:43:00 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 3D859B01B7; Sat, 8 Oct 2011 15:46:15 +0200 (CEST) Received: from [192.168.1.134] (235.4.222.87.dynamic.jazztel.es [87.222.4.235]) by mail.sipthor.net (Postfix) with ESMTPSA id 68016B0057; Sat, 8 Oct 2011 15:46:15 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Saul Ibarra Corretge In-Reply-To: Date: Sat, 8 Oct 2011 15:46:13 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <59F098F9-4A9E-4D85-B9E7-A53D3ED1C6BE@ag-projects.com> References: <2E239D6FCD033C4BAF15F386A979BF510F1367@sonusinmail02.sonusnet.com> <4E8AC222.4050308@alvestrand.no> <2E239D6FCD033C4BAF15F386A979BF510F14CE@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF510F14FD@sonusinmail02.sonusnet.com> <393F1888-F834-4DAE-B6B1-1C5D35EE3292@phonefromhere.com> <2E239D6FCD033C4BAF15F386A979BF510F152B@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF510F1532@sonusinmail02.sonusnet.com> <91986BEB-B85F-483D-A1DA-46236B2592D9@ag-projects.com> To: Neil Stratford X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Review request for RTCWeb standard 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: Sat, 08 Oct 2011 13:43:01 -0000 On Oct 8, 2011, at 3:34 PM, Neil Stratford wrote: > On Sat, Oct 8, 2011 at 10:30 AM, Saul Ibarra Corretge = wrote: >=20 > On Oct 7, 2011, at 1:53 PM, Neil Stratford wrote: > > - No server side infrastructure (SIP proxies etc) to maintain or = configure. > > > > - No special understanding in the server side web application beyond = discovering peer identities you might want to communicate with. >=20 > Looks like some zeroconf style thing, it could be an interesting thing = to explore. Do you have any ideas on how the discovery would work over = the Internet? >=20 > I imagine a signalling protocol such as this would look a lot like = p2psip, though there is something interesting about baking a p2p overlay = network into the browser and exposing it through an API that could then = be used to build all kinds of services in javascript, including p2p SIP = signalling for RTC. >=20 > The great thing about *not* defining a signalling protocol is that we = are free to experiment with signalling in all kinds of ways. I'm all for it :-) --=20 Sa=FAl Ibarra Corretg=E9 AG Projects From kpfleming@digium.com Sat Oct 8 07: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 AB0B721F8BF8 for ; Sat, 8 Oct 2011 07:14:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.314 X-Spam-Level: X-Spam-Status: No, score=-105.314 tagged_above=-999 required=5 tests=[AWL=-1.007, BAYES_00=-2.599, J_BACKHAIR_43=1, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AKUlJLOS175y for ; Sat, 8 Oct 2011 07:14:21 -0700 (PDT) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by ietfa.amsl.com (Postfix) with ESMTP id BD51521F8BF4 for ; Sat, 8 Oct 2011 07:14:21 -0700 (PDT) Received: from zimbra.digium.internal ([10.24.55.203] helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1RCXib-0004ty-RA for rtcweb@ietf.org; Sat, 08 Oct 2011 09:17:37 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id C59F1D82A3 for ; Sat, 8 Oct 2011 09:17:37 -0500 (CDT) Received: from zimbra.hsv.digium.com ([127.0.0.1]) by localhost (zimbra.hsv.digium.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MCZ4lDMoVV4D for ; Sat, 8 Oct 2011 09:17:37 -0500 (CDT) Received: from [192.168.1.10] (173-18-150-64.client.mchsi.com [173.18.150.64]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id D829CD8024 for ; Sat, 8 Oct 2011 09:17:36 -0500 (CDT) Message-ID: <4E905B7F.7010505@digium.com> Date: Sat, 08 Oct 2011 09:17:35 -0500 From: "Kevin P. Fleming" Organization: Digium, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110922 Thunderbird/3.1.15 MIME-Version: 1.0 CC: rtcweb@ietf.org References: <4E8F57EB.8030504@digium.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: Sat, 08 Oct 2011 14:14:22 -0000 On 10/08/2011 04:02 AM, Jos=E9 Luis Mill=E1n wrote: > Kevin, > > 2011/10/7 Kevin P. Fleming: >> On 09/16/2011 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 th= e >>> different audio/video streams between users connected to the web. Thi= s >>> 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 session= s >>> (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? >> >> (resurrecting this old thread) >> >> Regardless of the signaling protocol in use, it seems unlikely to me t= hat a >> web application developer is going to want to be *involved* in the cal= l >> signaling itself; they are going to pass that responsibility over to s= ome >> existing code/library/server/system (which could mean just shuttling S= IP >> messages back and forth between WebSocket connections and UDP connecti= ons). >> >> If this assumption is true, then the web application developer who wan= ts to >> achieve the result you describe above is going to choose a SIP >> library/server that allows them access to the call states and other pi= eces >> of information that they need, in preference to those who don't make t= hat >> information available. I can't imagine that a practical solution would= be to >> choose a SIP library/server that handles the calls in an 'opaque' fash= ion >> but then build a web application that is required to snoop on all the >> signaling to be able to monitor activity. >> > > Web developers have to use well defined APIs so they don't need to > know how the underlaying protocol works. Instead, they rely on the API > methods and information to achieve what I=F1aki is stating. I don't disagree with your statements here, but I'm not sure that those=20 statements change anything :-) This group is not defining APIs to be used on the *server* side, only on=20 the browser side. On the server side, if a web application wants to be=20 able to keep track of multimedia sessions and use that information for=20 various purposes, then yes... it will require APIs to do so. Those APIs=20 will be into whichever signaling library/server/component the web=20 application developer has chosen to handle the signaling of those=20 multimedia sessions. This was exactly my point, that the web application=20 would not be actively monitoring the signaling *itself* in order to keep=20 track of sessions... so if the signaling is just being routed by the web=20 application over to another component/server, that's perfectly=20 acceptable and doesn't interfere with the application's ability to keep=20 track of the sessions. --=20 Kevin P. Fleming Digium, Inc. | Director of Software Technologies Jabber: kfleming@digium.com | SIP: kpfleming@digium.com | Skype: kpflemin= g 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at www.digium.com & www.asterisk.org From ibc@aliax.net Sat Oct 8 09:34: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 6A79B21F8B53 for ; Sat, 8 Oct 2011 09:34:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[AWL=0.045, 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 ukGfDVhuRF1s for ; Sat, 8 Oct 2011 09:34:35 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id D5F8D21F8906 for ; Sat, 8 Oct 2011 09:34:34 -0700 (PDT) Received: by vws5 with SMTP id 5so4710639vws.31 for ; Sat, 08 Oct 2011 09:37:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.35.34 with SMTP id e2mr7130000vdj.52.1318091871171; Sat, 08 Oct 2011 09:37:51 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Sat, 8 Oct 2011 09:37:51 -0700 (PDT) In-Reply-To: References: <2E239D6FCD033C4BAF15F386A979BF510F1367@sonusinmail02.sonusnet.com> <4E8AC222.4050308@alvestrand.no> <2E239D6FCD033C4BAF15F386A979BF510F14CE@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF510F14FD@sonusinmail02.sonusnet.com> <393F1888-F834-4DAE-B6B1-1C5D35EE3292@phonefromhere.com> <2E239D6FCD033C4BAF15F386A979BF510F152B@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF510F1532@sonusinmail02.sonusnet.com> <91986BEB-B85F-483D-A1DA-46236B2592D9@ag-projects.com> Date: Sat, 8 Oct 2011 18:37:51 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Neil Stratford Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Review request for RTCWeb standard 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: Sat, 08 Oct 2011 16:34:35 -0000 2011/10/8 Neil Stratford : > The great thing about *not* defining a signalling protocol is that we are > free to experiment with signalling in all kinds of ways. Agreed. Defining a default/mandatory signaling protocol would limit future scenarios. We don't know yet what RTCweb will be used for. Signaling should depend on the needs of each service bringing media capabilities, and that is achieved by providing the signaling within a custom JavaScript code. Anyhow I expect I will read again (probably in any other thread) the same mail speaking about "the need for a default signaling protocol, as H323 or MEGACO", by ignoring any rationale given in this and other mails but most of the people in this maillist. I should make some SPAM filtering rule. Regards. --=20 I=C3=B1aki Baz Castillo From jmillan@aliax.net Sat Oct 8 14:48:29 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29CA521F8AE9 for ; Sat, 8 Oct 2011 14:48:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.03 X-Spam-Level: X-Spam-Status: No, score=-2.03 tagged_above=-999 required=5 tests=[AWL=-0.353, 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 lVmA8gzppCoh for ; Sat, 8 Oct 2011 14:48:27 -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 B205721F8A96 for ; Sat, 8 Oct 2011 14:48:27 -0700 (PDT) Received: by iaby26 with SMTP id y26so6926866iab.31 for ; Sat, 08 Oct 2011 14:51:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.69.80 with SMTP id y16mr5854750ibi.34.1318110703156; Sat, 08 Oct 2011 14:51:43 -0700 (PDT) Received: by 10.231.36.201 with HTTP; Sat, 8 Oct 2011 14:51:43 -0700 (PDT) In-Reply-To: <4E905B7F.7010505@digium.com> References: <4E8F57EB.8030504@digium.com> <4E905B7F.7010505@digium.com> Date: Sat, 8 Oct 2011 23:51:43 +0200 Message-ID: From: =?ISO-8859-1?Q?Jos=E9_Luis_Mill=E1n?= To: "Kevin P. Fleming" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org 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: Sat, 08 Oct 2011 21:48:29 -0000 2011/10/8 Kevin P. Fleming : > On 10/08/2011 04:02 AM, Jos=E9 Luis Mill=E1n wrote: >> >> Kevin, >> >> 2011/10/7 Kevin P. Fleming: >>> >>> On 09/16/2011 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? >>> >>> (resurrecting this old thread) >>> >>> Regardless of the signaling protocol in use, it seems unlikely to me th= at >>> a >>> web application developer is going to want to be *involved* in the call >>> signaling itself; they are going to pass that responsibility over to so= me >>> existing code/library/server/system (which could mean just shuttling SI= P >>> messages back and forth between WebSocket connections and UDP >>> connections). >>> >>> If this assumption is true, then the web application developer who want= s >>> to >>> achieve the result you describe above is going to choose a SIP >>> library/server that allows them access to the call states and other >>> pieces >>> of information that they need, in preference to those who don't make th= at >>> information available. I can't imagine that a practical solution would = be >>> to >>> choose a SIP library/server that handles the calls in an 'opaque' fashi= on >>> but then build a web application that is required to snoop on all the >>> signaling to be able to monitor activity. >>> >> >> Web developers have to use well defined APIs so they don't need to >> know how the underlaying protocol works. Instead, they rely on the API >> methods and information to achieve what I=F1aki is stating. > > I don't disagree with your statements here, but I'm not sure that those > statements change anything :-) > > This group is not defining APIs to be used on the *server* side, only on = the > browser side. On the server side, if a web application wants to be able to > keep track of multimedia sessions and use that information for various > purposes, then yes... it will require APIs to do so. Sorry if I'm not underdstanding you well. I understand from the paragraph above that the client may use these APIs to consult the server about it's own state (client's state). The web application does not need to monitor the signalling, but will be aware of its own state (sessions..) by simply relying on the signalling API. ie: Client executes the 'call' method of the API 'X', this method executes the corresponding callbacks according to the state of the running call: 'trying', 'ringing', 'ok'. This way the client is aware of its own state. If this is not what you meant, could you please clarify? Regards Those APIs will be into > whichever signaling library/server/component the web application develope= r > has chosen to handle the signaling of those multimedia sessions. This was > exactly my point, that the web application would not be actively monitori= ng > the signaling *itself* in order to keep track of sessions...so if the > signaling is just being routed by the web application over to another > component/server, that's perfectly acceptable and doesn't interfere with = the > application's ability to keep track of the sessions. > > -- > Kevin P. Fleming > Digium, Inc. | Director of Software Technologies > Jabber: kfleming@digium.com | SIP: kpfleming@digium.com | Skype: kpflemin= g > 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA > Check us out at www.digium.com & www.asterisk.org > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From sebastien.cubaud@orange.com Sun Oct 9 03:00: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 955B121F8B25 for ; Sun, 9 Oct 2011 03:00:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.317 X-Spam-Level: * X-Spam-Status: No, score=1.317 tagged_above=-999 required=5 tests=[AWL=-1.188, BAYES_50=0.001, FRT_BELOW2=2.154, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nS5hYbK2mMKz for ; Sun, 9 Oct 2011 03:00:05 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id B923621F8B33 for ; Sun, 9 Oct 2011 03:00:04 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id D6735FC400A; Sun, 9 Oct 2011 12:00:03 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id C83CAFC4006; Sun, 9 Oct 2011 12:00:03 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Sun, 9 Oct 2011 12:00:03 +0200 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: Sun, 9 Oct 2011 12:00:02 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] Summary of ICE discussion Thread-Index: AcyCorfYEOy7oXJvRF2NDEycgSphrQChiXRwAE+CiBAAAD10gAAAeaTA References: <4E8B192E.80809@ericsson.com> From: To: , X-OriginalArrivalTime: 09 Oct 2011 10:00:03.0820 (UTC) FILETIME=[373B72C0:01CC866A] Subject: Re: [rtcweb] Summary of ICE discussion X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Oct 2011 10:00:05 -0000 Hi there, Re Magnus's call for proposal (If anyone can find a solution that = fulfill the security goals and have improved legacy interoperability people = would=20 be interested in that solution. So far RTCP has been discarded as = insufficient.)=20 on media consent verification, here is below a suggestion for the group: Basically, the idea, compared to Hadriel's RTCP proposal, relies on the = use=20 of the signalling path instead of RTCP as a feedback channel for media=20 consent verification. Here are the steps I foresee before allowing the establishment of a = media session: =20 - Let's consider A (a RTC-Web compliant browser) connected to server S = and=20 wishing to share real-time media with destination B (potentially a SIP=20 endpoint or a browser) - A & B learn via the signalling channel the triple @IP, transport proto = and=20 associated listening port of the remote media - A sends a few RTP packets to B (3 as in RFC 2833/4733 or more?).- This = would allow the mechanism to resist against packet loss -. The format of such = packets are to be discussed =20 - Assuming B receives these packets, it then sends via the signalling = channel=20 an information from the media path unknown from S (i.e. not accessible = via JS).=20 I propose to use the min of the sequence number of the RTP packets = received=20 (which is random per RFC 3550) - A receives via S this info granting B's consent to receiving media = from A - A now can start sending media to B When B uses SIP as its signalling channel, Step 4 would probably require = a=20 SDP extension to convey this info, as well as possibly extended = H.248/Diameter informations would be required in a decoupled sig./media architecture. = Of course, a solution avoiding extensions would be more than welcome. The benefit of this mechanism largely relies on the assumption that the=20 transmission of information from the media termination of the = destination=20 to its associated signalling channel is less costly than implementing = ICE connectivity=20 checks. Which is still to be checked. This mechanism provides basic media consent verification and if it turns = out=20 that it provides less security properties than ICE or other drawbacks = (e.g.=20 increasing media session establishment delay, issues with the few = initial RTP=20 packets,..), it could be seen as a fallback media consent verification=20 when ICE is not implemented at each end of media terminations.=20 Looking forward to hearing feedbacks from the group on this. Cheers Sebastien -----Message d'origine----- De=A0: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] De la = part de Magnus Westerlund Envoy=E9=A0: mardi 4 octobre 2011 16:33 =C0=A0: rtcweb@ietf.org Objet=A0: [rtcweb] Summary of ICE discussion WG, I have bellow tired to summarize the result of the ICE discussion. This is intended as furthering this discussion and form a basis for going forward in the consensus process. I do expect people that disagree with my summary of the discussion to speak up. Major requirements - Need for data transmission consent for protocols using UDP as the traffic receiver needs to consent to receiving the data - Perform NAT and FW traversal when ever needed - Support IPv4 to IPv6 transition Desired behavior: - Be interoperable with deployed legacy systems as SIP Trunk, PSTN gateways, VoIP phones. WG chairs conclusion of discussion so far: - ICE is so far the only solution that provides the security goals and have any legacy deployment. - ICE usage will require that STUN connectivity MUST have succeeded prior to any data transmission to fulfill security goals. * The Browser will enforce this requirement to prevent being an attack vector in all cases. - If anyone can find a solution that fulfill the security goals and have improved legacy interoperability people would be interested in that solution. So far RTCP has been discarded as insufficient. - Media Gateway can support a reduced functionality set from Full ICE Cheers Magnus Westerlund as WG chair ---------------------------------------------------------------------- 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 ibc@aliax.net Sun Oct 9 09: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 1EE0421F8B2D for ; Sun, 9 Oct 2011 09:24:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.263 X-Spam-Level: X-Spam-Status: No, score=-0.263 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, 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 0eUmu9bfIW7X for ; Sun, 9 Oct 2011 09:24: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 6483121F8B17 for ; Sun, 9 Oct 2011 09:24:30 -0700 (PDT) Received: by vcbfo11 with SMTP id fo11so5112734vcb.31 for ; Sun, 09 Oct 2011 09:24:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.179.202 with SMTP id br10mr1124525vcb.41.1318177469492; Sun, 09 Oct 2011 09:24:29 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Sun, 9 Oct 2011 09:24:29 -0700 (PDT) In-Reply-To: References: <4E8B192E.80809@ericsson.com> Date: Sun, 9 Oct 2011 18:24:29 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: sebastien.cubaud@orange.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Summary of ICE discussion X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Oct 2011 16:24:31 -0000 2011/10/9 : > This mechanism provides basic media consent verification and if it turns = out > that it provides less security properties than ICE or other drawbacks (e.= g. > increasing media session establishment delay, issues with the few initial= RTP > packets,..), it could be seen as a fallback media consent verification > when ICE is not implemented at each end of media terminations. > > Looking forward to hearing feedbacks from the group on this. Hi, ICE is clearly the best solution as it handles NAT, security (peer verification) and allows IPv4/IPv6 transition. SIP endpoints *MUST* implement it or continue working in vendors wallen gardens. Bad luck for them. But creating a new spec (as you suggest) just to allow lazy SIP vendors (those who has never cared about security) to interoperate with RTCweb world instead on forcing them to implement ICE is IMHO a very bad idea. SIP vendors MUST do their homeworks. ICE and SRTP were initially designed for SIP. So SIP devices MUST implement them. --=20 I=C3=B1aki Baz Castillo From kpfleming@digium.com Mon Oct 10 07:59: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 A47E921F8BA8 for ; Mon, 10 Oct 2011 07:59:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.707 X-Spam-Level: X-Spam-Status: No, score=-101.707 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_BACKHAIR_43=1, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A5lRp41WgaNZ for ; Mon, 10 Oct 2011 07:59:21 -0700 (PDT) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by ietfa.amsl.com (Postfix) with ESMTP id 9D25B21F8B61 for ; Mon, 10 Oct 2011 07:59:21 -0700 (PDT) Received: from zimbra.digium.internal ([10.24.55.203] helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1RDHK2-0000WK-Gb for rtcweb@ietf.org; Mon, 10 Oct 2011 09:59:18 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id 7ACFDD82A3 for ; Mon, 10 Oct 2011 09:59:18 -0500 (CDT) Received: from zimbra.hsv.digium.com ([127.0.0.1]) by localhost (zimbra.hsv.digium.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c-rn69-Q8QQY for ; Mon, 10 Oct 2011 09:59:18 -0500 (CDT) Received: from [10.24.250.46] (unknown [10.24.250.46]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id 1D0E7D8024 for ; Mon, 10 Oct 2011 09:59:18 -0500 (CDT) Message-ID: <4E930845.60809@digium.com> Date: Mon, 10 Oct 2011 09:59:17 -0500 From: "Kevin P. Fleming" Organization: Digium, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110922 Thunderbird/3.1.15 MIME-Version: 1.0 CC: rtcweb@ietf.org References: <4E8F57EB.8030504@digium.com> <4E905B7F.7010505@digium.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: Mon, 10 Oct 2011 14:59:22 -0000 On 10/08/2011 04:51 PM, Jos=E9 Luis Mill=E1n wrote: > 2011/10/8 Kevin P. Fleming: >> On 10/08/2011 04:02 AM, Jos=E9 Luis Mill=E1n wrote: >>> >>> Kevin, >>> >>> 2011/10/7 Kevin P. Fleming: >>>> >>>> On 09/16/2011 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 strea= ms. >>>>> Of course this would require a SIP proxy/server in server side (thi= nk >>>>> 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-browse= rs >>>>> 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. T= his >>>>> 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 stre= am >>>>> is added to a multimedia session (i.e. offering video within an >>>>> already established audio session). > Sorry if I'm not underdstanding you well. I understand from the > paragraph above that the client may use these APIs to consult the > server about it's own state (client's state). > > The web application does not need to monitor the signalling, but will > be aware of its own state (sessions..) by simply relying on the > signalling API. ie: Client executes the 'call' method of the API 'X', > this method executes the corresponding callbacks according to the > state of the running call: 'trying', 'ringing', 'ok'. This way the > client is aware of its own state. > > If this is not what you meant, could you please clarify? I interpreted the paragraph above from Inaki's post very differently, so=20 I'll try to describe it more concretely. Imagine we have users Alice, Bob and Charlie, all of who are using a web=20 application called XYZ that utilizes RTCWEB functionality to allow=20 communication between its users. The XYZ application has two major=20 components: a set of Javascript/HTML that it pushes out to the browsers,=20 and a set of code (language/platform is irrelevant) that runs on the=20 server that pushed the code out, and communicates with that JavaScript co= de. When the XYZ application's Javascript wants to setup sessions to other=20 users of the application it uses the local WebRTC APIs to access the=20 browser's interfaces for media, and uses *some* sort of signaling=20 protocol over HTTP/WebSocket to establish the sessions through the XYZ=20 application server. This could be SIP, Jingle, or something else entirely= . In order for XYZ's Javascript running in Alice's browser to display the=20 state of *her* sessions with the XYZ application, the Javascript doesn't=20 need any help; it already knows what sessions it has established and=20 their states. The signaling protocol is irrelevant here. If the XYZ=20 application server implements the chosen signaling protocol itself, then=20 it *also* knows the states of these sessions, and by extension it knows=20 the states of all the other sessions that XYZ application users are=20 involved in. If the XYZ application wants to display in Alice's browser the states of=20 other sessions that Alice is not involved in (this is what I believe=20 Inaki was referring to above), then it can use this information that it=20 has (by virtue of implementing the signaling protocol itself) in order=20 to push information out to her browser for it to display. The situation changes quite a lot if the XYZ application server does=20 *not* implement the signaling protocol itself, though. If it just acts=20 as a conduit for that signaling to be sent between the browser and a=20 'communications server' of some type (I suspect this will be a very=20 common deployment model, as web application developers aren't going to=20 want to shoehorn an entire communications server into their web=20 application containers if they can avoid it), then it doesn't know the=20 state of any of these sessions at all; it just knows that it has seen=20 session signaling messages going back and forth. In this situation, if the XYZ application wants to display the states of=20 other sessions, it will have to have some API between itself and the=20 communications server (the browser is not involved here) in order to=20 monitor (and potentially control) those sessions. This allows the web=20 application developer to be completely insulated from the signaling=20 protocol that is used, and instead just use an API provided by the=20 communications server in order to track and control communications=20 sessions. Thus, the choice of signaling protocol is irrelevant, as long=20 as a hypothetical web application developer can find and use a suitable=20 communications server that implements the chosen protocol *and* provides=20 adequate APIs for the web application to fulfill its requirements. --=20 Kevin P. Fleming Digium, Inc. | Director of Software Technologies Jabber: kfleming@digium.com | SIP: kpfleming@digium.com | Skype: kpflemin= g 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at www.digium.com & www.asterisk.org From ibc@aliax.net Mon Oct 10 09:41: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 1E35F21F8C42 for ; Mon, 10 Oct 2011 09:41:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.47 X-Spam-Level: X-Spam-Status: No, score=-1.47 tagged_above=-999 required=5 tests=[AWL=1.207, 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 V0laNIvn-7NC for ; Mon, 10 Oct 2011 09:41: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 8E3DF21F8C31 for ; Mon, 10 Oct 2011 09:41:51 -0700 (PDT) Received: by vcbfo11 with SMTP id fo11so5914174vcb.31 for ; Mon, 10 Oct 2011 09:41:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.179.202 with SMTP id br10mr1436169vcb.41.1318264910872; Mon, 10 Oct 2011 09:41:50 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Mon, 10 Oct 2011 09:41:50 -0700 (PDT) In-Reply-To: <4E930845.60809@digium.com> References: <4E8F57EB.8030504@digium.com> <4E905B7F.7010505@digium.com> <4E930845.60809@digium.com> Date: Mon, 10 Oct 2011 18:41:50 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: "Kevin P. Fleming" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org 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: Mon, 10 Oct 2011 16:41:52 -0000 2011/10/10 Kevin P. Fleming : > In this situation, if the XYZ application wants to display the states of > other sessions, it will have to have some API between itself and the > communications server (the browser is not involved here) in order to moni= tor > (and potentially control) those sessions. This allows the web application > developer to be completely insulated from the signaling protocol that is > used, and instead just use an API provided by the communications server i= n > order to track and control communications sessions. Thus, the choice of > signaling protocol is irrelevant, as long as a hypothetical web applicati= on > developer can find and use a suitable communications server that implemen= ts > the chosen protocol *and* provides adequate APIs for the web application = to > fulfill its requirements. Hi Kevin. Yes. In fact, in case the signaling is carried via WebSocket, the WebSocket server could be a separate server (not colocated within the web server) so you get the web server and the signaling server in different servers (and you would need some kind of proprietary communication between them in order for the web server to get the sessions status). But that's changes nothing in the design on RTCweb IMHO. Regards. --=20 I=C3=B1aki Baz Castillo From kpfleming@digium.com Mon Oct 10 09:46: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 BD44521F8C30 for ; Mon, 10 Oct 2011 09:46:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.507 X-Spam-Level: X-Spam-Status: No, score=-103.507 tagged_above=-999 required=5 tests=[AWL=1.800, BAYES_00=-2.599, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l645OxsUrnlr for ; Mon, 10 Oct 2011 09:46:51 -0700 (PDT) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by ietfa.amsl.com (Postfix) with ESMTP id E82BF21F8C42 for ; Mon, 10 Oct 2011 09:46:50 -0700 (PDT) Received: from zimbra.digium.internal ([10.24.55.203] helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1RDJ06-0003Xs-Ln for rtcweb@ietf.org; Mon, 10 Oct 2011 11:46:50 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id 97F72D82A3 for ; Mon, 10 Oct 2011 11:46:50 -0500 (CDT) Received: from zimbra.hsv.digium.com ([127.0.0.1]) by localhost (zimbra.hsv.digium.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8qiZ9USxHs5R for ; Mon, 10 Oct 2011 11:46:50 -0500 (CDT) Received: from [10.24.250.46] (unknown [10.24.250.46]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id 2C899D8024 for ; Mon, 10 Oct 2011 11:46:50 -0500 (CDT) Message-ID: <4E932179.7080000@digium.com> Date: Mon, 10 Oct 2011 11:46:49 -0500 From: "Kevin P. Fleming" Organization: Digium, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110922 Thunderbird/3.1.15 MIME-Version: 1.0 CC: rtcweb@ietf.org References: <4E8F57EB.8030504@digium.com> <4E905B7F.7010505@digium.com> <4E930845.60809@digium.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: Mon, 10 Oct 2011 16:46:51 -0000 On 10/10/2011 11:41 AM, I=F1aki Baz Castillo wrote: > 2011/10/10 Kevin P. Fleming: >> In this situation, if the XYZ application wants to display the states = of >> other sessions, it will have to have some API between itself and the >> communications server (the browser is not involved here) in order to m= onitor >> (and potentially control) those sessions. This allows the web applicat= ion >> developer to be completely insulated from the signaling protocol that = is >> used, and instead just use an API provided by the communications serve= r in >> order to track and control communications sessions. Thus, the choice o= f >> signaling protocol is irrelevant, as long as a hypothetical web applic= ation >> developer can find and use a suitable communications server that imple= ments >> the chosen protocol *and* provides adequate APIs for the web applicati= on to >> fulfill its requirements. > > Hi Kevin. Yes. In fact, in case the signaling is carried via > WebSocket, the WebSocket server could be a separate server (not > colocated within the web server) so you get the web server and the > signaling server in different servers (and you would need some kind of > proprietary communication between them in order for the web server to > get the sessions status). > > But that's changes nothing in the design on RTCweb IMHO. That's correct; the only reason I brought it up is that the choice of=20 SIP as the RTCWEB signaling protocol, or something else, does not impact=20 this at all. Choosing Jingle does not make this easier for the web=20 application developer, and choosing SIP does not make it harder... in=20 either case, they either *are* the signaling endpoint at the server end,=20 or they aren't. Originally you had stated that if SIP was chosen, it=20 would make this sort of application harder to build, because the=20 application would not be likely to implement a SIP UA itself, and so it=20 wouldn't have access to the session state information. I'm not advocating that SIP be chosen... but for entirely different=20 reasons :-) --=20 Kevin P. Fleming Digium, Inc. | Director of Software Technologies Jabber: kfleming@digium.com | SIP: kpfleming@digium.com | Skype: kpflemin= g 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at www.digium.com & www.asterisk.org From ibc@aliax.net Mon Oct 10 09:57:52 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21B7321F8B84 for ; Mon, 10 Oct 2011 09:57:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.074 X-Spam-Level: X-Spam-Status: No, score=-2.074 tagged_above=-999 required=5 tests=[AWL=0.604, 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 OeSoQ0O9+iCs for ; Mon, 10 Oct 2011 09:57: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 912CA21F8B80 for ; Mon, 10 Oct 2011 09:57:51 -0700 (PDT) Received: by vcbfo11 with SMTP id fo11so5932722vcb.31 for ; Mon, 10 Oct 2011 09:57:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.179.202 with SMTP id br10mr1441735vcb.41.1318265871023; Mon, 10 Oct 2011 09:57:51 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Mon, 10 Oct 2011 09:57:50 -0700 (PDT) In-Reply-To: <4E932179.7080000@digium.com> References: <4E8F57EB.8030504@digium.com> <4E905B7F.7010505@digium.com> <4E930845.60809@digium.com> <4E932179.7080000@digium.com> Date: Mon, 10 Oct 2011 18:57:50 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: "Kevin P. Fleming" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org 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: Mon, 10 Oct 2011 16:57:52 -0000 2011/10/10 Kevin P. Fleming : > That's correct; the only reason I brought it up is that the choice of SIP= as > the RTCWEB signaling protocol, or something else, does not impact this at > all. Choosing Jingle does not make this easier for the web application > developer, and choosing SIP does not make it harder... in either case, th= ey > either *are* the signaling endpoint at the server end, or they aren't. > Originally you had stated that if SIP was chosen, it would make this sort= of > application harder to build, because the application would not be likely = to > implement a SIP UA itself, and so it wouldn't have access to the session > state information. Not exactly, I meant that, in case the browser speaks *native* SIP with a centralized SIP proxy, then it would be hard to get sessions information in the web server (as it would require some custom and complex communication with the SIP proxy). The same if it's a XMPP server or whatever. But if the signaling is carried via HTTP or WebSocket, the siteadmin can choose to pass all the signaling through the web server so it would be fully aware of the sessions status. So I meant the server rather than the client. The client, of course, must know the sessions he is involved in :) > I'm not advocating that SIP be chosen... but for entirely different reaso= ns The fact is that nobody advocates for a specific signaling protocol (well, just a person which insists and insists...). We need no default signaling protocol at all, but just freedom for each siteadmin to provide the signaling protocol it desired (of course, it should be carried via HTTP or WebSocket, as those protocols are the ones that a webbrowser can speak being controlled via JavaScript). Regards. --=20 I=C3=B1aki Baz Castillo From ted.ietf@gmail.com Mon Oct 10 11:51: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 B063E21F8B2D for ; Mon, 10 Oct 2011 11:51:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.698 X-Spam-Level: X-Spam-Status: No, score=-0.698 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 n5WP3-Xs-qAG for ; Mon, 10 Oct 2011 11:51: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 737B721F8AF8 for ; Mon, 10 Oct 2011 11:51:03 -0700 (PDT) Received: by ywm3 with SMTP id 3so7003411ywm.31 for ; Mon, 10 Oct 2011 11:51:03 -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=ftDqjOBLUpFTXSk2HqulcOSOr/+DUaWtgJEiaeEhEU8=; b=lvXBSWSXd4H9P6JophE9x2/30ej0Lu+lW/dS6a1smQTNomr+Qv4x0gSqtwQl0U7/gC 48m/tSf5HVnymTnJOC55BRssM0CvOjflCd8b2APWNoPLtcBonAv4g9aygW/styU4oy68 2CjdruO4efiMR/vO8sEPm8fGwVHlDPF5Tg4bY= MIME-Version: 1.0 Received: by 10.236.191.71 with SMTP id f47mr25521710yhn.125.1318272662954; Mon, 10 Oct 2011 11:51:02 -0700 (PDT) Received: by 10.236.105.169 with HTTP; Mon, 10 Oct 2011 11:51:02 -0700 (PDT) In-Reply-To: References: <4E8F57EB.8030504@digium.com> <4E905B7F.7010505@digium.com> <4E930845.60809@digium.com> <4E932179.7080000@digium.com> Date: Mon, 10 Oct 2011 11:51:02 -0700 Message-ID: From: Ted Hardie To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=20cf303f6496cae41804aef64507 Cc: rtcweb@ietf.org 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: Mon, 10 Oct 2011 18:51:07 -0000 --20cf303f6496cae41804aef64507 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Oct 10, 2011 at 9:57 AM, I=F1aki Baz Castillo wrote= : > We need no default signaling protocol at all, but just freedom for each > siteadmin to > provide the signaling protocol it desired (of course, it should be > carried via HTTP or WebSocket, as those protocols are the ones that a > webbrowser can speak being controlled via JavaScript). > > Taking off my various hats, I have to say I don't agree. We're putting together a system here in which a downloaded application must talk to the server from which it is downloaded, the local system into which it is downloaded, and the other endpoints with whom it wants to trade flows. If we decline to put any constraint at all on the signaling that goes between the downdloaded system and the server, we are, in essence, forcing the API between the downloaded code and the local environment to support any possible signaling. Since it is the local environment that will manage codecs and emit RTP flows, that's a rough ask--especially if it has to support signaling that might have radically different semantics. If we agreed on a semantic approach (e.g. solicit/propose or offer/answer), then the syntactic difference would be, I admit, largely a matter of taste. I would see no real reason not to have a baseline syntax, but I would probably agree to it being pseudo code of some sort. But if we have no agreed on *semantics* for the signaling, then the API between the downloade= d code and the local system is unbounded. That doesn't tend to make for stable systems or interoperability. If you must gateway between systems (something I agree is not job one), unbounded semantics would also imply arbitrary complexity in the gateways. Again, not good for stability or deployability. Lastly, there are also some security issues here. I had a chat with Jon Peterson last week about why SIP identity went down the road it did (something that, honestly, had always been a bit puzzling to me). As he walked me through it, one of the comments he made struck me as particularly important: if you are going to expect that you know who you are talking to by anything other than the assertion of the intermediary, you must provide both an assurance of identity and an assurance of the media path destinations. I'm not sure we do want this, honestly; the intermediaries i= n our system are powerful enough that trying to provide anything better than SSH-style identify may be foolish. But if we do, we need a common method o= f describing those destinations in order to get a common method of assuring them. That's a long, long way down the road to common signaling syntax; having that without common semantics seems liable to some pretty funky risks. I am, personally, far from convinced that having no constraints on the signaling is worth imposing unbounded complexity on the Javascrip/Browser API and any gateway systems, as well as circumscribing our security choices. It may seem to be a dazzling amount of freedom, but it is only on= e part of the system, and it ought to play well with others. Just my personal opinion, Ted Hardie --20cf303f6496cae41804aef64507 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Oct 10, 2011 at 9:57 AM, I=F1aki Baz Castillo <= ;ibc@aliax.net> wrote:
We need no default signaling protocol at all, but just freedom for each sit= eadmin to
provide the signaling protocol it desired (of course, it should be
carried via HTTP or WebSocket, as those protocols are the ones that a
webbrowser can speak being controlled via JavaScript).


Taking off my various hat= s, I have to say I don't agree. =A0 We're putting together a system= here in which a downloaded application must talk to the server from which = it is downloaded, the local system into which it is downloaded, and the oth= er endpoints with whom it wants to trade flows.=A0 If we decline to put any= constraint at all on the signaling that goes between the downdloaded syste= m and the server, we are, in essence, forcing the API between the downloade= d code and the local environment to support any possible signaling.=A0 Sinc= e it is the local environment that will manage codecs and emit RTP flows, t= hat's a rough ask--especially if it has to support signaling that might= have radically different semantics.=A0

If we agreed on a semantic approach (e.g. solicit/propose or offer/answ= er), then the syntactic difference would be, I admit, largely a matter of t= aste.=A0 I would see no real reason not to have a baseline syntax, but I wo= uld probably agree to it being pseudo code of some sort.=A0 But if we have = no agreed on *semantics* for the signaling, then the API between the downlo= aded code and the=A0 local system is unbounded.=A0 That doesn't tend to= make for stable systems or interoperability.

If you must gateway between systems (something I agree is not job one),= unbounded semantics would also imply arbitrary complexity in the gateways.= =A0 Again, not good for stability or deployability.

Lastly, there ar= e also some security issues here.=A0 I had a chat with Jon Peterson last we= ek about why SIP identity went down the road it did (something that, honest= ly, had always been a bit puzzling to me).=A0 As he walked me through it, o= ne of the comments he made struck me as particularly important:=A0 if you a= re going to expect that you know who you are talking to by anything other t= han the assertion of the intermediary, you must provide both an assurance o= f identity and an assurance of the media path destinations.=A0 I'm not = sure we do want this, honestly; the intermediaries in our system are powerf= ul enough that trying to provide anything better than SSH-style identify ma= y be foolish.=A0 But if we do, we need a common method of describing those = destinations in order to get a common method of assuring them.=A0 That'= s a long, long way down the road to common signaling syntax; having that wi= thout common semantics seems liable to some pretty funky risks.

I am, personally, far from convinced that having no constraints on the = signaling is worth imposing unbounded complexity on the Javascrip/Browser A= PI and any gateway systems, as well as circumscribing our security choices.= =A0 It may seem to be a dazzling amount of freedom, but it is only one part= of the system, and it ought to play well with others.

Just my personal opinion,

Ted Hardie
--20cf303f6496cae41804aef64507-- From ibc@aliax.net Mon Oct 10 13:35:00 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4B5621F8CD0 for ; Mon, 10 Oct 2011 13:35:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.275 X-Spam-Level: X-Spam-Status: No, score=-2.275 tagged_above=-999 required=5 tests=[AWL=0.402, 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 vFD8nqm4Cd6L for ; Mon, 10 Oct 2011 13:35: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 2677021F8CCA for ; Mon, 10 Oct 2011 13:35:00 -0700 (PDT) Received: by vcbfo11 with SMTP id fo11so6152953vcb.31 for ; Mon, 10 Oct 2011 13:34:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.35.34 with SMTP id e2mr15173923vdj.52.1318278898305; Mon, 10 Oct 2011 13:34:58 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Mon, 10 Oct 2011 13:34:58 -0700 (PDT) In-Reply-To: References: <4E8F57EB.8030504@digium.com> <4E905B7F.7010505@digium.com> <4E930845.60809@digium.com> <4E932179.7080000@digium.com> Date: Mon, 10 Oct 2011 22:34:58 +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] 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: Mon, 10 Oct 2011 20:35:00 -0000 2011/10/10 Ted Hardie : > Taking off my various hats, I have to say I don't agree. =C2=A0 We're put= ting > together a system here in which a downloaded application must talk to the > server from which it is downloaded, the local system into which it is > downloaded, and the other endpoints with whom it wants to trade flows.=C2= =A0 If > we decline to put any constraint at all on the signaling that goes betwee= n > the downdloaded system and the server, we are, in essence, forcing the AP= I > between the downloaded code and the local environment to support any > possible signaling.=C2=A0 Since it is the local environment that will man= age > codecs and emit RTP flows, that's a rough ask--especially if it has to > support signaling that might have radically different semantics. > > If we agreed on a semantic approach (e.g. solicit/propose or offer/answer= ), > then the syntactic difference would be, I admit, largely a matter of tast= e. Hi Ted. We should come to the reality: This is about establishing media sessions, and this is based on SDP, and SDP works as follows: - Alice sends, via some signaling protocol, a SDP offer to Bob. - Bob prompts the human user and replies a SDP anwser (if it accepts the ca= ll). - After that media session(s) starts. - At some point, Alice or Both could send a new SDP offer to modify the session(s) (for example, for adding video, putting on hold or whatever). And that's all. SIP and XMPP/Jingle do that at the end. Both have different semantics but similar target (exchange SDP information). That's the only we need to assume for RTCweb. --=20 I=C3=B1aki Baz Castillo From harald@alvestrand.no Mon Oct 10 13:50: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 C49E721F8532 for ; Mon, 10 Oct 2011 13:50:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.826 X-Spam-Level: X-Spam-Status: No, score=-107.826 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_BELOW2=2.154, RCVD_IN_DNSWL_HI=-8, RCVD_IN_SORBS_WEB=0.619, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DQ+8JI6BeUn1 for ; Mon, 10 Oct 2011 13:50:19 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 6F9ED21F8CE9 for ; Mon, 10 Oct 2011 13:50:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2548739E0F3 for ; Mon, 10 Oct 2011 22:50: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 Y5sKdi0X368K for ; Mon, 10 Oct 2011 22:50:16 +0200 (CEST) Received: from [10.168.111.151] (unknown [91.143.127.70]) by eikenes.alvestrand.no (Postfix) with ESMTPS id C923439E082 for ; Mon, 10 Oct 2011 22:50:15 +0200 (CEST) Message-ID: <4E935A8B.8020700@alvestrand.no> Date: Mon, 10 Oct 2011 22:50:19 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4E8B192E.80809@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: [rtcweb] Sebastien Cubaud's non-ICE mechanism (Re: Summary of ICE discussion) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2011 20:50:19 -0000 Changing the subject to keep threads separate.... On 10/09/2011 12:00 PM, sebastien.cubaud@orange.com wrote: > Hi there, > > Re Magnus's call for proposal (If anyone can find a solution that fulfill > the security goals and have improved legacy interoperability people would > be interested in that solution. So far RTCP has been discarded as insufficient.) > on media consent verification, here is below a suggestion for the group: > > Basically, the idea, compared to Hadriel's RTCP proposal, relies on the use > of the signalling path instead of RTCP as a feedback channel for media > consent verification. > > Here are the steps I foresee before allowing the establishment of a media session: > > - Let's consider A (a RTC-Web compliant browser) connected to server S and > wishing to share real-time media with destination B (potentially a SIP > endpoint or a browser) > - A& B learn via the signalling channel the triple @IP, transport proto and > associated listening port of the remote media > - A sends a few RTP packets to B (3 as in RFC 2833/4733 or more?).- This would > allow the mechanism to resist against packet loss -. The format of such packets > are to be discussed > - Assuming B receives these packets, it then sends via the signalling channel > an information from the media path unknown from S (i.e. not accessible via JS). > I propose to use the min of the sequence number of the RTP packets received > (which is random per RFC 3550) The sequence number is a 16-bit number, so there are 16 bits of randomness to play with here. An attack based on just returning a random number will succeed 1 out of 65.536 times; if any of the 3 packets' sequence numbers are acceptable, it will succeed 1 out of 21.845 times. A browser can reasonably limit the number of attempts per second (either overall or per-script); multiple browsers will not be able to coordinate on any such limit. Is this defense strong enough to warrant considering this further? > - A receives via S this info granting B's consent to receiving media from A > - A now can start sending media to B > > When B uses SIP as its signalling channel, Step 4 would probably require a > SDP extension to convey this info, as well as possibly extended H.248/Diameter > informations would be required in a decoupled sig./media architecture. > Of course, a solution avoiding extensions would be more than welcome. > > The benefit of this mechanism largely relies on the assumption that the > transmission of information from the media termination of the destination > to its associated signalling channel is less costly than implementing ICE connectivity > checks. Which is still to be checked. > > This mechanism provides basic media consent verification and if it turns out > that it provides less security properties than ICE or other drawbacks (e.g. > increasing media session establishment delay, issues with the few initial RTP > packets,..), it could be seen as a fallback media consent verification > when ICE is not implemented at each end of media terminations. > > Looking forward to hearing feedbacks from the group on this. > > Cheers > Sebastien > > -----Message d'origine----- > De : rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] De la part de Magnus Westerlund > Envoy : mardi 4 octobre 2011 16:33 > : rtcweb@ietf.org > Objet : [rtcweb] Summary of ICE discussion > > WG, > > I have bellow tired to summarize the result of the ICE discussion. This > is intended as furthering this discussion and form a basis for going > forward in the consensus process. I do expect people that disagree with > my summary of the discussion to speak up. > > Major requirements > > - Need for data transmission consent for protocols using UDP as the > traffic receiver needs to consent to receiving the data > > - Perform NAT and FW traversal when ever needed > > - Support IPv4 to IPv6 transition > > Desired behavior: > > - Be interoperable with deployed legacy systems as SIP Trunk, PSTN > gateways, VoIP phones. > > WG chairs conclusion of discussion so far: > > - ICE is so far the only solution that provides the security goals and > have any legacy deployment. > > - ICE usage will require that STUN connectivity MUST have succeeded > prior to any data transmission to fulfill security goals. > > * The Browser will enforce this requirement to prevent being an attack > vector in all cases. > > - If anyone can find a solution that fulfill the security goals and have > improved legacy interoperability people would be interested in that > solution. So far RTCP has been discarded as insufficient. > > - Media Gateway can support a reduced functionality set from Full ICE > > Cheers > > Magnus Westerlund > as WG chair > > ---------------------------------------------------------------------- > 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 ted.ietf@gmail.com Mon Oct 10 14:45: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 A59C821F8B66 for ; Mon, 10 Oct 2011 14:45:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[AWL=1.300, 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 qnnCN2w1lkr4 for ; Mon, 10 Oct 2011 14:45:54 -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 E711F21F8B59 for ; Mon, 10 Oct 2011 14:45:53 -0700 (PDT) Received: by ggnk3 with SMTP id k3so6107757ggn.31 for ; Mon, 10 Oct 2011 14:45: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; bh=qilpMLHr5Igagx3v+kRaJAn3JwrHPz3wwZdQ9h52Siw=; b=sbFgEQMP5sb6MHRmkO3t2XKRH4/TJKJ9sZ+UUiTeK4GAt2h94q81X2mUgEgGxNvg6I W9+B+3Bjtj4i9Cqh9bu1NDD2JdRShJLqC8SRETy5tVWTolYG2tXe986Pw2VMShwe9BAu B9lF2coXOPSY5RendQkbw9Oi9g/T0YZFxe4yk= MIME-Version: 1.0 Received: by 10.236.127.144 with SMTP id d16mr27245618yhi.40.1318283153160; Mon, 10 Oct 2011 14:45:53 -0700 (PDT) Received: by 10.236.105.169 with HTTP; Mon, 10 Oct 2011 14:45:53 -0700 (PDT) In-Reply-To: References: <4E8F57EB.8030504@digium.com> <4E905B7F.7010505@digium.com> <4E930845.60809@digium.com> <4E932179.7080000@digium.com> Date: Mon, 10 Oct 2011 14:45:53 -0700 Message-ID: From: Ted Hardie To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=20cf3010e3c50eb8e904aef8b737 Cc: rtcweb@ietf.org 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: Mon, 10 Oct 2011 21:45:54 -0000 --20cf3010e3c50eb8e904aef8b737 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Oct 10, 2011 at 1:34 PM, I=F1aki Baz Castillo wrote= : > > If we agreed on a semantic approach (e.g. solicit/propose or > offer/answer), > > then the syntactic difference would be, I admit, largely a matter of > taste. > > > Hi Ted. We should come to the reality: > > This is about establishing media sessions, and this is based on SDP, > and SDP works as follows: > > - Alice sends, via some signaling protocol, a SDP offer to Bob. > - Bob prompts the human user and replies a SDP anwser (if it accepts the > call). > - After that media session(s) starts. > - At some point, Alice or Both could send a new SDP offer to modify > the session(s) (for example, for adding video, putting on hold or > whatever). > > And that's all. SIP and XMPP/Jingle do that at the end. Both have > different semantics but similar target (exchange SDP information). > > If you believe that each RTCWeb Javascript/server pair needs to implement a= n SDP-based offer/answer protocol, but that it may choose among different syntaxes for carrying the SDP, then I think you're a lot closer to what I would call "having standard signaling" than not. That could be described in a document in pseudo-code which could be translated to JSON structures o= r whatever the current flavor of the month is easily enough. Because each offer/answer protocol had to support the same basic things the requirements on the Javascript/Browser API go down to a common core, which is far easier to get. I personally would describe that in some existing offer/answer protocol, just for clarity, but, as I said, that is largely a matter of taste. Again, speaking without hats on, regards, Ted > That's the only we need to assume for RTCweb. > > > > -- > I=F1aki Baz Castillo > > --20cf3010e3c50eb8e904aef8b737 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Oct 10, 2011 at 1:34 PM, I=F1aki Baz Castillo <= ;ibc@aliax.net> wrote:
> If we agreed on a semantic approach (e.g. solicit/propose or offer/ans= wer),
> then the syntactic difference would be, I admit, largely a matter of t= aste.


Hi Ted. We should come to the reality:

This is about establishing media sessions, and this is based on SDP,
and SDP works as follows:

- Alice sends, via some signaling protocol, a SDP offer to Bob.
- Bob prompts the human user and replies a SDP anwser (if it accepts the ca= ll).
- After that media session(s) starts.
- At some point, Alice or Both could send a new SDP offer to modify
the session(s) (for example, for adding video, putting on hold or
whatever).

And that's all. SIP and XMPP/Jingle do that at the end. Both have
different semantics but similar target (exchange SDP information).


If you believe that each RTCWeb Javascript/server= pair needs to implement an SDP-based offer/answer protocol, but that it ma= y choose among different syntaxes for carrying the SDP, then I think you= 9;re a lot closer to what I would call "having standard signaling"= ; than not.=A0=A0 That could be described in a document in pseudo-code whic= h could be translated to JSON structures or whatever the current flavor of = the month is easily enough.=A0 Because each offer/answer protocol had to su= pport the same basic things the requirements on the Javascript/Browser API = go down to a common core, which is far easier to get.

I personally would describe that in some existing offer/answer protocol= , just for clarity, but, as I said, that is largely a matter of taste.
<= br>Again, speaking without hats on,

regards,

Ted

=A0
That's the only we need to assume for RTCweb.



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

--20cf3010e3c50eb8e904aef8b737-- From ekr@rtfm.com Mon Oct 10 16:04: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 6F8E321F8B43 for ; Mon, 10 Oct 2011 16:04:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.823 X-Spam-Level: X-Spam-Status: No, score=-100.823 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FRT_BELOW2=2.154, 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 frkuUZ9Ty0Wl for ; Mon, 10 Oct 2011 16:04:58 -0700 (PDT) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id 6309A21F8B3A for ; Mon, 10 Oct 2011 16:04:58 -0700 (PDT) Received: by wwn22 with SMTP id 22so4293675wwn.1 for ; Mon, 10 Oct 2011 16:04:56 -0700 (PDT) Received: by 10.227.27.165 with SMTP id i37mr6629353wbc.106.1318287896058; Mon, 10 Oct 2011 16:04:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.196.83 with HTTP; Mon, 10 Oct 2011 16:04:16 -0700 (PDT) In-Reply-To: <4E935A8B.8020700@alvestrand.no> References: <4E8B192E.80809@ericsson.com> <4E935A8B.8020700@alvestrand.no> From: Eric Rescorla Date: Mon, 10 Oct 2011 16:04:16 -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] Sebastien Cubaud's non-ICE mechanism (Re: Summary of ICE discussion) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2011 23:04:59 -0000 On Mon, Oct 10, 2011 at 1:50 PM, Harald Alvestrand w= rote: > Changing the subject to keep threads separate.... > > On 10/09/2011 12:00 PM, sebastien.cubaud@orange.com wrote: >> >> Hi there, >> >> Re Magnus's call for proposal (If anyone can find a solution that fulfil= l >> =A0the security goals and have improved legacy interoperability people w= ould >> be interested in that solution. So far RTCP has been discarded as >> insufficient.) >> on media consent verification, here is below a suggestion for the group: >> >> Basically, the idea, compared to Hadriel's RTCP proposal, relies on the >> use >> of the signalling path instead of RTCP as a feedback channel for media >> consent verification. >> >> Here are the steps I foresee before allowing the establishment of a medi= a >> session: >> >> - Let's consider A (a RTC-Web compliant browser) connected to server S a= nd >> wishing to share real-time media with destination B (potentially a SIP >> endpoint or a browser) >> - A& =A0B learn via the signalling channel the triple @IP, transport pro= to >> and >> associated listening port of the remote media >> - A sends a few RTP packets to B (3 as in RFC 2833/4733 or more?).- This >> would >> =A0allow the mechanism to resist against packet loss -. The format of su= ch >> packets >> =A0are to be discussed >> - Assuming B receives these packets, it then sends via the signalling >> channel >> an information from the media path unknown from S (i.e. not accessible v= ia >> JS). >> I propose to use the min of the sequence number of the RTP packets >> received >> (which is random per RFC 3550) > > The sequence number is a 16-bit number, so there are 16 bits of randomnes= s > to play with here. > An attack based on just returning a random number will succeed 1 out of > 65.536 times; if any of the 3 packets' sequence numbers are acceptable, i= t > will succeed 1 out of 21.845 times. > > A browser can reasonably limit the number of attempts per second (either > overall or per-script); multiple browsers will not be able to coordinate = on > any such limit. > > Is this defense strong enough to warrant considering this further? IMO, this is far too little entropy. It's also unclear to me why this is significantly easier than just doing ICE Lite. -Ekr >> - A receives via S this info granting B's consent to receiving media fro= m >> A >> - A now can start sending media to B >> >> When B uses SIP as its signalling channel, Step 4 would probably require= a >> SDP extension to convey this info, as well as possibly extended >> H.248/Diameter >> =A0informations would be required in a decoupled sig./media architecture= . >> Of course, a solution avoiding extensions would be more than welcome. >> >> The benefit of this mechanism largely relies on the assumption that the >> transmission of information from the media termination of the destinatio= n >> to its associated signalling channel is less costly than implementing IC= E >> connectivity >> checks. Which is still to be checked. >> >> This mechanism provides basic media consent verification and if it turns >> out >> that it provides less security properties than ICE or other drawbacks >> (e.g. >> increasing media session establishment delay, issues with the few initia= l >> RTP >> packets,..), it could be seen as a fallback media consent verification >> when ICE is not implemented at each end of media terminations. >> >> Looking forward to hearing feedbacks from the group on this. >> >> Cheers >> Sebastien >> >> -----Message d'origine----- >> De : rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] De la part >> de Magnus Westerlund >> Envoy=E9 : mardi 4 octobre 2011 16:33 >> =C0 : rtcweb@ietf.org >> Objet : [rtcweb] Summary of ICE discussion >> >> WG, >> >> I have bellow tired to summarize the result of the ICE discussion. This >> is intended as furthering this discussion and form a basis for going >> forward in the consensus process. I do expect people that disagree with >> my summary of the discussion to speak up. >> >> Major requirements >> >> - Need for data transmission consent for protocols using UDP as the >> traffic receiver needs to consent to receiving the data >> >> - Perform NAT and FW traversal when ever needed >> >> - Support IPv4 to IPv6 transition >> >> Desired behavior: >> >> - Be interoperable with deployed legacy systems as SIP Trunk, PSTN >> gateways, VoIP phones. >> >> WG chairs conclusion of discussion so far: >> >> - ICE is so far the only solution that provides the security goals and >> have any legacy deployment. >> >> - ICE usage will require that STUN connectivity MUST have succeeded >> prior to any data transmission to fulfill security goals. >> >> =A0 * The Browser will enforce this requirement to prevent being an atta= ck >> vector in all cases. >> >> - If anyone can find a solution that fulfill the security goals and have >> improved legacy interoperability people would be interested in that >> solution. So far RTCP has been discarded as insufficient. >> >> - Media Gateway can support a reduced functionality set from Full ICE >> >> Cheers >> >> Magnus Westerlund >> as WG chair >> >> ---------------------------------------------------------------------- >> Multimedia Technologies, Ericsson Research EAB/TVM >> ---------------------------------------------------------------------- >> Ericsson AB =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Phone =A0+46 10 7148287 >> F=E4r=F6gatan 6 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Mobile +46 73 0949079 >> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com >> ---------------------------------------------------------------------- >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From ibc@aliax.net Mon Oct 10 16:09: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 C70AC21F8B7E for ; Mon, 10 Oct 2011 16:09:58 -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.302, 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 3t0Amkts+oY7 for ; Mon, 10 Oct 2011 16:09:58 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id BBDB721F8B6D for ; Mon, 10 Oct 2011 16:09:57 -0700 (PDT) Received: by vws5 with SMTP id 5so6268970vws.31 for ; Mon, 10 Oct 2011 16:09:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.25.75 with SMTP id a11mr15810902vdg.1.1318288192762; Mon, 10 Oct 2011 16:09:52 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Mon, 10 Oct 2011 16:09:52 -0700 (PDT) In-Reply-To: References: <4E8B192E.80809@ericsson.com> <4E935A8B.8020700@alvestrand.no> Date: Tue, 11 Oct 2011 01:09:52 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Sebastien Cubaud's non-ICE mechanism (Re: Summary of ICE discussion) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2011 23:09:59 -0000 2011/10/11 Eric Rescorla : > It's also unclear to me why this is significantly easier than just > doing ICE Lite. And it does not solve NAT neither allows IPv4/IPv6 interoperability. Why to make SIP devices to implement that instead of ICE (or ICE-Lite)? ICE was designed for SIP but now there are much more XMPP clients implementing it than SIP... how much must we wait in SIP? now it's clearly the moment but instead of endorsing ICE, do we really prefer to create a new pseudo-spec just to make SIP devices RTC-web compliant? And then, what will we do when IPv6 arrives? I strongly vote for using ICE and requiring ICE in SIP world (they just MUST, this is the time). --=20 I=C3=B1aki Baz Castillo From randell-ietf@jesup.org Mon Oct 10 17:16: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 AF7C721F8B52 for ; Mon, 10 Oct 2011 17:16: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=[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 RSaER-H-0Yv3 for ; Mon, 10 Oct 2011 17:16:00 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 579D521F8B43 for ; Mon, 10 Oct 2011 17:16:00 -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 1RDQ0l-00012o-85 for rtcweb@ietf.org; Mon, 10 Oct 2011 19:15:59 -0500 Message-ID: <4E9389C0.5050607@jesup.org> Date: Mon, 10 Oct 2011 20:11: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: <4E8B192E.80809@ericsson.com> <4E935A8B.8020700@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] Sebastien Cubaud's non-ICE mechanism (Re: Summary of ICE discussion) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 00:16:01 -0000 On 10/10/2011 7:04 PM, Eric Rescorla wrote: > On Mon, Oct 10, 2011 at 1:50 PM, Harald Alvestrand wrote: >> Changing the subject to keep threads separate.... >> >> On 10/09/2011 12:00 PM, sebastien.cubaud@orange.com wrote: >>> Here are the steps I foresee before allowing the establishment of a media >>> session: >>> >>> - Let's consider A (a RTC-Web compliant browser) connected to server S and >>> wishing to share real-time media with destination B (potentially a SIP >>> endpoint or a browser) >>> - A& B learn via the signalling channel the triple @IP, transport proto >>> and associated listening port of the remote media >>> - A sends a few RTP packets to B (3 as in RFC 2833/4733 or more?).- This >>> would allow the mechanism to resist against packet loss -. The format of such >>> packets are to be discussed >>> - Assuming B receives these packets, it then sends via the signalling >>> channel an information from the media path unknown from S (i.e. not accessible via >>> JS). >>> I propose to use the min of the sequence number of the RTP packets >>> received (which is random per RFC 3550) >> >> The sequence number is a 16-bit number, so there are 16 bits of randomness >> to play with here. >> An attack based on just returning a random number will succeed 1 out of >> 65.536 times; if any of the 3 packets' sequence numbers are acceptable, it >> will succeed 1 out of 21.845 times. If you use the sequence number and the timestamp, you have 48 bits of entropy... -- Randell Jesup randell-ietf@jesup.org From randell-ietf@jesup.org Mon Oct 10 17:25: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 BB2A321F8AEA for ; Mon, 10 Oct 2011 17:25:22 -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 FgOhjXpPR0pm for ; Mon, 10 Oct 2011 17:25:21 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id CE5CB21F8ACE for ; Mon, 10 Oct 2011 17:25:21 -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 1RDQ9p-0004s5-Cf for rtcweb@ietf.org; Mon, 10 Oct 2011 19:25:21 -0500 Message-ID: <4E938BF2.4070307@jesup.org> Date: Mon, 10 Oct 2011 20:21:06 -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: <4E8F57EB.8030504@digium.com> <4E905B7F.7010505@digium.com> <4E930845.60809@digium.com> <4E932179.7080000@digium.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [rtcweb] 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: Tue, 11 Oct 2011 00:25:23 -0000 On 10/10/2011 5:45 PM, Ted Hardie wrote: > On Mon, Oct 10, 2011 at 1:34 PM, Iaki Baz Castillo > wrote: > > > If we agreed on a semantic approach (e.g. solicit/propose or > offer/answer), > > then the syntactic difference would be, I admit, largely a matter > of taste. > > > Hi Ted. We should come to the reality: > > This is about establishing media sessions, and this is based on SDP, > and SDP works as follows: > > - Alice sends, via some signaling protocol, a SDP offer to Bob. > - Bob prompts the human user and replies a SDP anwser (if it accepts > the call). > - After that media session(s) starts. > - At some point, Alice or Both could send a new SDP offer to modify > the session(s) (for example, for adding video, putting on hold or > whatever). > > And that's all. SIP and XMPP/Jingle do that at the end. Both have > different semantics but similar target (exchange SDP information). > > > If you believe that each RTCWeb Javascript/server pair needs to > implement an SDP-based offer/answer protocol, but that it may choose > among different syntaxes for carrying the SDP, then I think you're a lot > closer to what I would call "having standard signaling" than not. Yes - this was not what I had assumed Iaki was arguing. I made a similar proposal some time ago (and so did others - Harald, etc) for standardizing O-A in some manner, and I suggested providing an *optional* simple signalling package that developers could use to quickly get up and running. It would not be a replacement for a fully-featured stack, but it might be a small subset of an existing full stack. I also think I proposed a way to handle the O-A portion (modification of Harald's semantics) that would help resolve simple forking. I'll dig the reference out, but it also helped solve the start-of-call-clipping problem. -- Randell Jesup randell-ietf@jesup.org From jdrosen@jdrosen.net Mon Oct 10 20:13: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 0D22F21F8CC8 for ; Mon, 10 Oct 2011 20:13:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LcIShJpRpHhK for ; Mon, 10 Oct 2011 20:13:02 -0700 (PDT) Received: from ecbiz71.inmotionhosting.com (ecbiz71.inmotionhosting.com [69.174.114.155]) by ietfa.amsl.com (Postfix) with ESMTP id 2C73821F8CE2 for ; Mon, 10 Oct 2011 20:13:02 -0700 (PDT) Received: from pool-173-63-39-69.nwrknj.fios.verizon.net ([173.63.39.69]:64060 helo=[192.168.1.7]) by ecbiz71.inmotionhosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RDSm5-0002x2-A2 for rtcweb@ietf.org; Mon, 10 Oct 2011 23:13:01 -0400 Message-ID: <4E93B43C.3060106@jdrosen.net> Date: Mon, 10 Oct 2011 23:13:00 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4E8B192E.80809@ericsson.com> <4E935A8B.8020700@alvestrand.no> <4E9389C0.5050607@jesup.org> In-Reply-To: <4E9389C0.5050607@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 - ecbiz71.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jdrosen.net Subject: Re: [rtcweb] Sebastien Cubaud's non-ICE mechanism (Re: Summary of ICE discussion) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 03:13:03 -0000 Security issues aside, the proposed solution does not work with existing SIP/RTP implementations. The main drawback of the ICE solution is that it won't work with deployed equipment. I see little benefit in specifying another solution which does not fix the main limitation we have with ICE. -Jonathan R. On 10/10/2011 8:11 PM, Randell Jesup wrote: > On 10/10/2011 7:04 PM, Eric Rescorla wrote: >> On Mon, Oct 10, 2011 at 1:50 PM, Harald >> Alvestrand wrote: >>> Changing the subject to keep threads separate.... >>> >>> On 10/09/2011 12:00 PM, sebastien.cubaud@orange.com wrote: >>>> Here are the steps I foresee before allowing the establishment of a >>>> media >>>> session: >>>> >>>> - Let's consider A (a RTC-Web compliant browser) connected to server >>>> S and >>>> wishing to share real-time media with destination B (potentially a SIP >>>> endpoint or a browser) >>>> - A& B learn via the signalling channel the triple @IP, transport proto >>>> and associated listening port of the remote media >>>> - A sends a few RTP packets to B (3 as in RFC 2833/4733 or more?).- >>>> This >>>> would allow the mechanism to resist against packet loss -. The >>>> format of such >>>> packets are to be discussed >>>> - Assuming B receives these packets, it then sends via the signalling >>>> channel an information from the media path unknown from S (i.e. not >>>> accessible via >>>> JS). >>>> I propose to use the min of the sequence number of the RTP packets >>>> received (which is random per RFC 3550) >>> >>> The sequence number is a 16-bit number, so there are 16 bits of >>> randomness >>> to play with here. >>> An attack based on just returning a random number will succeed 1 out of >>> 65.536 times; if any of the 3 packets' sequence numbers are >>> acceptable, it >>> will succeed 1 out of 21.845 times. > > If you use the sequence number and the timestamp, you have 48 bits of > entropy... > > -- Jonathan D. Rosenberg, Ph.D. SkypeID: jdrosen Skype Chief Technology Strategist jdrosen@skype.net http://www.skype.com jdrosen@jdrosen.net http://www.jdrosen.net From randell-ietf@jesup.org Mon Oct 10 21: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 8B8F921F8C26 for ; Mon, 10 Oct 2011 21:26:19 -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 wAeKC8+fkn+G for ; Mon, 10 Oct 2011 21:26: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 0351221F8C1A for ; Mon, 10 Oct 2011 21:26:18 -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 1RDTv0-0002Ep-9W for rtcweb@ietf.org; Mon, 10 Oct 2011 23:26:18 -0500 Message-ID: <4E93C46B.1000902@jesup.org> Date: Tue, 11 Oct 2011 00:22: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: <4E8B192E.80809@ericsson.com> <4E935A8B.8020700@alvestrand.no> <4E9389C0.5050607@jesup.org> <4E93B43C.3060106@jdrosen.net> In-Reply-To: <4E93B43C.3060106@jdrosen.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] Sebastien Cubaud's non-ICE mechanism (Re: Summary of ICE discussion) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 04:26:19 -0000 On 10/10/2011 11:13 PM, Jonathan Rosenberg wrote: > Security issues aside, the proposed solution does not work with existing > SIP/RTP implementations. The main drawback of the ICE solution is that > it won't work with deployed equipment. I see little benefit in > specifying another solution which does not fix the main limitation we > have with ICE. The only thing I've come up with that can work with existing equipment is a variant of CORS. Basically, if the destination doesn't respond to ICE (or more likely the app tells you it won't) you do a CORS-style 'preflight' check to the same IP address. If you're told "I'm an RTP gateway that accepts non-ICE traffic" with a valid handshake from the signalling (ala an ICE check), then traffic can flow/continue flowing (you may want to allow it to start before the check is complete, with a limited time/data until verification is required to continue). In practice, this could be implemented by redirecting HTTP/HTTPS traffic to the gateway's IP to an internal webserver that would respond. This allows layering onto existing gateways permission for a webrtc/rtcweb client to send to them, without modifying the gateway itself. Downsides: More complex. Assumes the gateway can either run a (dummy) webserver, at least enough to redirect, or it's behind a firewall that can port-forward traffic. An advantage, if the gateway is willing to risk DoS attempts, is that the gateway could indicate a max age for the CORS-type check, and so indicate that for future calls to that address the browser doesn't have to check. This is optional, though, and just saves checks (and if pre-check-complete data sending isn't allowed, then it may save setup time as well, except on the first call to a particular gateway). Is it workable? I think so. Is it worthwhile? I don't know. I'm somewhat skeptical since it solves only a subset of the problem space (for connecting to legacy devices/gateways). -- Randell Jesup randell-ietf@jesup.org From jmillan@aliax.net Mon Oct 10 23: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 5B6D121F86EE for ; Mon, 10 Oct 2011 23:28:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YLG+TqOSOEZC for ; Mon, 10 Oct 2011 23:28:49 -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 5410A21F8753 for ; Mon, 10 Oct 2011 23:28:49 -0700 (PDT) Received: by iaby26 with SMTP id y26so10137180iab.31 for ; Mon, 10 Oct 2011 23:28:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.5.73 with SMTP id 9mr7794832ibu.60.1318314528714; Mon, 10 Oct 2011 23:28:48 -0700 (PDT) Received: by 10.231.36.201 with HTTP; Mon, 10 Oct 2011 23:28:48 -0700 (PDT) Date: Tue, 11 Oct 2011 08:28:48 +0200 Message-ID: From: =?ISO-8859-1?Q?Jos=E9_Luis_Mill=E1n?= To: rtcweb@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [rtcweb] SIP on the Web: presentation and video X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 06:28:50 -0000 Hi, Some weeks ago we made a concrete proposal for signalling between Web browser and server in RTCweb. Such a definition was described in "draft-ibc-rtcweb-sip-websocket-00". We don't advocate for a default signaling protocol in RTCweb (not at all). Current proposal is just an example of a working signaling for RTCweb based on SIP and carried over WebSocket. We have just uploaded a video demo in which there can be seen a real implementation of the mentioned draft. The components of the signalling architecture are a WebSocket capable SIP proxy and a SIP stack written in JavaScript. These are needed to make the browser became a real SIP node, capable to interact with real SIP World. We would like to emphasize that the aim of this video is nothing but showing an implementation of the proposed signalling. We wish you enjoy. http://sip-on-the-web.aliax.net. Regards. I=F1aki Baz Jos=E9 Luis Mill=E1n From ibc@aliax.net Tue Oct 11 00:41:12 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3B4221F861E for ; Tue, 11 Oct 2011 00:41:12 -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.241, 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 L6-E1VAoU8my for ; Tue, 11 Oct 2011 00:41: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 3918421F8B8E for ; Tue, 11 Oct 2011 00:41:09 -0700 (PDT) Received: by vcbfo11 with SMTP id fo11so6522097vcb.31 for ; Tue, 11 Oct 2011 00:41:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.184.103 with SMTP id et7mr17239844vdc.35.1318318869351; Tue, 11 Oct 2011 00:41:09 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Tue, 11 Oct 2011 00:41:09 -0700 (PDT) In-Reply-To: References: <4E8F57EB.8030504@digium.com> <4E905B7F.7010505@digium.com> <4E930845.60809@digium.com> <4E932179.7080000@digium.com> Date: Tue, 11 Oct 2011 09:41:09 +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] 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: Tue, 11 Oct 2011 07:41:12 -0000 2011/10/10 Ted Hardie : > If you believe that each RTCWeb Javascript/server pair needs to implement= an > SDP-based offer/answer protocol, but that it may choose among different > syntaxes for carrying the SDP, then I think you're a lot closer to what I > would call "having standard signaling" than not. Hi Ted, alice from her browser can only establish a media session with bob if both visit the same website so they already share the same JS code dictaminating the signaling protocol to use (which can be SIP, or XMPP or some custom JSON based protocol). I just said that, regardless the chosen signaling protocol, such protocol would require some way to send and receive a SDP (or something that looks an SDP), so the JS API for dealing with media in a RTCweb capable browser will deal, at the end, with SDP's. IMHO that's obvious. But of course, depending on the chosen protocol, it could be simpler (don't allow parallel forking, don't allow renegotiation of the media after a call is established...) or complex (building a full SIP implementation). That's up to the site admin. I'n not speaking about a "standard signaling", not at all. >=C2=A0=C2=A0 That could be described > in a document in pseudo-code which could be translated to JSON structures= or > whatever the current flavor of the month is easily enough.=C2=A0 Because = each > offer/answer protocol had to support the same basic things the requiremen= ts > on the Javascript/Browser API go down to a common core, which is far easi= er > to get. > > I personally would describe that in some existing offer/answer protocol, > just for clarity, but, as I said, that is largely a matter of taste. Sure. Taking a working signaling protocol to build the RTCweb JS API on top of that is a good idea since we can find the requirements for such API. --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Tue Oct 11 00:46: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 B639621F8C1F for ; Tue, 11 Oct 2011 00:46:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.476 X-Spam-Level: X-Spam-Status: No, score=-2.476 tagged_above=-999 required=5 tests=[AWL=0.201, 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 YiUY2W4QwwJz for ; Tue, 11 Oct 2011 00:46:03 -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 AAB8721F8C0D for ; Tue, 11 Oct 2011 00:46:02 -0700 (PDT) Received: by vws5 with SMTP id 5so6535339vws.31 for ; Tue, 11 Oct 2011 00:46:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.184.103 with SMTP id et7mr17255434vdc.35.1318319162075; Tue, 11 Oct 2011 00:46:02 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Tue, 11 Oct 2011 00:46:02 -0700 (PDT) In-Reply-To: References: Date: Tue, 11 Oct 2011 09:46:02 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: =?UTF-8?B?Sm9zw6kgTHVpcyBNaWxsw6Fu?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SIP on the Web: presentation and video X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 07:46:03 -0000 2011/10/11 Jos=C3=A9 Luis Mill=C3=A1n : > Some weeks ago we made a concrete proposal for signalling between Web > browser and server in RTCweb. Such a definition was described in > "draft-ibc-rtcweb-sip-websocket-00". > > We don't advocate for a default signaling protocol in RTCweb (not at all)= . > Current proposal is just an example of a working signaling for RTCweb bas= ed > on SIP and carried over WebSocket. > > We have just uploaded a video demo in which there can be seen a real > implementation of the mentioned draft. > > The components of the signalling architecture are a WebSocket capable > SIP proxy and a SIP stack written in JavaScript. These are needed to > make the browser became a real SIP node, capable to interact with real > SIP World. > > We would like to emphasize that the aim of this video is nothing but > showing an implementation of the proposed signalling. > > > We wish you enjoy. > > http://sip-on-the-web.aliax.net. Hi, the video is at the end of the HTML presentation. Direct links anyhow: - Ogg Vorbis video (17 MB) - http://sip-on-the-web.aliax.net/sip-on-the-web= .ogv - MP4 video (5.7 MB) - http://sip-on-the-web.aliax.net/sip-on-the-web.mp4 - AVI video (46 MB) - http://sip-on-the-web.aliax.net/sip-on-the-web.avi Regards. --=20 I=C3=B1aki Baz Castillo From sebastien.cubaud@orange.com Tue Oct 11 00:51: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 9F5C221F8B37 for ; Tue, 11 Oct 2011 00:51:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.664 X-Spam-Level: X-Spam-Status: No, score=-0.664 tagged_above=-999 required=5 tests=[AWL=1.585, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kIR26-zFjhOR for ; Tue, 11 Oct 2011 00:51:07 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by ietfa.amsl.com (Postfix) with ESMTP id B075021F8B31 for ; Tue, 11 Oct 2011 00:51:06 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id B6D9E8B808D; Tue, 11 Oct 2011 09:52:26 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id AAC408B8091; Tue, 11 Oct 2011 09:52:26 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 11 Oct 2011 09:48:27 +0200 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, 11 Oct 2011 09:48:26 +0200 Message-ID: In-Reply-To: <4E93B43C.3060106@jdrosen.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] Sebastien Cubaud's non-ICE mechanism (Re: Summary of ICE discussion) Thread-Index: AcyHw7KHZmQN1dUbTQqm+QcGaRqUxgAJRXww References: <4E8B192E.80809@ericsson.com><4E935A8B.8020700@alvestrand.no><4E9389C0.5050607@jesup.org> <4E93B43C.3060106@jdrosen.net> From: To: , X-OriginalArrivalTime: 11 Oct 2011 07:48:27.0850 (UTC) FILETIME=[29B18AA0:01CC87EA] Subject: Re: [rtcweb] Sebastien Cubaud's non-ICE mechanism (Re: Summary of ICE discussion) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 07:51:08 -0000 Hi Jonathan,=20 The use of the SSRC - prior to being accessible via JS for mux/demux = purposes- could be an alternative to using the sequence number and/or = the timestamp (as suggested by Randell). SIP endpoints interfacing with = RTC-Web browsers would then only be required to implement RFC 5576 = (which may be less costly than STUN implementation, the SHA-1 = computation + CRC compute for the fingerprint).. Cheers Sebastien =20 -----Message d'origine----- De=A0: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] De la = part de Jonathan Rosenberg Envoy=E9=A0: mardi 11 octobre 2011 05:13 =C0=A0: rtcweb@ietf.org Objet=A0: Re: [rtcweb] Sebastien Cubaud's non-ICE mechanism (Re: Summary = of ICE discussion) Security issues aside, the proposed solution does not work with existing = SIP/RTP implementations. The main drawback of the ICE solution is that=20 it won't work with deployed equipment. I see little benefit in=20 specifying another solution which does not fix the main limitation we=20 have with ICE. -Jonathan R. On 10/10/2011 8:11 PM, Randell Jesup wrote: > On 10/10/2011 7:04 PM, Eric Rescorla wrote: >> On Mon, Oct 10, 2011 at 1:50 PM, Harald >> Alvestrand wrote: >>> Changing the subject to keep threads separate.... >>> >>> On 10/09/2011 12:00 PM, sebastien.cubaud@orange.com wrote: >>>> Here are the steps I foresee before allowing the establishment of a >>>> media >>>> session: >>>> >>>> - Let's consider A (a RTC-Web compliant browser) connected to = server >>>> S and >>>> wishing to share real-time media with destination B (potentially a = SIP >>>> endpoint or a browser) >>>> - A& B learn via the signalling channel the triple @IP, transport = proto >>>> and associated listening port of the remote media >>>> - A sends a few RTP packets to B (3 as in RFC 2833/4733 or more?).- >>>> This >>>> would allow the mechanism to resist against packet loss -. The >>>> format of such >>>> packets are to be discussed >>>> - Assuming B receives these packets, it then sends via the = signalling >>>> channel an information from the media path unknown from S (i.e. not >>>> accessible via >>>> JS). >>>> I propose to use the min of the sequence number of the RTP packets >>>> received (which is random per RFC 3550) >>> >>> The sequence number is a 16-bit number, so there are 16 bits of >>> randomness >>> to play with here. >>> An attack based on just returning a random number will succeed 1 out = of >>> 65.536 times; if any of the 3 packets' sequence numbers are >>> acceptable, it >>> will succeed 1 out of 21.845 times. > > If you use the sequence number and the timestamp, you have 48 bits of > entropy... > > --=20 Jonathan D. Rosenberg, Ph.D. SkypeID: jdrosen Skype Chief Technology Strategist jdrosen@skype.net http://www.skype.com jdrosen@jdrosen.net http://www.jdrosen.net _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From sebastien.cubaud@orange.com Tue Oct 11 01:02: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 A04C421F8CD2 for ; Tue, 11 Oct 2011 01:02:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.06 X-Spam-Level: X-Spam-Status: No, score=-1.06 tagged_above=-999 required=5 tests=[AWL=1.189, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id abj+3mG4Q5x7 for ; Tue, 11 Oct 2011 01:02:38 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id E706621F8C1F for ; Tue, 11 Oct 2011 01:02:37 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 614B540035; Tue, 11 Oct 2011 10:00:51 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 47E844002D; Tue, 11 Oct 2011 10:00:51 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 11 Oct 2011 10:00:06 +0200 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, 11 Oct 2011 10:00:05 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] Summary of ICE discussion Thread-Index: AcyGn/6FcwsFLHX3QXeqrlBNhu/ItgBSnkag References: <4E8B192E.80809@ericsson.com> From: To: X-OriginalArrivalTime: 11 Oct 2011 08:00:06.0238 (UTC) FILETIME=[C9F717E0:01CC87EB] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Summary of ICE discussion X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 08:02:38 -0000 SGkgScOxYWtpLA0KDQo+SUNFIGlzIGNsZWFybHkgdGhlIGJlc3Qgc29sdXRpb24gYXMgaXQgaGFu ZGxlcyBOQVQsIHNlY3VyaXR5IChwZWVyDQo+dmVyaWZpY2F0aW9uKSBhbmQgYWxsb3dzIElQdjQv SVB2NiB0cmFuc2l0aW9uLiANCg0KT2YgY291cnNlLCB0aGlzIHNvbHV0aW9uIGRvZXNuJ3QgbWVh biB0byBhZGRyZXNzIE5BVCB0cmF2ZXJzYWwgaXNzdWVzLCBub3IgbXVsdGlob21pbmcuDQpJQ0Ug c3RpbGwgcmVtYWlucyB0aGUgYmVzdCBjYW5kaWRhdGUgZm9yIHN1Y2ggcmVxdWlyZW1lbnRzIGFu ZCBpdCBpcyBpbiBubyB3YXkgbXkgaW50ZW50IHRvIA0KcXVlc3Rpb24gdGhlIHVzZSBvZiBJQ0Ug Zm9yIFJUQy1XZWIgY29tcGxpYW50IGFnZW50cyA6IG15IHByb3Bvc2FsJ3MgZ29hbCBpcyBvbmx5 IHRvIHBlcm1pdCANCnRoZSBtaW5pbWFsIGludGVyb3BlcmFiaWxpdHkgY29zdHMgd2l0aCBleGlz dGluZyBTSVAgZW5kcG9pbnRzIHdoaWxzdCB0cnlpbmcgdG8gYWRkcmVzcyBSVEMtV2ViIA0Kc3Bl Y2lmaWMgc2VjdXJpdHkgY2hhbGxlbmdlcyAoaS5lLiBtZWRpYSBjb25zZW50IHZlcmlmaWNhdGlv bikuIEFnYWluLCBpdCBkb2Vzbid0IHByZWNsdWRlIHRoZSANCnVzZSBvZiBJQ0UgZm9yIG1lZGlh IGNvbnNlbnQgdmVyaWZpY2F0aW9uLCBzaG91bGQgYWxsIGVuZHBvaW50cyBzdXBwb3J0IElDRS4g DQpDaGVlcnMNClNlYmFzdGllbg0KDQotLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCkRlwqA6 IEnDsWFraSBCYXogQ2FzdGlsbG8gW21haWx0bzppYmNAYWxpYXgubmV0XSANCkVudm95w6nCoDog ZGltYW5jaGUgOSBvY3RvYnJlIDIwMTEgMTg6MjQNCsOAwqA6IENVQkFVRCBTZWJhc3RpZW4gUkQt Q09SRS1MQU4NCkNjwqA6IG1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29uLmNvbTsgcnRjd2ViQGll dGYub3JnDQpPYmpldMKgOiBSZTogW3J0Y3dlYl0gU3VtbWFyeSBvZiBJQ0UgZGlzY3Vzc2lvbg0K DQoyMDExLzEwLzkgIDxzZWJhc3RpZW4uY3ViYXVkQG9yYW5nZS5jb20+Og0KPiBUaGlzIG1lY2hh bmlzbSBwcm92aWRlcyBiYXNpYyBtZWRpYSBjb25zZW50IHZlcmlmaWNhdGlvbiBhbmQgaWYgaXQg dHVybnMgb3V0DQo+IHRoYXQgaXQgcHJvdmlkZXMgbGVzcyBzZWN1cml0eSBwcm9wZXJ0aWVzIHRo YW4gSUNFIG9yIG90aGVyIGRyYXdiYWNrcyAoZS5nLg0KPiBpbmNyZWFzaW5nIG1lZGlhIHNlc3Np b24gZXN0YWJsaXNobWVudCBkZWxheSwgaXNzdWVzIHdpdGggdGhlIGZldyBpbml0aWFsIFJUUA0K PiBwYWNrZXRzLC4uKSwgaXQgY291bGQgYmUgc2VlbiBhcyBhIGZhbGxiYWNrIG1lZGlhIGNvbnNl bnQgdmVyaWZpY2F0aW9uDQo+IHdoZW4gSUNFIGlzIG5vdCBpbXBsZW1lbnRlZCBhdCBlYWNoIGVu ZCBvZiBtZWRpYSB0ZXJtaW5hdGlvbnMuDQo+DQo+IExvb2tpbmcgZm9yd2FyZCB0byBoZWFyaW5n IGZlZWRiYWNrcyBmcm9tIHRoZSBncm91cCBvbiB0aGlzLg0KDQpIaSwNCg0KSUNFIGlzIGNsZWFy bHkgdGhlIGJlc3Qgc29sdXRpb24gYXMgaXQgaGFuZGxlcyBOQVQsIHNlY3VyaXR5IChwZWVyDQp2 ZXJpZmljYXRpb24pIGFuZCBhbGxvd3MgSVB2NC9JUHY2IHRyYW5zaXRpb24uIFNJUCBlbmRwb2lu dHMgKk1VU1QqDQppbXBsZW1lbnQgaXQgb3IgY29udGludWUgd29ya2luZyBpbiB2ZW5kb3JzIHdh bGxlbiBnYXJkZW5zLiBCYWQgbHVjaw0KZm9yIHRoZW0uDQoNCkJ1dCBjcmVhdGluZyBhIG5ldyBz cGVjIChhcyB5b3Ugc3VnZ2VzdCkganVzdCB0byBhbGxvdyBsYXp5IFNJUA0KdmVuZG9ycyAodGhv c2Ugd2hvIGhhcyBuZXZlciBjYXJlZCBhYm91dCBzZWN1cml0eSkgdG8gaW50ZXJvcGVyYXRlDQp3 aXRoIFJUQ3dlYiB3b3JsZCBpbnN0ZWFkIG9uIGZvcmNpbmcgdGhlbSB0byBpbXBsZW1lbnQgSUNF IGlzIElNSE8gYQ0KdmVyeSBiYWQgaWRlYS4NCg0KU0lQIHZlbmRvcnMgTVVTVCBkbyB0aGVpciBo b21ld29ya3MuIElDRSBhbmQgU1JUUCB3ZXJlIGluaXRpYWxseQ0KZGVzaWduZWQgZm9yIFNJUC4g U28gU0lQIGRldmljZXMgTVVTVCBpbXBsZW1lbnQgdGhlbS4NCg0KLS0gDQpJw7Fha2kgQmF6IENh c3RpbGxvDQo8aWJjQGFsaWF4Lm5ldD4NCg== From ibc@aliax.net Tue Oct 11 01:03: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 260CB21F8CBC for ; Tue, 11 Oct 2011 01:03:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.205 X-Spam-Level: X-Spam-Status: No, score=-2.205 tagged_above=-999 required=5 tests=[AWL=-0.128, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_34=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 7dQcjjbbiopv for ; Tue, 11 Oct 2011 01:03:18 -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 A567F21F8C1F for ; Tue, 11 Oct 2011 01:03:18 -0700 (PDT) Received: by vcbfo11 with SMTP id fo11so6536173vcb.31 for ; Tue, 11 Oct 2011 01:03:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.35.34 with SMTP id e2mr17043971vdj.52.1318320198060; Tue, 11 Oct 2011 01:03:18 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Tue, 11 Oct 2011 01:03:18 -0700 (PDT) In-Reply-To: <4E93B43C.3060106@jdrosen.net> References: <4E8B192E.80809@ericsson.com> <4E935A8B.8020700@alvestrand.no> <4E9389C0.5050607@jesup.org> <4E93B43C.3060106@jdrosen.net> Date: Tue, 11 Oct 2011 10:03:18 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Jonathan Rosenberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Sebastien Cubaud's non-ICE mechanism (Re: Summary of ICE discussion) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 08:03:19 -0000 2011/10/11 Jonathan Rosenberg : > Security issues aside, the proposed solution does not work with existing > SIP/RTP implementations. The main drawback of the ICE solution is that it > won't work with deployed equipment. I see little benefit in specifying > another solution which does not fix the main limitation we have with ICE. I agree. IMHO it's time for SIP vendors to implement escurity in SIP devices (let's say ICE and SRTP, some specifications originally designed for SIP). SIP is deployed in different scenarios and each scenario has its own requirements (some of them require certain codecs, SIP over TLS, UPDATE/PRACK methods and so on). I consider RTCweb to be another multimedia communication scenario (but very big!!) so it can impose its own requirements (for example ICE+SRTP which sounds appropriate given the open Internet nature). So if SIP vendors want to interoperate with RTCweb devices, then implement ICE+SRTP, that's the key. --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Tue Oct 11 01:08: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 5E5C021F8CBC for ; Tue, 11 Oct 2011 01:08:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.189 X-Spam-Level: X-Spam-Status: No, score=-2.189 tagged_above=-999 required=5 tests=[AWL=-0.112, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_34=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 Ek1nbenHupEG for ; Tue, 11 Oct 2011 01:08:20 -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 D9D6221F8C64 for ; Tue, 11 Oct 2011 01:08:19 -0700 (PDT) Received: by vws5 with SMTP id 5so6550290vws.31 for ; Tue, 11 Oct 2011 01:08:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.90.206 with SMTP id by14mr17176876vdb.18.1318320499314; Tue, 11 Oct 2011 01:08:19 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Tue, 11 Oct 2011 01:08:19 -0700 (PDT) In-Reply-To: References: <4E8B192E.80809@ericsson.com> Date: Tue, 11 Oct 2011 10:08:19 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: sebastien.cubaud@orange.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Summary of ICE discussion X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 08:08:20 -0000 2011/10/11 : >>ICE is clearly the best solution as it handles NAT, security (peer >>verification) and allows IPv4/IPv6 transition. > > Of course, this solution doesn't mean to address NAT traversal issues, no= r multihoming. > ICE still remains the best candidate for such requirements and it is in n= o way my intent to > question the use of ICE for RTC-Web compliant agents : my proposal's goal= is only to permit > the minimal interoperability costs with existing SIP endpoints whilst try= ing to address RTC-Web > specific security challenges (i.e. media consent verification). Again, it= doesn't preclude the > use of ICE for media consent verification, should all endpoints support I= CE. Hi Sebastien, As I've said in other mails, ICE and SRTP was designed for SIP. If SIP vendors don't care about security (due to wallen gardens in which most of SIP is deployed) neither IPv4/IPv6 migration (again due the same reasons) that is their fault. If SIP vendors just react when needed, this is a good time for that, as the "market" will be Internet full of RTCweb capable web browsers implementing ICE+SRTP (being safer that 99% of current SIP devices, which is really sad). It's time for implementing ICE+SRTP in SIP. Please don't give SIP vendors another oportunity to avoid implementing that by offering them some workaround for media verification. --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Tue Oct 11 01:37: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 4778221F8CCC for ; Tue, 11 Oct 2011 01:37:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.476 X-Spam-Level: X-Spam-Status: No, score=-2.476 tagged_above=-999 required=5 tests=[AWL=0.201, 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 fx0BTnJ3NdNK for ; Tue, 11 Oct 2011 01:37:23 -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 89D8721F8C8D for ; Tue, 11 Oct 2011 01:37:21 -0700 (PDT) Received: by vcbfo11 with SMTP id fo11so6558760vcb.31 for ; Tue, 11 Oct 2011 01:37:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.9.3 with SMTP id j3mr1524423vcj.6.1318322240875; Tue, 11 Oct 2011 01:37:20 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Tue, 11 Oct 2011 01:37:20 -0700 (PDT) In-Reply-To: References: <4E8D6507.8000707@ericsson.com> Date: Tue, 11 Oct 2011 10:37:20 +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] Making progress on the signaling discussion (NB: Action items enclosed!) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 08:37:24 -0000 2011/10/7 I=C3=B1aki Baz Castillo : >> To clarify, what I see the question for the WG is how the signalling >> model for RTCWEB session establishment is intended to work. Thus the >> drafts intended for answering this needs to be focused on describing a >> signalling model. > > Yes, agreed. > > > Regards. > > > PS: SIP over WebSocket just works fine. A demonstration next week. Hi, as told in other thread, the demonstration and video of SIP over WebSocket is already available: http://sip-on-the-web.aliax.net/ So this becomes a signaling protocol example for RTCweb, a *known* signaling protocol in fact (so we can figure what we need from the future RTCweb JS API in order to deal with SDP's and media sessions). Regards. --=20 I=C3=B1aki Baz Castillo From saul@ag-projects.com Tue Oct 11 02:24: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 8283F21F8CB7 for ; Tue, 11 Oct 2011 02:24:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.688 X-Spam-Level: X-Spam-Status: No, score=-1.688 tagged_above=-999 required=5 tests=[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 yU72ra7wB60b for ; Tue, 11 Oct 2011 02:24:16 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id D8EF721F8CA5 for ; Tue, 11 Oct 2011 02:24:15 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 24808B01A5; Tue, 11 Oct 2011 11:23:21 +0200 (CEST) Received: from [192.168.99.36] (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id 45B51B019E; Tue, 11 Oct 2011 11:23:09 +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, 11 Oct 2011 11:23:08 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E8F57EB.8030504@digium.com> <4E905B7F.7010505@digium.com> <4E930845.60809@digium.com> <4E932179.7080000@digium.com> To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org 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: Tue, 11 Oct 2011 09:24:16 -0000 On Oct 11, 2011, at 9:41 AM, I=F1aki Baz Castillo wrote: > 2011/10/10 Ted Hardie : >> If you believe that each RTCWeb Javascript/server pair needs to = implement an >> SDP-based offer/answer protocol, but that it may choose among = different >> syntaxes for carrying the SDP, then I think you're a lot closer to = what I >> would call "having standard signaling" than not. >=20 > Hi Ted, alice from her browser can only establish a media session with > bob if both visit the same website so they already share the same JS > code dictaminating the signaling protocol to use (which can be SIP, or > XMPP or some custom JSON based protocol). >=20 > I just said that, regardless the chosen signaling protocol, such > protocol would require some way to send and receive a SDP (or > something that looks an SDP), so the JS API for dealing with media in > a RTCweb capable browser will deal, at the end, with SDP's. IMHO > that's obvious. >=20 Sure, reinventing SDP would not be nice. What would be nice is to have = some sort of RTCWeb API to manage something that corresponds to an SDP. = Then it would be up to the signaling protocol implementors to convert to = and from this entities to their real SDP representation, that is, = plaintext for SIP and XML for XMPP, for example. -- Sa=FAl Ibarra Corretg=E9 AG Projects From tim@phonefromhere.com Tue Oct 11 02:34: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 2898D21F8D02 for ; Tue, 11 Oct 2011 02:34:09 -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 dOrVN2g3eCK7 for ; Tue, 11 Oct 2011 02:34: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 6E2D821F8CFE for ; Tue, 11 Oct 2011 02:34:08 -0700 (PDT) Received: from [192.168.0.14] (unknown [93.89.81.113]) by zimbra.westhawk.co.uk (Postfix) with ESMTP id D018537A90C; Tue, 11 Oct 2011 10:46:54 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-13-716025862 From: Tim Panton In-Reply-To: <4E93C46B.1000902@jesup.org> Date: Tue, 11 Oct 2011 10:34:02 +0100 Message-Id: <82BBE73E-B84C-49E5-B702-87857E7B7432@phonefromhere.com> References: <4E8B192E.80809@ericsson.com> <4E935A8B.8020700@alvestrand.no> <4E9389C0.5050607@jesup.org> <4E93B43C.3060106@jdrosen.net> <4E93C46B.1000902@jesup.org> To: Randell Jesup X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Sebastien Cubaud's non-ICE mechanism (Re: Summary of ICE discussion) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 09:34:09 -0000 --Apple-Mail-13-716025862 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 11 Oct 2011, at 05:22, Randell Jesup wrote: >=20 > Is it workable? I think so. Is it worthwhile? I don't know. I'm = somewhat skeptical since it solves only a subset of the problem space = (for connecting to legacy devices/gateways). I just want to add that in my experience it is a _small_ subset of the = problem space.=20 This group risks duplicating my costly mistake by assuming that people want to connect to the PSTN/desk phones from their browser. In general they don't.=20 They want to communicate with other browser users on the same (or = related) site(s). That is the area we should be focussing on. If we get legacy interop too = - great, but PSTN interconnect really shouldn't be the deciding factor. Tim.= --Apple-Mail-13-716025862 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

Is it workable? =  I think so.  Is it worthwhile?  I don't know.  I'm = somewhat skeptical since it solves only a subset of the problem space = (for connecting to legacy = devices/gateways).

I just want to = add that in my experience it is a _small_ subset of the problem = space. 
This group risks duplicating my costly mistake by = assuming
that people want to connect to the PSTN/desk phones = from their browser.

In general they = don't. 
They want to communicate with other browser = users on the same (or related) site(s).
That is the area we = should be focussing on. If we get legacy interop too - great, = but
PSTN interconnect really shouldn't be the deciding = factor.

Tim.
= --Apple-Mail-13-716025862-- From neils@vipadia.com Tue Oct 11 03:04: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 4D18721F8D61 for ; Tue, 11 Oct 2011 03:04:53 -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 Ez578uG+vAa1 for ; Tue, 11 Oct 2011 03:04:52 -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 5604221F8D5C for ; Tue, 11 Oct 2011 03:04:51 -0700 (PDT) Received: by iaby26 with SMTP id y26so10375796iab.31 for ; Tue, 11 Oct 2011 03:04:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.3.225 with SMTP id 33mr7403827ibo.87.1318327491488; Tue, 11 Oct 2011 03:04:51 -0700 (PDT) Sender: neils@vipadia.com Received: by 10.231.200.146 with HTTP; Tue, 11 Oct 2011 03:04:51 -0700 (PDT) In-Reply-To: References: <4E8F57EB.8030504@digium.com> <4E905B7F.7010505@digium.com> <4E930845.60809@digium.com> <4E932179.7080000@digium.com> Date: Tue, 11 Oct 2011 11:04:51 +0100 X-Google-Sender-Auth: oVEbLqduuCB6ugIWpb-6d8a1FxA Message-ID: From: Neil Stratford To: Ted Hardie Content-Type: multipart/alternative; boundary=00151773de8ed3ee2b04af030988 Cc: rtcweb@ietf.org 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: Tue, 11 Oct 2011 10:04:53 -0000 --00151773de8ed3ee2b04af030988 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Oct 10, 2011 at 7:51 PM, Ted Hardie wrote: > > Taking off my various hats, I have to say I don't agree. We're putting > together a system here in which a downloaded application must talk to the > server from which it is downloaded, the local system into which it is > downloaded, and the other endpoints with whom it wants to trade flows. If > we decline to put any constraint at all on the signaling that goes between > the downdloaded system and the server, we are, in essence, forcing the API > between the downloaded code and the local environment to support any > possible signaling. Since it is the local environment that will manage > codecs and emit RTP flows, that's a rough ask--especially if it has to > support signaling that might have radically different semantics. > At the core of any RTC endpoint is an API to manage codecs and emit RTP, they are the fundamental building blocks and in my view should be exposed to javascript. Attempts to impose the semantics of a given signalling protocol on the API will cause unnecessary complication and limit the ability to innovate. If we agreed on a semantic approach (e.g. solicit/propose or offer/answer), > then the syntactic difference would be, I admit, largely a matter of taste. > I would see no real reason not to have a baseline syntax, but I would > probably agree to it being pseudo code of some sort. But if we have no > agreed on *semantics* for the signaling, then the API between the downloaded > code and the local system is unbounded. That doesn't tend to make for > stable systems or interoperability. > I believe that interoperability should be reduced to the media stream - there should be no requirement that signalling from two different vendors would need to interoperate unless they choose to do so. > If you must gateway between systems (something I agree is not job one), > unbounded semantics would also imply arbitrary complexity in the gateways. > Again, not good for stability or deployability. > If vendors wish to interoperate with a common signalling protocol such as SIP then they will design their protocols with semantics that make that an easy task. The key difference between rtcweb and traditional RTC is that we have the flexibility of the javascript execution engine and we can change the signalling protocol from one page to another, or even one call to the next. If you want to make a SIP call, then use SIP.js, if you want to call another browser within the same web application, then use whatever signalling is most appropriate for the application. > I am, personally, far from convinced that having no constraints on the > signaling is worth imposing unbounded complexity on the Javascrip/Browser > API and any gateway systems, as well as circumscribing our security > choices. It may seem to be a dazzling amount of freedom, but it is only one > part of the system, and it ought to play well with others. > I agree that we need to ensure that the API can support the signalling protocols that we want it to, but I don't think that we should limit the API in any way so that it can only support those protocols unless there are very good reasons to do so. Neil --00151773de8ed3ee2b04af030988 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Oct 10, 2011 at 7:51 PM, Ted Hardie <t= ed.ietf@gmail.com> wrote:

Taking off my various hats, = I have to say I don't agree. =A0 We're putting together a system he= re in which a downloaded application must talk to the server from which it = is downloaded, the local system into which it is downloaded, and the other = endpoints with whom it wants to trade flows.=A0 If we decline to put any co= nstraint at all on the signaling that goes between the downdloaded system a= nd the server, we are, in essence, forcing the API between the downloaded c= ode and the local environment to support any possible signaling.=A0 Since i= t is the local environment that will manage codecs and emit RTP flows, that= 's a rough ask--especially if it has to support signaling that might ha= ve radically different semantics.=A0

At the core of any RTC endpoin= t is an API to manage codecs and emit RTP, they are the fundamental buildin= g blocks and in my view should be exposed to javascript. Attempts to impose= the semantics of a given signalling protocol on the API will cause unneces= sary complication and limit the ability to innovate.

If we agreed on a semantic approach (e.g. solicit/propose or offer/answe= r), then the syntactic difference would be, I admit, largely a matter of ta= ste.=A0 I would see no real reason not to have a baseline syntax, but I wou= ld probably agree to it being pseudo code of some sort.=A0 But if we have n= o agreed on *semantics* for the signaling, then the API between the downloa= ded code and the=A0 local system is unbounded.=A0 That doesn't tend to = make for stable systems or interoperability.

I believe that interoperabilit= y should be reduced to the media stream - there should be no requirement th= at signalling from two different vendors would need to interoperate unless = they choose to do so.
=A0
If you must gateway between systems (something I agree is not job one), u= nbounded semantics would also imply arbitrary complexity in the gateways.= =A0 Again, not good for stability or deployability.

If vendors wish to interoperat= e with a common signalling protocol such as SIP then they will design their= protocols with semantics that make that an easy task. The key difference b= etween rtcweb and traditional RTC is that we have the flexibility of the ja= vascript execution engine and we can change the signalling protocol from on= e page to another, or even one call to the next. If you want to make a SIP = call, then use SIP.js, if you want to call another browser within the same = web application, then use whatever signalling is most appropriate for the a= pplication.
=A0
I am, personally, far from convinced that having no constraints on the si= gnaling is worth imposing unbounded complexity on the Javascrip/Browser API= and any gateway systems, as well as circumscribing our security choices.= =A0 It may seem to be a dazzling amount of freedom, but it is only one part= of the system, and it ought to play well with others.

I agree that we need to ensure= that the API can support the signalling protocols that we want it to, but = I don't think that we should limit the API in any way so that it can on= ly support those protocols unless there are very good reasons to do so.

Neil
--00151773de8ed3ee2b04af030988-- From neils@vipadia.com Tue Oct 11 03:49: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 6641321F8C83 for ; Tue, 11 Oct 2011 03:49:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.826 X-Spam-Level: X-Spam-Status: No, score=-2.826 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tqZiYVlc5mjp for ; Tue, 11 Oct 2011 03:49:41 -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 D83FE21F8C74 for ; Tue, 11 Oct 2011 03:49:40 -0700 (PDT) Received: by iaby26 with SMTP id y26so10425808iab.31 for ; Tue, 11 Oct 2011 03:49:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.24.96 with SMTP id u32mr10010501ibb.61.1318330180526; Tue, 11 Oct 2011 03:49:40 -0700 (PDT) Sender: neils@vipadia.com Received: by 10.231.200.146 with HTTP; Tue, 11 Oct 2011 03:49:40 -0700 (PDT) In-Reply-To: References: Date: Tue, 11 Oct 2011 11:49:40 +0100 X-Google-Sender-Auth: ADhC199ONBv7hnaEwNlYEX08rxE Message-ID: From: Neil Stratford To: =?ISO-8859-1?Q?Jos=E9_Luis_Mill=E1n?= Content-Type: multipart/alternative; boundary=0015177414281b60fc04af03aac3 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SIP on the Web: presentation and video X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 10:49:41 -0000 --0015177414281b60fc04af03aac3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Oct 11, 2011 at 7:28 AM, Jos=E9 Luis Mill=E1n w= rote: > Hi, > > Some weeks ago we made a concrete proposal for signalling between Web > browser and server in RTCweb. Such a definition was described in > "draft-ibc-rtcweb-sip-websocket-00". > > We don't advocate for a default signaling protocol in RTCweb (not at all)= . > Current proposal is just an example of a working signaling for RTCweb bas= ed > on SIP and carried over WebSocket. > > We have just uploaded a video demo in which there can be seen a real > implementation of the mentioned draft. > > The components of the signalling architecture are a WebSocket capable > SIP proxy and a SIP stack written in JavaScript. These are needed to > make the browser became a real SIP node, capable to interact with real > SIP World. > > We would like to emphasize that the aim of this video is nothing but > showing an implementation of the proposed signalling. This is a great demo of what you can do in javascript. How would you deal with SIP credentials if you didn't want to expose them t= o the user but instead use an existing authenticated web session? Would it require a custom SIP authentication scheme to be implemented in the SIP proxy/registrar? Neil --0015177414281b60fc04af03aac3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Oct 11, 2011 at 7:28 AM, Jos=E9 Luis Mill=E1n <= ;jmillan@aliax.net> wrot= e:
Hi,

Some weeks ago we made a concrete proposal for signalling between Web
browser and server in RTCweb. Such a definition was described in
"draft-ibc-rtcweb-sip-websocket-00".

We don't advocate for a default signaling protocol in RTCweb (not at al= l).
Current proposal is just an example of a working signaling for RTCweb based=
on SIP and carried over WebSocket.

We have just uploaded a video demo in which there can be seen a real
implementation of the mentioned draft.

The components of the signalling architecture are a WebSocket capable
SIP proxy and a SIP stack written in JavaScript. These are needed to
make the browser became a real SIP node, capable to interact with real
SIP World.

We would like to emphasize that the aim of this video is nothing but
showing an implementation of the proposed signalling.

=
This is a great demo of what you can do in javascript.=A0
<= div>
How would you deal with SIP credentials if you didn'= t want to expose them to the user but instead use an existing authenticated= web session? Would it require a custom SIP authentication scheme to be imp= lemented in the SIP proxy/registrar?

Neil=A0
--0015177414281b60fc04af03aac3-- From ibc@aliax.net Tue Oct 11 03: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 103AE21F8C4D for ; Tue, 11 Oct 2011 03:58:01 -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.181, 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 0qwzFIMAhaxJ for ; Tue, 11 Oct 2011 03:58:00 -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 6CC7821F8C3E for ; Tue, 11 Oct 2011 03:58:00 -0700 (PDT) Received: by vws5 with SMTP id 5so6679200vws.31 for ; Tue, 11 Oct 2011 03:57:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.25.75 with SMTP id a11mr17779857vdg.1.1318330679767; Tue, 11 Oct 2011 03:57:59 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Tue, 11 Oct 2011 03:57:59 -0700 (PDT) In-Reply-To: References: Date: Tue, 11 Oct 2011 12:57:59 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Neil Stratford Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SIP on the Web: presentation and video X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 10:58:01 -0000 2011/10/11 Neil Stratford : > This is a great demo of what you can do in javascript. I hope the SIP proxy implementing WebSocket transport is also an important piece :) > How would you deal with SIP credentials if you didn't want to expose them= to > the user but instead use an existing authenticated web session? Would it > require a custom SIP authentication scheme to be implemented in the SIP > proxy/registrar? Good question. There are some alternatives: WebSocket allows sending a "Cookie" header during the WebSocket handshake between client and server (which is a HTTP GET request). Such "Cookie" header is populated by the *web* server once the user has logged in the web (by following any existing login mechanism). Then the WebSocket server could validate the "Cookie" header in order to authenticate SIP requests from the user. If the proxy implementing WebSocket transport is just an outbound proxy (not a registrar for example) it could add a "P-Asserted-Identity" header to the SIP REGISTER request before routing it to the registrar server. Another alternative would be: the user (the web browser) retrieves his SIP username and password from the web server (hopefully by mandating HTTPS) and uses them to calculate the Digest credentials when the SIP proxy replies 401/407. Regards. --=20 I=C3=B1aki Baz Castillo From sebastien.cubaud@orange.com Tue Oct 11 04:10: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 8972421F8D27 for ; Tue, 11 Oct 2011 04:10:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.298 X-Spam-Level: X-Spam-Status: No, score=-1.298 tagged_above=-999 required=5 tests=[AWL=0.951, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T0owv1KaTyPZ for ; Tue, 11 Oct 2011 04:10:18 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id 82BF121F8D23 for ; Tue, 11 Oct 2011 04:10:18 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 66143FCC002; Tue, 11 Oct 2011 13:10:17 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 5AA69FCC001; Tue, 11 Oct 2011 13:10:17 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 11 Oct 2011 13:10:17 +0200 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, 11 Oct 2011 13:10:15 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] Sebastien Cubaud's non-ICE mechanism (Re: Summary of ICE discussion) Thread-Index: AcyHw7KHZmQN1dUbTQqm+QcGaRqUxgAJRXwwAActoyA= References: <4E8B192E.80809@ericsson.com><4E935A8B.8020700@alvestrand.no><4E9389C0.5050607@jesup.org> <4E93B43C.3060106@jdrosen.net> From: To: , X-OriginalArrivalTime: 11 Oct 2011 11:10:17.0280 (UTC) FILETIME=[5B79EC00:01CC8806] Subject: Re: [rtcweb] Sebastien Cubaud's non-ICE mechanism (Re: Summary of ICE discussion) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 11:10:19 -0000 Hi, sorry for my previous message that I probably sent too rapidly: I = have just realized that RFC 5576 couldn't be used to describe = synchronization source from remote endpoints. So, even for SSRC, = extended procedures would be required.. Too bad! (; Cheers Sebastien -----Message d'origine----- De=A0: CUBAUD Sebastien RD-CORE-LAN=20 Envoy=E9=A0: mardi 11 octobre 2011 09:48 =C0=A0: 'Jonathan Rosenberg'; rtcweb@ietf.org Objet=A0: RE: [rtcweb] Sebastien Cubaud's non-ICE mechanism (Re: Summary = of ICE discussion) Hi Jonathan,=20 The use of the SSRC - prior to being accessible via JS for mux/demux = purposes- could be an alternative to using the sequence number and/or = the timestamp (as suggested by Randell). SIP endpoints interfacing with = RTC-Web browsers would then only be required to implement RFC 5576 = (which may be less costly than STUN implementation, the SHA-1 = computation + CRC compute for the fingerprint).. Cheers Sebastien =20 -----Message d'origine----- De=A0: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] De la = part de Jonathan Rosenberg Envoy=E9=A0: mardi 11 octobre 2011 05:13 =C0=A0: rtcweb@ietf.org Objet=A0: Re: [rtcweb] Sebastien Cubaud's non-ICE mechanism (Re: Summary = of ICE discussion) Security issues aside, the proposed solution does not work with existing = SIP/RTP implementations. The main drawback of the ICE solution is that=20 it won't work with deployed equipment. I see little benefit in=20 specifying another solution which does not fix the main limitation we=20 have with ICE. -Jonathan R. On 10/10/2011 8:11 PM, Randell Jesup wrote: > On 10/10/2011 7:04 PM, Eric Rescorla wrote: >> On Mon, Oct 10, 2011 at 1:50 PM, Harald >> Alvestrand wrote: >>> Changing the subject to keep threads separate.... >>> >>> On 10/09/2011 12:00 PM, sebastien.cubaud@orange.com wrote: >>>> Here are the steps I foresee before allowing the establishment of a >>>> media >>>> session: >>>> >>>> - Let's consider A (a RTC-Web compliant browser) connected to = server >>>> S and >>>> wishing to share real-time media with destination B (potentially a = SIP >>>> endpoint or a browser) >>>> - A& B learn via the signalling channel the triple @IP, transport = proto >>>> and associated listening port of the remote media >>>> - A sends a few RTP packets to B (3 as in RFC 2833/4733 or more?).- >>>> This >>>> would allow the mechanism to resist against packet loss -. The >>>> format of such >>>> packets are to be discussed >>>> - Assuming B receives these packets, it then sends via the = signalling >>>> channel an information from the media path unknown from S (i.e. not >>>> accessible via >>>> JS). >>>> I propose to use the min of the sequence number of the RTP packets >>>> received (which is random per RFC 3550) >>> >>> The sequence number is a 16-bit number, so there are 16 bits of >>> randomness >>> to play with here. >>> An attack based on just returning a random number will succeed 1 out = of >>> 65.536 times; if any of the 3 packets' sequence numbers are >>> acceptable, it >>> will succeed 1 out of 21.845 times. > > If you use the sequence number and the timestamp, you have 48 bits of > entropy... > > --=20 Jonathan D. Rosenberg, Ph.D. SkypeID: jdrosen Skype Chief Technology Strategist jdrosen@skype.net http://www.skype.com jdrosen@jdrosen.net http://www.jdrosen.net _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From mperumal@cisco.com Tue Oct 11 05:05: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 263E221F8560 for ; Tue, 11 Oct 2011 05:05:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.445 X-Spam-Level: X-Spam-Status: No, score=-8.445 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_BELOW2=2.154, 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 M7EYTLarYyEH for ; Tue, 11 Oct 2011 05:05: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 AFE0821F851F for ; Tue, 11 Oct 2011 05:05:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mperumal@cisco.com; l=6883; q=dns/txt; s=iport; t=1318334727; x=1319544327; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=0neOKqUQ2k/T3pxSYR2kcmE9Np24xEG6OBEcf6dWp20=; b=kbAm+9/QSYdu/7Ys7X9WWROosuAZPhvBMStksZqfBZ38y+S21KHAiqey B42MDziC0zelNi/oZRh1URB5uKNFG5v5xsEB505iXHQBMmdVA5CUUON+/ khDL6pAQHHL1hYY2+Qn1h4LEYIFguz2Od+W52j9JCIf0HAsMG992QcGSh o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnkAAI8wlE5Io8UR/2dsb2JhbABDmQSPIoEFgVMBAQEEAQEBCQYBChM+FwICAgEIEQEDAQELBhcBBgEaDB8DBggBAQQBCggIEweHY5plAZ5QAwKGaWEEh08ukSmMKQ X-IronPort-AV: E=Sophos;i="4.68,523,1312156800"; d="scan'208";a="57554604" Received: from bgl-core-2.cisco.com ([72.163.197.17]) by ams-iport-2.cisco.com with ESMTP; 11 Oct 2011 12:05:25 +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 p9BC5NaP017193; Tue, 11 Oct 2011 12:05:24 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); Tue, 11 Oct 2011 17:35: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: Tue, 11 Oct 2011 17:35:07 +0530 Message-ID: <1D062974A4845E4D8A343C6538049202068FED61@XMB-BGL-414.cisco.com> In-Reply-To: <4E935A8B.8020700@alvestrand.no> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] Sebastien Cubaud's non-ICE mechanism (Re: Summary of ICE discussion) Thread-Index: AcyHjkLROLg5C5rpSKevWSMpyvuZJwAYOygA References: <4E8B192E.80809@ericsson.com> <4E935A8B.8020700@alvestrand.no> From: "Muthu Arul Mozhi Perumal (mperumal)" To: "Harald Alvestrand" , X-OriginalArrivalTime: 11 Oct 2011 12:05:14.0613 (UTC) FILETIME=[08D70250:01CC880E] Subject: Re: [rtcweb] Sebastien Cubaud's non-ICE mechanism (Re: Summary of ICE discussion) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 12:05:29 -0000 |> - Assuming B receives these packets, it then sends=20 |> via the signalling channel an information from the=20 |> media path unknown from S (i.e. not accessible via JS). A requirement hidden here is that B shouldn't alert the user till the = entire consent verification is complete (otherwise B would have to = buffer the media coming from the user). If B is a PSTN gateway this = isn't going to be trivial to implement. If we go down this path, I think we would end up reinventing = ICE/ICE-Lite in a different form (which doesn't look worth the effort), = so we should just make use of ICE. Muthu |-----Original Message----- |From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On = Behalf Of Harald Alvestrand |Sent: Tuesday, October 11, 2011 2:20 AM |To: rtcweb@ietf.org |Subject: [rtcweb] Sebastien Cubaud's non-ICE mechanism (Re: Summary of = ICE discussion) | |Changing the subject to keep threads separate.... | |On 10/09/2011 12:00 PM, sebastien.cubaud@orange.com wrote: |> Hi there, |> |> Re Magnus's call for proposal (If anyone can find a solution that = fulfill |> the security goals and have improved legacy interoperability people = would |> be interested in that solution. So far RTCP has been discarded as = insufficient.) |> on media consent verification, here is below a suggestion for the = group: |> |> Basically, the idea, compared to Hadriel's RTCP proposal, relies on = the use |> of the signalling path instead of RTCP as a feedback channel for = media |> consent verification. |> |> Here are the steps I foresee before allowing the establishment of a = media session: |> |> - Let's consider A (a RTC-Web compliant browser) connected to server = S and |> wishing to share real-time media with destination B (potentially a = SIP |> endpoint or a browser) |> - A& B learn via the signalling channel the triple @IP, transport = proto and |> associated listening port of the remote media |> - A sends a few RTP packets to B (3 as in RFC 2833/4733 or more?).- = This would |> allow the mechanism to resist against packet loss -. The format of = such packets |> are to be discussed |> - Assuming B receives these packets, it then sends via the signalling = channel |> an information from the media path unknown from S (i.e. not = accessible via JS). |> I propose to use the min of the sequence number of the RTP packets = received |> (which is random per RFC 3550) |The sequence number is a 16-bit number, so there are 16 bits of |randomness to play with here. |An attack based on just returning a random number will succeed 1 out of |65.536 times; if any of the 3 packets' sequence numbers are acceptable, |it will succeed 1 out of 21.845 times. | |A browser can reasonably limit the number of attempts per second = (either |overall or per-script); multiple browsers will not be able to = coordinate |on any such limit. | |Is this defense strong enough to warrant considering this further? | |> - A receives via S this info granting B's consent to receiving media = from A |> - A now can start sending media to B |> |> When B uses SIP as its signalling channel, Step 4 would probably = require a |> SDP extension to convey this info, as well as possibly extended = H.248/Diameter |> informations would be required in a decoupled sig./media = architecture. |> Of course, a solution avoiding extensions would be more than welcome. |> |> The benefit of this mechanism largely relies on the assumption that = the |> transmission of information from the media termination of the = destination |> to its associated signalling channel is less costly than implementing = ICE connectivity |> checks. Which is still to be checked. |> |> This mechanism provides basic media consent verification and if it = turns out |> that it provides less security properties than ICE or other drawbacks = (e.g. |> increasing media session establishment delay, issues with the few = initial RTP |> packets,..), it could be seen as a fallback media consent = verification |> when ICE is not implemented at each end of media terminations. |> |> Looking forward to hearing feedbacks from the group on this. |> |> Cheers |> Sebastien |> |> -----Message d'origine----- |> De : rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] De la = part de Magnus Westerlund |> Envoy=E9 : mardi 4 octobre 2011 16:33 |> =C0 : rtcweb@ietf.org |> Objet : [rtcweb] Summary of ICE discussion |> |> WG, |> |> I have bellow tired to summarize the result of the ICE discussion. = This |> is intended as furthering this discussion and form a basis for going |> forward in the consensus process. I do expect people that disagree = with |> my summary of the discussion to speak up. |> |> Major requirements |> |> - Need for data transmission consent for protocols using UDP as the |> traffic receiver needs to consent to receiving the data |> |> - Perform NAT and FW traversal when ever needed |> |> - Support IPv4 to IPv6 transition |> |> Desired behavior: |> |> - Be interoperable with deployed legacy systems as SIP Trunk, PSTN |> gateways, VoIP phones. |> |> WG chairs conclusion of discussion so far: |> |> - ICE is so far the only solution that provides the security goals = and |> have any legacy deployment. |> |> - ICE usage will require that STUN connectivity MUST have succeeded |> prior to any data transmission to fulfill security goals. |> |> * The Browser will enforce this requirement to prevent being an = attack |> vector in all cases. |> |> - If anyone can find a solution that fulfill the security goals and = have |> improved legacy interoperability people would be interested in that |> solution. So far RTCP has been discarded as insufficient. |> |> - Media Gateway can support a reduced functionality set from Full ICE |> |> Cheers |> |> Magnus Westerlund |> as WG chair |> |> = ---------------------------------------------------------------------- |> 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 |> | |_______________________________________________ |rtcweb mailing list |rtcweb@ietf.org |https://www.ietf.org/mailman/listinfo/rtcweb From sebastien.cubaud@orange.com Tue Oct 11 05:57: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 EA04E21F8CD9 for ; Tue, 11 Oct 2011 05:57:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.38 X-Spam-Level: X-Spam-Status: No, score=-0.38 tagged_above=-999 required=5 tests=[AWL=-0.285, BAYES_00=-2.599, FRT_BELOW2=2.154, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uujhQRd55M7t for ; Tue, 11 Oct 2011 05:57:13 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id AE9E621F8C00 for ; Tue, 11 Oct 2011 05:57:12 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 02AE44010B; Tue, 11 Oct 2011 14:49:05 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id B56C5340128; Tue, 11 Oct 2011 14:44:58 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 11 Oct 2011 14:44:58 +0200 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, 11 Oct 2011 14:44:57 +0200 Message-ID: In-Reply-To: <1D062974A4845E4D8A343C6538049202068FED61@XMB-BGL-414.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] Sebastien Cubaud's non-ICE mechanism (Re: Summary ofICE discussion) Thread-Index: AcyHjkLROLg5C5rpSKevWSMpyvuZJwAYOygAAAgRaIA= References: <4E8B192E.80809@ericsson.com><4E935A8B.8020700@alvestrand.no> <1D062974A4845E4D8A343C6538049202068FED61@XMB-BGL-414.cisco.com> From: To: , , X-OriginalArrivalTime: 11 Oct 2011 12:44:58.0847 (UTC) FILETIME=[95F43EF0:01CC8813] Subject: Re: [rtcweb] Sebastien Cubaud's non-ICE mechanism (Re: Summary ofICE discussion) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 12:57:14 -0000 Hi Muthu,=20 |>A requirement hidden here is that B shouldn't alert the user till the = entire consent verification is complete (otherwise B would have to = buffer the |>media coming from the user). I am not sure to follow your concern here: alerting the user would look = to me as associated to the first signalling step in which B provides its = @IP, transport port, listening port. For instance, as in your example, = if B is a PSTN gateway, assuming SIP is the protocol used by the GW to = interoperate with RTC-Web, the PSTN gateway may send a IAM message upon = reception on the initial SIP INVITE. And this IAM would trigger the = alerting of the user (and should alerting the user be a concern, SIP = preconditions could be used to prevent it until a precondition being = that A has received media consent verification from B be satisfied). If you mean that the initial "testing" RTP packets could be rendered to = the user, this is what I meant as "the format [of the initial RTP = packets] are to be discussed" in my initial mail. I guess there are = possible ways to make those RTP flows transparent to the end user (e.g. = having them discarded by a standard RTP implementations, containing = white noise, etc..). Prior to discussing these details, I guess the main = point is to determine whether an extension to SIP, as minimal as it can = be, is a viable option for SIP endpoints interfacing with RTC-Web = compared to ICE connectivity checks procedure.=20 Kind regards, Sebastien -----Message d'origine----- De=A0: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] De la = part de Muthu Arul Mozhi Perumal (mperumal) Envoy=E9=A0: mardi 11 octobre 2011 14:05 =C0=A0: Harald Alvestrand; rtcweb@ietf.org Objet=A0: Re: [rtcweb] Sebastien Cubaud's non-ICE mechanism (Re: Summary = ofICE discussion) |> - Assuming B receives these packets, it then sends=20 |> via the signalling channel an information from the=20 |> media path unknown from S (i.e. not accessible via JS). A requirement hidden here is that B shouldn't alert the user till the = entire consent verification is complete (otherwise B would have to = buffer the media coming from the user). If B is a PSTN gateway this = isn't going to be trivial to implement. If we go down this path, I think we would end up reinventing = ICE/ICE-Lite in a different form (which doesn't look worth the effort), = so we should just make use of ICE. Muthu |-----Original Message----- |From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On = Behalf Of Harald Alvestrand |Sent: Tuesday, October 11, 2011 2:20 AM |To: rtcweb@ietf.org |Subject: [rtcweb] Sebastien Cubaud's non-ICE mechanism (Re: Summary of = ICE discussion) | |Changing the subject to keep threads separate.... | |On 10/09/2011 12:00 PM, sebastien.cubaud@orange.com wrote: |> Hi there, |> |> Re Magnus's call for proposal (If anyone can find a solution that = fulfill |> the security goals and have improved legacy interoperability people = would |> be interested in that solution. So far RTCP has been discarded as = insufficient.) |> on media consent verification, here is below a suggestion for the = group: |> |> Basically, the idea, compared to Hadriel's RTCP proposal, relies on = the use |> of the signalling path instead of RTCP as a feedback channel for = media |> consent verification. |> |> Here are the steps I foresee before allowing the establishment of a = media session: |> |> - Let's consider A (a RTC-Web compliant browser) connected to server = S and |> wishing to share real-time media with destination B (potentially a = SIP |> endpoint or a browser) |> - A& B learn via the signalling channel the triple @IP, transport = proto and |> associated listening port of the remote media |> - A sends a few RTP packets to B (3 as in RFC 2833/4733 or more?).- = This would |> allow the mechanism to resist against packet loss -. The format of = such packets |> are to be discussed |> - Assuming B receives these packets, it then sends via the signalling = channel |> an information from the media path unknown from S (i.e. not = accessible via JS). |> I propose to use the min of the sequence number of the RTP packets = received |> (which is random per RFC 3550) |The sequence number is a 16-bit number, so there are 16 bits of |randomness to play with here. |An attack based on just returning a random number will succeed 1 out of |65.536 times; if any of the 3 packets' sequence numbers are acceptable, |it will succeed 1 out of 21.845 times. | |A browser can reasonably limit the number of attempts per second = (either |overall or per-script); multiple browsers will not be able to = coordinate |on any such limit. | |Is this defense strong enough to warrant considering this further? | |> - A receives via S this info granting B's consent to receiving media = from A |> - A now can start sending media to B |> |> When B uses SIP as its signalling channel, Step 4 would probably = require a |> SDP extension to convey this info, as well as possibly extended = H.248/Diameter |> informations would be required in a decoupled sig./media = architecture. |> Of course, a solution avoiding extensions would be more than welcome. |> |> The benefit of this mechanism largely relies on the assumption that = the |> transmission of information from the media termination of the = destination |> to its associated signalling channel is less costly than implementing = ICE connectivity |> checks. Which is still to be checked. |> |> This mechanism provides basic media consent verification and if it = turns out |> that it provides less security properties than ICE or other drawbacks = (e.g. |> increasing media session establishment delay, issues with the few = initial RTP |> packets,..), it could be seen as a fallback media consent = verification |> when ICE is not implemented at each end of media terminations. |> |> Looking forward to hearing feedbacks from the group on this. |> |> Cheers |> Sebastien |> |> -----Message d'origine----- |> De : rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] De la = part de Magnus Westerlund |> Envoy=E9 : mardi 4 octobre 2011 16:33 |> =C0 : rtcweb@ietf.org |> Objet : [rtcweb] Summary of ICE discussion |> |> WG, |> |> I have bellow tired to summarize the result of the ICE discussion. = This |> is intended as furthering this discussion and form a basis for going |> forward in the consensus process. I do expect people that disagree = with |> my summary of the discussion to speak up. |> |> Major requirements |> |> - Need for data transmission consent for protocols using UDP as the |> traffic receiver needs to consent to receiving the data |> |> - Perform NAT and FW traversal when ever needed |> |> - Support IPv4 to IPv6 transition |> |> Desired behavior: |> |> - Be interoperable with deployed legacy systems as SIP Trunk, PSTN |> gateways, VoIP phones. |> |> WG chairs conclusion of discussion so far: |> |> - ICE is so far the only solution that provides the security goals = and |> have any legacy deployment. |> |> - ICE usage will require that STUN connectivity MUST have succeeded |> prior to any data transmission to fulfill security goals. |> |> * The Browser will enforce this requirement to prevent being an = attack |> vector in all cases. |> |> - If anyone can find a solution that fulfill the security goals and = have |> improved legacy interoperability people would be interested in that |> solution. So far RTCP has been discarded as insufficient. |> |> - Media Gateway can support a reduced functionality set from Full ICE |> |> Cheers |> |> Magnus Westerlund |> as WG chair |> |> = ---------------------------------------------------------------------- |> 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 |> | |_______________________________________________ |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 csp@csperkins.org Tue Oct 11 08:35: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 D445621F8E73 for ; Tue, 11 Oct 2011 08:35:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.116 X-Spam-Level: X-Spam-Status: No, score=-103.116 tagged_above=-999 required=5 tests=[AWL=0.483, 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 2S9xPIKv6UXA for ; Tue, 11 Oct 2011 08:35:06 -0700 (PDT) Received: from anchor-msapost-1.mail.demon.net (anchor-msapost-1.mail.demon.net [195.173.77.164]) by ietfa.amsl.com (Postfix) with ESMTP id 58CB621F8C10 for ; Tue, 11 Oct 2011 08:35:06 -0700 (PDT) Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]) by anchor-post-1.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1RDeMD-000564-g8; Tue, 11 Oct 2011 15:35:05 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Colin Perkins In-Reply-To: <4E8F711B.3050808@jesup.org> Date: Tue, 11 Oct 2011 16:35:02 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E8DCA06.5060506@jesup.org> <4E8F711B.3050808@jesup.org> To: Randell Jesup X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Congestion Control 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: Tue, 11 Oct 2011 15:35:07 -0000 On 7 Oct 2011, at 22:37, Randell Jesup wrote: > On 10/7/2011 3:12 PM, Colin Perkins wrote: >> [inline] >>=20 >> On 6 Oct 2011, at 16:32, Randell Jesup wrote: >> ... >>> Startup: >>>=20 >>> There are issues both with starting too low (quality is poor at the = start and takes a while to get better), and with starting too high (you = immediately can get into a delay situation and have to go into = recovery). In general, starting too low is better than starting too = high, as when we ramp up past the bottleneck we will not be too far over = the limit and so recovery will be easier. In general, the bottleneck = link is often upstream, though this is moderating as high-bandwidth = broadband becomes more common. >>>=20 >>> Options include: >>> a) Start at fixed value >>> b) Start at N% below the value from the last call with this person >>> (probably requires the App to help here) >>> c) Start at N% below the value from the last call with anyone >>> d) Have the other side tell us the rate they successfully received = in the >>> last call. Start the call at the lower of the last-call = reception >>> rate from the far end or our last-call sending rate, minus n% >>> e) probe bandwidth at or before the start of the call using a = packet >>> train >>>=20 >>> 'a' will be quite sub-optimal for most cases, though if the value is = low enough it won't be over-bandwidth. Some applications (games, etc) = may want to limit the starting bandwidth to avoid negative interactions = with other dataflows. >>>=20 >>> 'b' has a problem that if the last call had a much higher bottleneck = bandwidth (especially on the remote downstream), the new call may be = over-bandwidth, perhaps badly. This won't be the norm, but may happen = especially with mobile/wifi at either end. >>>=20 >>> 'c' has a problem that if the last callee had a much higher = bottleneck bandwidth (especially on the remote downstream), the new call = may be over-bandwidth, perhaps badly. If the caller's upstream = bandwidth is high compared to typical downstream bandwidth, then the = likelihood of starting over-bandwidth is high. >>>=20 >>> 'd' has the advantage of selecting an appropriate value regardless = of whether the bottleneck is on upstream or downstream. The downside of = 'd' is that the bottlenecks may have changed since the last call in = which case we may start over-bandwidth. The historical data could be = transferred via pre-call signalling. >>>=20 >>> 'e' allows direct measurement of the current call bottlenecks. = However 'e' can be misled if a mid-call router that isn't the bottleneck = buffers the packet train while housekeeping or doing other operations = and then releases them (it can collapse the signal from an earlier = bottleneck). It would need to be combined with starting on the low side = until a valid measurement is completed. Single measurements are = imprecise with packet trains. >>=20 >> For a new call, the only safe approach for the network would seem to = be option (a), starting at a low rate, followed by a fairly rapid = increase in rate to find the safe operating point (i.e., mirroring TCP = slow start in concept, if not in detail). The low rate would be chosen = to support the voice channel, presumably, so the call is useful = immediately, but might then take several RTTs to ramp up to a high = enough rate for video to be usable. An initial delay on the video is not = an ideal user experience, but I don't see it as being especially = problematic provided the voice channel is usable immediately, and we = don't seem to have safe options for avoiding it. >=20 > I understand your concern, and agree one should start "low" - but I = also feel that for many applications and many users, this would be an = over-conservatism that would seriously degrade a very important point in = a communication. That initial "answer" behavior had a big impact on the = user experience and in the end, utility to the user. In "most" calls = (I'd guess for residential desktop browsers >95%, laptops >70% though = much more variable) the bottleneck will be the same or similar to the = last call - the local upstream, which is fairly constant. >=20 > There are users and use-cases where this consistency will not apply - = mobile laptop users (when away from desk/office), tablet/handsets. I = will note that in most of these cases the change in bottleneck will tend = to be less than 2x, so major changes in bandwidth will be fairly = uncommon. (You can get a hint on this by checking for external IP = address changes!) >=20 > In most videophones and soft clients that I've looked at, they have a = configured bitrate set by the user and either start at that bitrate, or = start at a fraction of that bitrate. At WorldGate, we started at a = sliding percentage of the configured bandwidth - a higher percentage at = low bandwidths, and down to 50% of configured at high bandwidths, = combined (as you suggest) with a much higher ramp-up rate (and = faster/further cut-back on problems) for the first seconds of the call. >=20 > These things, taken together, make we want to be a bit more aggressive = at using history, and perhaps also use the recent N calls' variance in = bottleneck rate as a guide (if they're all good at higher rates, start = at 50 or 60% of the average; if there's a lot of variance (laptop moving = around) use not the last call, but perhaps the lowest quartile or 10th = minus 10 or 20%. >=20 > Also - this is something that I strongly feel should not be normative. = This is guidance and I do feel that there is a place for the = application to provide input and/or user preference here. I think we = *should* provide guidance and defaults. I'm hesitant to accept the argument that bottleneck bandwidth is likely = to be roughly consistent, so we can start at a rate near that bandwidth. = There's getting to be a lot more mobile devices that can switch between = WiFi and 3G links with potentially very different capacity, and even = ADSL lines can be highly variable with time of day and other users on = the same link. As a result, if we are to use history, I think we need = normative rules for how, so we at least limit the amount and duration of = any damage caused when the history-derived bandwidth estimate is wrong. >> Using a packet pair/train to get an estimate of the available = bandwidth is appealing, but I'm unconvinced it's accurate enough to be = reliable. We've done packet pair measurements to residential links that = show extremely inaccurate (high) bandwidth estimates in many cases, so I = wouldn't trust that as an initial sending rate. Using a longer packet = train would improve accuracy, but at the cost of loading the path, and = potentially disrupting any traffic sharing the path. I'm not sure such a = bandwidth estimate is that worthwhile if it delays/disrupts the start of = the voice channel. >=20 >=20 > I am likewise leery of packet trains, especially short start-of-call = trains. They're interesting, but as you mention they don't seem = reliable enough. >=20 >> When restarting a previously application limited flow after some = short pause in transmission (e.g., the centralised video mixer scenario, = where only the active speaker sends video to the mixer), then I'm much = more comfortable with restarting at or near the previous rate, provided = there's been no indication that the path has changed. The rationale here = is that you've had some recent indication that the path can support the = rate, but with a new connection, even if to someone you've previously = spoken with, there's much less of a guarantee that the available = bandwidth is consistent with the previous observation. >=20 >=20 > Agreed. >=20 >>> Even if the data flows are separately congestion controlled, in many = uses >>> they will be non-continuous flows (discrete messages as opposed to = data or >>> file transfers). These sorts of channels have different needs and >>> different impacts on the media channels from continuous flows: = they're >>> bursty; low delay is important (especially on the initial packet for = a >>> burst, which is often the only packet), and without a steady stream >>> congestion control will have little effect - and will have little = impact on >>> the media flows. For small bursts of data traffic, the "right" = solution >>> may be to simply ignore them up to some limit, and above that limit = start >>> to subtract the data channel usage from the available bandwidth for >>> variable-rate encoders. >>>=20 >>> The problem here will be defining "small". This will need to be = tested and >>> simulated so we know the impacts of different data usage patterns. = I'll >>> throw a straw-man proposal out there: if the increase in data usage = over >>> the last 1/2 second is below 20% of the total estimated channel = bandwidth, >>> no adjustment to the media channels shall be done, and normal = congestion >>> control mechanisms will be allowed to operate with no interference. = Above >>> that value, the media channels if possible will be adjusted down in >>> bandwidth by some amount related to the increase in data channel = bandwidth. >>>=20 >>> The reason for using the increase in bandwidth here is that for = steady >>> flows, normal congestion control should operate well; the problem is = when >>> you have a spike in bandwidth use - the latency in reaction may be = longer >>> than the duration of the burst, and hurt end-to-end delay in the = meantime. >>> So when there's a sudden jump in data bandwidth, you temporarily = offset >>> media down to keep delay and buffering under control. You could = also >>> increase media bitrates if a steady flow suddenly drops, though = normal >>> congestion control mechanisms should use the now-available bandwidth >>> quickly on their own. >> Is there some way of measuring the spare queueing capacity of the = path, perhaps by periodic probing? To define "small" in a way that's = meaningful to the path, we'd be looking at a burst that can be queued in = the network without causing excessive delay or queue overflow/loss. = Using "1/2 second" or "20%" seems too arbitrary. >=20 >=20 > It may be possible to use naturally-occuring bursts (or slightly = artificially-contrived bursts) to probe the channel. For example, = periodic or error-recovery iframes amount to a fairly large burst of = large packets; measuring the dispersion at the reception end may will = give you a reasonable estimate of unused bandwidth. (I'll note that if = you don't have access to the raw network interface this might be a = little noisier). Unused bandwidth might be less important than unused queuing capacity.=20= >>> JS Interface: >>>=20 >>> We need to tell the application about bandwidth changes, and give it = the >>> option of making choices, both in the allocation of bits among the = various >>> streams of data, and of the actual streams themselves (adding or = shutting >>> down streams, or switching modes (mono/stereo, codecs possibly, = etc)). If >>> the application doesn't care to make a choice we'll do it for them. = We'll >>> also want the JS application to be able to affect the = congestion-control >>> status of the data channels, so it could take bits from the data = channels >>> without engendering a tug-of-war and temporary = over-bandwidth/buffering. >>>=20 >>> There are inherent delays to some of these actions by the app, and = in an >>> over-bandwidth case we need to reduce bandwidth *now*, so we may = want to >>> have the "I'm over-bandwidth" case start by automatically reducing >>> bandwidth if possible, and inform the JS app of the reduction and = let it >>> rebalance or change the details or nature of the call. >>>=20 >>> We could use some good straw-men proposals for an API here to the JS = code. >> The right model might be for the application to communicate policy = for how to adapt, which the browser then implements. Putting Javascript = in the congestion control loop is a concern because of the slow = response, which runs the risk of causing oscillation. If we can let the = browser run the rate adaption mechanism that's more likely to be stable, = and leave the slower Javascript to make the decision about adaptation = policy. >=20 >=20 > Agreed, though some of the adaptations have to occur at the = application level (turning off channels, which may involve UI changes, = etc). That was why I suggested we adapt using defaults (and any hints = given ("policy" in your post)), and then inform the JS app of the change = and allow it to rebalance or re-allocate the BW usage, or to change the = already-made decisions. This helps guarantee we have working defaults = and response speed. >=20 > I fear if we try to push all that logic down into the media code it = becomes too complex, because you have to anticipate any way an = application might want to react, and provide it (and test it). Agree. There's clearly a balance to be got here. The main point is that = the javascript can be in the control loop, since it's operating at a = slower timescale. --=20 Colin Perkins http://csperkins.org/ From randell-ietf@jesup.org Tue Oct 11 23:58: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 E2DDD21F8C52 for ; Tue, 11 Oct 2011 23:58:30 -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 fGceItXxaskF for ; Tue, 11 Oct 2011 23:58:29 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 8A94C21F8C51 for ; Tue, 11 Oct 2011 23:58:29 -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 1RDslo-0006T8-1C; Wed, 12 Oct 2011 01:58:28 -0500 Message-ID: <4E953992.9070505@jesup.org> Date: Wed, 12 Oct 2011 02:54:10 -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, rtp-congestion@alvestrand.no References: <4E8DCA06.5060506@jesup.org> <4E8F711B.3050808@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] Congestion Control 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, 12 Oct 2011 06:58:31 -0000 Inline below... We should probably move this to rtp-congestion. On 10/11/2011 11:35 AM, Colin Perkins wrote: > On 7 Oct 2011, at 22:37, Randell Jesup wrote: >> On 10/7/2011 3:12 PM, Colin Perkins wrote: >>> [inline] >>> >>> On 6 Oct 2011, at 16:32, Randell Jesup wrote: >>> ... >>>> Startup: >>>> >>>> There are issues both with starting too low (quality is poor at the start and takes a while to get better), and with starting too high (you immediately can get into a delay situation and have to go into recovery). In general, starting too low is better than starting too high, as when we ramp up past the bottleneck we will not be too far over the limit and so recovery will be easier. In general, the bottleneck link is often upstream, though this is moderating as high-bandwidth broadband becomes more common. >>>> >>>> Options include: >>>> a) Start at fixed value >>>> b) Start at N% below the value from the last call with this person >>>> (probably requires the App to help here) >>>> c) Start at N% below the value from the last call with anyone >>>> d) Have the other side tell us the rate they successfully received in the >>>> last call. Start the call at the lower of the last-call reception >>>> rate from the far end or our last-call sending rate, minus n% >>>> e) probe bandwidth at or before the start of the call using a packet >>>> train >>>> >>>> 'a' will be quite sub-optimal for most cases, though if the value is low enough it won't be over-bandwidth. Some applications (games, etc) may want to limit the starting bandwidth to avoid negative interactions with other dataflows. >>>> >>>> 'b' has a problem that if the last call had a much higher bottleneck bandwidth (especially on the remote downstream), the new call may be over-bandwidth, perhaps badly. This won't be the norm, but may happen especially with mobile/wifi at either end. >>>> >>>> 'c' has a problem that if the last callee had a much higher bottleneck bandwidth (especially on the remote downstream), the new call may be over-bandwidth, perhaps badly. If the caller's upstream bandwidth is high compared to typical downstream bandwidth, then the likelihood of starting over-bandwidth is high. >>>> >>>> 'd' has the advantage of selecting an appropriate value regardless of whether the bottleneck is on upstream or downstream. The downside of 'd' is that the bottlenecks may have changed since the last call in which case we may start over-bandwidth. The historical data could be transferred via pre-call signalling. >>>> >>>> 'e' allows direct measurement of the current call bottlenecks. However 'e' can be misled if a mid-call router that isn't the bottleneck buffers the packet train while housekeeping or doing other operations and then releases them (it can collapse the signal from an earlier bottleneck). It would need to be combined with starting on the low side until a valid measurement is completed. Single measurements are imprecise with packet trains. >>> For a new call, the only safe approach for the network would seem to be option (a), starting at a low rate, followed by a fairly rapid increase in rate to find the safe operating point (i.e., mirroring TCP slow start in concept, if not in detail). The low rate would be chosen to support the voice channel, presumably, so the call is useful immediately, but might then take several RTTs to ramp up to a high enough rate for video to be usable. An initial delay on the video is not an ideal user experience, but I don't see it as being especially problematic provided the voice channel is usable immediately, and we don't seem to have safe options for avoiding it. >> I understand your concern, and agree one should start "low" - but I also feel that for many applications and many users, this would be an over-conservatism that would seriously degrade a very important point in a communication. That initial "answer" behavior had a big impact on the user experience and in the end, utility to the user. In "most" calls (I'd guess for residential desktop browsers>95%, laptops>70% though much more variable) the bottleneck will be the same or similar to the last call - the local upstream, which is fairly constant. >> >> There are users and use-cases where this consistency will not apply - mobile laptop users (when away from desk/office), tablet/handsets. I will note that in most of these cases the change in bottleneck will tend to be less than 2x, so major changes in bandwidth will be fairly uncommon. (You can get a hint on this by checking for external IP address changes!) >> >> In most videophones and soft clients that I've looked at, they have a configured bitrate set by the user and either start at that bitrate, or start at a fraction of that bitrate. At WorldGate, we started at a sliding percentage of the configured bandwidth - a higher percentage at low bandwidths, and down to 50% of configured at high bandwidths, combined (as you suggest) with a much higher ramp-up rate (and faster/further cut-back on problems) for the first seconds of the call. >> >> These things, taken together, make we want to be a bit more aggressive at using history, and perhaps also use the recent N calls' variance in bottleneck rate as a guide (if they're all good at higher rates, start at 50 or 60% of the average; if there's a lot of variance (laptop moving around) use not the last call, but perhaps the lowest quartile or 10th minus 10 or 20%. >> >> Also - this is something that I strongly feel should not be normative. This is guidance and I do feel that there is a place for the application to provide input and/or user preference here. I think we *should* provide guidance and defaults. > I'm hesitant to accept the argument that bottleneck bandwidth is likely to be roughly consistent, so we can start at a rate near that bandwidth. There's getting to be a lot more mobile devices that can switch between WiFi and 3G links with potentially very different capacity, and even ADSL lines can be highly variable with time of day and other users on the same link. As a result, if we are to use history, I think we need normative rules for how, so we at least limit the amount and duration of any damage caused when the history-derived bandwidth estimate is wrong. Hopefully we can identify most of the interface changes such as you mention (IP address changes, OS notification, etc). But even if we can't (ADSL or cable modem upstream variability), the algorithm is adaptive; the downside of starting too high is that it quickly sees that packets arrive at the destination slower than they should; so roughly (depending on RTT) a fractional second or perhaps in some cases a second or two will go by before low-latency within-bandwidth communication is established. And if we're only a little over it may not be very noticeable. And as I suggested, if you start at a significant reduction from expected bandwidth (I generally would recommend 20-30% below at "low" bandwidths, and up to 50-60% reduction at "high" bandwidths), the odds of being over the actual limit, especially in the ADSL/Cable cases is low. >>> Using a packet pair/train to get an estimate of the available bandwidth is appealing, but I'm unconvinced it's accurate enough to be reliable. We've done packet pair measurements to residential links that show extremely inaccurate (high) bandwidth estimates in many cases, so I wouldn't trust that as an initial sending rate. Using a longer packet train would improve accuracy, but at the cost of loading the path, and potentially disrupting any traffic sharing the path. I'm not sure such a bandwidth estimate is that worthwhile if it delays/disrupts the start of the voice channel. >> >> I am likewise leery of packet trains, especially short start-of-call trains. They're interesting, but as you mention they don't seem reliable enough. >> >>> When restarting a previously application limited flow after some short pause in transmission (e.g., the centralised video mixer scenario, where only the active speaker sends video to the mixer), then I'm much more comfortable with restarting at or near the previous rate, provided there's been no indication that the path has changed. The rationale here is that you've had some recent indication that the path can support the rate, but with a new connection, even if to someone you've previously spoken with, there's much less of a guarantee that the available bandwidth is consistent with the previous observation. >> >> Agreed. >> >>>> Even if the data flows are separately congestion controlled, in many uses >>>> they will be non-continuous flows (discrete messages as opposed to data or >>>> file transfers). These sorts of channels have different needs and >>>> different impacts on the media channels from continuous flows: they're >>>> bursty; low delay is important (especially on the initial packet for a >>>> burst, which is often the only packet), and without a steady stream >>>> congestion control will have little effect - and will have little impact on >>>> the media flows. For small bursts of data traffic, the "right" solution >>>> may be to simply ignore them up to some limit, and above that limit start >>>> to subtract the data channel usage from the available bandwidth for >>>> variable-rate encoders. >>>> >>>> The problem here will be defining "small". This will need to be tested and >>>> simulated so we know the impacts of different data usage patterns. I'll >>>> throw a straw-man proposal out there: if the increase in data usage over >>>> the last 1/2 second is below 20% of the total estimated channel bandwidth, >>>> no adjustment to the media channels shall be done, and normal congestion >>>> control mechanisms will be allowed to operate with no interference. Above >>>> that value, the media channels if possible will be adjusted down in >>>> bandwidth by some amount related to the increase in data channel bandwidth. >>>> >>>> The reason for using the increase in bandwidth here is that for steady >>>> flows, normal congestion control should operate well; the problem is when >>>> you have a spike in bandwidth use - the latency in reaction may be longer >>>> than the duration of the burst, and hurt end-to-end delay in the meantime. >>>> So when there's a sudden jump in data bandwidth, you temporarily offset >>>> media down to keep delay and buffering under control. You could also >>>> increase media bitrates if a steady flow suddenly drops, though normal >>>> congestion control mechanisms should use the now-available bandwidth >>>> quickly on their own. >>> Is there some way of measuring the spare queueing capacity of the path, perhaps by periodic probing? To define "small" in a way that's meaningful to the path, we'd be looking at a burst that can be queued in the network without causing excessive delay or queue overflow/loss. Using "1/2 second" or "20%" seems too arbitrary. >> >> It may be possible to use naturally-occuring bursts (or slightly artificially-contrived bursts) to probe the channel. For example, periodic or error-recovery iframes amount to a fairly large burst of large packets; measuring the dispersion at the reception end may will give you a reasonable estimate of unused bandwidth. (I'll note that if you don't have access to the raw network interface this might be a little noisier). > Unused bandwidth might be less important than unused queuing capacity. I'm not sure we care about unused queuing capability at all - we want to stay out of the queue. We are interested in how far below the limit where queuing begins we are. >>>> JS Interface: >>>> >>>> We need to tell the application about bandwidth changes, and give it the >>>> option of making choices, both in the allocation of bits among the various >>>> streams of data, and of the actual streams themselves (adding or shutting >>>> down streams, or switching modes (mono/stereo, codecs possibly, etc)). If >>>> the application doesn't care to make a choice we'll do it for them. We'll >>>> also want the JS application to be able to affect the congestion-control >>>> status of the data channels, so it could take bits from the data channels >>>> without engendering a tug-of-war and temporary over-bandwidth/buffering. >>>> >>>> There are inherent delays to some of these actions by the app, and in an >>>> over-bandwidth case we need to reduce bandwidth *now*, so we may want to >>>> have the "I'm over-bandwidth" case start by automatically reducing >>>> bandwidth if possible, and inform the JS app of the reduction and let it >>>> rebalance or change the details or nature of the call. >>>> >>>> We could use some good straw-men proposals for an API here to the JS code. >>> The right model might be for the application to communicate policy for how to adapt, which the browser then implements. Putting Javascript in the congestion control loop is a concern because of the slow response, which runs the risk of causing oscillation. If we can let the browser run the rate adaption mechanism that's more likely to be stable, and leave the slower Javascript to make the decision about adaptation policy. >> >> Agreed, though some of the adaptations have to occur at the application level (turning off channels, which may involve UI changes, etc). That was why I suggested we adapt using defaults (and any hints given ("policy" in your post)), and then inform the JS app of the change and allow it to rebalance or re-allocate the BW usage, or to change the already-made decisions. This helps guarantee we have working defaults and response speed. >> >> I fear if we try to push all that logic down into the media code it becomes too complex, because you have to anticipate any way an application might want to react, and provide it (and test it). > > Agree. There's clearly a balance to be got here. The main point is that the javascript can be in the control loop, since it's operating at a slower timescale. > -- Randell Jesup randell-ietf@jesup.org From harald@alvestrand.no Wed Oct 12 00: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 8408D21F8B1D for ; Wed, 12 Oct 2011 00:44:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u5ja4eGyM532 for ; Wed, 12 Oct 2011 00:44:39 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id C344E21F8A6F for ; Wed, 12 Oct 2011 00:44:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A80C539E10E; Wed, 12 Oct 2011 09:44: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 Xl6NFOnZkmVV; Wed, 12 Oct 2011 09:44:37 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (unknown [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 4121A39E072; Wed, 12 Oct 2011 09:44:37 +0200 (CEST) Message-ID: <4E954564.200@alvestrand.no> Date: Wed, 12 Oct 2011 09:44:36 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: "rtcweb@ietf.org" , "public-webrtc@w3.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [rtcweb] New mailing list: RTP-congestion X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 07:44:40 -0000 In order to facilitate a (hopefully) wide bandwidth exchange between those people who are most intensely interested in the subject, I've set up a new mailing list called "rtp-congestion@alvestrand.no", with the following description: Discussions about congestion control in RTP. This is related to, but not part of, the RTCWEB WG of the IETF. This list is operated under IETF contribution rules; please regard the NOTE WELL as being included. Subscribe here: http://www.alvestrand.no/mailman/listinfo/rtp-congestion Harald From harald@alvestrand.no Wed Oct 12 02:01: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 7AC4121F8C10 for ; Wed, 12 Oct 2011 02:01:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mXgeLbRubv1p for ; Wed, 12 Oct 2011 02:01:43 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id CD78C21F8B0F for ; Wed, 12 Oct 2011 02:01:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3195439E178 for ; Wed, 12 Oct 2011 11:01:42 +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 3ooJgtefUEBF for ; Wed, 12 Oct 2011 11:01:41 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (unknown [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id ABB4239E072 for ; Wed, 12 Oct 2011 11:01:41 +0200 (CEST) Message-ID: <4E955775.10206@alvestrand.no> Date: Wed, 12 Oct 2011 11:01:41 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4E8D6507.8000707@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [rtcweb] Making progress on the signaling discussion (NB: Action items enclosed!) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 09:01:43 -0000 On 10/11/11 10:37, Iñaki Baz Castillo wrote: > 2011/10/7 Iñaki Baz Castillo: >>> To clarify, what I see the question for the WG is how the signalling >>> model for RTCWEB session establishment is intended to work. Thus the >>> drafts intended for answering this needs to be focused on describing a >>> signalling model. >> Yes, agreed. >> >> >> Regards. >> >> >> PS: SIP over WebSocket just works fine. A demonstration next week. > > Hi, as told in other thread, the demonstration and video of SIP over > WebSocket is already available: > > http://sip-on-the-web.aliax.net/ > > So this becomes a signaling protocol example for RTCweb, a *known* > signaling protocol in fact (so we can figure what we need from the > future RTCweb JS API in order to deal with SDP's and media sessions). > the video has a caveat of course: we don't know that the signalling can be successfully connected to the browser's API, because there's no API to connect to yet. One of the worries I have with doing a "low level spec" unconstrained by our present competence (ignorance?) in is that I'm reasonably sure we have the knowledge to generate and parse SDP, because the codebases we are building on already generate and parse SDP, and the information present there is enough to set up calls, because we're already setting up calls using that information. I'm less sure of our "getting things right" if we start off by describing the capabilities and control knobs to be exposed in an unconstrained API. Harald From neils@vipadia.com Wed Oct 12 02:46: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 27C5F21F8B95 for ; Wed, 12 Oct 2011 02:46:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.901 X-Spam-Level: X-Spam-Status: No, score=-2.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] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dR26A28Bs-3m for ; Wed, 12 Oct 2011 02:46:22 -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 9C27921F88B7 for ; Wed, 12 Oct 2011 02:46:22 -0700 (PDT) Received: by iaby26 with SMTP id y26so742650iab.31 for ; Wed, 12 Oct 2011 02:46:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.24.96 with SMTP id u32mr11961953ibb.61.1318412782103; Wed, 12 Oct 2011 02:46:22 -0700 (PDT) Sender: neils@vipadia.com Received: by 10.231.200.146 with HTTP; Wed, 12 Oct 2011 02:46:22 -0700 (PDT) In-Reply-To: <4E955775.10206@alvestrand.no> References: <4E8D6507.8000707@ericsson.com> <4E955775.10206@alvestrand.no> Date: Wed, 12 Oct 2011 10:46:22 +0100 X-Google-Sender-Auth: dt6QjMatYTczh96_THON_0V01jw Message-ID: From: Neil Stratford To: Harald Alvestrand Content-Type: multipart/alternative; boundary=0015177414288b6b9d04af16e599 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Making progress on the signaling discussion (NB: Action items enclosed!) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 09:46:23 -0000 --0015177414288b6b9d04af16e599 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Oct 12, 2011 at 10:01 AM, Harald Alvestrand wrote > One of the worries I have with doing a "low level spec" unconstrained by > our present competence (ignorance?) in is that I'm reasonably sure we have > the knowledge to generate and parse SDP, because the codebases we are > building on already generate and parse SDP, and the information present > there is enough to set up calls, because we're already setting up calls > using that information. > > I'm less sure of our "getting things right" if we start off by describing > the capabilities and control knobs to be exposed in an unconstrained API. As a counter argument, those very same codebases that generate and parse SDP also contain internal APIs that look a lot like a low level spec API, and the information they present is enough to generate and parse SDP and set up calls. Maybe we don't like those APIs and perhaps they expose too much as they were never intended to be made public, but they do exist already. Neil --0015177414288b6b9d04af16e599 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Oct 12, 2011 at 10:01 AM, Harald Alvestrand <<= a href=3D"mailto:harald@alvestrand.no">harald@alvestrand.no> = wrote
One of the worries I have with doing a "low level spec" unconstra= ined by our present competence (ignorance?) in =A0is that I'm reasonabl= y sure we have the knowledge to generate and parse SDP, because the codebas= es we are building on already generate and parse SDP, and the information p= resent there is enough to set up calls, because we're already setting u= p calls using that information.

I'm less sure of our "getting things right" if we start off b= y describing the capabilities and control knobs to be exposed in an unconst= rained API.

As a counter argument, those ve= ry same codebases that generate and parse SDP also contain internal APIs th= at look a lot like a low level spec API, and the information they present i= s enough to generate and parse SDP and set up calls.

Maybe we don't like those APIs and perhaps they exp= ose too much as they were never intended to be made public, but they do exi= st already.

Neil=A0
--0015177414288b6b9d04af16e599-- From harald@alvestrand.no Wed Oct 12 03: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 B60B521F8C06 for ; Wed, 12 Oct 2011 03:00:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k75YKP76zsnW for ; Wed, 12 Oct 2011 03:00:10 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id DF4C021F8B56 for ; Wed, 12 Oct 2011 03:00:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 370AD39E182; Wed, 12 Oct 2011 12:00:09 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zo+7tcXk57aE; Wed, 12 Oct 2011 12:00:08 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (unknown [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id A5BBC39E178; Wed, 12 Oct 2011 12:00:06 +0200 (CEST) Message-ID: <4E956526.2090604@alvestrand.no> Date: Wed, 12 Oct 2011 12:00:06 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: Neil Stratford References: <4E8D6507.8000707@ericsson.com> <4E955775.10206@alvestrand.no> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040901070802090502030606" Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Making progress on the signaling discussion (NB: Action items enclosed!) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 10:00:10 -0000 This is a multi-part message in MIME format. --------------040901070802090502030606 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 10/12/11 11:46, Neil Stratford wrote: > On Wed, Oct 12, 2011 at 10:01 AM, Harald Alvestrand > > wrote > > One of the worries I have with doing a "low level spec" > unconstrained by our present competence (ignorance?) in is that > I'm reasonably sure we have the knowledge to generate and parse > SDP, because the codebases we are building on already generate and > parse SDP, and the information present there is enough to set up > calls, because we're already setting up calls using that information. > > I'm less sure of our "getting things right" if we start off by > describing the capabilities and control knobs to be exposed in an > unconstrained API. > > > As a counter argument, those very same codebases that generate and > parse SDP also contain internal APIs that look a lot like a low level > spec API, and the information they present is enough to generate and > parse SDP and set up calls. > > Maybe we don't like those APIs and perhaps they expose too much as > they were never intended to be made public, but they do exist already. Yup. And I suspect they're all subtly different. > > Neil --------------040901070802090502030606 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 10/12/11 11:46, Neil Stratford wrote:
On Wed, Oct 12, 2011 at 10:01 AM, Harald Alvestrand <harald@alvestrand.no> wrote
One of the worries I have with doing a "low level spec" unconstrained by our present competence (ignorance?) in  is that I'm reasonably sure we have the knowledge to generate and parse SDP, because the codebases we are building on already generate and parse SDP, and the information present there is enough to set up calls, because we're already setting up calls using that information.

I'm less sure of our "getting things right" if we start off by describing the capabilities and control knobs to be exposed in an unconstrained API.

As a counter argument, those very same codebases that generate and parse SDP also contain internal APIs that look a lot like a low level spec API, and the information they present is enough to generate and parse SDP and set up calls.

Maybe we don't like those APIs and perhaps they expose too much as they were never intended to be made public, but they do exist already.
Yup. And I suspect they're all subtly different.


Neil 

--------------040901070802090502030606-- From tim@phonefromhere.com Wed Oct 12 03: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 C43BB21F8C04 for ; Wed, 12 Oct 2011 03:31:26 -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 q+tfnhUFF3OX for ; Wed, 12 Oct 2011 03:31:26 -0700 (PDT) Received: from zimbra.westhawk.co.uk (zimbra.westhawk.co.uk [192.67.4.167]) by ietfa.amsl.com (Postfix) with ESMTP id F28B621F8BDE for ; Wed, 12 Oct 2011 03:31:25 -0700 (PDT) Received: from [192.168.0.14] (unknown [93.89.81.113]) by zimbra.westhawk.co.uk (Postfix) with ESMTP id 22AA137A902; Wed, 12 Oct 2011 11:44:07 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-26-805858366 From: Tim Panton In-Reply-To: <4E956526.2090604@alvestrand.no> Date: Wed, 12 Oct 2011 11:31:14 +0100 Message-Id: <380E325E-A7EF-489A-AA24-0270224FC87A@phonefromhere.com> References: <4E8D6507.8000707@ericsson.com> <4E955775.10206@alvestrand.no> <4E956526.2090604@alvestrand.no> To: Harald Alvestrand X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Making progress on the signaling discussion (NB: Action items enclosed!) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 10:31:26 -0000 --Apple-Mail-26-805858366 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 12 Oct 2011, at 11:00, Harald Alvestrand wrote: > On 10/12/11 11:46, Neil Stratford wrote: >>=20 >> On Wed, Oct 12, 2011 at 10:01 AM, Harald Alvestrand = wrote >> One of the worries I have with doing a "low level spec" unconstrained = by our present competence (ignorance?) in is that I'm reasonably sure = we have the knowledge to generate and parse SDP, because the codebases = we are building on already generate and parse SDP, and the information = present there is enough to set up calls, because we're already setting = up calls using that information. >>=20 >> I'm less sure of our "getting things right" if we start off by = describing the capabilities and control knobs to be exposed in an = unconstrained API. >>=20 >> As a counter argument, those very same codebases that generate and = parse SDP also contain internal APIs that look a lot like a low level = spec API, and the information they present is enough to generate and = parse SDP and set up calls. >>=20 >> Maybe we don't like those APIs and perhaps they expose too much as = they were never intended to be made public, but they do exist already. > Yup. And I suspect they're all subtly different. >=20 You could look at that in a positive light -=20 as evidence that there are multiple ways to solve this problem and = deduce: a) it isn't impossibly hard b) there isn't one 'correct' way of doing it. Which would lead me back to specifying as _little_ as possible and = letting innovation take place. Tim= --Apple-Mail-26-805858366 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
On 12 Oct 2011, at 11:00, Harald Alvestrand wrote:

On 10/12/11 11:46, Neil Stratford wrote:
On Wed, Oct 12, 2011 at 10:01 AM, Harald Alvestrand <harald@alvestrand.no> wrote
One of the worries I have with doing a "low level spec" unconstrained by our present competence (ignorance?) in  is that I'm reasonably sure we have the knowledge to generate and parse SDP, because the codebases we are building on already generate and parse SDP, and the information present there is enough to set up calls, because we're already setting up calls using that information.

I'm less sure of our "getting things right" if we start off by describing the capabilities and control knobs to be exposed in an unconstrained API.

As a counter argument, those very same codebases that generate and parse SDP also contain internal APIs that look a lot like a low level spec API, and the information they present is enough to generate and parse SDP and set up calls.

Maybe we don't like those APIs and perhaps they expose too much as they were never intended to be made public, but they do exist already.
Yup. And I suspect they're all subtly different.


You could look at that in a positive light - 
as evidence that there are multiple ways to solve this problem and deduce:
a) it isn't impossibly hard
b) there isn't one 'correct' way of doing it.

Which would lead me back to specifying as _little_ as possible and letting innovation take place.

Tim
--Apple-Mail-26-805858366-- From harald@alvestrand.no Wed Oct 12 04:39: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 55A7C21F8C7D for ; Wed, 12 Oct 2011 04:39:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r+CrX+pKQdOH for ; Wed, 12 Oct 2011 04:39:05 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 1CFB921F8C7E for ; Wed, 12 Oct 2011 04:39:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 70B1239E10E; Wed, 12 Oct 2011 13:39: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 ubz9JMAWN5ts; Wed, 12 Oct 2011 13:39:03 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (unknown [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id C196E39E072; Wed, 12 Oct 2011 13:39:03 +0200 (CEST) Message-ID: <4E957C55.9020706@alvestrand.no> Date: Wed, 12 Oct 2011 13:39:01 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: Tim Panton References: <4E8D6507.8000707@ericsson.com> <4E955775.10206@alvestrand.no> <4E956526.2090604@alvestrand.no> <380E325E-A7EF-489A-AA24-0270224FC87A@phonefromhere.com> In-Reply-To: <380E325E-A7EF-489A-AA24-0270224FC87A@phonefromhere.com> Content-Type: multipart/alternative; boundary="------------050801010605030005000307" Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Making progress on the signaling discussion (NB: Action items enclosed!) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 11:39:06 -0000 This is a multi-part message in MIME format. --------------050801010605030005000307 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 10/12/11 12:31, Tim Panton wrote: > > On 12 Oct 2011, at 11:00, Harald Alvestrand wrote: > >> On 10/12/11 11:46, Neil Stratford wrote: >>> On Wed, Oct 12, 2011 at 10:01 AM, Harald Alvestrand >>> > wrote >>> >>> One of the worries I have with doing a "low level spec" >>> unconstrained by our present competence (ignorance?) in is that >>> I'm reasonably sure we have the knowledge to generate and parse >>> SDP, because the codebases we are building on already generate >>> and parse SDP, and the information present there is enough to >>> set up calls, because we're already setting up calls using that >>> information. >>> >>> I'm less sure of our "getting things right" if we start off by >>> describing the capabilities and control knobs to be exposed in >>> an unconstrained API. >>> >>> >>> As a counter argument, those very same codebases that generate and >>> parse SDP also contain internal APIs that look a lot like a low >>> level spec API, and the information they present is enough to >>> generate and parse SDP and set up calls. >>> >>> Maybe we don't like those APIs and perhaps they expose too much as >>> they were never intended to be made public, but they do exist already. >> Yup. And I suspect they're all subtly different. >> > > You could look at that in a positive light - > as evidence that there are multiple ways to solve this problem and deduce: > a) it isn't impossibly hard > b) there isn't one 'correct' way of doing it. > > Which would lead me back to specifying as _little_ as possible and > letting innovation take place. > We have to specify enough for interoperation in at least the use cases of the scenarios document. In enough detail for interoperation to happen. That could turn out to be a lot, especially if we can't point to existing specs and say "use that". Harald --------------050801010605030005000307 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 10/12/11 12:31, Tim Panton wrote:

On 12 Oct 2011, at 11:00, Harald Alvestrand wrote:

On 10/12/11 11:46, Neil Stratford wrote:
On Wed, Oct 12, 2011 at 10:01 AM, Harald Alvestrand <harald@alvestrand.no> wrote
One of the worries I have with doing a "low level spec" unconstrained by our present competence (ignorance?) in  is that I'm reasonably sure we have the knowledge to generate and parse SDP, because the codebases we are building on already generate and parse SDP, and the information present there is enough to set up calls, because we're already setting up calls using that information.

I'm less sure of our "getting things right" if we start off by describing the capabilities and control knobs to be exposed in an unconstrained API.

As a counter argument, those very same codebases that generate and parse SDP also contain internal APIs that look a lot like a low level spec API, and the information they present is enough to generate and parse SDP and set up calls.

Maybe we don't like those APIs and perhaps they expose too much as they were never intended to be made public, but they do exist already.
Yup. And I suspect they're all subtly different.


You could look at that in a positive light - 
as evidence that there are multiple ways to solve this problem and deduce:
a) it isn't impossibly hard
b) there isn't one 'correct' way of doing it.

Which would lead me back to specifying as _little_ as possible and letting innovation take place.

We have to specify enough for interoperation in at least the use cases of the scenarios document.
In enough detail for interoperation to happen.

That could turn out to be a lot, especially if we can't point to existing specs and say "use that".

              Harald

--------------050801010605030005000307-- From matthew.kaufman@skype.net Wed Oct 12 05:00: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 EC2D421F8C41 for ; Wed, 12 Oct 2011 05:00:30 -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 x3KdPlG-i0It for ; Wed, 12 Oct 2011 05:00:30 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id 1166B21F8C2A for ; Wed, 12 Oct 2011 05:00:30 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id 91CDE16F0; Wed, 12 Oct 2011 14:00:27 +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=d2uKEihycNjLfq g1cTYqSnA71EU=; b=V+5dssLSpmAwrumBSoCiYo7/yFPp0NF5LMqZTGWfo+LZYL YtwqMPmL/OSVUp4st8dMXQuV08+QxPqW0L8OsNY+3RpH626DmyIozMS4VhnQZkL3 OIhc/4d9nxOyWDY1HkfOUBv2Mw13cZ0L5rCOxqg+51WAnrQfSGXlBRuSYB28U= 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=dZfVc2oMDQsikcXpIdNDxv lTiu5uN9A0XE0MXLZ9pxDwHZQ/MSAzybIvf6O7CnLsq9jwBhbeuJOpcx49aka4Yt 9mupPa35ybJS+kT+oS7Q0Lq4URyd5McTKY4QUkejPzkkb0Lgzk8Y2us712ELt6eM d2iS1DrbuGYp59KetrvAI= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id 904ED7F6; Wed, 12 Oct 2011 14:00:27 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id 63D5F1672682; Wed, 12 Oct 2011 14:00:27 +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 JDIS4iyRMWFD; Wed, 12 Oct 2011 14:00:26 +0200 (CEST) Received: from dhcp-222-27.meetings.nanog.org (dhcp-222-27.meetings.nanog.org [199.187.222.27]) by zimbra.skype.net (Postfix) with ESMTPSA id 0DE371672681; Wed, 12 Oct 2011 14:00:24 +0200 (CEST) Message-ID: <4E958157.7050203@skype.net> Date: Wed, 12 Oct 2011 08:00:23 -0400 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: <4E8D6507.8000707@ericsson.com> <4E955775.10206@alvestrand.no> In-Reply-To: <4E955775.10206@alvestrand.no> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Making progress on the signaling discussion (NB: Action items enclosed!) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 12:00:31 -0000 On 10/12/11 5:01 AM, Harald Alvestrand wrote: > ... > we don't know that the signalling can be successfully connected to the > browser's API, because there's no API to connect to yet. > > One of the worries I have with doing a "low level spec" unconstrained > by our present competence (ignorance?) in is that I'm reasonably sure > we have the knowledge to generate and parse SDP, because the codebases > we are building on already generate and parse SDP, and the information > present there is enough to set up calls, because we're already setting > up calls using that information. And yet those aforementioned codebases generate and parse SDP, and set up calls, using an API underneath them which is obviously capable (existence proof), even though it wasn't designed this way. Just like you can build a SIP/SDP softphone using the Win32 APIs, even though Win32's API design didn't take SIP or SDP into account when it was being specified. > > I'm less sure of our "getting things right" if we start off by > describing the capabilities and control knobs to be exposed in an > unconstrained API. I am absolutely certain we can build whatever we want, including SIP or SDP compatibility, if we make the API low enough level that *anything* can be built. And I believe that once we get to this level, we've made the browser the new operating system and a platform for future innovation... instead of locking developers in to a single way of solving things by putting an entire softphone in there. Matthew Kaufman From tim@phonefromhere.com Wed Oct 12 05:14: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 7321B21F8CC7 for ; Wed, 12 Oct 2011 05:14:21 -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 bTcXLKNSJesY for ; Wed, 12 Oct 2011 05:14: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 6D36E21F8CC3 for ; Wed, 12 Oct 2011 05:14:20 -0700 (PDT) Received: from [192.168.0.14] (unknown [93.89.81.113]) by zimbra.westhawk.co.uk (Postfix) with ESMTP id D0C8137A902; Wed, 12 Oct 2011 13:26:23 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-27-811995111 From: Tim Panton In-Reply-To: <4E957C55.9020706@alvestrand.no> Date: Wed, 12 Oct 2011 13:13:31 +0100 Message-Id: <13C2526B-E7B1-408C-BD1D-EC5E8C8F6472@phonefromhere.com> References: <4E8D6507.8000707@ericsson.com> <4E955775.10206@alvestrand.no> <4E956526.2090604@alvestrand.no> <380E325E-A7EF-489A-AA24-0270224FC87A@phonefromhere.com> <4E957C55.9020706@alvestrand.no> To: Harald Alvestrand X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Making progress on the signaling discussion (NB: Action items enclosed!) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 12:14:21 -0000 --Apple-Mail-27-811995111 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 12 Oct 2011, at 12:39, Harald Alvestrand wrote: > On 10/12/11 12:31, Tim Panton wrote: >>=20 >>=20 >> On 12 Oct 2011, at 11:00, Harald Alvestrand wrote: >>=20 >>> On 10/12/11 11:46, Neil Stratford wrote: >>>>=20 >>>> On Wed, Oct 12, 2011 at 10:01 AM, Harald Alvestrand = wrote >>>> One of the worries I have with doing a "low level spec" = unconstrained by our present competence (ignorance?) in is that I'm = reasonably sure we have the knowledge to generate and parse SDP, because = the codebases we are building on already generate and parse SDP, and the = information present there is enough to set up calls, because we're = already setting up calls using that information. >>>>=20 >>>> I'm less sure of our "getting things right" if we start off by = describing the capabilities and control knobs to be exposed in an = unconstrained API. >>>>=20 >>>> As a counter argument, those very same codebases that generate and = parse SDP also contain internal APIs that look a lot like a low level = spec API, and the information they present is enough to generate and = parse SDP and set up calls. >>>>=20 >>>> Maybe we don't like those APIs and perhaps they expose too much as = they were never intended to be made public, but they do exist already. >>> Yup. And I suspect they're all subtly different. >>>=20 >>=20 >> You could look at that in a positive light -=20 >> as evidence that there are multiple ways to solve this problem and = deduce: >> a) it isn't impossibly hard >> b) there isn't one 'correct' way of doing it. >>=20 >> Which would lead me back to specifying as _little_ as possible and = letting innovation take place. >>=20 > We have to specify enough for interoperation in at least the use cases = of the scenarios document. > In enough detail for interoperation to happen. >=20 > That could turn out to be a lot, especially if we can't point to = existing specs and say "use that". So, to paraphrase (and make sure I understand) - your argument is that = if we don't use SDP, we will have to specify all the fields and associated meanings for every = codec we expect to support. If we do use SDP, then we just point at existing usage and say - 'there, = use that' . If we use a subset or variant on SDP we can say - 'use that, except for = this bit to do with port allocation'. Is that a fair (if informal) summary? Tim. >=20 > Harald >=20 --Apple-Mail-27-811995111 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
On 12 Oct 2011, at 12:39, Harald Alvestrand wrote:

On 10/12/11 12:31, Tim Panton wrote:

On 12 Oct 2011, at 11:00, Harald Alvestrand wrote:

On 10/12/11 11:46, Neil Stratford wrote:
On Wed, Oct 12, 2011 at 10:01 AM, Harald Alvestrand <harald@alvestrand.no> wrote
One of the worries I have with doing a "low level spec" unconstrained by our present competence (ignorance?) in  is that I'm reasonably sure we have the knowledge to generate and parse SDP, because the codebases we are building on already generate and parse SDP, and the information present there is enough to set up calls, because we're already setting up calls using that information.

I'm less sure of our "getting things right" if we start off by describing the capabilities and control knobs to be exposed in an unconstrained API.

As a counter argument, those very same codebases that generate and parse SDP also contain internal APIs that look a lot like a low level spec API, and the information they present is enough to generate and parse SDP and set up calls.

Maybe we don't like those APIs and perhaps they expose too much as they were never intended to be made public, but they do exist already.
Yup. And I suspect they're all subtly different.


You could look at that in a positive light - 
as evidence that there are multiple ways to solve this problem and deduce:
a) it isn't impossibly hard
b) there isn't one 'correct' way of doing it.

Which would lead me back to specifying as _little_ as possible and letting innovation take place.

We have to specify enough for interoperation in at least the use cases of the scenarios document.
In enough detail for interoperation to happen.

That could turn out to be a lot, especially if we can't point to existing specs and say "use that".

So, to paraphrase (and make sure I understand) - your argument is that if we don't use SDP,
we will have to specify all the fields and associated meanings for every codec we expect to support.

If we do use SDP, then we just point at existing usage and say - 'there, use that' .

If we use a subset or variant on SDP we can say - 'use that, except for this bit to do with port allocation'.

Is that a fair (if informal) summary?

Tim.


              Harald


--Apple-Mail-27-811995111-- From stefan.lk.hakansson@ericsson.com Wed Oct 12 05:18: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 5782121F8C75 for ; Wed, 12 Oct 2011 05:18:42 -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 Ve-2tLwL9D3e for ; Wed, 12 Oct 2011 05:18: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 9DC5D21F8C4C for ; Wed, 12 Oct 2011 05:18:41 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-76-4e95857790f9 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id B4.27.20773.775859E4; Wed, 12 Oct 2011 14:17:59 +0200 (CEST) Received: from [150.132.141.51] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.137.0; Wed, 12 Oct 2011 14:17:59 +0200 Message-ID: <4E958576.4020307@ericsson.com> Date: Wed, 12 Oct 2011 14:17:58 +0200 From: =?ISO-8859-1?Q?Stefan_H=E5kansson_LK?= User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4E8D6507.8000707@ericsson.com> <4E955775.10206@alvestrand.no> <4E958157.7050203@skype.net> In-Reply-To: <4E958157.7050203@skype.net> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [rtcweb] Making progress on the signaling discussion (NB: Action items enclosed!) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 12:18:42 -0000 On 2011-10-12 14:00, Matthew Kaufman wrote: > And I believe that once we get to this level, we've made the browser the > new operating system and a platform for future innovation... instead of > locking developers in to a single way of solving things by putting an > entire softphone in there. I think that the current API proposal (dealing with MediaStreams and tracks thereof) leaves quite much room for innovation and is far from "an entire softphone" approach. From tim@phonefromhere.com Wed Oct 12 05:37: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 4931121F8C10 for ; Wed, 12 Oct 2011 05:37: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=[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 D4oiZUBKRQwS for ; Wed, 12 Oct 2011 05:37: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 275F321F8B2F for ; Wed, 12 Oct 2011 05:37:39 -0700 (PDT) Received: from [192.168.0.14] (unknown [93.89.81.113]) by zimbra.westhawk.co.uk (Postfix) with ESMTP id 155BD37A902; Wed, 12 Oct 2011 13:49:35 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-28-813386311 From: Tim Panton In-Reply-To: <4E95871F.9010605@alvestrand.no> Date: Wed, 12 Oct 2011 13:36:42 +0100 Message-Id: References: <4E8D6507.8000707@ericsson.com> <4E955775.10206@alvestrand.no> <4E956526.2090604@alvestrand.no> <380E325E-A7EF-489A-AA24-0270224FC87A@phonefromhere.com> <4E957C55.9020706@alvestrand.no> <13C2526B-E7B1-408C-BD1D-EC5E8C8F6472@phonefromhere.com> <4E95871F.9010605@alvestrand.no> To: Harald Alvestrand X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Making progress on the signaling discussion (NB: Action items enclosed!) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 12:37:40 -0000 --Apple-Mail-28-813386311 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 12 Oct 2011, at 13:25, Harald Alvestrand wrote: > On 10/12/11 14:13, Tim Panton wrote: >>=20 >>=20 >> On 12 Oct 2011, at 12:39, Harald Alvestrand wrote: >>=20 >>> On 10/12/11 12:31, Tim Panton wrote: >>>>=20 >>>>=20 >>>> On 12 Oct 2011, at 11:00, Harald Alvestrand wrote: >>>>=20 >>>>> On 10/12/11 11:46, Neil Stratford wrote: >>>>>>=20 >>>>>> On Wed, Oct 12, 2011 at 10:01 AM, Harald Alvestrand = wrote >>>>>> One of the worries I have with doing a "low level spec" = unconstrained by our present competence (ignorance?) in is that I'm = reasonably sure we have the knowledge to generate and parse SDP, because = the codebases we are building on already generate and parse SDP, and the = information present there is enough to set up calls, because we're = already setting up calls using that information. >>>>>>=20 >>>>>> I'm less sure of our "getting things right" if we start off by = describing the capabilities and control knobs to be exposed in an = unconstrained API. >>>>>>=20 >>>>>> As a counter argument, those very same codebases that generate = and parse SDP also contain internal APIs that look a lot like a low = level spec API, and the information they present is enough to generate = and parse SDP and set up calls. >>>>>>=20 >>>>>> Maybe we don't like those APIs and perhaps they expose too much = as they were never intended to be made public, but they do exist = already. >>>>> Yup. And I suspect they're all subtly different. >>>>>=20 >>>>=20 >>>> You could look at that in a positive light -=20 >>>> as evidence that there are multiple ways to solve this problem and = deduce: >>>> a) it isn't impossibly hard >>>> b) there isn't one 'correct' way of doing it. >>>>=20 >>>> Which would lead me back to specifying as _little_ as possible and = letting innovation take place. >>>>=20 >>> We have to specify enough for interoperation in at least the use = cases of the scenarios document. >>> In enough detail for interoperation to happen. >>>=20 >>> That could turn out to be a lot, especially if we can't point to = existing specs and say "use that". >>=20 >> So, to paraphrase (and make sure I understand) - your argument is = that if we don't use SDP, >> we will have to specify all the fields and associated meanings for = every codec we expect to support. >>=20 >> If we do use SDP, then we just point at existing usage and say - = 'there, use that' . >>=20 >> If we use a subset or variant on SDP we can say - 'use that, except = for this bit to do with port allocation'. >>=20 >> Is that a fair (if informal) summary? > Yes, exactly. >=20 > We've been around this bush a few times under the guise of "why don't = we redefine SDP in JSON" or "why don't we redefine SDP in XML"; this = time, it somewhat resembles "why don't we reencode SDP as API calls". I = believe a lot of the same arguments apply. >=20 Lets assume we use a subset/variant of SDP as a codec capability = description 'language' - (i.e. we won't be using the parts that relate = to network properties). The question then becomes: 'Is current SDP usage so idiosyncratic that = it is difficult/impossible to describe a mapping to/from (say) a set of = javascript objects which would work for all existing and future codecs = that play by the current rules?'=20 Tim. --Apple-Mail-28-813386311 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
On 12 Oct 2011, at 13:25, Harald Alvestrand wrote:

On 10/12/11 14:13, Tim Panton wrote:

On 12 Oct 2011, at 12:39, Harald Alvestrand wrote:

On 10/12/11 12:31, Tim Panton wrote:

On 12 Oct 2011, at 11:00, Harald Alvestrand wrote:

On 10/12/11 11:46, Neil Stratford wrote:
On Wed, Oct 12, 2011 at 10:01 AM, Harald Alvestrand <harald@alvestrand.no> wrote
One of the worries I have with doing a "low level spec" unconstrained by our present competence (ignorance?) in  is that I'm reasonably sure we have the knowledge to generate and parse SDP, because the codebases we are building on already generate and parse SDP, and the information present there is enough to set up calls, because we're already setting up calls using that information.

I'm less sure of our "getting things right" if we start off by describing the capabilities and control knobs to be exposed in an unconstrained API.

As a counter argument, those very same codebases that generate and parse SDP also contain internal APIs that look a lot like a low level spec API, and the information they present is enough to generate and parse SDP and set up calls.

Maybe we don't like those APIs and perhaps they expose too much as they were never intended to be made public, but they do exist already.
Yup. And I suspect they're all subtly different.


You could look at that in a positive light - 
as evidence that there are multiple ways to solve this problem and deduce:
a) it isn't impossibly hard
b) there isn't one 'correct' way of doing it.

Which would lead me back to specifying as _little_ as possible and letting innovation take place.

We have to specify enough for interoperation in at least the use cases of the scenarios document.
In enough detail for interoperation to happen.

That could turn out to be a lot, especially if we can't point to existing specs and say "use that".

So, to paraphrase (and make sure I understand) - your argument is that if we don't use SDP,
we will have to specify all the fields and associated meanings for every codec we expect to support.

If we do use SDP, then we just point at existing usage and say - 'there, use that' .

If we use a subset or variant on SDP we can say - 'use that, except for this bit to do with port allocation'.

Is that a fair (if informal) summary?
Yes, exactly.

We've been around this bush a few times under the guise of "why don't we redefine SDP in JSON" or "why don't we redefine SDP in XML"; this time, it somewhat resembles "why don't we reencode SDP as API calls". I believe a lot of the same arguments apply.


Lets assume we use a subset/variant of SDP as a codec capability description 'language' - (i.e. we won't be using the parts that relate to network properties).

The question then becomes: 'Is current SDP usage so idiosyncratic that it is difficult/impossible to describe a mapping to/from (say) a set of javascript objects which would work for all existing and future codecs that play by the current rules?' 


Tim.

--Apple-Mail-28-813386311-- From harald@alvestrand.no Wed Oct 12 05:44: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 8FC5121F8C4C for ; Wed, 12 Oct 2011 05:44:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wkBglZcFVIzw for ; Wed, 12 Oct 2011 05:44:05 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 9077421F8C35 for ; Wed, 12 Oct 2011 05:44:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id CB87E39E10E; Wed, 12 Oct 2011 14:25: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 5La7QHMJgVK0; Wed, 12 Oct 2011 14:25:05 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (unknown [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 07F9239E072; Wed, 12 Oct 2011 14:25:05 +0200 (CEST) Message-ID: <4E95871F.9010605@alvestrand.no> Date: Wed, 12 Oct 2011 14:25:03 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: Tim Panton References: <4E8D6507.8000707@ericsson.com> <4E955775.10206@alvestrand.no> <4E956526.2090604@alvestrand.no> <380E325E-A7EF-489A-AA24-0270224FC87A@phonefromhere.com> <4E957C55.9020706@alvestrand.no> <13C2526B-E7B1-408C-BD1D-EC5E8C8F6472@phonefromhere.com> In-Reply-To: <13C2526B-E7B1-408C-BD1D-EC5E8C8F6472@phonefromhere.com> Content-Type: multipart/alternative; boundary="------------050604030702040202000507" Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Making progress on the signaling discussion (NB: Action items enclosed!) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 12:44:06 -0000 This is a multi-part message in MIME format. --------------050604030702040202000507 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 10/12/11 14:13, Tim Panton wrote: > > On 12 Oct 2011, at 12:39, Harald Alvestrand wrote: > >> On 10/12/11 12:31, Tim Panton wrote: >>> >>> On 12 Oct 2011, at 11:00, Harald Alvestrand wrote: >>> >>>> On 10/12/11 11:46, Neil Stratford wrote: >>>>> On Wed, Oct 12, 2011 at 10:01 AM, Harald Alvestrand >>>>> > wrote >>>>> >>>>> One of the worries I have with doing a "low level spec" >>>>> unconstrained by our present competence (ignorance?) in is >>>>> that I'm reasonably sure we have the knowledge to generate and >>>>> parse SDP, because the codebases we are building on already >>>>> generate and parse SDP, and the information present there is >>>>> enough to set up calls, because we're already setting up calls >>>>> using that information. >>>>> >>>>> I'm less sure of our "getting things right" if we start off by >>>>> describing the capabilities and control knobs to be exposed in >>>>> an unconstrained API. >>>>> >>>>> >>>>> As a counter argument, those very same codebases that generate and >>>>> parse SDP also contain internal APIs that look a lot like a low >>>>> level spec API, and the information they present is enough to >>>>> generate and parse SDP and set up calls. >>>>> >>>>> Maybe we don't like those APIs and perhaps they expose too much as >>>>> they were never intended to be made public, but they do exist already. >>>> Yup. And I suspect they're all subtly different. >>>> >>> >>> You could look at that in a positive light - >>> as evidence that there are multiple ways to solve this problem and >>> deduce: >>> a) it isn't impossibly hard >>> b) there isn't one 'correct' way of doing it. >>> >>> Which would lead me back to specifying as _little_ as possible and >>> letting innovation take place. >>> >> We have to specify enough for interoperation in at least the use >> cases of the scenarios document. >> In enough detail for interoperation to happen. >> >> That could turn out to be a lot, especially if we can't point to >> existing specs and say "use that". > > So, to paraphrase (and make sure I understand) - your argument is that > if we don't use SDP, > we will have to specify all the fields and associated meanings for > every codec we expect to support. > > If we do use SDP, then we just point at existing usage and say - > 'there, use that' . > > If we use a subset or variant on SDP we can say - 'use that, except > for this bit to do with port allocation'. > > Is that a fair (if informal) summary? Yes, exactly. We've been around this bush a few times under the guise of "why don't we redefine SDP in JSON" or "why don't we redefine SDP in XML"; this time, it somewhat resembles "why don't we reencode SDP as API calls". I believe a lot of the same arguments apply. --------------050604030702040202000507 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 10/12/11 14:13, Tim Panton wrote:

On 12 Oct 2011, at 12:39, Harald Alvestrand wrote:

On 10/12/11 12:31, Tim Panton wrote:

On 12 Oct 2011, at 11:00, Harald Alvestrand wrote:

On 10/12/11 11:46, Neil Stratford wrote:
On Wed, Oct 12, 2011 at 10:01 AM, Harald Alvestrand <harald@alvestrand.no> wrote
One of the worries I have with doing a "low level spec" unconstrained by our present competence (ignorance?) in  is that I'm reasonably sure we have the knowledge to generate and parse SDP, because the codebases we are building on already generate and parse SDP, and the information present there is enough to set up calls, because we're already setting up calls using that information.

I'm less sure of our "getting things right" if we start off by describing the capabilities and control knobs to be exposed in an unconstrained API.

As a counter argument, those very same codebases that generate and parse SDP also contain internal APIs that look a lot like a low level spec API, and the information they present is enough to generate and parse SDP and set up calls.

Maybe we don't like those APIs and perhaps they expose too much as they were never intended to be made public, but they do exist already.
Yup. And I suspect they're all subtly different.


You could look at that in a positive light - 
as evidence that there are multiple ways to solve this problem and deduce:
a) it isn't impossibly hard
b) there isn't one 'correct' way of doing it.

Which would lead me back to specifying as _little_ as possible and letting innovation take place.

We have to specify enough for interoperation in at least the use cases of the scenarios document.
In enough detail for interoperation to happen.

That could turn out to be a lot, especially if we can't point to existing specs and say "use that".

So, to paraphrase (and make sure I understand) - your argument is that if we don't use SDP,
we will have to specify all the fields and associated meanings for every codec we expect to support.

If we do use SDP, then we just point at existing usage and say - 'there, use that' .

If we use a subset or variant on SDP we can say - 'use that, except for this bit to do with port allocation'.

Is that a fair (if informal) summary?
Yes, exactly.

We've been around this bush a few times under the guise of "why don't we redefine SDP in JSON" or "why don't we redefine SDP in XML"; this time, it somewhat resembles "why don't we reencode SDP as API calls". I believe a lot of the same arguments apply.

--------------050604030702040202000507-- From neils@vipadia.com Wed Oct 12 05:45: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 D232F21F8C4C for ; Wed, 12 Oct 2011 05:45:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.926 X-Spam-Level: X-Spam-Status: No, score=-2.926 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hnl814ymsrZm for ; Wed, 12 Oct 2011 05:45:07 -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 EBFE721F8CBD for ; Wed, 12 Oct 2011 05:45:06 -0700 (PDT) Received: by iaby26 with SMTP id y26so930953iab.31 for ; Wed, 12 Oct 2011 05:45:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.24.96 with SMTP id u32mr12223035ibb.61.1318422172235; Wed, 12 Oct 2011 05:22:52 -0700 (PDT) Sender: neils@vipadia.com Received: by 10.231.200.146 with HTTP; Wed, 12 Oct 2011 05:22:52 -0700 (PDT) In-Reply-To: <13C2526B-E7B1-408C-BD1D-EC5E8C8F6472@phonefromhere.com> References: <4E8D6507.8000707@ericsson.com> <4E955775.10206@alvestrand.no> <4E956526.2090604@alvestrand.no> <380E325E-A7EF-489A-AA24-0270224FC87A@phonefromhere.com> <4E957C55.9020706@alvestrand.no> <13C2526B-E7B1-408C-BD1D-EC5E8C8F6472@phonefromhere.com> Date: Wed, 12 Oct 2011 13:22:52 +0100 X-Google-Sender-Auth: imeJ_Ig8xUKe63RRG5eIFkm47HM Message-ID: From: Neil Stratford To: Tim Panton Content-Type: multipart/alternative; boundary=0015177414283d782704af1915aa Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Making progress on the signaling discussion (NB: Action items enclosed!) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 12:45:08 -0000 --0015177414283d782704af1915aa Content-Type: text/plain; charset=ISO-8859-1 On Wed, Oct 12, 2011 at 1:13 PM, Tim Panton wrote: > > So, to paraphrase (and make sure I understand) - your argument is that if > we don't use SDP, > we will have to specify all the fields and associated meanings for every > codec we expect to support. > > If we do use SDP, then we just point at existing usage and say - 'there, > use that' . > > If we use a subset or variant on SDP we can say - 'use that, except for > this bit to do with port allocation'. > > Is that a fair (if informal) summary? > It's interesting to look at how XMPP/Jingle addressed this concern in XEP-0167: http://xmpp.org/extensions/xep-0167.html#sdp The SDP definitions are mapped to name/value pairs where possible according to defined rules. Neil --0015177414283d782704af1915aa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Oct 12, 2011 at 1:13 PM, Tim Panton <tim@phonefromhere.com> wrot= e:

So, to paraphrase (and make sure I understand) - your = argument is that if we don't use SDP,
we will have to specify= all the fields and associated meanings for every codec we expect to suppor= t.

If we do use SDP, then we just point at existing usage = and say - 'there, use that' .

If we use a = subset or variant on SDP we can say - 'use that, except for this bit to= do with port allocation'.

Is that a fair (if informal) summary?
=

It's interesting to look at how XMPP/J= ingle addressed this concern in XEP-0167:

The SDP definitions are mapped to name/value pairs wher= e possible according to defined rules.=A0

Neil
--0015177414283d782704af1915aa-- From harald@alvestrand.no Wed Oct 12 05:48: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 E826C21F8CBF for ; Wed, 12 Oct 2011 05:48:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PxVxrjKuquxo for ; Wed, 12 Oct 2011 05:48:27 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 663A921F8CBD for ; Wed, 12 Oct 2011 05:48:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5E3B339E182; Wed, 12 Oct 2011 14:42:19 +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 owhhN4oXAnSk; Wed, 12 Oct 2011 14:42:19 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (unknown [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id EB6F939E072; Wed, 12 Oct 2011 14:42:18 +0200 (CEST) Message-ID: <4E958B29.4000404@alvestrand.no> Date: Wed, 12 Oct 2011 14:42:17 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: Tim Panton References: <4E8D6507.8000707@ericsson.com> <4E955775.10206@alvestrand.no> <4E956526.2090604@alvestrand.no> <380E325E-A7EF-489A-AA24-0270224FC87A@phonefromhere.com> <4E957C55.9020706@alvestrand.no> <13C2526B-E7B1-408C-BD1D-EC5E8C8F6472@phonefromhere.com> <4E95871F.9010605@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] Making progress on the signaling discussion (NB: Action items enclosed!) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 12:48:28 -0000 On 10/12/11 14:36, Tim Panton wrote: > > >> > > Lets assume we use a subset/variant of SDP as a codec capability > description 'language' - (i.e. we won't be using the parts that relate > to network properties). (note - I'm not making that assumption) > > The question then becomes: 'Is current SDP usage so idiosyncratic that > it is difficult/impossible to describe a mapping to/from (say) a set > of javascript objects which would work for all existing and future > codecs that play by the current rules?' > The problem I see there is "future codecs". Anyone who specifies anything that they know has to be handled in SIP for some reason tend to specify their mapping to SIP in great detail, but not necessarily with a great deal of formality. I couldn't say offhand what the "current rules" are. That makes it hard to make a parser/generator that is guaranteed to handle all valid examples. Harald From prvs=259ad5c1c=tterriberry@mozilla.com Wed Oct 12 06:59: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 9D68E21F8CD3 for ; Wed, 12 Oct 2011 06:59:40 -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 7+HvNaa3ydP1 for ; Wed, 12 Oct 2011 06:59:40 -0700 (PDT) Received: from mxip3i.isis.unc.edu (mxip3i.isis.unc.edu [152.2.2.195]) by ietfa.amsl.com (Postfix) with ESMTP id 21A6221F8CBC for ; Wed, 12 Oct 2011 06:59:40 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAHOclU6sGgRS/2dsb2JhbABDpz+BdoFTAQEEAThAAQULCyEWDwkDAgECAUUTAQcCF4djuj2HWASHf5EMEoxM X-IronPort-AV: E=Sophos;i="4.67,675,1309752000"; d="scan'208";a="200046163" Received: from mr1a.isis.unc.edu (HELO smtp.unc.edu) ([172.26.4.82]) by mxip3o.isis.unc.edu with ESMTP; 12 Oct 2011 09:59:39 -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 p9CDxb0P025779 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 12 Oct 2011 09:59:38 -0400 (EDT) Message-ID: <4E959D48.3090401@mozilla.com> Date: Wed, 12 Oct 2011 06:59:36 -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: <4E8D6507.8000707@ericsson.com> <4E955775.10206@alvestrand.no> <4E956526.2090604@alvestrand.no> <380E325E-A7EF-489A-AA24-0270224FC87A@phonefromhere.com> <4E957C55.9020706@alvestrand.no> <13C2526B-E7B1-408C-BD1D-EC5E8C8F6472@phonefromhere.com> <4E95871F.9010605@alvestrand.no> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Making progress on the signaling discussion (NB: Action items enclosed!) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 13:59:40 -0000 > Lets assume we use a subset/variant of SDP as a codec capability > description 'language' - (i.e. we won't be using the parts that relate > to network properties). I've seen this proposed a couple of times now, and I would like to point out that this is a terrible assumption. There are many things that one might want to control about a codec that will never show up in SDP, because they don't require explicit negotiation between sender and receiver (e.g., the sender gets to make a unilateral decision and the receiver simply deals with it... like, say, the amount of time a video encoder is willing to spend doing a motion search, etc.). Limiting yourself to the parameters that do happen to show up in SDP is a pretty poor half-solution, if you really do think you need a low-level API of this kind, and may not have obvious extension points to get to a full solution. From tim@phonefromhere.com Wed Oct 12 07:58: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 AB0D221F8BC4 for ; Wed, 12 Oct 2011 07:58: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=[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 DWZfi1m8ugNK for ; Wed, 12 Oct 2011 07:58:18 -0700 (PDT) Received: from zimbra.westhawk.co.uk (zimbra.westhawk.co.uk [192.67.4.167]) by ietfa.amsl.com (Postfix) with ESMTP id 06EE921F8B87 for ; Wed, 12 Oct 2011 07:58:17 -0700 (PDT) Received: from [192.168.0.14] (unknown [93.89.81.113]) by zimbra.westhawk.co.uk (Postfix) with ESMTP id 3E15D37A902; Wed, 12 Oct 2011 16:11:04 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Tim Panton In-Reply-To: <4E959D48.3090401@mozilla.com> Date: Wed, 12 Oct 2011 15:58:11 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9E790044-DE19-46DD-89D8-C4F2973F8D65@phonefromhere.com> References: <4E8D6507.8000707@ericsson.com> <4E955775.10206@alvestrand.no> <4E956526.2090604@alvestrand.no> <380E325E-A7EF-489A-AA24-0270224FC87A@phonefromhere.com> <4E957C55.9020706@alvestrand.no> <13C2526B-E7B1-408C-BD1D-EC5E8C8F6472@phonefromhere.com> <4E95871F.9010605@alvestrand.no> <4E959D48.3090401@mozill a.com> To: Timothy B. Terriberry X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Making progress on the signaling discussion (NB: Action items enclosed!) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 14:58:18 -0000 On 12 Oct 2011, at 14:59, Timothy B. Terriberry wrote: >> Lets assume we use a subset/variant of SDP as a codec capability >> description 'language' - (i.e. we won't be using the parts that = relate >> to network properties). >=20 > I've seen this proposed a couple of times now, and I would like to = point out that this is a terrible assumption. There are many things that = one might want to control about a codec that will never show up in SDP, = because they don't require explicit negotiation between sender and = receiver (e.g., the sender gets to make a unilateral decision and the = receiver simply deals with it... like, say, the amount of time a video = encoder is willing to spend doing a motion search, etc.). >=20 > Limiting yourself to the parameters that do happen to show up in SDP = is a pretty poor half-solution, if you really do think you need a = low-level API of this kind, and may not have obvious extension points to = get to a full solution. Which leaves us with the choice of: a) having 2 different APIs - one for SDP params and one for = everything else b) extending SDP to include things that will only be used = locally=20 c) describing a mapping from SDP to javascript objects for a = 'full' codec description object d) ? Tim (P).= From roman@telurix.com Wed Oct 12 09: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 829DF21F8CFA for ; Wed, 12 Oct 2011 09:49:04 -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 r6W5Cr8rzq3I for ; Wed, 12 Oct 2011 09:49:03 -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 DE88F21F8B52 for ; Wed, 12 Oct 2011 09:49:02 -0700 (PDT) Received: by vcbfo11 with SMTP id fo11so920817vcb.31 for ; Wed, 12 Oct 2011 09:49:02 -0700 (PDT) Received: by 10.220.191.203 with SMTP id dn11mr2238383vcb.16.1318438142234; Wed, 12 Oct 2011 09:49:02 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by mx.google.com with ESMTPS id hl5sm599642vdb.18.2011.10.12.09.49.01 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 12 Oct 2011 09:49:01 -0700 (PDT) Received: by qyk33 with SMTP id 33so237413qyk.10 for ; Wed, 12 Oct 2011 09:49:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.32.162 with SMTP id k2mr2137994pbi.132.1318438140587; Wed, 12 Oct 2011 09:49:00 -0700 (PDT) Received: by 10.68.47.40 with HTTP; Wed, 12 Oct 2011 09:49:00 -0700 (PDT) In-Reply-To: <9E790044-DE19-46DD-89D8-C4F2973F8D65@phonefromhere.com> References: <4E8D6507.8000707@ericsson.com> <4E955775.10206@alvestrand.no> <4E956526.2090604@alvestrand.no> <380E325E-A7EF-489A-AA24-0270224FC87A@phonefromhere.com> <4E957C55.9020706@alvestrand.no> <13C2526B-E7B1-408C-BD1D-EC5E8C8F6472@phonefromhere.com> <4E95871F.9010605@alvestrand.no> <4E959D48.3090401@mozilla.com> <9E790044-DE19-46DD-89D8-C4F2973F8D65@phonefromhere.com> Date: Wed, 12 Oct 2011 12:49:00 -0400 Message-ID: From: Roman Shpount To: rtcweb@ietf.org Content-Type: multipart/alternative; boundary=bcaec520e4f3072f2704af1ccdf7 Subject: Re: [rtcweb] Making progress on the signaling discussion (NB: Action items enclosed!) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 16:49:04 -0000 --bcaec520e4f3072f2704af1ccdf7 Content-Type: text/plain; charset=ISO-8859-1 As far as I can see from this discussion there are several different items for consensus: 1. The API level: I think most of the people on the list agree that API should deal with media streams and media stream descriptions, i.e. should be as low level as possible without implementing actual RTP. There are few people here who argue for a higher level API that would allow to setup connection using some sort of higher level signalling protocol which will deal with individual stream setup in a manner transparent to a developer, but from what a lot of people on the list (including me) believe this can be implemented in JavaScript and does not need to be standardized. 2. API Semantics: I would say that API should be complete enough to implement everything that is currently supported by Offer/Answer and SIP signalling. It does not have to be offer/answer and can allow for new negotiation scenarios, but all the current scenarios, including forking, remote target SDP updates should be supported. I think RTC should provide a framework that would allow to implement all the current VoIP offer/answer negotiation flows. I don't think that we can ignore some of those flows even though some of the people on the list argue against it saying that this flows are specific for PSTN, or caused by SIP design flaw, or some other corner case of exiting offer/answer model. 3. Signaling Offer and Answer Format: Some people argue for direct use of SDP. Others argue for using JavaScript object or set of API methods to define the same. The main argument for using JavaScipt object/API methods would be that it will make it easier to manipulate session description from JavaScript. The main argument for using SDP is simpler interoperability with existing VoIP solutions. I would strongly argue for JavaScipt object/API primarily based on the fact that SDP is not enough to fully define the media parameters. Typically all the non-negotiated media stream parameters in VoIP solutions are defined from device configuration. We will need an API convey those preferences to RTC implementation which means a set of custom APIs on top of SDP. If we are doing custom APIs for media, we might as well make one that covers all the features. This being said, I would also argue that we need to have an API that can be used with new codecs implemented by the browser without explicitly extending the JavaScript signaling code. The current proposed API assumes that JavaScript code understands the meaning of all the codec parameters to negotiate them on behalf of the user. If new codec is added, JavaScript would need to be updated to correctly select the parameters for new codec. We should provide a programming model where it is possible to delegate the codec selection and codec parameter negotiation to the RTC API while still allowing to do this negotiation from JavaScript. P.S. I do find the current API proposal a bit deficient due to its inability to support forking, asymmetric codec selection, and delegating codec negotiation to the RTC implementation. _____________ Roman Shpount --bcaec520e4f3072f2704af1ccdf7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable As far as I can see from this discussion there are several different items = for consensus:

1. The API level: I think most of the people on the l= ist agree that API should deal with media streams and media stream descript= ions, i.e. should be as low level as possible without implementing actual R= TP. There are few people here who argue for a higher level API that would a= llow to setup connection using some sort of higher level signalling protoco= l which will deal with individual stream setup in a manner transparent to a= developer, but from what a lot of people on the list (including me) believ= e this can be implemented in JavaScript and does not need to be standardize= d.

2. API Semantics: I would say that API should be complete enough to imp= lement everything that is currently supported by Offer/Answer and SIP signa= lling. It does not have to be offer/answer and can allow for new negotiatio= n scenarios, but all the current scenarios, including forking, remote targe= t SDP updates should be supported. I think RTC should provide a framework t= hat would allow to implement all the current VoIP offer/answer negotiation = flows. I don't think that we can ignore some of those flows even though= some of the people on the list argue against it saying that this flows are= specific for PSTN, or caused by SIP design flaw, or some other corner case= of exiting offer/answer model.

3. Signaling Offer and Answer Format: Some people argue for direct use = of SDP. Others argue for using JavaScript object or set of API methods to d= efine the same. The main argument for using JavaScipt object/API methods wo= uld be that it will make it easier to manipulate session description from J= avaScript. The main argument for using SDP is simpler interoperability with= existing VoIP solutions. I would strongly argue for JavaScipt object/API p= rimarily based on the fact that SDP is not enough to fully define the media= parameters. Typically all the non-negotiated media stream parameters in Vo= IP solutions are defined from device configuration. We will need an API con= vey those preferences to RTC implementation which means a set of custom API= s on top of SDP. If we are doing custom APIs for media, we might as well ma= ke one that covers all the features.

This being said, I would also argue that we need to have an API that ca= n be used with new codecs implemented by the browser without explicitly ext= ending the JavaScript signaling code. The current proposed API assumes that= JavaScript code understands the meaning of all the codec parameters to neg= otiate them on behalf of the user. If new codec is added, JavaScript would = need to be updated to correctly select the parameters for new codec. We sho= uld provide a programming model where it is possible to delegate the codec = selection and codec parameter negotiation to the RTC API while still allowi= ng to do this negotiation from JavaScript.

P.S. I do find the current API proposal a bit deficient due to its inab= ility to support forking, asymmetric codec selection, and delegating codec = negotiation to the RTC implementation.
_____________
Roman Shpount

--bcaec520e4f3072f2704af1ccdf7-- From ibc@aliax.net Wed Oct 12 09:56: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 0322C21F8B82 for ; Wed, 12 Oct 2011 09:56:15 -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.151, 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 R95vgUnzjk5l for ; Wed, 12 Oct 2011 09:56:14 -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 77EF221F8B7C for ; Wed, 12 Oct 2011 09:56:14 -0700 (PDT) Received: by vcbfo11 with SMTP id fo11so929296vcb.31 for ; Wed, 12 Oct 2011 09:56:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.35.34 with SMTP id e2mr24256536vdj.52.1318438573852; Wed, 12 Oct 2011 09:56:13 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Wed, 12 Oct 2011 09:56:13 -0700 (PDT) In-Reply-To: References: <4E8D6507.8000707@ericsson.com> <4E955775.10206@alvestrand.no> <4E956526.2090604@alvestrand.no> <380E325E-A7EF-489A-AA24-0270224FC87A@phonefromhere.com> <4E957C55.9020706@alvestrand.no> <13C2526B-E7B1-408C-BD1D-EC5E8C8F6472@phonefromhere.com> <4E95871F.9010605@alvestrand.no> <4E959D48.3090401@mozilla.com> <9E790044-DE19-46DD-89D8-C4F2973F8D65@phonefromhere.com> Date: Wed, 12 Oct 2011 18:56:13 +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] Making progress on the signaling discussion (NB: Action items enclosed!) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 16:56:15 -0000 2011/10/12 Roman Shpount : > P.S. I do find the current API proposal a bit deficient due to its inabil= ity > to support forking, asymmetric codec selection, and delegating codec > negotiation to the RTC implementation. Perhaps I miss something but... which "current API" do you mean? Thanks. --=20 I=C3=B1aki Baz Castillo From roman@telurix.com Wed Oct 12 10:03: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 009CF21F8C93 for ; Wed, 12 Oct 2011 10:03:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.826 X-Spam-Level: X-Spam-Status: No, score=-2.826 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3dj4-zRH6VDY for ; Wed, 12 Oct 2011 10:03:49 -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 8953D21F8C67 for ; Wed, 12 Oct 2011 10:03:49 -0700 (PDT) Received: by pzk37 with SMTP id 37so490472pzk.9 for ; Wed, 12 Oct 2011 10:03:49 -0700 (PDT) Received: by 10.68.26.168 with SMTP id m8mr2500788pbg.29.1318439029315; Wed, 12 Oct 2011 10:03:49 -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 ki1sm1680942pbb.3.2011.10.12.10.03.47 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 12 Oct 2011 10:03:47 -0700 (PDT) Received: by pzk37 with SMTP id 37so490391pzk.9 for ; Wed, 12 Oct 2011 10:03:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.74.4 with SMTP id p4mr2454091pbv.47.1318439026770; Wed, 12 Oct 2011 10:03:46 -0700 (PDT) Received: by 10.68.47.40 with HTTP; Wed, 12 Oct 2011 10:03:46 -0700 (PDT) In-Reply-To: References: <4E8D6507.8000707@ericsson.com> <4E955775.10206@alvestrand.no> <4E956526.2090604@alvestrand.no> <380E325E-A7EF-489A-AA24-0270224FC87A@phonefromhere.com> <4E957C55.9020706@alvestrand.no> <13C2526B-E7B1-408C-BD1D-EC5E8C8F6472@phonefromhere.com> <4E95871F.9010605@alvestrand.no> <4E959D48.3090401@mozilla.com> <9E790044-DE19-46DD-89D8-C4F2973F8D65@phonefromhere.com> Date: Wed, 12 Oct 2011 13:03:46 -0400 Message-ID: From: Roman Shpount To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=f46d0413911dd943e904af1d0185 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Making progress on the signaling discussion (NB: Action items enclosed!) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 17:03:50 -0000 --f46d0413911dd943e904af1d0185 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Oct 12, 2011 at 12:56 PM, I=F1aki Baz Castillo wrot= e: > 2011/10/12 Roman Shpount : > > P.S. I do find the current API proposal a bit deficient due to its > inability > > to support forking, asymmetric codec selection, and delegating codec > > negotiation to the RTC implementation. > > Perhaps I miss something but... which "current API" do you mean? > > I've meant "Architecture and API for RTCWeb" from Neil Stratford: https://docs.google.com/document/pub?id=3D1MfrFHKx6O6yWtIv_jqwyH-RAbm8AgRtX= Q7dJTZz5J2g&pli=3D1and draft-jennings-rtcweb-api-00. There might be something that I've missed while reading those documents but I could not figure out how to implement any of the features that I've listed. _____________ Roman Shpount --f46d0413911dd943e904af1d0185 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Oct 12, 2011 at 12:56 = PM, I=F1aki Baz Castillo <ibc@aliax.net> wrote:
2011/10/12 Roman Shpount <roman@tel= urix.com>:
> P.S. I do find the current API proposal a bit defici= ent due to its inability
> to support forking, asymmetric codec selection, and delegating codec > negotiation to the RTC implementation.

Perhaps I miss something but... which "current API" do you = mean?

=A0
I've meant "Architecture and = API for RTCWeb" from Neil Stratford: https://docs.google.com/document/pub?id=3D1MfrFHKx6O6yWtIv_jqwyH-RAbm8Ag= RtXQ7dJTZz5J2g&pli=3D1 and draft-jennings-rtcweb-api-00. There migh= t be something that I've missed while reading those documents but I cou= ld not figure out how to implement any of the features that I've listed= .

_____________
Roman Shpount

--f46d0413911dd943e904af1d0185-- From randell-ietf@jesup.org Wed Oct 12 15:17: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 DCD0D21F8CC3 for ; Wed, 12 Oct 2011 15:17: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 r36To1odKmU2 for ; Wed, 12 Oct 2011 15:17:04 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 1D6D921F8CC0 for ; Wed, 12 Oct 2011 15:17: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 1RE76l-0004Sb-Cc for rtcweb@ietf.org; Wed, 12 Oct 2011 17:17:03 -0500 Message-ID: <4E9610DC.3000807@jesup.org> Date: Wed, 12 Oct 2011 18:12: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: <4E8D6507.8000707@ericsson.com> <4E955775.10206@alvestrand.no> <4E956526.2090604@alvestrand.no> <380E325E-A7EF-489A-AA24-0270224FC87A@phonefromhere.com> <4E957C55.9020706@alvestrand.no> <13C2526B-E7B1-408C-BD1D-EC5E8C8F6472@phonefromhere.com> <4E95871F.9010605@alvestrand.no> <4E959D48.3090401@mozill a.com> In-Reply-To: <4E959D48.3090401@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] Making progress on the signaling discussion (NB: Action items enclosed!) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 22:17:05 -0000 On 10/12/2011 9:59 AM, Timothy B. Terriberry wrote: >> Lets assume we use a subset/variant of SDP as a codec capability >> description 'language' - (i.e. we won't be using the parts that relate >> to network properties). > > I've seen this proposed a couple of times now, and I would like to point > out that this is a terrible assumption. There are many things that one > might want to control about a codec that will never show up in SDP, > because they don't require explicit negotiation between sender and > receiver (e.g., the sender gets to make a unilateral decision and the > receiver simply deals with it... like, say, the amount of time a video > encoder is willing to spend doing a motion search, etc.). > > Limiting yourself to the parameters that do happen to show up in SDP is > a pretty poor half-solution, if you really do think you need a low-level > API of this kind, and may not have obvious extension points to get to a > full solution. Typically the SDP O-A specifies what you want to receive, and indirectly (mostly) what you want to send. This leaves lots of choices about how to achieve that (especially for encoding) up to the application logic at either end, once the negotiation is complete. (As Tim points out.) The "simple" solution would be to embed that application logic in the browser code, and feed it the SDP (or equivalent). We have a more complex case here, where we have the app which may have something to say about those choices, or want to vary things during a call, etc. We also have a wider problem space than "video calling"; so there may be valid reasons for the app to want different behavior from the codecs. With SDP completely generated by and processed the browser, new video codec support is straightforward, which is a good thing. However, this means that the app has more complexity in modifying or controlling the negotiation and the way the codecs operate (the "application logic" above). The problem with providing the app full access to the codec controls and negotiation is that it's a severely open-ended problem, and each codec is different, with different knobs. Effectively the app would likely support only one or only the original "standard" codecs; existing apps wouldn't use (or might break) "new" codecs. One end of the spectrum effectively gives JS full control of every knob in the codec API, which is totally different from one codec to the next. The other end is where you abstract out "common" codec parameters into generic values/sliders (image quality vs motion representation, quality versus efficiency/frame-rate, etc), which may or may not be handled for a given codec (or you punt and give the app no control of these things). Note that the knobs for the same codec (H.264, VP8, Opus, etc) might be different in different browsers, because the underlying implementation is different. The downside of the generic approach is that many codec-specific things won't be possible to modify, or doing so will be very indirect and might have side-effects. Once again the basic tension between ease-of-use and give-me-control-damn-it is a primary factor here. An added factor here is that in the complex model, if a codec is added by the browser, the app may not be able to use it (or able to use it above a basic, automatic level) without being updated. You could write an codec-interface abstraction JS that isolated the main app from the codec complexity (taking the place of the aforementioned sliders, etc), but then that has to be updated, which is largely the same problem (especially given security concerns). However, in my mind the more critical issue is ease-of-use (and also inter-browser compatibility - two encoders for the same codec may have very different knobs at a low level). Most users of WebRTC won't be interested in tweaking the IDR quantization levels; they are more likely to be interested in the overall quality/speed/efficiency/frame-rate sort of tradeoffs. Some users may want to tweak each and every parameter and buy into updating that code for new codecs (and for new parameters in existing codecs). I'm more than half-tempted to not provide any interface to the codec parameters initially, or a very general one (but extensible for future use) just covering the most basic tradeoffs only. Much more than half-tempted. I would in general allow for these parameters to be tweaked during a call by the app, though this opens the question about if tweaking them can require a re-negotiation of the call. -- Randell Jesup randell-ietf@jesup.org From randell-ietf@jesup.org Wed Oct 12 15:25: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 1C32A21F8CC0 for ; Wed, 12 Oct 2011 15:25: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.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 mD146uWZ7cKN for ; Wed, 12 Oct 2011 15:25:26 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 9D07A21F8CC7 for ; Wed, 12 Oct 2011 15:25: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 1RE7Es-0007Lv-8Z for rtcweb@ietf.org; Wed, 12 Oct 2011 17:25:26 -0500 Message-ID: <4E9612D3.2040207@jesup.org> Date: Wed, 12 Oct 2011 18:21:07 -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: <4E8D6507.8000707@ericsson.com> <4E955775.10206@alvestrand.no> <4E956526.2090604@alvestrand.no> <380E325E-A7EF-489A-AA24-0270224FC87A@phonefromhere.com> <4E957C55.9020706@alvestrand.no> <13C2526B-E7B1-408C-BD1D-EC5E8C8F6472@phonefromhere.com> <4E95871F.9010605@alvestrand.no> <4E959D48.3090401@mozilla.com> <9E790044-DE19-46DD-89D8-C4F2973F8D65@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] Making progress on the signaling discussion (NB: Action items enclosed!) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 22:25:27 -0000 [not responding to the other items mentioned in this post; perhaps later] On 10/12/2011 12:49 PM, Roman Shpount wrote: > This being said, I would also argue that we need to have an API that can > be used with new codecs implemented by the browser without explicitly > extending the JavaScript signaling code. The current proposed API > assumes that JavaScript code understands the meaning of all the codec > parameters to negotiate them on behalf of the user. If new codec is > added, JavaScript would need to be updated to correctly select the > parameters for new codec. We should provide a programming model where it > is possible to delegate the codec selection and codec parameter > negotiation to the RTC API while still allowing to do this negotiation > from JavaScript. Agreed, I think. > P.S. I do find the current API proposal a bit deficient due to its > inability to support forking, asymmetric codec selection, and delegating > codec negotiation to the RTC implementation. See my much earlier discussion of Forking support by modifying Harald's OFFER/ANSWER messages to include ACCEPT, which also helps solve the answer-time clipping issues. (I'll try to dig it out of the archives and repost a link.) -- Randell Jesup randell-ietf@jesup.org From roman@telurix.com Wed Oct 12 15:49: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 AB3E621F8C49 for ; Wed, 12 Oct 2011 15:49:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.901 X-Spam-Level: X-Spam-Status: No, score=-2.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] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iPHRpiwp0zxx for ; Wed, 12 Oct 2011 15:49:10 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1EAC121F8B72 for ; Wed, 12 Oct 2011 15:49:09 -0700 (PDT) Received: by qadb12 with SMTP id b12so1329138qad.31 for ; Wed, 12 Oct 2011 15:49:07 -0700 (PDT) Received: by 10.224.210.130 with SMTP id gk2mr1014605qab.23.1318459746993; Wed, 12 Oct 2011 15:49:06 -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 f8sm4835380qap.15.2011.10.12.15.49.05 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 12 Oct 2011 15:49:05 -0700 (PDT) Received: by gyh20 with SMTP id 20so1406066gyh.31 for ; Wed, 12 Oct 2011 15:49:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.17.225 with SMTP id r1mr4093408pbd.64.1318459744568; Wed, 12 Oct 2011 15:49:04 -0700 (PDT) Received: by 10.68.47.40 with HTTP; Wed, 12 Oct 2011 15:49:04 -0700 (PDT) In-Reply-To: <4E9612D3.2040207@jesup.org> References: <4E8D6507.8000707@ericsson.com> <4E955775.10206@alvestrand.no> <4E956526.2090604@alvestrand.no> <380E325E-A7EF-489A-AA24-0270224FC87A@phonefromhere.com> <4E957C55.9020706@alvestrand.no> <13C2526B-E7B1-408C-BD1D-EC5E8C8F6472@phonefromhere.com> <4E95871F.9010605@alvestrand.no> <4E959D48.3090401@mozilla.com> <9E790044-DE19-46DD-89D8-C4F2973F8D65@phonefromhere.com> <4E9612D3.2040207@jesup.org> Date: Wed, 12 Oct 2011 18:49:04 -0400 Message-ID: From: Roman Shpount To: Randell Jesup Content-Type: multipart/alternative; boundary=bcaec520ea85b9c62104af21d492 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Making progress on the signaling discussion (NB: Action items enclosed!) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 22:49:10 -0000 --bcaec520ea85b9c62104af21d492 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Oct 12, 2011 at 6:21 PM, Randell Jesup wrote: > See my much earlier discussion of Forking support by modifying Harald's > OFFER/ANSWER messages to include ACCEPT, which also helps solve the > answer-time clipping issues. > > (I'll try to dig it out of the archives and repost a link.) > I do remember your proposal, and it does address the situation where JavaScript would need to update the remote target. I am not sure it covers the case where multiple streams need to be created based on several answers to the same offer (flow that corresponds to multiple 200 OK responses to a single INVITE). I don't think it would be very difficult to implement disambiguation of multiple remote media sources based on remote IP and allow JavaScript to manage each stream separately. I would suggest some sort of CLONE API, taking the remote description and creating a new stream, for this purpose. _____________ Roman Shpount --bcaec520ea85b9c62104af21d492 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Oct 12, 2011 at 6:= 21 PM, Randell Jesup <randell-ietf@jesup.org> wrote:
See my much earlier discussion of Forking support by modifying Harald's= OFFER/ANSWER messages to include ACCEPT, which also helps solve the answer= -time clipping issues.

(I'll try to dig it out of the archives and repost a link.)

I do remember your proposal,= and it does address the situation where JavaScript would need to update th= e remote target. I am not sure it covers the case where multiple streams ne= ed to be created based on several answers to the same offer (flow that corr= esponds to multiple 200 OK responses to a single INVITE). I don't think= it would be very difficult to implement disambiguation of multiple remote = media sources based on remote IP and allow JavaScript to manage each stream= separately. I would suggest some sort of CLONE API, taking the remote desc= ription and creating a new stream, for this purpose.
_____________
Roman Shpount


--bcaec520ea85b9c62104af21d492-- From randell-ietf@jesup.org Wed Oct 12 21: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 C374D21F8AD1 for ; Wed, 12 Oct 2011 21:33:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_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 7Z61mwC1saS9 for ; Wed, 12 Oct 2011 21:33: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 59C9921F8ACA for ; Wed, 12 Oct 2011 21:33:48 -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 1RECzL-0006FX-Lq for rtcweb@ietf.org; Wed, 12 Oct 2011 23:33:47 -0500 Message-ID: <4E966928.1020100@jesup.org> Date: Thu, 13 Oct 2011 00:29: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: <4E8D6507.8000707@ericsson.com> <4E955775.10206@alvestrand.no> <4E956526.2090604@alvestrand.no> <380E325E-A7EF-489A-AA24-0270224FC87A@phonefromhere.com> <4E957C55.9020706@alvestrand.no> <13C2526B-E7B1-408C-BD1D-EC5E8C8F6472@phonefromhere.com> <4E95871F.9010605@alvestrand.no> <4E959D48.3090401@mozilla.com> <9E790044-DE19-46DD-89D8-C4F2973F8D65@phonefromhere.com> <4E9612D3.2040207@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] Making progress on the signaling discussion (NB: Action items enclosed!) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 04:33:48 -0000 On 10/12/2011 6:49 PM, Roman Shpount wrote: > > > On Wed, Oct 12, 2011 at 6:21 PM, Randell Jesup > wrote: > > See my much earlier discussion of Forking support by modifying > Harald's OFFER/ANSWER messages to include ACCEPT, which also helps > solve the answer-time clipping issues. > > (I'll try to dig it out of the archives and repost a link.) > > > I do remember your proposal, and it does address the situation where > JavaScript would need to update the remote target. I am not sure it > covers the case where multiple streams need to be created based on > several answers to the same offer (flow that corresponds to multiple 200 > OK responses to a single INVITE). It did cover that case - it was up to the app what to do when the first ACCEPT was processed. I didn't go into the JS-level mechanisms used. > I don't think it would be very > difficult to implement disambiguation of multiple remote media sources > based on remote IP and allow JavaScript to manage each stream > separately. Do not assume that remote IP == source - this is easily provably false, though if you used remote IP+port AND local IP+port I think it would be ok. However, for each remote connection we should have a DTLS connection instance, so that's probably simplest. > I would suggest some sort of CLONE API, taking the remote > description and creating a new stream, for this purpose. Quite possibly this is really a W3C area... though they're all interrelated. -- Randell Jesup randell-ietf@jesup.org From roman@telurix.com Wed Oct 12 21:48: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 EDF7A21F8B16 for ; Wed, 12 Oct 2011 21:48:25 -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.250, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 VqUkb-d4Nuyk for ; Wed, 12 Oct 2011 21:48:25 -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 3F06321F8A55 for ; Wed, 12 Oct 2011 21:48:25 -0700 (PDT) Received: by vws5 with SMTP id 5so1466543vws.31 for ; Wed, 12 Oct 2011 21:48:24 -0700 (PDT) Received: by 10.52.36.197 with SMTP id s5mr2187005vdj.36.1318481304393; Wed, 12 Oct 2011 21:48:24 -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 jo8sm2699945vdb.20.2011.10.12.21.48.22 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 12 Oct 2011 21:48:23 -0700 (PDT) Received: by ggnk3 with SMTP id k3so1694079ggn.31 for ; Wed, 12 Oct 2011 21:48:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.8.233 with SMTP id u9mr6059770pba.30.1318481302251; Wed, 12 Oct 2011 21:48:22 -0700 (PDT) Received: by 10.68.47.40 with HTTP; Wed, 12 Oct 2011 21:48:22 -0700 (PDT) In-Reply-To: <4E966928.1020100@jesup.org> References: <4E8D6507.8000707@ericsson.com> <4E955775.10206@alvestrand.no> <4E956526.2090604@alvestrand.no> <380E325E-A7EF-489A-AA24-0270224FC87A@phonefromhere.com> <4E957C55.9020706@alvestrand.no> <13C2526B-E7B1-408C-BD1D-EC5E8C8F6472@phonefromhere.com> <4E95871F.9010605@alvestrand.no> <4E959D48.3090401@mozilla.com> <9E790044-DE19-46DD-89D8-C4F2973F8D65@phonefromhere.com> <4E9612D3.2040207@jesup.org> <4E966928.1020100@jesup.org> Date: Thu, 13 Oct 2011 00:48:22 -0400 Message-ID: From: Roman Shpount To: Randell Jesup Content-Type: multipart/alternative; boundary=bcaec5215a59a9e87b04af26d948 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Making progress on the signaling discussion (NB: Action items enclosed!) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 04:48:26 -0000 --bcaec5215a59a9e87b04af26d948 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Oct 13, 2011 at 12:29 AM, Randell Jesup wrote: > It did cover that case - it was up to the app what to do when the first > ACCEPT was processed. I didn't go into the JS-level mechanisms used. I guess I might be missing something, but how, using ACCEPT, RTC can generate a single offer, get two answers back, and create two media streams? Creating a second media stream does not mean that this is a last answer for this stream (corresponds to new SIP dialog created by provisional response) and accepting a stream does not mean it cannot be cloned (corresponds to new SIP dialog created by new final response). So essentially we need four operations: create offer, create media stream based on an answer, update existing stream based on a new answer for the same dialog, and finalize the media stream. Or alternatively we can achieve the same with create offer and stream together, process answer, accept (finalize the stream) and clone the stream. Either way we need four methods and we achieve the same functionality. Do not assume that remote IP == source - this is easily provably false, > though if you used remote IP+port AND local IP+port I think it would be ok. > However, for each remote connection we should have a DTLS connection > instance, so that's probably simplest. > Yes, I do agree we should disambiguate on local/remote IP+port pair. I did not realize we are requiring DTLS/SRTP in RTC. I don't think I've seen a single implementation of this in the wild, and I do not see any harm in supporting SRTP and (with user confirmation) of plain RTP. _____________ Roman Shpount --bcaec5215a59a9e87b04af26d948 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Oct 13, 2011 at 12:29 AM, Randell Je= sup <randell= -ietf@jesup.org> wrote:
It did cover that case - it was up to the app what to do when the first ACC= EPT was processed. =A0I didn't go into the JS-level mechanisms used.

I guess I might be missing something, but how, using ACC= EPT, RTC can generate a single offer, get two answers back, and create two = media streams? Creating a second media stream does not mean that this is a = last answer for this stream (corresponds to new SIP dialog created by prov= isional response) and accepting a stream does not mean it cannot be cloned = (corresponds to new SIP dialog created by new final response). So essentia= lly we need four operations: create offer, create media stream based on an = answer, update existing stream based on a new answer for the same dialog, a= nd finalize the media stream. Or alternatively we can achieve the same with= create offer and stream together, process answer, accept (finalize the str= eam) and clone the stream. Either way we need four methods and we achieve t= he same functionality.

Do not assume that remote IP =3D=3D source - this is easily prov= ably false, though if you used remote IP+port AND local IP+port I think it = would be ok. =A0However, for each remote connection we should have a DTLS c= onnection instance, so that's probably simplest.

Yes, I do agree we should disambiguate on local/remo= te IP+port pair. I=20 did not realize we are requiring DTLS/SRTP in RTC. I don't think I'= ve=20 seen a single implementation of this in the wild, and I do not see any=20 harm in supporting SRTP and (with user confirmation) of plain RTP.
_____________
Roman Shpount

--bcaec5215a59a9e87b04af26d948-- From randell-ietf@jesup.org Wed Oct 12 22:08: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 F335721F8AFF for ; Wed, 12 Oct 2011 22:08:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.256 X-Spam-Level: X-Spam-Status: No, score=-2.256 tagged_above=-999 required=5 tests=[AWL=-0.257, 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 cYhPJoSvWceX for ; Wed, 12 Oct 2011 22:08:01 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 7821C21F8AD1 for ; Wed, 12 Oct 2011 22:08: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 1REDWS-0000do-K5 for rtcweb@ietf.org; Thu, 13 Oct 2011 00:08:00 -0500 Message-ID: <4E96712C.7020706@jesup.org> Date: Thu, 13 Oct 2011 01:03:40 -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: <4E8D6507.8000707@ericsson.com> <4E955775.10206@alvestrand.no> <4E956526.2090604@alvestrand.no> <380E325E-A7EF-489A-AA24-0270224FC87A@phonefromhere.com> <4E957C55.9020706@alvestrand.no> <13C2526B-E7B1-408C-BD1D-EC5E8C8F6472@phonefromhere.com> <4E95871F.9010605@alvestrand.no> <4E959D48.3090401@mozilla.com> <9E790044-DE19-46DD-89D8-C4F2973F8D65@phonefromhere.com> <4E9612D3.2040207@jesup.org> <4E966928.1020100@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] Making progress on the signaling discussion (NB: Action items enclosed!) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 05:08:02 -0000 On 10/13/2011 12:48 AM, Roman Shpount wrote: > > On Thu, Oct 13, 2011 at 12:29 AM, Randell Jesup > wrote: > > It did cover that case - it was up to the app what to do when the > first ACCEPT was processed. I didn't go into the JS-level > mechanisms used. > > > I guess I might be missing something, but how, using ACCEPT, RTC can > generate a single offer, get two answers back, and create two media > streams? Creating a second media stream does not mean that this is a > last answer for this stream (corresponds to new SIP dialog created by > provisional response) and accepting a stream does not mean it cannot be > cloned (corresponds to new SIP dialog created by new final response). So > essentially we need four operations: create offer, create media stream > based on an answer, update existing stream based on a new answer for the > same dialog, and finalize the media stream. Or alternatively we can > achieve the same with create offer and stream together, process answer, > accept (finalize the stream) and clone the stream. Either way we need > four methods and we achieve the same functionality. I'm not sure we're actually disagreeing here - I'll dig out my original message. > Do not assume that remote IP == source - this is easily provably > false, though if you used remote IP+port AND local IP+port I think > it would be ok. However, for each remote connection we should have > a DTLS connection instance, so that's probably simplest. > > > Yes, I do agree we should disambiguate on local/remote IP+port pair. I > did not realize we are requiring DTLS/SRTP in RTC. I don't think I've > seen a single implementation of this in the wild, and I do not see any > harm in supporting SRTP and (with user confirmation) of plain RTP. Yes, allowing any non-encrypted connection is controversial currently. DTLS for the PeerConnection and any data channels, and DTLS-SRTP for the media channels. See ekr's security spec. As for implementations, that should not be a problem. Plain SRTP with SDES I consider more problematic, since it inherently exposes the keys to the un-trusted app and server. -- Randell Jesup randell-ietf@jesup.org From thomas@cipango.org Thu Oct 13 01:13: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 5290521F8B43 for ; Thu, 13 Oct 2011 01:13:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.301 X-Spam-Level: X-Spam-Status: No, score=0.301 tagged_above=-999 required=5 tests=[BAYES_50=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 8kMmZbbNBKpc for ; Thu, 13 Oct 2011 01:13:42 -0700 (PDT) Received: from mo1.mail-out.ovh.net (11.mo1.mail-out.ovh.net [188.165.48.29]) by ietfa.amsl.com (Postfix) with ESMTP id 5314A21F8B2E for ; Thu, 13 Oct 2011 01:13:42 -0700 (PDT) Received: from mail194.ha.ovh.net (b9.ovh.net [213.186.33.59]) by mo1.mail-out.ovh.net (Postfix) with SMTP id 888141000B81 for ; Thu, 13 Oct 2011 10:15:19 +0200 (CEST) Received: from b0.ovh.net (HELO queueout) (213.186.33.50) by b0.ovh.net with SMTP; 13 Oct 2011 10:13:38 +0200 Received: from unknown (HELO ?192.168.2.127?) (thomas.leseney%nexcom.fr@46.31.211.34) by ns0.ovh.net with SMTP; 13 Oct 2011 10:13:37 +0200 X-Ovh-Mailout: 178.32.228.1 (mo1.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: Thu, 13 Oct 2011 10:13:36 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1433860A-492D-4D92-AF80-32627DF25498@cipango.org> References: To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= X-Mailer: Apple Mail (2.1084) X-Ovh-Tracer-Id: 11362863336545125171 X-Ovh-Remote: 46.31.211.34 () X-Ovh-Local: 213.186.33.20 (ns0.ovh.net) X-Spam-Check: DONE|U 0.500004/N X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: -96 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeeftddrfeeiucetggdotefuucfrrhhofhhilhgvmecuqfggjfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnegfrhhlucfvnfffucdlgedm Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SIP on the Web: presentation and video X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 08:13:43 -0000 Hi I=F1aki and Jos=E9,=20 We've added SIP over WebSocket support to cipango (sip/http servlets) = based on your proposal and are wondering whether you plan to share the = JS client ?=20 We would be interested for testing purposes and we'll be happy then to = provide feedback. Regards,=20 Thomas Le 11 oct. 2011 =E0 09:46, I=F1aki Baz Castillo a =E9crit : > 2011/10/11 Jos=E9 Luis Mill=E1n : >> Some weeks ago we made a concrete proposal for signalling between Web >> browser and server in RTCweb. Such a definition was described in >> "draft-ibc-rtcweb-sip-websocket-00". >>=20 >> We don't advocate for a default signaling protocol in RTCweb (not at = all). >> Current proposal is just an example of a working signaling for RTCweb = based >> on SIP and carried over WebSocket. >>=20 >> We have just uploaded a video demo in which there can be seen a real >> implementation of the mentioned draft. >>=20 >> The components of the signalling architecture are a WebSocket capable >> SIP proxy and a SIP stack written in JavaScript. These are needed to >> make the browser became a real SIP node, capable to interact with = real >> SIP World. >>=20 >> We would like to emphasize that the aim of this video is nothing but >> showing an implementation of the proposed signalling. >>=20 >>=20 >> We wish you enjoy. >>=20 >> http://sip-on-the-web.aliax.net. >=20 >=20 > Hi, the video is at the end of the HTML presentation. Direct links = anyhow: >=20 > - Ogg Vorbis video (17 MB) - = http://sip-on-the-web.aliax.net/sip-on-the-web.ogv > - MP4 video (5.7 MB) - = http://sip-on-the-web.aliax.net/sip-on-the-web.mp4 > - AVI video (46 MB) - = http://sip-on-the-web.aliax.net/sip-on-the-web.avi >=20 > Regards. >=20 >=20 > --=20 > I=F1aki Baz Castillo > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From sebastien.cubaud@orange.com Thu Oct 13 06:22: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 06C7D21F8AAA for ; Thu, 13 Oct 2011 06:22:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[AWL=-1.077, BAYES_00=-2.599, FRT_BELOW2=2.154, 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 iRD5F9SP0W7O for ; Thu, 13 Oct 2011 06:22:51 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by ietfa.amsl.com (Postfix) with ESMTP id 2624E21F8A64 for ; Thu, 13 Oct 2011 06:22:51 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 9797EB58C06; Sun, 9 Oct 2011 11:58:35 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id 9135FB58B7A; Sun, 9 Oct 2011 11:58:35 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Sun, 9 Oct 2011 11:49:00 +0200 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: Sun, 9 Oct 2011 11:48:59 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] Summary of ICE discussion Thread-Index: AcyCorfYEOy7oXJvRF2NDEycgSphrQChiXRwAE+CiBAAAD10gA== References: <4E8B192E.80809@ericsson.com> From: To: , X-OriginalArrivalTime: 09 Oct 2011 09:49:00.0448 (UTC) FILETIME=[ABD4EA00:01CC8668] Subject: Re: [rtcweb] Summary of ICE discussion X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 13:22:52 -0000 Hi there, Re Magnus's call for proposal (If anyone can find a solution that = fulfill the security goals and have improved legacy interoperability people = would=20 be interested in that solution. So far RTCP has been discarded as = insufficient.)=20 on media consent verification, here is below a suggestion for the group: Basically, the idea, compared to Hadriel's RTCP proposal, relies on the = use=20 of the signalling path instead of RTCP as a feedback channel for media=20 consent verification. Here are the steps I foresee before allowing the establishment of a = media session: =20 - Let's consider A (a RTC-Web compliant browser) connected to server S = and=20 wishing to share real-time media with destination B (potentially a SIP=20 endpoint or a browser) - A & B learn via the signalling channel the triple @IP, transport proto = and=20 associated listening port of the remote media - A sends a few RTP packets to B (3 as in RFC 2833/4733 or more?).- This = would allow the mechanism to resist against packet loss - =20 - Assuming B receives these packets, it then sends via the signalling = channel=20 an information from the media path unknown from S (i.e. not accessible = via JS).=20 I propose to use the min of the sequence number of the RTP packets = received=20 (which is random per RFC 3550) - A receives via S this info granting B's consent to receiving media = from A - A now can start sending media to B When B uses SIP as its signalling channel, Step 4 would probably require = a=20 SDP extension to convey this info, as well as possibly extended = H.248/Diameter informations would be required in a decoupled sig./media architecture. = Of course, a solution avoiding extensions would be more than welcome. The benefit of this mechanism largely relies on the assumption that the=20 transmission of information from the media termination of the = destination=20 to its associated signalling channel is less costly than implementing = ICE connectivity=20 checks. Which is still to be checked. This mechanism provides basic media consent verification and if it turns = out=20 that it provides less security properties than ICE or other drawbacks = (e.g.=20 increasing media session establishment delay, issues with the few = initial RTP=20 packets,..), it could be seen as a fallback media consent verification=20 when ICE is not implemented at each end of media terminations.=20 Looking forward to hearing feedbacks from the group on this. Cheers Sebastien -----Message d'origine----- De=A0: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] De la = part de Magnus Westerlund Envoy=E9=A0: mardi 4 octobre 2011 16:33 =C0=A0: rtcweb@ietf.org Objet=A0: [rtcweb] Summary of ICE discussion WG, I have bellow tired to summarize the result of the ICE discussion. This is intended as furthering this discussion and form a basis for going forward in the consensus process. I do expect people that disagree with my summary of the discussion to speak up. Major requirements - Need for data transmission consent for protocols using UDP as the traffic receiver needs to consent to receiving the data - Perform NAT and FW traversal when ever needed - Support IPv4 to IPv6 transition Desired behavior: - Be interoperable with deployed legacy systems as SIP Trunk, PSTN gateways, VoIP phones. WG chairs conclusion of discussion so far: - ICE is so far the only solution that provides the security goals and have any legacy deployment. - ICE usage will require that STUN connectivity MUST have succeeded prior to any data transmission to fulfill security goals. * The Browser will enforce this requirement to prevent being an attack vector in all cases. - If anyone can find a solution that fulfill the security goals and have improved legacy interoperability people would be interested in that solution. So far RTCP has been discarded as insufficient. - Media Gateway can support a reduced functionality set from Full ICE Cheers Magnus Westerlund as WG chair ---------------------------------------------------------------------- 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 BeckW@telekom.de Fri Oct 14 08: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 6D32621F8C78 for ; Fri, 14 Oct 2011 08:27:52 -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_DE=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 ZlNXmk9VpL-R for ; Fri, 14 Oct 2011 08:27:51 -0700 (PDT) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by ietfa.amsl.com (Postfix) with ESMTP id 7A0B521F8C6B for ; Fri, 14 Oct 2011 08:27:51 -0700 (PDT) Received: from he111630.emea1.cds.t-internal.com ([10.134.93.22]) by tcmail71.telekom.de with ESMTP/TLS/AES128-SHA; 14 Oct 2011 17:26:07 +0200 Received: from HE111644.EMEA1.CDS.T-INTERNAL.COM ([169.254.4.223]) by HE111630.emea1.cds.t-internal.com ([::1]) with mapi; Fri, 14 Oct 2011 17:26:07 +0200 From: To: Date: Fri, 14 Oct 2011 17:24:38 +0200 Thread-Topic: Signalling, SDP, and the way we think about interconnecting RTCWEB applications Thread-Index: AcyKhWL740Pq1wxmRW2Lk9otaYDGCw== Message-ID: Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [rtcweb] Signalling, SDP, and the way we think about interconnecting RTCWEB 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: Fri, 14 Oct 2011 15:27:52 -0000 The interconnection trapezoid we inherited from SIP has become a sort of Go= rdian knot. If we could avoid RTCWEB server from having to speak to each ot= her at all, we could avoid re-inventing SDP syntax and/or semantics, at lea= st to some degree. https://datatracker.ietf.org/doc/draft-beck-rtcweb-alt-ic/ investigates how= we could get rid of server-to-server communication and the associated prob= lems by using 3rd party authentication/authorization. The VWRAP WG discusse= d something similar with regard virtual world systems interconnection. I know I missed the dead-line to announce this draft last week. Wolfgang -- Deutsche Telekom Netzproduktion GmbH Fixed Mobile Engineering Deutschland Wolfgang Beck Heinrich-Hertz-Stra=DFe 3-7, 64295 Darmstadt +49 6151 628 2832 (Tel.) www.telekom.de Erleben, was verbindet. Deutsche Telekom Netzproduktion GmbH Aufsichtsrat: Dr. Thomas Knoll (Vorsitzender) Gesch=E4ftsf=FChrung: Dr. Bruno Jacobfeuerborn (Vorsitzender), Albert Mathe= is, Klaus Peren Handelsregister: Amtsgericht Bonn HRB 14190 Sitz der Gesellschaft Bonn USt-IdNr. DE 814645262 Gro=DFe Ver=E4nderungen fangen klein an - Ressourcen schonen und nicht jede= E-Mail drucken. From ibc@aliax.net Fri Oct 14 08:43: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 D364821F8CA0 for ; Fri, 14 Oct 2011 08:43:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[AWL=0.127, 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 ICTaW62cRhBa for ; Fri, 14 Oct 2011 08:43:59 -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 2834B21F8C9F for ; Fri, 14 Oct 2011 08:43:59 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so1324542vcb.31 for ; Fri, 14 Oct 2011 08:43:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.184.103 with SMTP id et7mr9493042vdc.35.1318607038558; Fri, 14 Oct 2011 08:43:58 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Fri, 14 Oct 2011 08:43:58 -0700 (PDT) In-Reply-To: References: Date: Fri, 14 Oct 2011 17:43:58 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: BeckW@telekom.de Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Signalling, SDP, and the way we think about interconnecting RTCWEB 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: Fri, 14 Oct 2011 15:43:59 -0000 2011/10/14 : > The interconnection trapezoid we inherited from SIP has become a sort of = Gordian knot. If we could avoid RTCWEB server from having to speak to each = other at all, we could avoid re-inventing SDP syntax and/or semantics, at l= east to some degree. Hi, maybe I miss something, but this is WWW world and here there is no server-to-external-server interoperability, never. The SIP trapezoid exists and works, but IMHO there will never be a "RTCweb trapezoid". Or do we expect that a user visiting facebook.com should be able to establish a media session with other user visiting linkedin.com? I don't think that will occur. There are not "federated chats" in the web, why should we specify "federated media sessions"? IMHO this is out of the scope of RTCweb, and in case of introducing it in the specifications, it would become an overkill (standarizing signaling between different WWW domains? that's not feasible in this world). So I agree with your draft. Instead of "federating" (a concept that does not exist in WWW jungle) using OAuth or something similar is the key (so a linkedin.com visitor would establish a HTTP/WebSocket connection with Facebook.com servers in order to establish a media session with other user visiting Facebook). Regards. --=20 I=C3=B1aki Baz Castillo From randell-ietf@jesup.org Fri Oct 14 09: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 96AE321F8C5F for ; Fri, 14 Oct 2011 09:34:01 -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 HugGiFbl2nkV for ; Fri, 14 Oct 2011 09:34:00 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id DE66221F8CD2 for ; Fri, 14 Oct 2011 09:34:00 -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 1REkhs-00061x-7D for rtcweb@ietf.org; Fri, 14 Oct 2011 11:34:00 -0500 Message-ID: <4E986370.4030601@jesup.org> Date: Fri, 14 Oct 2011 12:29:36 -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: 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] Signalling, SDP, and the way we think about interconnecting RTCWEB 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: Fri, 14 Oct 2011 16:34:01 -0000 On 10/14/2011 11:43 AM, Iñaki Baz Castillo wrote: > 2011/10/14: >> The interconnection trapezoid we inherited from SIP has become a sort of Gordian knot. If we could avoid RTCWEB server from having to speak to each other at all, we could avoid re-inventing SDP syntax and/or semantics, at least to some degree. > > Hi, maybe I miss something, but this is WWW world and here there is no > server-to-external-server interoperability, never. > > The SIP trapezoid exists and works, but IMHO there will never be a > "RTCweb trapezoid". Or do we expect that a user visiting facebook.com > should be able to establish a media session with other user visiting > linkedin.com? I don't think that will occur. There are not "federated > chats" in the web, why should we specify "federated media sessions"? Well, out of that 'jungle' as you refer to it the result is client apps that have to talk N protocols -- look at Pidgeon/libpurple, for example. How many IM protocols have to be encoded within it? Effectively it's N clients with a single UI front end - and it has to reverse-engineer each of those other-site protocols, generally, and track when they change. Similar things go on with other "let me post something to N places" tools, etc. Federation sounds like a major win over that. > IMHO this is out of the scope of RTCweb, and in case of introducing it > in the specifications, it would become an overkill (standarizing > signaling between different WWW domains? that's not feasible in this > world). rtcweb is explicitly NOT standardizing the method of federation. SIP is an option, but just an option. If there is complexity, it will exist solely at the federation gateway. (And if everyone has a way to convert to (say) SDP offer-answer, it may work fairly easily.) > So I agree with your draft. Instead of "federating" (a concept that > does not exist in WWW jungle) using OAuth or something similar is the > key (so a linkedin.com visitor would establish a HTTP/WebSocket > connection with Facebook.com servers in order to establish a media > session with other user visiting Facebook). For that to work, you have to assume that the apps on linkedin and facebook each use the same signalling/etc protocol over the websocket, OR they know the details of the protocol the other uses, OR they all have a single default "fallback" signalling method, which I thought you wanted to avoid. -- Randell Jesup randell-ietf@jesup.org From HKaplan@acmepacket.com Fri Oct 14 10: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 2F8E021F8CA5 for ; Fri, 14 Oct 2011 10:59:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.351 X-Spam-Level: X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[AWL=-0.052, 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 tQbRUuF+dGXR for ; Fri, 14 Oct 2011 10:59:54 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 6218E21F8C6F for ; Fri, 14 Oct 2011 10:59: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; Fri, 14 Oct 2011 13:59: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, 14 Oct 2011 13:59:53 -0400 From: Hadriel Kaplan To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= Thread-Topic: [rtcweb] Signalling, SDP, and the way we think about interconnecting RTCWEB applications Thread-Index: AQHMipsTQTQZSKEKrkKeWaPKwpQ4nw== Date: Fri, 14 Oct 2011 17:59:53 +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="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [rtcweb] Signalling, SDP, and the way we think about interconnecting RTCWEB 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: Fri, 14 Oct 2011 17:59:55 -0000 On Oct 14, 2011, at 11:43 AM, I=F1aki Baz Castillo wrote: > Hi, maybe I miss something, but this is WWW world and here there is no > server-to-external-server interoperability, never. That's odd - I could have sworn the emails I type into my gmail account rea= ch servers outside of Google, using a standard protocol: SMTP. Is gmail no= t in the "WWW world"? ;) > The SIP trapezoid exists and works, but IMHO there will never be a > "RTCweb trapezoid". Or do we expect that a user visiting facebook.com > should be able to establish a media session with other user visiting > linkedin.com? I don't think that will occur. There are not "federated > chats" in the web, why should we specify "federated media sessions"? Ummm, but there *are* federated chats. When I join the jabber room for IET= F meetings, I don't have a personal account on the IETF's jabber site to do= so. I don't debate that chat is mostly done in closed communities (AIM, YIM, et= c.), but SMS is a type of chat and widely popular in a federated model. An= d it's usage grew tremendously once different providers federated, which I = assume wasn't a coincidence of timing. > So I agree with your draft. Instead of "federating" (a concept that > does not exist in WWW jungle) using OAuth or something similar is the > key (so a linkedin.com visitor would establish a HTTP/WebSocket > connection with Facebook.com servers in order to establish a media > session with other user visiting Facebook). One problem with that of course is that the user interface would change dra= matically every call, and depending on which direction the call was. My gu= ess is people generally get used to and like their particular UI - where th= e icons are, what they look like, menu options, settings, etc. And I would expect some sites to offer JS which lets me do things like turn= video off forever, or use a static picture/video of my choosing, which wou= ld somehow have to be communicated to the called domain's JS. (And that's j= ust the tip of the proverbial iceberg) -hadriel From ibc@aliax.net Fri Oct 14 11: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 003AF21F8BB6 for ; Fri, 14 Oct 2011 11:33:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.557 X-Spam-Level: X-Spam-Status: No, score=-2.557 tagged_above=-999 required=5 tests=[AWL=0.120, 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 ZBGpTesniVMe for ; Fri, 14 Oct 2011 11:33:48 -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 3303E21F8B9D for ; Fri, 14 Oct 2011 11:33:48 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so1499996vcb.31 for ; Fri, 14 Oct 2011 11:33:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.184.103 with SMTP id et7mr10275347vdc.35.1318617227637; Fri, 14 Oct 2011 11:33:47 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Fri, 14 Oct 2011 11:33:47 -0700 (PDT) In-Reply-To: <4E986370.4030601@jesup.org> References: <4E986370.4030601@jesup.org> Date: Fri, 14 Oct 2011 20:33:47 +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] Signalling, SDP, and the way we think about interconnecting RTCWEB 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: Fri, 14 Oct 2011 18:33:49 -0000 2011/10/14 Randell Jesup : >> The SIP trapezoid exists and works, but IMHO there will never be a >> "RTCweb trapezoid". Or do we expect that a user visiting facebook.com >> should be able to establish a media session with other user visiting >> linkedin.com? I don't think that will occur. There are not "federated >> chats" in the web, why should we specify "federated media sessions"? > > Well, out of that 'jungle' as you refer to it the result is client apps t= hat > have to talk N protocols -- look at Pidgeon/libpurple, for example. =C2= =A0How > many IM protocols have to be encoded within it? =C2=A0Effectively it's N = clients > with a single UI front end - and it has to reverse-engineer each of those > other-site protocols, generally, and track when they change. =C2=A0Simila= r things > go on with other "let me post something to N places" tools, etc. WWW is different. The "software" is provided by each web site. This is at least how WW works today. >> IMHO this is out of the scope of RTCweb, and in case of introducing it >> in the specifications, it would become an overkill (standarizing >> signaling between different WWW domains? that's not feasible in this >> world). > > rtcweb is explicitly NOT standardizing the method of federation. =C2=A0SI= P is an > option, but just an option. =C2=A0If there is complexity, it will exist s= olely at > the federation gateway. =C2=A0(And if everyone has a way to convert to (s= ay) SDP > offer-answer, it may work fairly easily.) Then, if rtcweb is explicitly NOT standardizing the method of federation, what is this discussion about? :) >> So I agree with your draft. Instead of "federating" (a concept that >> does not exist in WWW jungle) using OAuth or something similar is the >> key (so a linkedin.com visitor would establish a HTTP/WebSocket >> connection with Facebook.com servers in order to establish a media >> session with other user visiting Facebook). > > For that to work, you have to assume that the apps on linkedin and facebo= ok > each use the same signalling/etc protocol over the websocket, No, I meant that web sites A.com and B.com allow to each other displaying the visitors in each page, so a visitor in A.com can see in the web the visitors connected to B.com. But if a visitor in A.com wants to talk with a visitor in B.com, A.com retrieves the JS signaling from *B.com* (B.com allows that due to some kind of authorization, i.e. OAuth) and both visitors in A.com and B.com speak the signaling protocol of B.com. --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Fri Oct 14 11:48: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 D94AB21F8CDB for ; Fri, 14 Oct 2011 11:48:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.564 X-Spam-Level: X-Spam-Status: No, score=-2.564 tagged_above=-999 required=5 tests=[AWL=0.113, 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 IKvPrQsNo9lP for ; Fri, 14 Oct 2011 11:48:21 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id E249021F8B05 for ; Fri, 14 Oct 2011 11:48:20 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so1513818vcb.31 for ; Fri, 14 Oct 2011 11:48:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.90.206 with SMTP id by14mr10282925vdb.18.1318618100339; Fri, 14 Oct 2011 11:48:20 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Fri, 14 Oct 2011 11:48:20 -0700 (PDT) In-Reply-To: References: Date: Fri, 14 Oct 2011 20:48:20 +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] Signalling, SDP, and the way we think about interconnecting RTCWEB 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: Fri, 14 Oct 2011 18:48:22 -0000 2011/10/14 Hadriel Kaplan : > On Oct 14, 2011, at 11:43 AM, I=C3=B1aki Baz Castillo wrote: > >> Hi, maybe I miss something, but this is WWW world and here there is no >> server-to-external-server interoperability, never. > > That's odd - I could have sworn the emails I type into my gmail account r= each servers outside of Google, using a standard protocol: SMTP. =C2=A0Is g= mail not in the "WWW world"? > ;) Good example, but I expect that SMTP is much simpler than a realtime communication protocol :) >> The SIP trapezoid exists and works, but IMHO there will never be a >> "RTCweb trapezoid". Or do we expect that a user visiting facebook.com >> should be able to establish a media session with other user visiting >> linkedin.com? I don't think that will occur. There are not "federated >> chats" in the web, why should we specify "federated media sessions"? > > Ummm, but there *are* federated chats. =C2=A0When I join the jabber room = for IETF meetings, I don't have a personal account on the IETF's jabber sit= e to do so. I'm not opposed to RTCweb federation, how could I say that? :) I just meant that trying to "standarize" that is unfeasible IMHO. First of all, because standarizing that means that we assume that every kind of communications made on top of RTCweb specs are the same, with same properties and capabilities. But I strongly assume that some web site could offer audio calls between users while other site just offers video calls. Some web site offers like-SIP full telephony capabilities (forking, earlymedia, transference) while another web site is just interested in very simple audio calls. How to make a standard for federating all those different scenarios? IMHO it's a no-go. >> So I agree with your draft. Instead of "federating" (a concept that >> does not exist in WWW jungle) using OAuth or something similar is the >> key (so a linkedin.com visitor would establish a HTTP/WebSocket >> connection with Facebook.com servers in order to establish a media >> session with other user visiting Facebook). > > One problem with that of course is that the user interface would change d= ramatically every call, and depending on which direction the call was. =C2= =A0My guess is people generally get used to and like their particular UI - = where the icons are, what they look like, menu options, settings, etc. You are right. But see my comment above. What are we trying to achieve in this thread? I expect all of this stuff will work as today's WWW world: A very big web site decides its *own* API/signaling and others (other websites!) must implement it if they want to offer their users RTC communications with users in the big web site. Or do we want to standarize the API/signaling each web site MUST offer to others? this is WWW world, such things are not welcome here. WWW people don't like protocols or standards (others than their custom protocols in JSON). Look the example of authentication in WWW: HTTP defines HTTP Digest/Basic authentication but, how many web sites use it? no one today. All of them prefer to use an HTML form with some kind of JavaScript stuff and some custom message format (of course in JSON because JSON is the only message format in the world). > And I would expect some sites to offer JS which lets me do things like tu= rn video off forever, or use a static picture/video of my choosing, which w= ould somehow have to be communicated to the called domain's JS. (And that's= just the tip of the proverbial iceberg) Ok, then what is this thread about? :) --=20 I=C3=B1aki Baz Castillo From HKaplan@acmepacket.com Fri Oct 14 13:56: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 68ABE21F8C9A for ; Fri, 14 Oct 2011 13:56:59 -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.058, 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 PknlqUhMJyAa for ; Fri, 14 Oct 2011 13:56:59 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 7B80721F8CCA for ; Fri, 14 Oct 2011 13:56:58 -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, 14 Oct 2011 16:56:56 -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, 14 Oct 2011 16:56:57 -0400 From: Hadriel Kaplan To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= Thread-Topic: [rtcweb] Signalling, SDP, and the way we think about interconnecting RTCWEB applications Thread-Index: AQHMirPPbto5n2WwikyaKnAMkjYYlA== Date: Fri, 14 Oct 2011 20:56:56 +0000 Message-ID: <92A553E5-107A-4987-A5F5-1F56FB5A7800@acmepacket.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [216.41.24.34] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [rtcweb] Signalling, SDP, and the way we think about interconnecting RTCWEB 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: Fri, 14 Oct 2011 20:56:59 -0000 On Oct 14, 2011, at 2:48 PM, I=F1aki Baz Castillo wrote: > I'm not opposed to RTCweb federation, how could I say that? :) > I just meant that trying to "standarize" that is unfeasible IMHO. > First of all, because standarizing that means that we assume that > every kind of communications made on top of RTCweb specs are the same, > with same properties and capabilities. But I strongly assume that some > web site could offer audio calls between users while other site just > offers video calls. Some web site offers like-SIP full telephony > capabilities (forking, earlymedia, transference) while another web > site is just interested in very simple audio calls. How to make a > standard for federating all those different scenarios? IMHO it's a > no-go. Oh yeah I don't mean to imply we should mandate what the inter-domain proto= col must be. Domains can use whatever they like: SIP, H.323, XMPP, BICC, I= AX, some-apple-protocol, some-google-protocol, ... Who are we to tell a web admin what protocol to use to another web admin? = And even if we did, why would they listen to us? *BUT* we do have to make sure that SIP can actually be used for such an int= er-domain protocol; both because it's an active IETF-defined protocol for r= eal-time communications between peers and we'd look pretty silly if RTCWEB = couldn't use it between RTCWEB domains, but also because SIP arguably is th= e most popular one out there and we should do everything in our power to ma= ke it usable to/from RTCWEB domains with as least cost/complexity as possib= le. And I don't mean that only in the aspect of federation or PSTN-access. I d= on't know if RTCWeb will be popular for those. But I can guess one applica= tion where it will be popular: corporate websites, such as support/help pag= es or sales pages. Lots of companies already use plugins/flash on their su= pport/sales websites to enable audio and chat from customers to their inter= nal support/sales people. Obviously those sales/support employees could be= using a browser to communicate with customers using the same website, but = it's also as likely that they use their existing SIP infrastructure interna= lly - if for no other reason than they already have it and it works with th= eir IVR, ACD and recording systems, and they can reach employees on mobile = phones or the PSTN back out their SIP trunks. Another obvious application for RTCWEB-to-SIP is Webex, where a company cou= ld deploy their own web server for webex-style conferencing without paying = Cisco/Webex. Although most if not all the users on a webex have browser ac= cess, it's still the case you need SIP-PSTN access because you need to let = conference-type phones access the meeting. As for example happened this we= ek at the IETF CLUE WG interim meeting: a webex session was available but t= he physical meeting room used a Polycom conference-phone for the moderator = "participant". -hadriel p.s. I mean this all in the aspect of a trapezoid where SIP is the high-pat= h between servers, not SIP between the browser and its server. From ibc@aliax.net Fri Oct 14 14:18: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 9634321F8B1A for ; Fri, 14 Oct 2011 14:18:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.27 X-Spam-Level: X-Spam-Status: No, score=-2.27 tagged_above=-999 required=5 tests=[AWL=-0.193, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_33=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 NQeHQiiTnFFF for ; Fri, 14 Oct 2011 14:18:53 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id D4EF721F8B18 for ; Fri, 14 Oct 2011 14:18:52 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so1640736vcb.31 for ; Fri, 14 Oct 2011 14:18:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.9.3 with SMTP id j3mr792813vcj.6.1318627130329; Fri, 14 Oct 2011 14:18:50 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Fri, 14 Oct 2011 14:18:50 -0700 (PDT) In-Reply-To: <92A553E5-107A-4987-A5F5-1F56FB5A7800@acmepacket.com> References: <92A553E5-107A-4987-A5F5-1F56FB5A7800@acmepacket.com> Date: Fri, 14 Oct 2011 23:18:50 +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] Signalling, SDP, and the way we think about interconnecting RTCWEB 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: Fri, 14 Oct 2011 21:18:53 -0000 2011/10/14 Hadriel Kaplan : > *BUT* we do have to make sure that SIP can actually be used for such an i= nter-domain protocol; both because it's an active IETF-defined protocol for= real-time communications between peers and we'd look pretty silly if RTCWE= B couldn't use it between RTCWEB domains, but also because SIP arguably is = the most popular one out there RTCweb is mostly focused on pure Internet world. Is SIP more extended in pure Internet than XMPP? I don't think so (I mean pure Internet, not telcos' private IP networks). So you like SIP (and me), but I would like to hear the opinion of Google folks about it :) More comments below. > And I don't mean that only in the aspect of federation or PSTN-access. = =C2=A0I don't know if RTCWeb will be popular for those. =C2=A0But I can gue= ss one application where it will be popular: corporate websites, such as su= pport/help pages or sales pages. =C2=A0Lots of companies already use plugin= s/flash on their support/sales websites to enable audio and chat from custo= mers to their internal support/sales people. =C2=A0Obviously those sales/su= pport employees could be using a browser to communicate with customers usin= g the same website, but it's also as likely that they use their existing SI= P infrastructure internally - if for no other reason than they already have= it and it works with their IVR, ACD and recording systems, and they can re= ach employees on mobile phones or the PSTN back out their SIP trunks. If you want your RTCweb deploment to interact with SIP... why don't you use just SIP? :) http://sip-on-the-web.aliax.net/ Why are you assuming that there must be some kind of protocol gateway RTCweb<->SIP ? Personally I hate gateways! even more when they are unnecessary. Ok, so let's assume that you want some custom singaling protocol for your RTCweb deployment (instead of using SIP over WebSocket) but want also to interact with a SIP network out there. What is the problem with current RTCweb specs? You say "we do have to make sure that SIP can actually be used for such an inter-domain protocol" but what do you mean with that? Of course I want that a RTCweb client can establish a media session with a pure SIP client (assuming ICE+RTP supported in the SIP device), don't the current RTCweb specs allow that? I assume such specs and the resulting JS API will be done with that in mind (but not just SIP but also XMPP-Jingle and other VoIP protocols based on SDP exchange/negotiation). So honestly, I don't understand what you mean in your mail. Of course we all want RTCweb to be interoperable with a SIP network but, how is that related to "RTCweb federation"? The success of a interoperation between RTCweb and a SIP network just depends on how good you are designing your signaling mapping between your custom RTCweb signaling and SIP, no more. Regards. --=20 I=C3=B1aki Baz Castillo From ted.ietf@gmail.com Fri Oct 14 14:27: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 CE79121F8C6B for ; Fri, 14 Oct 2011 14:27:05 -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.350, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=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 Ev30r9eomotf for ; Fri, 14 Oct 2011 14:27:04 -0700 (PDT) Received: from mail-yx0-f179.google.com (mail-yx0-f179.google.com [209.85.213.179]) by ietfa.amsl.com (Postfix) with ESMTP id 81B8B21F8C46 for ; Fri, 14 Oct 2011 14:27:04 -0700 (PDT) Received: by yxn35 with SMTP id 35so1552190yxn.38 for ; Fri, 14 Oct 2011 14:27:04 -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=FyUWfurdTjIEdNqJl21LE8F2/D5dno5MRDQA8NC8dRU=; b=UKcycrbw4WbZx4d4IR1+8f3WT7BSAOZzx6udi7MH/oiSTgpXUtPUg9U+vYekxtrVcM Uu8M7++ZwHdrAKM9QgZtVKSmSNGVVj9d0G+B3iKe7g49XqFWCiiDk+/hefHGwwaojxnk j1MByKrVl02ov1/FS/y8drB7QfQFmnYTpfLnU= MIME-Version: 1.0 Received: by 10.236.73.130 with SMTP id v2mr14689170yhd.57.1318627623970; Fri, 14 Oct 2011 14:27:03 -0700 (PDT) Received: by 10.236.105.169 with HTTP; Fri, 14 Oct 2011 14:27:03 -0700 (PDT) In-Reply-To: References: <92A553E5-107A-4987-A5F5-1F56FB5A7800@acmepacket.com> Date: Fri, 14 Oct 2011 14:27:03 -0700 Message-ID: From: Ted Hardie To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=20cf300515181e256f04af48ebea Cc: "" Subject: Re: [rtcweb] Signalling, SDP, and the way we think about interconnecting RTCWEB 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: Fri, 14 Oct 2011 21:27:05 -0000 --20cf300515181e256f04af48ebea Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Oct 14, 2011 at 2:18 PM, I=F1aki Baz Castillo wrote= : > 2011/10/14 Hadriel Kaplan : > > *BUT* we do have to make sure that SIP can actually be used for such an > inter-domain protocol; both because it's an active IETF-defined protocol = for > real-time communications between peers and we'd look pretty silly if RTCW= EB > couldn't use it between RTCWEB domains, but also because SIP arguably is = the > most popular one out there > > RTCweb is mostly focused on pure Internet world. Is SIP more extended > in pure Internet than XMPP? I don't think so (I mean pure Internet, > not telcos' private IP networks). So you like SIP (and me), but I > would like to hear the opinion of Google folks about it :) > > Not speaking for Google, but I have no idea what you mean by "pure Internet world" here. I'm also not really clear what your aim is. Hadriel has said that the overall system must be designed such that it is possible to use SI= P as a federation protocol, but that it should not be restricted so that only SIP can be used as a federation protocol. Perhaps if you responded to his point on this issue, the rest of your comments might seem more clear. regards, Ted Hardie > More comments below. > > > > And I don't mean that only in the aspect of federation or PSTN-access. = I > don't know if RTCWeb will be popular for those. But I can guess one > application where it will be popular: corporate websites, such as > support/help pages or sales pages. Lots of companies already use > plugins/flash on their support/sales websites to enable audio and chat fr= om > customers to their internal support/sales people. Obviously those > sales/support employees could be using a browser to communicate with > customers using the same website, but it's also as likely that they use > their existing SIP infrastructure internally - if for no other reason tha= n > they already have it and it works with their IVR, ACD and recording syste= ms, > and they can reach employees on mobile phones or the PSTN back out their = SIP > trunks. > > If you want your RTCweb deploment to interact with SIP... why don't > you use just SIP? :) > > http://sip-on-the-web.aliax.net/ > > Why are you assuming that there must be some kind of protocol gateway > RTCweb<->SIP ? Personally I hate gateways! even more when they are > unnecessary. > > > Ok, so let's assume that you want some custom singaling protocol for > your RTCweb deployment (instead of using SIP over WebSocket) but want > also to interact with a SIP network out there. What is the problem > with current RTCweb specs? > > You say "we do have to make sure that SIP can actually be used for > such an inter-domain protocol" but what do you mean with that? Of > course I want that a RTCweb client can establish a media session with > a pure SIP client (assuming ICE+RTP supported in the SIP device), > don't the current RTCweb specs allow that? I assume such specs and the > resulting JS API will be done with that in mind (but not just SIP but > also XMPP-Jingle and other VoIP protocols based on SDP > exchange/negotiation). > > > So honestly, I don't understand what you mean in your mail. Of course > we all want RTCweb to be interoperable with a SIP network but, how is > that related to "RTCweb federation"? The success of a interoperation > between RTCweb and a SIP network just depends on how good you are > designing your signaling mapping between your custom RTCweb signaling > and SIP, no more. > > > Regards. > > > > > -- > I=F1aki Baz Castillo > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --20cf300515181e256f04af48ebea Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Oct 14, 2011 at 2:18 PM, I=F1aki Baz Castillo <= ;ibc@aliax.net> wrote:
2011/10/14 Hadriel Kaplan <HKa= plan@acmepacket.com>:
> *BUT* we do have to make sure that SIP can actually = be used for such an inter-domain protocol; both because it's an active = IETF-defined protocol for real-time communications between peers and we'= ;d look pretty silly if RTCWEB couldn't use it between RTCWEB domains, = but also because SIP arguably is the most popular one out there

RTCweb is mostly focused on pure Internet world. Is SIP more extended=
in pure Internet than XMPP? I don't think so (I mean pure Internet,
not telcos' private IP networks). So you like SIP (and me), but I
would like to hear the opinion of Google folks about it :)


Not speaking for Google, but I have no idea what = you mean by "pure Internet world" here.=A0 I'm also not reall= y clear what your aim is.=A0 Hadriel has said that the overall system must = be designed such that it is possible to use SIP as a federation protocol, b= ut that it should not be restricted so that only SIP can be used as a feder= ation protocol.=A0 Perhaps if you responded to his point on this issue, the= rest of your comments might seem more clear.

regards,

Ted Hardie
=A0
More comments below.


> And I don't mean that only in the aspect of federation or PSTN-acc= ess. =A0I don't know if RTCWeb will be popular for those. =A0But I can = guess one application where it will be popular: corporate websites, such as= support/help pages or sales pages. =A0Lots of companies already use plugin= s/flash on their support/sales websites to enable audio and chat from custo= mers to their internal support/sales people. =A0Obviously those sales/suppo= rt employees could be using a browser to communicate with customers using t= he same website, but it's also as likely that they use their existing S= IP infrastructure internally - if for no other reason than they already hav= e it and it works with their IVR, ACD and recording systems, and they can r= each employees on mobile phones or the PSTN back out their SIP trunks.

If you want your RTCweb deploment to interact with SIP... why don'= ;t
you use just SIP? :)

=A0http://s= ip-on-the-web.aliax.net/

Why are you assuming that there must be some kind of protocol gateway
RTCweb<->SIP ? =A0Personally I hate gateways! even more when they are=
unnecessary.


Ok, so let's assume that you want some custom singaling protocol for your RTCweb deployment (instead of using SIP over WebSocket) but want
also to interact with a SIP network out there. What is the problem
with current RTCweb specs?

You say "we do have to make sure that SIP can actually be used for
such an inter-domain protocol" but what do you mean with that? Of
course I want that a RTCweb client can establish a media session with
a pure SIP client (assuming ICE+RTP supported in the SIP device),
don't the current RTCweb specs allow that? I assume such specs and the<= br> resulting JS API will be done with that in mind (but not just SIP but
also XMPP-Jingle and other VoIP protocols based on SDP
exchange/negotiation).


So honestly, I don't understand what you mean in your mail. Of course we all want RTCweb to be interoperable with a SIP network but, how is
that related to "RTCweb federation"? The success of a interoperat= ion
between RTCweb and a SIP network just depends on how good you are
designing your signaling mapping between your custom RTCweb signaling
and SIP, no more.


Regards.




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

--20cf300515181e256f04af48ebea-- From ibc@aliax.net Fri Oct 14 14: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 68CE821F8C6B for ; Fri, 14 Oct 2011 14:41:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.117, 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 V7hx0mRS8w8Y for ; Fri, 14 Oct 2011 14:41:48 -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 703ED21F8BA7 for ; Fri, 14 Oct 2011 14:41:43 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so1654670vcb.31 for ; Fri, 14 Oct 2011 14:41:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.90.206 with SMTP id by14mr10865906vdb.18.1318628502512; Fri, 14 Oct 2011 14:41:42 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Fri, 14 Oct 2011 14:41:42 -0700 (PDT) In-Reply-To: References: <92A553E5-107A-4987-A5F5-1F56FB5A7800@acmepacket.com> Date: Fri, 14 Oct 2011 23:41:42 +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: "" Subject: Re: [rtcweb] Signalling, SDP, and the way we think about interconnecting RTCWEB 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: Fri, 14 Oct 2011 21:41:48 -0000 2011/10/14 Ted Hardie : > Not speaking for Google, but I have no idea what you mean by "pure Intern= et > world" here. "Pure Internet" is just Internet, and that is not a private network or a telco IP infrastructure. I just meant that. > I'm also not really clear what your aim is.=C2=A0 Hadriel has said > that the overall system must be designed such that it is possible to use = SIP > as a federation protocol, but that it should not be restricted so that on= ly > SIP can be used as a federation protocol.=C2=A0 Perhaps if you responded = to his > point on this issue, the rest of your comments might seem more clear. Ok, let me try again: IMHO RTCweb (specially the JS API for managing media sessions) must be designed in a way that it's possible for a developer to implement a SIP client in JavaScript or another custom signaling protocol having a gateway that maps it to/from SIP. This means that SIP features as parallel forking, early media, conference... should be possible using the RTCweb JavaScript API. I think we agree here :) So, assuming that there MUST NOT exist a *standard* signaling protocol for federation in RTCweb, what is the purpose of speaking about "federation"? Probably we all are speaking about the same concept, but for me "federation" means a RTCweb server communicating with other RTCweb server. If Hadriel and you meant "RTCweb server communicating with a SIP network" then I repeat my first paragraph :) So in order to accomplish with requirements of Hadriel we need to make the RTCweb client stack and the RTCweb JavaScript API flexible enough so all (or most of) the SIP features can be implemented in JavaScript (I mean "audio/video features" since all the signaling can already be coded in different ways). Hope it's more clear now. Best regards. --=20 I=C3=B1aki Baz Castillo From HKaplan@acmepacket.com Fri Oct 14 15: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 D5BE621F8B3E for ; Fri, 14 Oct 2011 15:41:27 -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.051, 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 Ql6OLXjfCMw1 for ; Fri, 14 Oct 2011 15:41:27 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 38F4C21F8B1D for ; Fri, 14 Oct 2011 15:41: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; Fri, 14 Oct 2011 18:41:25 -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, 14 Oct 2011 18:41:25 -0400 From: Hadriel Kaplan To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= Thread-Topic: [rtcweb] Signalling, SDP, and the way we think about interconnecting RTCWEB applications Thread-Index: AQHMisJn8rgfXfSp5UKW00f9VXqrDA== Date: Fri, 14 Oct 2011 22:41:24 +0000 Message-ID: <5748C5EE-48D1-4D30-B0D2-8703C45972EE@acmepacket.com> References: <92A553E5-107A-4987-A5F5-1F56FB5A7800@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: <65F998441F1FAE4D828546CCB16DFB3B@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [rtcweb] Signalling, SDP, and the way we think about interconnecting RTCWEB 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: Fri, 14 Oct 2011 22:41:28 -0000 On Oct 14, 2011, at 5:41 PM, I=F1aki Baz Castillo wrote: > 2011/10/14 Ted Hardie : >> Not speaking for Google, but I have no idea what you mean by "pure Inter= net >> world" here. >=20 > "Pure Internet" is just Internet, and that is not a private network or > a telco IP infrastructure. I just meant that. Actually I think you'd be surprised. I don't know what Google Talk's lates= t numbers are, but I bet there is in fact more SIP done than XMPP even acro= ss the "Public Pure Pristine Internet". It's not as much SIP as is done wi= thin the same network, but it's a still a lot.=20 (of course the real king of "public Internet" VoIP would probably be Skype = protocol :) > Ok, let me try again: >=20 > IMHO RTCweb (specially the JS API for managing media sessions) must be > designed in a way that it's possible for a developer to implement a > SIP client in JavaScript or another custom signaling protocol having a > gateway that maps it to/from SIP. This means that SIP features as > parallel forking, early media, conference... should be possible using > the RTCweb JavaScript API. I think we agree here :) Right I think we do agree - I was under the impression you were saying we d= on't need to work with SIP. -hadriel From ted.ietf@gmail.com Fri Oct 14 15:42: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 E4BC221F8C22 for ; Fri, 14 Oct 2011 15:42:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.765 X-Spam-Level: X-Spam-Status: No, score=-2.765 tagged_above=-999 required=5 tests=[AWL=0.533, 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 V0OZwYph7IMI for ; Fri, 14 Oct 2011 15:42:00 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 173FE21F8C0E for ; Fri, 14 Oct 2011 15:41:58 -0700 (PDT) Received: by ggnk3 with SMTP id k3so1860910ggn.31 for ; Fri, 14 Oct 2011 15:41:57 -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=2K71qB6XZBrAcgfnZlnO2oW9oQARm2H4pyBlyTRJRhk=; b=xH4yRkgUN28e0cXirD0VuuqRjno79WFmn2iHpVPp3RcvgT0HNfXv5tXCI1K2F71abI jFlLvuyDTOHhW4gZL1f8zuD5FqxvgEQ3iJeL54NGJnFfWEJojTLtVjYKjQJ6Yg5+VX1f UxYgJX96mI881HbSGAc1fJOAEzFypTLxDAe0c= MIME-Version: 1.0 Received: by 10.236.187.36 with SMTP id x24mr14902865yhm.74.1318632117558; Fri, 14 Oct 2011 15:41:57 -0700 (PDT) Received: by 10.236.105.169 with HTTP; Fri, 14 Oct 2011 15:41:57 -0700 (PDT) In-Reply-To: References: <92A553E5-107A-4987-A5F5-1F56FB5A7800@acmepacket.com> Date: Fri, 14 Oct 2011 15:41:57 -0700 Message-ID: From: Ted Hardie To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=20cf303dd9d0f4db8f04af49f647 Cc: "" Subject: Re: [rtcweb] Signalling, SDP, and the way we think about interconnecting RTCWEB 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: Fri, 14 Oct 2011 22:42:01 -0000 --20cf303dd9d0f4db8f04af49f647 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Oct 14, 2011 at 2:41 PM, I=F1aki Baz Castillo > IMHO RTCweb (specially the JS API for managing media sessions) must be > designed in a way that it's possible for a developer to implement a > SIP client in JavaScript or another custom signaling protocol having a > gateway that maps it to/from SIP. This means that SIP features as > parallel forking, early media, conference... should be possible using > the RTCweb JavaScript API. > Do you think you could support SIP identity with a javascript client? > So, assuming that there MUST NOT exist a *standard* signaling protocol > for federation in RTCweb, what is the purpose of speaking about > "federation"? I don't think RFC 2119 MUST NOTs belong here. Understanding federation as a use case does not mandate a "one ring to rule them all" approach to federation. We could define one (as XMPP defines how different XMPP servers pass traffic among themselves). That would not mandate that all servers use it. We could also choose not to define one, but if we support the use case, we would have to understand what the minima= l set of data that had to be pass over the protocols implementing the federation would be, what security is required, and so on. > Probably we all are speaking about the same concept, but > for me "federation" means a RTCweb server communicating with other > RTCweb server. If Hadriel and you meant "RTCweb server communicating > with a SIP network" then I repeat my first paragraph :) > > So in order to accomplish with requirements of Hadriel we need to make > the RTCweb client stack and the RTCweb JavaScript API flexible enough > so all (or most of) the SIP features can be implemented in JavaScript > (I mean "audio/video features" since all the signaling can already be > coded in different ways). > > Hope it's more clear now. > > Well, given that you don't believe in the need for a protocol here at all, but only an incredibly flexible API, it seems a bit unclear why you're not making these points on the W3C public mailing list for this activity. A truly well structured API here will imply, at least in my view, at least = a common model for negotiation and a common set of structured data to be passed via this javascript-implemented protocol. Doing that without defining a standard protocol is actually harder than doing it while definin= g a protocol. I've heard the various arguments against defining one, but none of them seems to stand up against the base fact that you can have a standard protocol--known to be available--without restricting the ability to create proprietary protocols using the same API. regards, Ted --20cf303dd9d0f4db8f04af49f647 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Oct 14, 2011 at 2:41 PM, I=F1aki Baz Castillo
IMHO RTCweb (specially the JS API for managing media sessions) must be
designed in a way that it's possible for a developer to implement a
SIP client in JavaScript or another custom signaling protocol having a
gateway that maps it to/from SIP. This means that SIP features as
parallel forking, early media, conference... should be possible using
the RTCweb JavaScript API.

Do you think you could= support SIP identity with a javascript client?

=A0
So, assuming that there MUST NOT exist a *standard* signaling protocol
for federation in RTCweb, what is the purpose of speaking about
"federation"?

I don't think RFC 2119 MU= ST NOTs belong here.=A0

Understanding federation as a use case does= not mandate a "one ring to rule them all" approach to federation= .=A0 We could define one (as XMPP defines how different XMPP servers pass t= raffic among themselves).=A0 That would not mandate that all servers use it= .=A0 We could also choose not to define one, but if we support the use case= , we would have to understand what the minimal set of data that had to be p= ass over the protocols implementing the federation would be, what security = is required, and so on.


=A0
= Probably we all are speaking about the same concept, but
for me "federation" means a RTCweb server communicating with othe= r
RTCweb server. If Hadriel and you meant "RTCweb server communicating with a SIP network" then I repeat my first paragraph :)

So in order to accomplish with requirements of Hadriel we need to make
the RTCweb client stack and the RTCweb JavaScript API flexible enough
so all (or most of) the SIP features can be implemented in JavaScript
(I mean "audio/video features" since all the signaling can alread= y be
coded in different ways).

Hope it's more clear now.


Well, given that you don't believe in the nee= d for a protocol here at all, but only an incredibly flexible API, it seems= a bit unclear why you're not making these points on the W3C public mai= ling list for this activity.=A0

A truly well structured API here will imply, at least in my view, at le= ast a common model for negotiation and a common set of structured data to b= e passed via this javascript-implemented protocol.=A0 Doing that without de= fining a standard protocol is actually harder than doing it while defining = a protocol.=A0

I've heard the various arguments against defining one, but none of = them seems to stand up against the base fact that you can have a standard p= rotocol--known to be available--without restricting the ability to create p= roprietary protocols using the same API.=A0

regards,

Ted

=A0
--20cf303dd9d0f4db8f04af49f647-- From fluffy@cisco.com Fri Oct 14 20: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 CDCA021F8CA3 for ; Fri, 14 Oct 2011 20:09:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i0rahEzNWa4V for ; Fri, 14 Oct 2011 20:09:17 -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 530CA21F8CA0 for ; Fri, 14 Oct 2011 20:09:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=478; q=dns/txt; s=iport; t=1318648157; x=1319857757; h=from:content-transfer-encoding:subject:date:message-id: cc:to:mime-version; bh=QyLplz6ceRwitZkCO3FcZx62/uD09uv2c7bxWtsKMCw=; b=dfPszj7lp2fIkbcsXeMk2mFDoCc6q9fMK4pzSdGJJQpO7H1wHSAqqeQ6 1HfVeVw0qMpoPoUzbe6CbGofGJMKc1kudgU8oYxDmOH/5FF8oD+tfmio6 C7YKWP8Ep54nuumUD9NOUZXzol7uDHDsNpo6MSTIQl3qP+G7SWR4UZ8TN w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwEAJ74mE6rRDoG/2dsb2JhbABDqGeBBYFzFAEnOgWBPzSHZZhbAZ4thxhhBIgBi3aFKIxM X-IronPort-AV: E=Sophos;i="4.69,349,1315180800"; d="scan'208";a="8044318" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 15 Oct 2011 03:09: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 p9F39GKk032333; Sat, 15 Oct 2011 03:09:16 GMT From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 14 Oct 2011 21:09:16 -0600 Message-Id: <15B0E3AD-3086-499A-8E79-7AE58B3376C4@cisco.com> To: rtcweb@ietf.org, public-webrtc@w3.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: Jonathan Rosenberg Subject: [rtcweb] SDP Offer/Answer draft-jennings-rtcweb-signaling X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Oct 2011 03:09:17 -0000 Jonathan and I submitted a new draft on setting up media based on the = SDP Offer/Answer model. The ASCII flows are a bit hard to read so until = I update them, I recommend reading the PDF version at=20 http://tools.ietf.org/pdf/draft-jennings-rtcweb-signaling-00.pdf Clearly the draft is an early stage but we plan to revise it before the = deadline for the IETF 82. Love to get input - particularly on if this = looks like generally the right direction to go.=20 From ibc@aliax.net Sat Oct 15 01:37: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 9E23421F8B1A for ; Sat, 15 Oct 2011 01:37:06 -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.111, 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 c75AEA+5EXCj for ; Sat, 15 Oct 2011 01:37:06 -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 2471021F8B1F for ; Sat, 15 Oct 2011 01:37:04 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so1888053vcb.31 for ; Sat, 15 Oct 2011 01:37:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.117.81 with SMTP id p17mr896999vcq.41.1318667824288; Sat, 15 Oct 2011 01:37:04 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Sat, 15 Oct 2011 01:37:04 -0700 (PDT) In-Reply-To: <5748C5EE-48D1-4D30-B0D2-8703C45972EE@acmepacket.com> References: <92A553E5-107A-4987-A5F5-1F56FB5A7800@acmepacket.com> <5748C5EE-48D1-4D30-B0D2-8703C45972EE@acmepacket.com> Date: Sat, 15 Oct 2011 10:37:04 +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] Signalling, SDP, and the way we think about interconnecting RTCWEB 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, 15 Oct 2011 08:37:06 -0000 2011/10/15 Hadriel Kaplan : >> Ok, let me try again: >> >> IMHO RTCweb (specially the JS API for managing media sessions) must be >> designed in a way that it's possible for a developer to implement a >> SIP client in JavaScript or another custom signaling protocol having a >> gateway that maps it to/from SIP. This means that SIP features as >> parallel forking, early media, conference... should be possible using >> the RTCweb JavaScript API. I think we agree here :) > > Right I think we do agree - I was under the impression you were saying we= don't need to work with SIP. Humm, taking into account that I'm involved in SIP over WebSocket to make pure SIP (no protocol conversion) available for RTCweb... it would be annoying that I wouldn't like to interoperate with SIP :) --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Sat Oct 15 01: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 330C421F8B30 for ; Sat, 15 Oct 2011 01:43:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.571 X-Spam-Level: X-Spam-Status: No, score=-2.571 tagged_above=-999 required=5 tests=[AWL=0.106, 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 zRIZLao3td+9 for ; Sat, 15 Oct 2011 01:43:38 -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 7469421F8ACE for ; Sat, 15 Oct 2011 01:43:38 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so1890016vcb.31 for ; Sat, 15 Oct 2011 01:43:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.184.11 with SMTP id ci11mr964817vcb.76.1318668217880; Sat, 15 Oct 2011 01:43:37 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Sat, 15 Oct 2011 01:43:37 -0700 (PDT) In-Reply-To: References: <92A553E5-107A-4987-A5F5-1F56FB5A7800@acmepacket.com> Date: Sat, 15 Oct 2011 10:43:37 +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: "" Subject: Re: [rtcweb] Signalling, SDP, and the way we think about interconnecting RTCWEB 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, 15 Oct 2011 08:43:39 -0000 2011/10/15 Ted Hardie : > On Fri, Oct 14, 2011 at 2:41 PM, I=C3=B1aki Baz Castillo >> >> IMHO RTCweb (specially the JS API for managing media sessions) must be >> designed in a way that it's possible for a developer to implement a >> SIP client in JavaScript or another custom signaling protocol having a >> gateway that maps it to/from SIP. This means that SIP features as >> parallel forking, early media, conference... should be possible using >> the RTCweb JavaScript API. > > Do you think you could support SIP identity with a javascript client? Yes. The spec (RFC 4474) does NOT mandate that the SIP client MUST to have a list of CA's and verify the retrieved certificate by itself. A JavaScript client receiving an incoming INVITE with Identity and Identity-Info header could make a webservice call (i.e. using AJAX) and ask its web server to retrieve it and verify it in behalf of the client. And still that is SIP. So yes, I could support SIP Indentity with a JavaScript client. >> So, assuming that there MUST NOT exist a *standard* signaling protocol >> for federation in RTCweb, what is the purpose of speaking about >> "federation"? > > I don't think RFC 2119 MUST NOTs belong here. > > Understanding federation as a use case does not mandate a "one ring to ru= le > them all" approach to federation.=C2=A0 We could define one (as XMPP defi= nes how > different XMPP servers pass traffic among themselves).=C2=A0 That would n= ot > mandate that all servers use it.=C2=A0 We could also choose not to define= one, > but if we support the use case, we would have to understand what the mini= mal > set of data that had to be pass over the protocols implementing the > federation would be, what security is required, and so on. So just imagine that SIP is used for federation and make the requirements assuming that. >> Probably we all are speaking about the same concept, but >> for me "federation" means a RTCweb server communicating with other >> RTCweb server. If Hadriel and you meant "RTCweb server communicating >> with a SIP network" then I repeat my first paragraph :) >> >> So in order to accomplish with requirements of Hadriel we need to make >> the RTCweb client stack and the RTCweb JavaScript API flexible enough >> so all (or most of) the SIP features can be implemented in JavaScript >> (I mean "audio/video features" since all the signaling can already be >> coded in different ways). >> >> Hope it's more clear now. >> > > Well, given that you don't believe in the need for a protocol here at all= , A protocol is needed, of course. But not a *specific* protocol. > but only an incredibly flexible API, it seems a bit unclear why you're no= t > making these points on the W3C public mailing list for this activity. I expect such work must come once the requirements for such API are done in this WG. > A truly well structured API here will imply, at least in my view, at leas= t a > common model for negotiation and a common set of structured data to be > passed via this javascript-implemented protocol.=C2=A0 Doing that without > defining a standard protocol is actually harder than doing it while defin= ing > a protocol. > > I've heard the various arguments against defining one, but none of them > seems to stand up against the base fact that you can have a standard > protocol--known to be available--without restricting the ability to creat= e > proprietary protocols using the same API. There have been lot of arguments contrary to defining a "default signaling protocol". I don't want to repeat them again, but neither answer as if they don't exist. Regards. --=20 I=C3=B1aki Baz Castillo From neils@vipadia.com Sat Oct 15 02:12: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 3C74B21F8B4C for ; Sat, 15 Oct 2011 02:12:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.939 X-Spam-Level: X-Spam-Status: No, score=-2.939 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qUOXUZWI1Jcv for ; Sat, 15 Oct 2011 02:12:34 -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 910E821F8B18 for ; Sat, 15 Oct 2011 02:12:34 -0700 (PDT) Received: by iabn5 with SMTP id n5so3792703iab.31 for ; Sat, 15 Oct 2011 02:12:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.3.225 with SMTP id 33mr5006443ibo.87.1318669954074; Sat, 15 Oct 2011 02:12:34 -0700 (PDT) Sender: neils@vipadia.com Received: by 10.231.200.146 with HTTP; Sat, 15 Oct 2011 02:12:34 -0700 (PDT) In-Reply-To: References: <92A553E5-107A-4987-A5F5-1F56FB5A7800@acmepacket.com> Date: Sat, 15 Oct 2011 10:12:34 +0100 X-Google-Sender-Auth: 2qEcdlVXMniOtkIQYGzbDC3cQ1o Message-ID: From: Neil Stratford To: Ted Hardie Content-Type: multipart/alternative; boundary=00151773de8e304a6004af52c6eb Cc: "" Subject: Re: [rtcweb] Signalling, SDP, and the way we think about interconnecting RTCWEB 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, 15 Oct 2011 09:12:35 -0000 --00151773de8e304a6004af52c6eb Content-Type: text/plain; charset=ISO-8859-1 On Fri, Oct 14, 2011 at 11:41 PM, Ted Hardie wrote: > > A truly well structured API here will imply, at least in my view, at least > a common model for negotiation and a common set of structured data to be > passed via this javascript-implemented protocol. Doing that without > defining a standard protocol is actually harder than doing it while defining > a protocol. > I disagree that there is any requirement for a common model for negotiation. By all means ensure that the API enables the implementation of SIP and XMPP/Jingle, but to start with a single protocol and use that to define the API will undoubtedly lead to unnecessary limitations in the API. > I've heard the various arguments against defining one, but none of them > seems to stand up against the base fact that you can have a standard > protocol--known to be available--without restricting the ability to create > proprietary protocols using the same API. > Which is true, so long as you don't let your protocol choices leak into the API definition, which is unfortunately already the case with SDP. Neil --00151773de8e304a6004af52c6eb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Oct 14, 2011 at 11:41 PM, Ted Hardie <ted.ietf@gmail.com> wrote:
=

A truly well structured API here will i= mply, at least in my view, at least a common model for negotiation and a co= mmon set of structured data to be passed via this javascript-implemented pr= otocol.=A0 Doing that without defining a standard protocol is actually hard= er than doing it while defining a protocol.=A0

I disagree that there is any r= equirement for a common model for negotiation. By all means ensure that the= API enables the implementation of SIP and XMPP/Jingle, but to start with a= single protocol and use that to define the API will undoubtedly lead to un= necessary limitations in the API.
=A0
I've heard the various arguments against defining one, but none of t= hem seems to stand up against the base fact that you can have a standard pr= otocol--known to be available--without restricting the ability to create pr= oprietary protocols using the same API.=A0

Which is true, so long as you = don't let your protocol choices leak into the API definition, which is = unfortunately already the case with SDP.

Neil=A0
--00151773de8e304a6004af52c6eb-- From ibc@aliax.net Sat Oct 15 02: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 19E3D21F849E for ; Sat, 15 Oct 2011 02:20:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.101, 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 3gkqNtZxElSE for ; Sat, 15 Oct 2011 02:20:42 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5B33D21F8482 for ; Sat, 15 Oct 2011 02:20:42 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so1901806vcb.31 for ; Sat, 15 Oct 2011 02:20:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.35.34 with SMTP id e2mr12322964vdj.52.1318670441614; Sat, 15 Oct 2011 02:20:41 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Sat, 15 Oct 2011 02:20:41 -0700 (PDT) In-Reply-To: <15B0E3AD-3086-499A-8E79-7AE58B3376C4@cisco.com> References: <15B0E3AD-3086-499A-8E79-7AE58B3376C4@cisco.com> Date: Sat, 15 Oct 2011 11:20:41 +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: Jonathan Rosenberg , rtcweb@ietf.org, public-webrtc@w3.org Subject: Re: [rtcweb] SDP Offer/Answer draft-jennings-rtcweb-signaling X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Oct 2011 09:20:43 -0000 2011/10/15 Cullen Jennings : > Jonathan and I submitted a new draft on setting up media based on the SDP= Offer/Answer model. The ASCII flows are a bit hard to read so until I upda= te them, I recommend reading the PDF version at > > http://tools.ietf.org/pdf/draft-jennings-rtcweb-signaling-00.pdf > > Clearly the draft is an early stage but we plan to revise it before the d= eadline for the IETF 82. Love to get input - particularly on if this looks = like generally the right direction to go. Hi, thanks for this work. IMHO this is clearly the way to go, and the proposal that could make everyone happy. Let me just a comment: ----------------------------- 5.3.3. OK The OK message is used by the receiver of an ANSWER message to indicate that it has received the ANSWER message. It has no contents itself and is merely used to stop the retransmissions of the ANSWER ----------------------------- I wonder how much needed is the OK message taking into account that the transport will always be reliable. So, instead of retransmiting the ANSWER until an OK arrives, why not retransmit the OFFER until an ANSWER arrives and drop the OK message from the spec? Probably I miss something here as in the case the offered wants to signal ringing (a 180 in SIP) it conveys no media so there would be no ANSWER message for long time until the offered human user decides to accept or reject the incoming call. If so, please forget this comment :) 2) --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Sat Oct 15 02: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 E4E2E21F8B62 for ; Sat, 15 Oct 2011 02:46:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.097, 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 8drBpCi3cLTB for ; Sat, 15 Oct 2011 02:46:37 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4F22821F8B4C for ; Sat, 15 Oct 2011 02:46:27 -0700 (PDT) Received: by vws5 with SMTP id 5so1917296vws.31 for ; Sat, 15 Oct 2011 02:46:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.184.103 with SMTP id et7mr12618106vdc.35.1318671986666; Sat, 15 Oct 2011 02:46:26 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Sat, 15 Oct 2011 02:46:26 -0700 (PDT) In-Reply-To: References: <15B0E3AD-3086-499A-8E79-7AE58B3376C4@cisco.com> Date: Sat, 15 Oct 2011 11:46:26 +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: Jonathan Rosenberg , rtcweb@ietf.org, public-webrtc@w3.org Subject: Re: [rtcweb] SDP Offer/Answer draft-jennings-rtcweb-signaling X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Oct 2011 09:46:38 -0000 2011/10/15 I=C3=B1aki Baz Castillo : > ----------------------------- > 5.3.3. =C2=A0OK > The OK message is used by the receiver of an ANSWER message to > indicate that it has received the ANSWER message. It has no contents > itself and is merely used to stop the retransmissions of the ANSWER > ----------------------------- Hi, some other possible issues with the above ROAP OK message: ROAP OK message fits well with the ACK for 2XX in SIP. Let's assume that alice (pure SIP UA) and bob (RTCweb client) can intercommunicate via a RTCweb server implementing SIP over WebSocket (so JS in both browser is speaking real SIP rather than a custom protocol). NOTE: When alice sends a SIP INVITE to bob it arrives unchanged to bob. bob extracts the SDP and converts it into a ROAP OFFER. So I write it as "INVITE + ROAP OFFER" but it just means a common SIP INVITE with an SDP. case 1) SDP OFFER in the INVITE alice (SIP client) bob (RTCweb client) --------> INVITE + ROAP OFFER (F1) 200 OK + ROAP ANSWER (F2) <--------- (200 is lost in the network or server) 200 OK + ROAP ANSWER (F2) <--------- 200 OK + ROAP ANSWER (F2) <--------- ---------> ACK (F3) ISSUE: How would bob receive a ROAP OK message? Possible response: bob should generate it by itself upon receipt of the SIP ACK and signal it to the RTCweb stack in his browser. Am I right? case 2) SDP OFFER in the 200 OK alice (SIP client) bob (RTCweb client) --------> INVITE (no SDP) 200 OK + ROAP OFFER (F2) <--------- (200 is lost in the network or server) 200 OK + ROAP OFFER (F2) <--------- 200 OK + ROAP OFFER (F2) <--------- ---------> ACK + ROAP ANSWER (F3) ISSUE: In this case there is no SIP message to confirm the receipt of the ACK (which carries the SDP answer) so bob has no chance to send the ROAP OK message over the wire. Would it break the signaling? Possible response: there is no need at all in sending the ROAP OK message (if alice is a pure SIP client it does not need it, and if alice is a RTCweb client it should autogenerate it). ISSUE: Now imagine that alice is also a WEBrtc client. In this case (Case 2) when alice sends the ACK + ROAP ANSWER she will not receive a new SIP message (which could be mapped to ROAP OK) so, should alice signal the ROAP OK message to his RTCweb stack once the ACK + ROAP ANSWER is sent? Possible response: yes. Thanks a lot. --=20 I=C3=B1aki Baz Castillo From wolfgang.beck01@googlemail.com Sat Oct 15 02: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 7862B21F8B7C for ; Sat, 15 Oct 2011 02:59:49 -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 6iiSA1IyZpLs for ; Sat, 15 Oct 2011 02:59:48 -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 CEAE921F8B75 for ; Sat, 15 Oct 2011 02:59:48 -0700 (PDT) Received: by ggnv1 with SMTP id v1so19278ggn.31 for ; Sat, 15 Oct 2011 02:59:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=+RRptCd5W+CxYZjOU5WvItr+LRwaH93J1gC5zlEHeU4=; b=xj0gikEm9RDfpkq4FpCqOQ0eo1SlABywbGtUjb1dlq3Wj75OG1BV0dj1im1Z3P1akv 3QkQv5Wwpp9RyqnMGDH2vWa4M1QfXjZnpNFVGtKOa4ViS0G+wgw9dT/wbRrNThOy2zcu ZezGUEBPMw3CgE0vccztQqEkl6pOAfynQ4Zbw= MIME-Version: 1.0 Received: by 10.68.9.2 with SMTP id v2mr22998470pba.101.1318672787020; Sat, 15 Oct 2011 02:59:47 -0700 (PDT) Received: by 10.68.55.230 with HTTP; Sat, 15 Oct 2011 02:59:46 -0700 (PDT) In-Reply-To: References: <92A553E5-107A-4987-A5F5-1F56FB5A7800@acmepacket.com> Date: Sat, 15 Oct 2011 11:59:46 +0200 Message-ID: From: Wolfgang To: "" Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [rtcweb] Signalling, SDP, and the way we think about interconnecting RTCWEB 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, 15 Oct 2011 09:59:49 -0000 First, the draft is not about SIP vs XMPP vs xy. All those protocols try to be general and necessarily suffer from feature creep and complexity. SIP once started as a much simpler alternative to H.323 and look where we are now. XMPP has defined more than 300 extensions. But I think there is not much disagreement about the call signaling part. The question is if we can get rid of SDP as well. If both sides *implicitly* know what codec parameters they are going to use there is no longer the need to negotiate them. If caller and callee use the same RTCWEB client this should be doable. The RTCWEB server may need some hints about the browsers capabilities -- eg does it support a camera, is the bandwidth limited -- to provide it with an applicable RTCWEB client. But we don't need a way to convey and negotiate dozens of codec parameters. If we insist on interoperability between RTCWEB client A and RTCWEB client B we will end up re-inventing SDP and/or SIP. And of course we will have to keep RTCWEB and SDP standardization in sync. Wolfgang From harald@alvestrand.no Sat Oct 15 04: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 E0E9921F8B48 for ; Sat, 15 Oct 2011 04:29:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rb8XyBCgIjx6 for ; Sat, 15 Oct 2011 04:29:08 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 133E721F8B3F for ; Sat, 15 Oct 2011 04:29:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9AD8939E0BF for ; Sat, 15 Oct 2011 13:29:06 +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 dN6O6Hn5Gmap for ; Sat, 15 Oct 2011 13:29:05 +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 22D1239E051 for ; Sat, 15 Oct 2011 13:29:05 +0200 (CEST) Message-ID: <4E996E80.6070500@alvestrand.no> Date: Sat, 15 Oct 2011 13:29:04 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110922 Thunderbird/3.1.15 MIME-Version: 1.0 To: rtcweb@ietf.org References: <92A553E5-107A-4987-A5F5-1F56FB5A7800@acmepacket.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Signalling, SDP, and the way we think about interconnecting RTCWEB 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, 15 Oct 2011 11:29:09 -0000 On 10/15/2011 11:59 AM, Wolfgang wrote: > First, the draft is not about SIP vs XMPP vs xy. All those protocols > try to be general and necessarily suffer from feature creep and > complexity. SIP once started as a much simpler alternative to H.323 > and look where we are now. XMPP has defined more than 300 extensions. > But I think there is not much disagreement about the call signaling > part. > > The question is if we can get rid of SDP as well. If both sides > *implicitly* know what codec parameters they are going to use there is > no longer the need to negotiate them. If caller and callee use the > same RTCWEB client this should be doable. The RTCWEB server may need > some hints about the browsers capabilities -- eg does it support a > camera, is the bandwidth limited -- to provide it with an applicable > RTCWEB client. But we don't need a way to convey and negotiate dozens > of codec parameters. Remember that: a) codecs are (currently) part of the platform, not of the application. b) one of our aims for negotiation is that if application X is deployed in browsers A and B, and both browser A and B support a "best codec" W that was created *after* X was last updated, then the codec W should be used. Given the last point - the app *cannot* "implicitly" what codec will be used. And given that it doesn't know the codec, it can't know the parameters either. (that said... I'm all in favour of fewer parameters. The RTP format for VP8 that we're in the process of finishing has zero parameters. I hope it will remain that way.) > If we insist on interoperability between RTCWEB client A and RTCWEB > client B we will end up re-inventing SDP and/or SIP. And of course we > will have to keep RTCWEB and SDP standardization in sync. We absolutely insist on interoperability between browser A and browser B, if both are runnning applications that want to communicate. Whether RTCWEB client A wants to communicate with RTCWEB client B should be entirely up to them. We're here to make it possible, not here to make it mandatory. > > Wolfgang > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From neils@vipadia.com Sat Oct 15 05:08: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 EACF521F8B2B for ; Sat, 15 Oct 2011 05:08:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.946 X-Spam-Level: X-Spam-Status: No, score=-2.946 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pu4pfcxLzZpw for ; Sat, 15 Oct 2011 05:08: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 DCE2521F8B1A for ; Sat, 15 Oct 2011 05:08:42 -0700 (PDT) Received: by iabn5 with SMTP id n5so3963456iab.31 for ; Sat, 15 Oct 2011 05:08:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.24.96 with SMTP id u32mr5298360ibb.61.1318680520906; Sat, 15 Oct 2011 05:08:40 -0700 (PDT) Sender: neils@vipadia.com Received: by 10.231.200.146 with HTTP; Sat, 15 Oct 2011 05:08:40 -0700 (PDT) In-Reply-To: <4E996E80.6070500@alvestrand.no> References: <92A553E5-107A-4987-A5F5-1F56FB5A7800@acmepacket.com> <4E996E80.6070500@alvestrand.no> Date: Sat, 15 Oct 2011 13:08:40 +0100 X-Google-Sender-Auth: s75pphGUVkoZqt4RcbfdoY2oYpg Message-ID: From: Neil Stratford To: Harald Alvestrand Content-Type: multipart/alternative; boundary=0015177414280557bc04af553cd6 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Signalling, SDP, and the way we think about interconnecting RTCWEB 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, 15 Oct 2011 12:08:47 -0000 --0015177414280557bc04af553cd6 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Oct 15, 2011 at 12:29 PM, Harald Alvestrand wrote: > >> Remember that: > a) codecs are (currently) part of the platform, not of the application. > b) one of our aims for negotiation is that if application X is deployed in > browsers A and B, and both browser A and B support a "best codec" W that was > created *after* X was last updated, then the codec W should be used. > > Given the last point - the app *cannot* "implicitly" what codec will be > used. And given that it doesn't know the codec, it can't know the parameters > either. > > (that said... I'm all in favour of fewer parameters. The RTP format for VP8 > that we're in the process of finishing has zero parameters. I hope it will > remain that way. Can we work around this issue by delegating parameter negotiation to the codec itself? Each codec in the codec capability list could present (at a minimum) it's name, priority and a codec specific parameter negotiation function. We can then delegate the complicated codec specific details (when necessary) without needing any advance knowledge in the javascript application. We would need to standardise the parameter lists such that different codec implementations can interop, but that is the same with SDP. Neil --0015177414280557bc04af553cd6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sat, Oct 15, 2011 at 12:29 PM, Harald Alvestrand <<= a href=3D"mailto:harald@alvestrand.no">harald@alvestrand.no> = wrote:

Remember that:
a) codecs are (currently) part of the platform, not of the application.
b) one of our aims for negotiation is that if application X is deployed in = browsers A and B, and both browser A and B support a "best codec"= W that was created *after* X was last updated, then the codec W should be = used.

Given the last point - the app *cannot* "implicitly" what codec w= ill be used. And given that it doesn't know the codec, it can't kno= w the parameters either.

(that said... I'm all in favour of fewer parameters. The RTP format for= VP8 that we're in the process of finishing has zero parameters. I hope= it will remain that way.

Can we work aroun= d this issue by delegating parameter negotiation to the codec itself? Each = codec in the codec capability list could present (at a minimum) it's na= me, priority and a codec specific parameter negotiation function. We can th= en delegate the complicated codec specific details (when necessary) without= needing any advance knowledge in the javascript application. We would need= to standardise the parameter lists such that different codec implementatio= ns can interop, but that is the same with SDP.

Neil=A0

--0015177414280557bc04af553cd6-- From wolfgang.beck01@googlemail.com Sat Oct 15 05: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 359EA21F8AA8 for ; Sat, 15 Oct 2011 05:58:26 -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 8+dw+EZTptxp for ; Sat, 15 Oct 2011 05:58:25 -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 BFF2121F8A7D for ; Sat, 15 Oct 2011 05:58:20 -0700 (PDT) Received: by pzk34 with SMTP id 34so1736169pzk.9 for ; Sat, 15 Oct 2011 05:58:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZI6xc/kOoZcBjgjCoVxrni3uI/n42TW9AjoPj2hy/pY=; b=qKZs8FGGoYYBG0ia+FmbM8FCb6HdDFtvM3kaVjIG8eeyFAJ4xWQhPQtmuFIV1RX15q LWdAmh+AXWSniVdUVD1oM+EvjlljNO/jmdamsMlCW/A5NRZgSGlOFX38UGX+WkA722Cg OGFAjKRRpAv6QT8w7eX4eDD1XnyDdp+8EJlMY= MIME-Version: 1.0 Received: by 10.68.39.231 with SMTP id s7mr16167907pbk.33.1318683500416; Sat, 15 Oct 2011 05:58:20 -0700 (PDT) Received: by 10.68.55.230 with HTTP; Sat, 15 Oct 2011 05:58:20 -0700 (PDT) In-Reply-To: References: <92A553E5-107A-4987-A5F5-1F56FB5A7800@acmepacket.com> <4E996E80.6070500@alvestrand.no> Date: Sat, 15 Oct 2011 14:58:20 +0200 Message-ID: From: Wolfgang To: Neil Stratford Content-Type: text/plain; charset=ISO-8859-1 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Signalling, SDP, and the way we think about interconnecting RTCWEB 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, 15 Oct 2011 12:58:26 -0000 On Sat, Oct 15, 2011 at 2:08 PM, Neil Stratford wrote: > On Sat, Oct 15, 2011 at 12:29 PM, Harald Alvestrand > wrote: >> b) one of our aims for negotiation is that if application X is deployed in >> browsers A and B, and both browser A and B support a "best codec" W that was >> created *after* X was last updated, then the codec W should be used. >> >> Given the last point - the app *cannot* "implicitly" what codec will be >> used. And given that it doesn't know the codec, it can't know the parameters >> either. Is this goal worth all the complexity introduced with codec negotiation? >> (that said... I'm all in favour of fewer parameters. The RTP format for >> VP8 that we're in the process of finishing has zero parameters. I hope it >> will remain that way. That's nice if it really stays that way. MPEG2 had this, too. But then people started using it in ways that haven't been anticipated and it turned into a horrible mess. >> We absolutely insist on interoperability between browser A and browser B, if both are runnning applications that want >> to communicate. No disagreement here. >> Whether RTCWEB client A wants to communicate with RTCWEB client B should be entirely up to them. We're here >> to make it possible, not here to make it mandatory. What does this requirement cost us in terms of complexity? If we have to replicate SIP's and SDP's functionalities, it might be not worth it. Neil Stratford wrote: > Can we work around this issue by delegating parameter negotiation to the > codec itself? Each codec in the codec capability list could present (at a > minimum) it's name, priority and a codec specific parameter negotiation > function. We can then delegate the complicated codec specific details (when > necessary) without needing any advance knowledge in the javascript > application. We would need to standardise the parameter lists such that > different codec implementations can interop, but that is the same with SDP. Do you mean moving codec parameter negotiation into the RTP stream? It would require transcoding if your media stream leaves RTCWEB. And you are just moving the complexity to a different part of the system.. Wolfgang From harald@alvestrand.no Sat Oct 15 06:44: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 A92CE21F8B4A for ; Sat, 15 Oct 2011 06:44:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1+llVb06gjUZ for ; Sat, 15 Oct 2011 06:44:12 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id C11E521F8B47 for ; Sat, 15 Oct 2011 06:44:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3953639E0CD; Sat, 15 Oct 2011 15:44: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 XIAdPdGkeFAy; Sat, 15 Oct 2011 15:44: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 CB73839E051; Sat, 15 Oct 2011 15:44:07 +0200 (CEST) Message-ID: <4E998E27.9080104@alvestrand.no> Date: Sat, 15 Oct 2011 15:44:07 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110922 Thunderbird/3.1.15 MIME-Version: 1.0 To: Neil Stratford References: <92A553E5-107A-4987-A5F5-1F56FB5A7800@acmepacket.com> <4E996E80.6070500@alvestrand.no> In-Reply-To: Content-Type: multipart/alternative; boundary="------------000300070508000402010403" Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Signalling, SDP, and the way we think about interconnecting RTCWEB 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, 15 Oct 2011 13:44:12 -0000 This is a multi-part message in MIME format. --------------000300070508000402010403 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 10/15/2011 02:08 PM, Neil Stratford wrote: > On Sat, Oct 15, 2011 at 12:29 PM, Harald Alvestrand > > wrote: > > > Remember that: > a) codecs are (currently) part of the platform, not of the > application. > b) one of our aims for negotiation is that if application X is > deployed in browsers A and B, and both browser A and B support a > "best codec" W that was created *after* X was last updated, then > the codec W should be used. > > Given the last point - the app *cannot* "implicitly" what codec > will be used. And given that it doesn't know the codec, it can't > know the parameters either. > > (that said... I'm all in favour of fewer parameters. The RTP > format for VP8 that we're in the process of finishing has zero > parameters. I hope it will remain that way. > > > Can we work around this issue by delegating parameter negotiation to > the codec itself? Each codec in the codec capability list could > present (at a minimum) it's name, priority and a codec specific > parameter negotiation function. We can then delegate the complicated > codec specific details (when necessary) without needing any advance > knowledge in the javascript application. We would need to standardise > the parameter lists such that different codec implementations can > interop, but that is the same with SDP. Yes, maybe we could do that. But would it make a difference? SDP is (among other things) exactly such a parameter list standardisation, each and every codec deployed with RTP tends to publish a specification on how to encode those parameter lists in SDP, and each and every video engine implementing those codecs tends to have code in it that parses that SDP and does the negotiation on that basis. Are we reinventing another encoding format for SDP again? --------------000300070508000402010403 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 10/15/2011 02:08 PM, Neil Stratford wrote:
On Sat, Oct 15, 2011 at 12:29 PM, Harald Alvestrand <harald@alvestrand.no> wrote:

Remember that:
a) codecs are (currently) part of the platform, not of the application.
b) one of our aims for negotiation is that if application X is deployed in browsers A and B, and both browser A and B support a "best codec" W that was created *after* X was last updated, then the codec W should be used.

Given the last point - the app *cannot* "implicitly" what codec will be used. And given that it doesn't know the codec, it can't know the parameters either.

(that said... I'm all in favour of fewer parameters. The RTP format for VP8 that we're in the process of finishing has zero parameters. I hope it will remain that way.

Can we work around this issue by delegating parameter negotiation to the codec itself? Each codec in the codec capability list could present (at a minimum) it's name, priority and a codec specific parameter negotiation function. We can then delegate the complicated codec specific details (when necessary) without needing any advance knowledge in the javascript application. We would need to standardise the parameter lists such that different codec implementations can interop, but that is the same with SDP.
Yes, maybe we could do that. But would it make a difference?

SDP is (among other things) exactly such a parameter list standardisation, each and every codec deployed with RTP tends to publish a specification on how to encode those parameter lists in SDP, and each and every video engine implementing those codecs tends to have code in it that parses that SDP and does the negotiation on that basis.

Are we reinventing another encoding format for SDP again?


--------------000300070508000402010403-- From neils@vipadia.com Sat Oct 15 07: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 2F7C821F84A9 for ; Sat, 15 Oct 2011 07:10:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.951 X-Spam-Level: X-Spam-Status: No, score=-2.951 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VyeJAbGXEMlg for ; Sat, 15 Oct 2011 07:10: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 1023621F84A8 for ; Sat, 15 Oct 2011 07:10:42 -0700 (PDT) Received: by iabn5 with SMTP id n5so4070750iab.31 for ; Sat, 15 Oct 2011 07:10:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.24.96 with SMTP id u32mr5485572ibb.61.1318687834031; Sat, 15 Oct 2011 07:10:34 -0700 (PDT) Sender: neils@vipadia.com Received: by 10.231.200.146 with HTTP; Sat, 15 Oct 2011 07:10:33 -0700 (PDT) In-Reply-To: <4E998E27.9080104@alvestrand.no> References: <92A553E5-107A-4987-A5F5-1F56FB5A7800@acmepacket.com> <4E996E80.6070500@alvestrand.no> <4E998E27.9080104@alvestrand.no> Date: Sat, 15 Oct 2011 15:10:33 +0100 X-Google-Sender-Auth: 9AeQDpW_jwjjjnhsPoqnyBLzNXo Message-ID: From: Neil Stratford To: Harald Alvestrand Content-Type: multipart/alternative; boundary=001517741428eac4c204af56eff4 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Signalling, SDP, and the way we think about interconnecting RTCWEB 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, 15 Oct 2011 14:10:45 -0000 --001517741428eac4c204af56eff4 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Oct 15, 2011 at 2:44 PM, Harald Alvestrand wrote: > ** > On 10/15/2011 02:08 PM, Neil Stratford wrote: > > On Sat, Oct 15, 2011 at 12:29 PM, Harald Alvestrand wrote: > >> >>> Remember that: >> a) codecs are (currently) part of the platform, not of the application. >> b) one of our aims for negotiation is that if application X is deployed in >> browsers A and B, and both browser A and B support a "best codec" W that was >> created *after* X was last updated, then the codec W should be used. >> >> Given the last point - the app *cannot* "implicitly" what codec will be >> used. And given that it doesn't know the codec, it can't know the parameters >> either. >> >> (that said... I'm all in favour of fewer parameters. The RTP format for >> VP8 that we're in the process of finishing has zero parameters. I hope it >> will remain that way. > > > Can we work around this issue by delegating parameter negotiation to the > codec itself? Each codec in the codec capability list could present (at a > minimum) it's name, priority and a codec specific parameter negotiation > function. We can then delegate the complicated codec specific details (when > necessary) without needing any advance knowledge in the javascript > application. We would need to standardise the parameter lists such that > different codec implementations can interop, but that is the same with SDP. > > Yes, maybe we could do that. But would it make a difference? > > SDP is (among other things) exactly such a parameter list standardisation, > each and every codec deployed with RTP tends to publish a specification on > how to encode those parameter lists in SDP, and each and every video engine > implementing those codecs tends to have code in it that parses that SDP and > does the negotiation on that basis. > > Are we reinventing another encoding format for SDP again? > I guess there are a couple of points here: 1. Yes, we are re-inventing SDP, but at a lower level, so we leave it up to the developer to use SDP, or something else if they prefer. 2. I fully support that we need to interop with SIP, and that we should make that a simple thing to do. However, I also think that rtcweb will rapidly become the dominant RTC platform due to the pervasiveness of browsers. Codec developers will be targeting rtcweb as a primary platform, especially if we make it easy to download and deploy new codecs. Neil --001517741428eac4c204af56eff4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sat, Oct 15, 2011 at 2:44 PM, Harald Alvestrand <harald@alvestrand.no> w= rote:
=20 =20 =20
On 10/15/2011 02:08 PM, Neil Stratford wrote:
On Sat, Oct 15, 2011 at 12:29 PM, Harald Alve= strand <harald@alvestrand.no> wrote:

Remember that:
a) codecs are (currently) part of the platform, not of the application.
b) one of our aims for negotiation is that if application X is deployed in browsers A and B, and both browser A and B support a "best codec" W that was created *after* X was last up= dated, then the codec W should be used.

Given the last point - the app *cannot* "implicitly" wh= at codec will be used. And given that it doesn't know the codec, it can't know the parameters either.

(that said... I'm all in favour of fewer parameters. The RTP format for VP8 that we're in the process of finishing has zer= o parameters. I hope it will remain that way.

Can we work around this issue by delegating parameter negotiation to the codec itself? Each codec in the codec capability list could present (at a minimum) it's name, priority and a codec specific parameter negotiation function. We can then delegate the complicated codec specific details (when necessary) without needing any advance knowledge in the javascript application. We would need to standardise the parameter lists such that different codec implementations can interop, but that is the same with SDP.
Yes, maybe we could do that. But would it make a difference?

SDP is (among other things) exactly such a parameter list standardisation, each and every codec deployed with RTP tends to publish a specification on how to encode those parameter lists in SDP, and each and every video engine implementing those codecs tends to have code in it that parses that SDP and does the negotiation on that basis.

Are we reinventing another encoding format for SDP again?

I guess there are a couple of points here:=A0<= /div>

1. Yes, we are re-inventing SDP, but at a lower le= vel, so we leave it up to the developer to use SDP, or something else if th= ey prefer.=A0

2. I fully support that we need to interop with SIP, and tha= t we should make that a simple thing to do. However, I also think that rtcw= eb will rapidly become the dominant RTC platform due to the pervasiveness o= f browsers. Codec developers will be targeting rtcweb as a primary platform= , especially if we make it easy to download and deploy new codecs.

Neil
--001517741428eac4c204af56eff4-- From radhika.r.roy.civ@mail.mil Sat Oct 15 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 1567B21F862F for ; Sat, 15 Oct 2011 08:18:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.421 X-Spam-Level: X-Spam-Status: No, score=-2.421 tagged_above=-999 required=5 tests=[AWL=0.178, 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 GNM6nWuXIV3M for ; Sat, 15 Oct 2011 08:18:04 -0700 (PDT) Received: from edge-cols.mail.mil (edge-cols.mail.mil [131.64.100.9]) by ietfa.amsl.com (Postfix) with ESMTP id 652AF21F861E for ; Sat, 15 Oct 2011 08:18:03 -0700 (PDT) Received: from UCOLHP2Z.easf.csd.disa.mil (131.64.100.147) by ucolhp2w.easf.csd.disa.mil (131.64.100.9) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sat, 15 Oct 2011 10:17:56 -0500 Received: from UCOLHP4D.easf.csd.disa.mil ([169.254.9.97]) by UCOLHP2Z.easf.csd.disa.mil ([169.254.99.133]) with mapi id 14.01.0323.003; Sat, 15 Oct 2011 10:17:55 -0500 From: "Roy, Radhika R USA CIV (US)" To: Neil Stratford , Harald Alvestrand Thread-Topic: [rtcweb] Signalling, SDP, and the way we think about interconnecting RTCWEB applications Thread-Index: AQHMizM3ErWhbt2SxUOIUHEWWONYYpV9g+Lg Date: Sat, 15 Oct 2011 15:17:54 +0000 Message-ID: <8486C8728176924BAF5BDB2F7D7EEDDF3E0906A2@ucolhp4d.easf.csd.disa.mil> References: <92A553E5-107A-4987-A5F5-1F56FB5A7800@acmepacket.com> <4E996E80.6070500@alvestrand.no> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.64.77.7] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Signalling, SDP, and the way we think about interconnecting RTCWEB 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, 15 Oct 2011 15:18:05 -0000 Folks: A given codec type in known, its parameters should also be known per its sp= ecifications. So, it the negotiations between codec-types only. You can see how SDP is used for negotiations between different codec types = using SIP. Similar mechanisms can also be used here. Radhika -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Neil Stratford Sent: Saturday, October 15, 2011 8:09 AM To: Harald Alvestrand Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Signalling, SDP, and the way we think about interconn= ecting RTCWEB applications On Sat, Oct 15, 2011 at 12:29 PM, Harald Alvestrand = wrote: Remember that: a) codecs are (currently) part of the platform, not of the application. b) one of our aims for negotiation is that if application X is deployed in= browsers A and B, and both browser A and B support a "best codec" W that w= as created *after* X was last updated, then the codec W should be used. =09 Given the last point - the app *cannot* "implicitly" what codec will be us= ed. And given that it doesn't know the codec, it can't know the parameters = either. =09 (that said... I'm all in favour of fewer parameters. The RTP format for VP= 8 that we're in the process of finishing has zero parameters. I hope it wil= l remain that way. Can we work around this issue by delegating parameter negotiation to the co= dec itself? Each codec in the codec capability list could present (at a min= imum) it's name, priority and a codec specific parameter negotiation functi= on. We can then delegate the complicated codec specific details (when neces= sary) without needing any advance knowledge in the javascript application. = We would need to standardise the parameter lists such that different codec = implementations can interop, but that is the same with SDP. Neil=20 From stewe@stewe.org Sat Oct 15 11: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 39AED21F8AB8 for ; Sat, 15 Oct 2011 11:42:47 -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=[BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 70VJTdjH1+yi for ; Sat, 15 Oct 2011 11:42:46 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by ietfa.amsl.com (Postfix) with ESMTP id 2856121F88B7 for ; Sat, 15 Oct 2011 11:42:43 -0700 (PDT) Received: from [192.168.1.64] (unverified [71.202.147.60]) by stewe.org (SurgeMail 3.9e) with ESMTP id 49913-1743317 for multiple; Sat, 15 Oct 2011 20:42:41 +0200 User-Agent: Microsoft-MacOutlook/14.13.0.110805 Date: Sat, 15 Oct 2011 11:42:39 -0400 From: Stephan Wenger To: Harald Alvestrand , Message-ID: Thread-Topic: [rtcweb] Signalling, SDP, and the way we think about interconnecting RTCWEB applications In-Reply-To: <4E996E80.6070500@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] Signalling, SDP, and the way we think about interconnecting RTCWEB 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, 15 Oct 2011 18:42:47 -0000 Hi Harald, On 10.15.2011 07:29 , "Harald Alvestrand" wrote: > >Given the last point - the app *cannot* "implicitly" what codec will be >used. And given that it doesn't know the codec, it can't know the >parameters either. > >(that said... I'm all in favour of fewer parameters. The RTP format for >VP8 that we're in the process of finishing has zero parameters. I hope >it will remain that way.) I would be surprised if that were the case. As the very minimum, I would suspect that you need some form of upper bound for computational decoder complexity (measured in pixel numbers per second, framerate/picture size combination, or whatever). It doest make sense that two systems agree on VP8, and the receiver cannot rdecode the sender's bitstream because the receiver is a cheap cellphone and the sender is a desktop PC which likes to send 1080p. Let me also note that the VP8 payload spec (at least the current public version) has a number of "optional" mechanisms, which you would want to negotiate, no? Stephan From harald@alvestrand.no Sat Oct 15 13: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 093A121F8520 for ; Sat, 15 Oct 2011 13:15:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SBtFbGziDVBa for ; Sat, 15 Oct 2011 13:15:20 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id EC28421F848A for ; Sat, 15 Oct 2011 13:15:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2233439E0CD; Sat, 15 Oct 2011 22:15:18 +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 wEhdOIJd6t8A; Sat, 15 Oct 2011 22:15:17 +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 3756F39E0BF; Sat, 15 Oct 2011 22:15:17 +0200 (CEST) Message-ID: <4E99E9D4.5020400@alvestrand.no> Date: Sat, 15 Oct 2011 22:15:16 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110922 Thunderbird/3.1.15 MIME-Version: 1.0 To: Stephan Wenger References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rtcweb@ietf.org Subject: [rtcweb] VP8 and parameters (Re: Signalling, SDP, and the way we think about interconnecting RTCWEB 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, 15 Oct 2011 20:15:21 -0000 On 10/15/2011 05:42 PM, Stephan Wenger wrote: > Hi Harald, > > On 10.15.2011 07:29 , "Harald Alvestrand" wrote: > >> Given the last point - the app *cannot* "implicitly" what codec will be >> used. And given that it doesn't know the codec, it can't know the >> parameters either. >> >> (that said... I'm all in favour of fewer parameters. The RTP format for >> VP8 that we're in the process of finishing has zero parameters. I hope >> it will remain that way.) > I would be surprised if that were the case. As the very minimum, I would > suspect that you need some form of upper bound for computational decoder > complexity (measured in pixel numbers per second, framerate/picture size > combination, or whatever). It doest make sense that two systems agree on > VP8, and the receiver cannot rdecode the sender's bitstream because the > receiver is a cheap cellphone and the sender is a desktop PC which likes > to send 1080p. Let me also note that the VP8 payload spec (at least the > current public version) has a number of "optional" mechanisms, which you > would want to negotiate, no? (changing the subject again) This is a discussion more relevant for the payload wg.... As far as I understand the current spec, the features are optional in the sense that the sender can choose to use them or not; the recipient has to be able to decode the stream, no matter what features are used. We've got generic features in SDP to negotiate bitrate, resolution and some other parameters in a codec-independent fashion, and the RTP/AVPF profile has things like TMMBR to tamp down the sending rate even more; we'll see if those prove adequate to protect low-powered recipients from high-powered senders. If not, I guess the specs will have to grow. From dzonatas@gmail.com Sat Oct 15 15:46: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 E93E521F8558 for ; Sat, 15 Oct 2011 15:46:14 -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 h34nWdyJVPcI for ; Sat, 15 Oct 2011 15:46:14 -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 51C5921F8551 for ; Sat, 15 Oct 2011 15:46:14 -0700 (PDT) Received: by vws5 with SMTP id 5so2180521vws.31 for ; Sat, 15 Oct 2011 15:46:13 -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 :content-type; bh=6XCk656T+T2IcutWUxsoa2mOoXDOoGY8UtCG+e+dRLs=; b=iJn+2taODshL9iZkb+iYWSJFudCT8GHXkror3qdPn+R+ZrKjnTpR5pBDgmRd+DbJhE xAfquRNp8DeVvjbS7AsXmi2YpJRYB5Ix5sz4M2ri/QcIt1L6evK02b7JGmyG+EYsnKLo NVpXGOxUN9g0uAuLb4YfFhQA65z1aexAq322A= MIME-Version: 1.0 Received: by 10.52.34.100 with SMTP id y4mr14266640vdi.66.1318718772312; Sat, 15 Oct 2011 15:46:12 -0700 (PDT) Received: by 10.52.107.202 with HTTP; Sat, 15 Oct 2011 15:46:12 -0700 (PDT) In-Reply-To: References: Date: Sat, 15 Oct 2011 15:46:12 -0700 Message-ID: From: Dzonatas Sol To: rtcweb@ietf.org Content-Type: multipart/alternative; boundary=20cf3079bb06fb7c4104af5e237d Subject: Re: [rtcweb] Signalling, SDP, and the way we think about interconnecting RTCWEB 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, 15 Oct 2011 22:46:15 -0000 --20cf3079bb06fb7c4104af5e237d Content-Type: text/plain; charset=ISO-8859-1 On Fri, Oct 14, 2011 at 8:24 AM, wrote: > The interconnection trapezoid we inherited from SIP has become a sort of > Gordian knot. If we could avoid RTCWEB server from having to speak to each > other at all, we could avoid re-inventing SDP syntax and/or semantics, at > least to some degree. > > https://datatracker.ietf.org/doc/draft-beck-rtcweb-alt-ic/ investigates > how we could get rid of server-to-server communication and the associated > problems by using 3rd party authentication/authorization. The VWRAP WG > discussed something similar with regard virtual world systems > interconnection. > There are always "border crossing" issues, which often exploits encryption as useless even if it works. Main thing is that assets should not be cached server-to-server unless those servers tether those assets, yet imagine the transient optimizations possible. --20cf3079bb06fb7c4104af5e237d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On = Fri, Oct 14, 2011 at 8:24 AM, <BeckW@telekom.de> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"> The interconnection trapezoid we inherited from SIP has become a sort of Go= rdian knot. If we could avoid RTCWEB server from having to speak to each ot= her at all, we could avoid re-inventing SDP syntax and/or semantics, at lea= st to some degree.

https://datatracker.ietf.org/doc/draft-beck-rtcweb-alt-ic/ investigates how we could get rid of server-to-server communication and t= he associated problems by using 3rd party authentication/authorization. The= VWRAP WG discussed something similar with regard virtual world systems int= erconnection.





--20cf3079bb06fb7c4104af5e237d-- From wolfgang.beck01@googlemail.com Sun Oct 16 01: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 C540B21F8678 for ; Sun, 16 Oct 2011 01:39:29 -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 rPqFtxNArBd6 for ; Sun, 16 Oct 2011 01:39:29 -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 3EFE421F8783 for ; Sun, 16 Oct 2011 01:39:29 -0700 (PDT) Received: by iabn5 with SMTP id n5so5046381iab.31 for ; Sun, 16 Oct 2011 01:39:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=sOXyr9FD1nVvixq4iWI/IapAcGeZfZ6EOvHwIBdHtM0=; b=lm1u4tQe91vMQw4fQvRDGVvz7zf45UhAoKtr+PBJPISIiLHVEmxpqcLH5qiTZG4/vz 4TsxqU7p+0Ku/rxr6ivYYpaf6tFbTOIDtiPFXYW5YAsFafcwXh148lg1BWOEykVNVh/U aSixjsGno+8q24FWqd4T/b36jz09jP6I1vN2c= MIME-Version: 1.0 Received: by 10.68.73.73 with SMTP id j9mr29401759pbv.67.1318754367557; Sun, 16 Oct 2011 01:39:27 -0700 (PDT) Received: by 10.68.55.230 with HTTP; Sun, 16 Oct 2011 01:39:27 -0700 (PDT) In-Reply-To: References: <92A553E5-107A-4987-A5F5-1F56FB5A7800@acmepacket.com> <4E996E80.6070500@alvestrand.no> <8486C8728176924BAF5BDB2F7D7EEDDF3E0906A2@ucolhp4d.easf.csd.disa.mil> Date: Sun, 16 Oct 2011 10:39:27 +0200 Message-ID: From: Wolfgang To: "" Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [rtcweb] Signalling, SDP, and the way we think about interconnecting RTCWEB 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: Sun, 16 Oct 2011 08:39:29 -0000 On Sat, Oct 15, 2011 at 5:17 PM, Roy, Radhika R USA CIV (US) wrote: > Folks: > > A given codec type in known, its parameters should also be known per its specifications. So, it the negotiations between codec-types only. > > You can see how SDP is used for negotiations between different codec types using SIP. Similar mechanisms can also be used here. > > Radhika So why do we transport some codec parameters outside the media stream at all? The called device might need information about the media stream before establishing it. The server might need access to codec parameters to forward the call to the best destination: imagine a user with two RTCWEB clients, one only supports only low resolution video, the other one full HD. A high resolution video call comes in. How should the server select the called client if it doesn't have access to the media stream which carries the resolution parameters? In my model the server would know what type of call was set up as it always controls both ends of the call. If some other application controls the calling party, you need some standardized protocol like SDP. Wolfgang From dzonatas@gmail.com Sun Oct 16 08:19: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 0D54221F8A4E for ; Sun, 16 Oct 2011 08:19:36 -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 rlFLuI0uHs11 for ; Sun, 16 Oct 2011 08:19:35 -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 4FA6D21F8A71 for ; Sun, 16 Oct 2011 08:19:35 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so2427574vcb.31 for ; Sun, 16 Oct 2011 08:19: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 :content-type; bh=RAv/YoHhoYJoVeOZmi213aQAk5mrLUsq+tGG/wIdH1w=; b=ubSVdjQaZrL9tvGEW8HVN/sRpAxV2riDCbJ9PLURM2aZEF5rjYx9nYgrAqXDvQ4/xn M3xHFf8LUT7iy8qzZT5aol4MI2gQANyH1oA/V9k+l4c+7BRb38TdOMbCuv81y/L38Dk2 PXR56KtzJfpTOKdlUSxCzTIrw+CU9LIkeBzjM= MIME-Version: 1.0 Received: by 10.52.36.237 with SMTP id t13mr16467104vdj.45.1318778374633; Sun, 16 Oct 2011 08:19:34 -0700 (PDT) Received: by 10.52.107.202 with HTTP; Sun, 16 Oct 2011 08:19:34 -0700 (PDT) In-Reply-To: References: Date: Sun, 16 Oct 2011 08:19:34 -0700 Message-ID: From: Dzonatas Sol To: rtcweb@ietf.org Content-Type: multipart/alternative; boundary=20cf30780d008eb80404af6c04b3 Subject: Re: [rtcweb] Signalling, SDP, and the way we think about interconnecting RTCWEB 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: Sun, 16 Oct 2011 15:19:36 -0000 --20cf30780d008eb80404af6c04b3 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Oct 16, 2011 at 12:36 AM, Wolfgang wrote: > On Sun, Oct 16, 2011 at 12:46 AM, Dzonatas Sol wrote: > > > There are always "border crossing" issues, which often exploits > encryption > > as useless even if it works. > > Main thing is that assets should not be cached server-to-server unless > those > > servers tether those assets, yet imagine the > > transient optimizations possible. > > I'm not sure what you are trying to explain.. > > I'm aware that 3d party authentication has its own set of problems, > but it might be a way to get forward with RTCWEB's signaling problem > without re-inventing SIP or XMPP. > > In SL, the main tether is simulated gravity. It's harder for the client to just make-up gravity that would agree with the server. With that known logic and ray-casts there are many other security options besides encryption. It's seems hard for devs to justify that level of security without such case being used for games or only seen as games when it is real-time ubiquity in mind. In your case to "avoid RTCWEB server from having to speak to each other at all" that would mean absolute no tether and no simulated gravity. If that was the case then, how do we deal with needs at the Olympics? I would not expect everyone's mobile to work in unison perfectly as one web to meet all needs. Safety net? Yes. On a recent news: I like CSS regions suggestion which limits javascript just to those regions. I think that helps model this WGs overall case with the trapezoid layout as CSS. --20cf30780d008eb80404af6c04b3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sun, Oct 16, 2011 at 12:36 AM, Wolfgang <wolfgang.beck0= 1@googlemail.com> wrote:
On Sun, Oct 16, 2011 at 12:46 AM, Dzonatas Sol <dzonatas@gmail.com> wrote:

> There are always "border crossing" issues, which often explo= its encryption
> as useless even if it works.
> Main thing is that assets should not be cached server-to-server unless= those
> servers tether those assets, yet imagine the
> transient=A0optimizations=A0possible.

I'm not sure what you are trying to explain..

I'm aware that 3d party authentication has its own set of problems,
but it might be a way to get forward with RTCWEB's signaling problem without re-inventing SIP or XMPP.



In SL, the main te= ther is simulated gravity. It's harder for the client to just make-up g= ravity that would agree with the server. With that known logic and ray-cast= s there are many other security options besides encryption.

It's seems hard for devs to justify that level of s= ecurity without such case being used for games or only seen as games when i= t is real-time=A0ubiquity in mind.

In your case to= "avoid RTCWEB server from having to speak to ea= ch other at all" that would mean absolute no tether and no simulated g= ravity. If that was the case then, how do we deal with needs at the = Olympics? I would not expect everyone's mobile to work in unison perfec= tly as one web to meet all needs. Safety net? Yes.=A0

On a recent news:=A0I like CSS regions suggestion which= limits javascript just to those regions. I think that helps model this WGs= overall case with the trapezoid layout as CSS.

--20cf30780d008eb80404af6c04b3-- From randell-ietf@jesup.org Sun Oct 16 20:38: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 B33CF11E8073 for ; Sun, 16 Oct 2011 20:38:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067, 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 yIX-5nVQ8m-g for ; Sun, 16 Oct 2011 20:38:47 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 2568F21F85BB for ; Sun, 16 Oct 2011 20:38: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 1RFe2H-0000ym-NO for rtcweb@ietf.org; Sun, 16 Oct 2011 22:38:46 -0500 Message-ID: <4E9BA235.3010808@jesup.org> Date: Sun, 16 Oct 2011 23:34:13 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <92A553E5-107A-4987-A5F5-1F56FB5A7800@acmepacket.com> <4E996E80.6070500@alvestrand.no> <8486C8728176924BAF5BDB2F7D7EEDDF3E0906A2@ucolhp4d.easf.csd.disa.mil> 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] Signalling, SDP, and the way we think about interconnecting RTCWEB 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, 17 Oct 2011 03:38:47 -0000 On 10/16/2011 4:39 AM, Wolfgang wrote: > On Sat, Oct 15, 2011 at 5:17 PM, Roy, Radhika R USA CIV (US) > wrote: >> Folks: >> >> A given codec type in known, its parameters should also be known per its specifications. So, it the negotiations between codec-types only. >> >> You can see how SDP is used for negotiations between different codec types using SIP. Similar mechanisms can also be used here. >> >> Radhika > So why do we transport some codec parameters outside the media stream > at all? The called device might need information about the media > stream before establishing it. Exactly, and the media stream is unreliable. This is the purpose of sprop-parameter-sets in H.264 SDP. Also think of gatewaying rtcweb to SDP. > The server might need access to codec parameters to forward the call > to the best destination: imagine a user with two RTCWEB clients, one > only supports only low resolution video, the other one full HD. A high > resolution video call comes in. How should the server select the > called client if it doesn't have access to the media stream which > carries the resolution parameters? I'm not certain how "the server" would select the client in your scenario under any usage; how would the server know before forwarding the call which client supported the incoming call's parameters? Though of course you could expose those capabilities to the server explicitly when 'registering'. The problem is that this requires the JS client and the server to understand exactly how the codec implementation will handle the parameters - you could use a bunch of codec-specific things like H.264 does, or generic capabilities. Generic capabilities won't capture all the dimensions of codec negotiation, of course. > In my model the server would know what type of call was set up as it > always controls both ends of the call. If some other application > controls the calling party, you need some standardized protocol like > SDP. So the server negotiates the parameters? I'm not sure what "my model" means here (and I reviewed earlier messages from you here). -- Randell Jesup randell-ietf@jesup.org From wolfgang.beck01@googlemail.com Sun Oct 16 23:14: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 7249D21F8AF6 for ; Sun, 16 Oct 2011 23:14:28 -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 m-Mq7jQGW5T1 for ; Sun, 16 Oct 2011 23:14:27 -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 9786621F85D1 for ; Sun, 16 Oct 2011 23:14:27 -0700 (PDT) Received: by pzk34 with SMTP id 34so5952416pzk.9 for ; Sun, 16 Oct 2011 23:14:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=tW5UTCZg8pmweoS8fi4u4Qrmm9BMoBzV3WONGhOf0QE=; b=l8UfcJ6uBxQ4ukfuXT4rKJ3XHsDZMunwrNYGiao6I+Fp3zA6UTZT9yeFHcy0p5HqM+ ZAXUmTksvz67tzt0YI4M4rTbDgIxx/UXPpOem3eoui9uA/TlmB6LAoZHeIuFVvqtx5Cz x6BafauoAoaGucWfZJn1q4xqzUfhDGh2qGUAM= MIME-Version: 1.0 Received: by 10.68.0.5 with SMTP id 5mr36498747pba.118.1318832065764; Sun, 16 Oct 2011 23:14:25 -0700 (PDT) Received: by 10.68.55.230 with HTTP; Sun, 16 Oct 2011 23:14:25 -0700 (PDT) In-Reply-To: <4E9BA235.3010808@jesup.org> References: <92A553E5-107A-4987-A5F5-1F56FB5A7800@acmepacket.com> <4E996E80.6070500@alvestrand.no> <8486C8728176924BAF5BDB2F7D7EEDDF3E0906A2@ucolhp4d.easf.csd.disa.mil> <4E9BA235.3010808@jesup.org> Date: Mon, 17 Oct 2011 08:14:25 +0200 Message-ID: From: Wolfgang To: Randell Jesup Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Signalling, SDP, and the way we think about interconnecting RTCWEB 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, 17 Oct 2011 06:14:28 -0000 On Mon, Oct 17, 2011 at 5:34 AM, Randell Jesup wro= te: > On 10/16/2011 4:39 AM, Wolfgang wrote: >> So why do we transport some codec parameters outside the media stream >> at all? The called device might need information about the media >> stream before establishing it. > > Exactly, and the media stream is unreliable. =A0This is the purpose of > sprop-parameter-sets in H.264 SDP. =A0Also think of gatewaying rtcweb to = SDP. > >> The server might need access to codec parameters to forward the call >> to the best destination: imagine a user with two RTCWEB clients, one >> only supports only low resolution video, the other one full HD. A high >> resolution video call comes in. How should the server select the >> called client if it doesn't have access to the media stream which >> carries the resolution parameters? > > I'm not certain how "the server" would select the client in your scenario > under any usage; how would the server know before forwarding the call whi= ch > client supported the incoming call's parameters? That's a valid point. So you think Radhika's proposal to only negotiate codec types but not codec parameters in the signaling path would cover all realistic use cases? >> In my model the server would know what type of call was set up as it >> always controls both ends of the call. If some other application >> controls the calling party, you need some standardized protocol like >> SDP. > > So the server negotiates the parameters? =A0I'm not sure what "my model" = means > here (and I reviewed earlier messages from you here). I didn't have company email access during the weekend and I'm the author of https://datatracker.ietf.org/doc/draft-beck-rtcweb-alt-ic/. The idea is to always use only one RTCWEB server and authenticate/authorize unknown users by 3rd part= y authentication. Like commenting on a blog using OpenID. Wolfgang Beck > > > -- > Randell Jesup > randell-ietf@jesup.org > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From pravindran@sonusnet.com Mon Oct 17 00:45: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 5DDDE21F8B35 for ; Mon, 17 Oct 2011 00:45:14 -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 xgcoCYTIv84g for ; Mon, 17 Oct 2011 00:45:13 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 5BBFA21F8B33 for ; Mon, 17 Oct 2011 00:45:13 -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 p9H7jeBE005300; Mon, 17 Oct 2011 03:45:40 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail05.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 17 Oct 2011 03:45:05 -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_01CC8CA0.AD35D50C" Date: Mon, 17 Oct 2011 13:15:15 +0530 Message-ID: <2E239D6FCD033C4BAF15F386A979BF511598EE@sonusinmail02.sonusnet.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] Review request for RTCWeb standard signaling protocol Thread-Index: AcyE58qiQsg22CmbRQ+ec/AyTlzr8wHt+TLw References: <2E239D6FCD033C4BAF15F386A979BF510F1367@sonusinmail02.sonusnet.com><4E8AC222.4050308@alvestrand.no><2E239D6FCD033C4BAF15F386A979BF510F14CE@sonusinmail02.sonusnet.com><2E239D6FCD033C4BAF15F386A979BF510F14FD@sonusinmail02.sonusnet.com><393F1888-F834-4DAE-B6B1-1C5D35EE3292@phonefromhere.com><2E239D6FCD033C4BAF15F386A979BF510F152B@sonusinmail02.sonusnet.com><2E239D6FCD033C4BAF15F386A979BF510F1532@sonusinmail02.sonusnet.com> From: "Ravindran Parthasarathi" To: "Neil Stratford" X-OriginalArrivalTime: 17 Oct 2011 07:45:05.0876 (UTC) FILETIME=[AFC94140:01CC8CA0] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Review request for RTCWeb standard 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, 17 Oct 2011 07:45:14 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC8CA0.AD35D50C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable My argument is that if we want the ultimate goal of simplicity for end user web developers then we should minimise everything they have to touch - and that includes removing any requirement for server side infrastructure beyond the basic bare minimum, which would mean no SIP proxies, no websocket servers etc etc. =20 But as I said, we don't need to standardise a protocol at all, so we shouldn't. If we are lucky we'll see a whole spectrum of solutions. =20 Without server interaction, it is not possible for browser to establish the session with other browser. Unlike other endpoint, browser needs server to provide routing or perform the authentication or atleast configuration information. AFAIK, RTCWeb client to RTCWeb client is not the motive of the work. If so, SIP is the IETF protocol between RTCWeb client to RTCWeb client which MUST be recommended because of the UA to UA communication nature. IOW, RTCWeb server signaling plays the key role which calls for standardization as browser & RTCWebserver is not required from the same vendor. =20 Thanks Partha =20 From: neils@vipadia.com [mailto:neils@vipadia.com] On Behalf Of Neil Stratford Sent: Friday, October 07, 2011 5:24 PM To: Ravindran Parthasarathi Cc: samuel; Tim Panton; rtcweb@ietf.org Subject: Re: [rtcweb] Review request for RTCWeb standard signaling protocol =20 On Fri, Oct 7, 2011 at 12:40 PM, Ravindran Parthasarathi wrote: Browser to browser real time communication is no different from other real-time communication apart from the existing web infrastructure. In case your argument is to use the existing web infrastructure like websocket, I agree with you. =20 It is different to traditional RTC - we have a javascript execution engine intimately tied in to every client. This completely changes the solution space. =20 But in case it is not the reason, Could you please list the reason for new signaling protocol requirement . =20 I already listed them:=20 =20 - No server side infrastructure (SIP proxies etc) to maintain or configure. - No special understanding in the server side web application beyond discovering peer identities you might want to communicate with. =20 My argument is that if we want the ultimate goal of simplicity for end user web developers then we should minimise everything they have to touch - and that includes removing any requirement for server side infrastructure beyond the basic bare minimum, which would mean no SIP proxies, no websocket servers etc etc. =20 But as I said, we don't need to standardise a protocol at all, so we shouldn't. If we are lucky we'll see a whole spectrum of solutions. =20 Neil ------_=_NextPart_001_01CC8CA0.AD35D50C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

<snip> My argument is that if we want the = ultimate goal of simplicity for end user web developers then we should minimise everything they have to touch - and that includes removing any = requirement for server side infrastructure beyond the basic bare minimum, which would = mean no SIP proxies, no websocket servers etc etc.

 

But as I said, we don't need to standardise a = protocol at all, so we shouldn't. If we are lucky we'll see a whole spectrum of = solutions.

 </snip>

 

Without server interaction, it is not possible for = browser to establish the session with other browser. Unlike other endpoint, browser needs = server to provide routing or  perform the authentication or atleast = configuration information. AFAIK, RTCWeb client to RTCWeb client is not the motive of = the work. If so, SIP is the IETF protocol between RTCWeb client to RTCWeb = client which MUST be recommended because of the UA to UA communication nature. IOW, = RTCWeb server signaling plays the key role which calls for standardization as = browser & RTCWebserver is not required from the same = vendor.

 

Thanks

Partha

 

From:= = neils@vipadia.com [mailto:neils@vipadia.com] On Behalf Of Neil Stratford
Sent: Friday, October 07, 2011 5:24 PM
To: Ravindran Parthasarathi
Cc: samuel; Tim Panton; rtcweb@ietf.org
Subject: Re: [rtcweb] Review request for RTCWeb standard = signaling protocol

 

On Fri, Oct 7, 2011 at 12:40 PM, Ravindran = Parthasarathi <pravindran@sonusnet.com> = wrote:

Browser to browser real time communication is no different from other real-time communication apart = from the existing web infrastructure. In case your argument is to use the = existing web infrastructure like websocket, I agree with you.

 

It is different to traditional RTC - we have a = javascript execution engine intimately tied in to every client. This completely = changes the solution space.

 

But in case it is not the = reason, Could you please list the reason for new signaling protocol requirement = .

 

I already listed them: 

 

- No server side infrastructure (SIP proxies etc) to maintain or = configure.

- No special understanding in the server side web application beyond = discovering peer identities you might want to communicate with.

 

My argument is that if we want the ultimate goal of simplicity for end user web developers then we should minimise = everything they have to touch - and that includes removing any requirement for server = side infrastructure beyond the basic bare minimum, which would mean no SIP = proxies, no websocket servers etc etc.

 

But as I said, we don't need to standardise a = protocol at all, so we shouldn't. If we are lucky we'll see a whole spectrum of = solutions.

 

Neil

------_=_NextPart_001_01CC8CA0.AD35D50C-- From pravindran@sonusnet.com Mon Oct 17 00: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 28EAF21F849C for ; Mon, 17 Oct 2011 00:55:59 -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 Wvh2cEPWCnUY for ; Mon, 17 Oct 2011 00: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 6A37821F8493 for ; Mon, 17 Oct 2011 00:55: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 p9H7uTL1012651; Mon, 17 Oct 2011 03:56:29 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail05.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 17 Oct 2011 03:55: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: Mon, 17 Oct 2011 13:26:05 +0530 Message-ID: <2E239D6FCD033C4BAF15F386A979BF511598F1@sonusinmail02.sonusnet.com> In-Reply-To: <1636CB96-8B00-4387-8ED2-9B74EB818E45@acmepacket.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] Review request for RTCWeb standard signaling protocol Thread-Index: AQHMhSH3WAYm6sWfE0aVzRoo8GFJXZWAN0Jg References: <2E239D6FCD033C4BAF15F386A979BF510F1367@sonusinmail02.sonusnet.com> <4E8AC222.4050308@alvestrand.no> <2E239D6FCD033C4BAF15F386A979BF510F14CE@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF510F14FD@sonusinmail02.sonusnet.com> <393F1888-F834-4DAE-B6B1-1C5D35EE3292@phonefromhere.com> <2E239D6FCD033C4BAF15F386A979BF510F152B@sonusinmail02.sonusnet.com> <1636CB96-8B00-4387-8ED2-9B74EB818E45@acmepacket.com> From: "Ravindran Parthasarathi" To: "Hadriel Kaplan" , X-OriginalArrivalTime: 17 Oct 2011 07:55:55.0336 (UTC) FILETIME=[32E4FC80:01CC8CA2] Subject: Re: [rtcweb] Review request for RTCWeb standard 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, 17 Oct 2011 07:55:59 -0000 Hadriel, Neil makes an excellent point which has only been briefly brought up but >should be made more explicit: picking a standard signaling protocol for >the Browser to implement is only half the problem - the other half of >the problem is the Web Server has to implement it too, tie it into a >location database, possibly with authentication and authorization policy >rules, and whatever else the specific Web application needs. My way of looking at the problem is between RTCWeb client (browser + javascript) and RTCWeb server signaling. I think that we are in the agreement that server has to perform couple of functionality like authentication and authorization policy which is normally dealt in all signaling protocol. My point is that it is better to spell out RTCWeb standard protocol between RTCWeb client and RTCWeb server by which RTCWeb server vendors shall interop smoothly with RTCWeb client. I missed to spell out in my draft about RTCWeb server dependency but pointed out the issues in gateway development of RTCWeb server & legacy server and it may be because I'm more concern about gateways ;-) I'll clarify in the next revision. Also, I'm not against creative RTCweb developer to innovate new signaling protocol for their website. But IETF MUST not mandate every web developer to create the signaling protocol to make RTCWeb solution work.=20 Thanks Partha >-----Original Message----- >From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] >Sent: Saturday, October 08, 2011 12:20 AM >To: >Cc: Ravindran Parthasarathi; Neil Stratford >Subject: Re: [rtcweb] Review request for RTCWeb standard signaling >protocol > > >Neil makes an excellent point which has only been briefly brought up but >should be made more explicit: picking a standard signaling protocol for >the Browser to implement is only half the problem - the other half of >the problem is the Web Server has to implement it too, tie it into a >location database, possibly with authentication and authorization policy >rules, and whatever else the specific Web application needs. > >There is no "20 lines of code" solution once you realize that. It may >be 20 lines of JavaScript, but that's only part of the problem/solution. >In fact, the most likely way to get to 20 lines of code for the Web >Server owner is for him/her to use a public JS library for signaling >which is paired with a web server module written for that specific JS >library. > >-hadriel > > >On Oct 7, 2011, at 7:16 AM, Neil Stratford wrote: > >> >> If we did go down the hypothetical new standard protocol route (which >I really think we shouldn't) my requirements would be: >> - No server side infrastructure (SIP proxies etc) to maintain or >configure. >> - No special understanding in the server side web application beyond >discovering peer identities you might want to communicate with. >> >> Which would lead to something looking like a browser maintained peer >to peer network, at which point we are re-inventing the web, which >sounds like something beyond this group. So I strongly support not >picking a default and instead encourage some innovation at the >javascript level. >> >> Neil >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb From tim@phonefromhere.com Mon Oct 17 00:57: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 C0C3E21F8B12 for ; Mon, 17 Oct 2011 00:57:17 -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 gVuGbr7Vrjge for ; Mon, 17 Oct 2011 00:57:17 -0700 (PDT) Received: from zimbra.westhawk.co.uk (zimbra.westhawk.co.uk [192.67.4.167]) by ietfa.amsl.com (Postfix) with ESMTP id EBEDC21F8801 for ; Mon, 17 Oct 2011 00:57:16 -0700 (PDT) Received: from [192.168.157.49] (unknown [93.89.81.113]) by zimbra.westhawk.co.uk (Postfix) with ESMTP id 62CBD37A907; Mon, 17 Oct 2011 09:10:02 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/alternative; boundary="Apple-Mail=_0C231C42-B1BD-45FA-95E8-210FEF0C398E" From: Tim Panton In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF511598EE@sonusinmail02.sonusnet.com> Date: Mon, 17 Oct 2011 08:57:13 +0100 Message-Id: <665A16AB-AAD8-42B3-AC17-7E629EA2DE35@phonefromhere.com> References: <2E239D6FCD033C4BAF15F386A979BF510F1367@sonusinmail02.sonusnet.com><4E8AC222.4050308@alvestrand.no><2E239D6FCD033C4BAF15F386A979BF510F14CE@sonusinmail02.sonusnet.com><2E239D6FCD033C4BAF15F386A979BF510F14FD@sonusinmail02.sonusnet.com><393F1888-F834-4DAE-B6B1-1C5D35EE3292@phonefromhere.com><2E239D6FCD033C4BAF15F386A979BF510F152B@sonusinmail02.sonusnet.com><2E239D6FCD033C4BAF15F386A979BF510F1532@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF511598EE@sonusinmail02.sonusnet.com> To: "Ravindran Parthasarathi" X-Mailer: Apple Mail (2.1251.1) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Review request for RTCWeb standard 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, 17 Oct 2011 07:57:17 -0000 --Apple-Mail=_0C231C42-B1BD-45FA-95E8-210FEF0C398E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 17 Oct 2011, at 08:45, Ravindran Parthasarathi wrote: > RTCWeb server signaling plays the key role which calls for = standardization as browser & RTCWebserver is not required from the same = vendor. And that is where we differ. The web server can _serve_ it's javascript = to the browser.=20 So the only standards needed are the pre-existing web standards of = javascript and http. The browser only has to be capable of running the javascript served to = ensure compatibility. That's the way that everything on the web works these days, from = shopping carts to realtime=20 chat. The browser is given site-specific code to run that interacts with = site-specific code on the web server. The web server may choose to convert those requests into = a standard protocol=20 for further processing (e.g. SQL), or may deal with the request = internally. Note, I'm not ruling out the use of SIP, but as I=F1aki Baz Castillo = has demonstrated, that too can be accomplished purely with existing web technologies. No embedded = signalling code=20 is needed. Tim. --Apple-Mail=_0C231C42-B1BD-45FA-95E8-210FEF0C398E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
RTCWeb server = signaling plays the key role which calls for standardization as browser = & RTCWebserver is not required from the same = vendor.

And that is where we = differ. The web server can _serve_ it's javascript to the = browser. 
So the only standards needed are the = pre-existing web standards of javascript and = http.

The browser only has to be capable of = running the javascript served to ensure compatibility.
That's = the way that everything on the web works these days, from shopping carts = to realtime 
chat. The browser is given site-specific = code to run that interacts with site-specific code on
the web = server. The web server may choose to convert those requests into a = standard protocol 
for further processing (e.g. SQL), or = may deal with the request internally.

Note, I'm = not ruling out the use of SIP, but as  I=F1aki Baz Castillo = has demonstrated, that too
can be accomplished purely with = existing web technologies. No embedded signalling = code 
is = needed.

Tim.

= --Apple-Mail=_0C231C42-B1BD-45FA-95E8-210FEF0C398E-- From pravindran@sonusnet.com Mon Oct 17 06:04: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 2065621F8B88 for ; Mon, 17 Oct 2011 06:04:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[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 uTJFAKe4yAu5 for ; Mon, 17 Oct 2011 06:04:09 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 8D96C21F8B87 for ; Mon, 17 Oct 2011 06:04: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 p9HD4fOG017857; Mon, 17 Oct 2011 09:04:41 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail04.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 17 Oct 2011 09:04: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_01CC8CCD.3E90E198" Date: Mon, 17 Oct 2011 18:34:03 +0530 Message-ID: <2E239D6FCD033C4BAF15F386A979BF5115992E@sonusinmail02.sonusnet.com> In-Reply-To: <665A16AB-AAD8-42B3-AC17-7E629EA2DE35@phonefromhere.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] Review request for RTCWeb standard signaling protocol Thread-Index: AcyMomLtAl0IYhbeSN65p41bPoj/EwAJ2bQA References: <2E239D6FCD033C4BAF15F386A979BF510F1367@sonusinmail02.sonusnet.com><4E8AC222.4050308@alvestrand.no><2E239D6FCD033C4BAF15F386A979BF510F14CE@sonusinmail02.sonusnet.com><2E239D6FCD033C4BAF15F386A979BF510F14FD@sonusinmail02.sonusnet.com><393F1888-F834-4DAE-B6B1-1C5D35EE3292@phonefromhere.com><2E239D6FCD033C4BAF15F386A979BF510F152B@sonusinmail02.sonusnet.com><2E239D6FCD033C4BAF15F386A979BF510F1532@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF511598EE@sonusinmail02.sonusnet.com> <665A16AB-AAD8-42B3-AC17-7E629EA2DE35@phonefromhere.com> From: "Ravindran Parthasarathi" To: "Tim Panton" X-OriginalArrivalTime: 17 Oct 2011 13:04:06.0543 (UTC) FILETIME=[408341F0:01CC8CCD] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Review request for RTCWeb standard 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, 17 Oct 2011 13:04:12 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC8CCD.3E90E198 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Tim, =20 Please read inline. =20 Thanks Partha =20 From: Tim Panton [mailto:tim@phonefromhere.com]=20 Sent: Monday, October 17, 2011 1:27 PM To: Ravindran Parthasarathi Cc: Neil Stratford; samuel; rtcweb@ietf.org Subject: Re: [rtcweb] Review request for RTCWeb standard signaling = protocol =20 =20 On 17 Oct 2011, at 08:45, Ravindran Parthasarathi wrote: RTCWeb server signaling plays the key role which calls for = standardization as browser & RTCWebserver is not required from the same = vendor. =20 And that is where we differ. The web server can _serve_ it's javascript = to the browser.=20 Here, webserver acts as a configuration/provisional module to = browser and dynamically load the Javascript based signaling protocol in = the endpoint. Please note that Javascript is a programming environment = and not the signaling replacement. Apart from this webserver needs to = develop its own signaling protocol to acts as RTCWeb server. In case of = Inaki SIP over websocket usecase, RTCWeb server acts as SIP proxy or SIP = B2BUA. =20 The argument here is whether the complete protocol & application has to = be developed in each webserver vs the signaling protocol API exists in = browser, IETF defined standard signaling protocol in webserver, web = programmer invokes server API & client API to make the RTCWeb = application. I prefer the second approach because web developer has no = need to understand the underlying intricacies. You can easily the = understand the complication involved in signaling protocol by the = offer/answer discussion in RTCWeb alias.=20 =20 =20 =20 So the only standards needed are the pre-existing web standards of = javascript and http. HTTP is not replacement of SIP in RTCWeb. I agree to the extend = that websocket change the signaling paradigm in RTCWeb because two = communication established between client & server then routing issue is = resolved automatically which is one of the core function of signaling = protocol =20 The browser only has to be capable of running the javascript served to = ensure compatibility. Javascript is the programming environment That's the way that everything on the web works these days, from = shopping carts to realtime=20 chat. The browser is given site-specific code to run that interacts with = site-specific code on the web server. The web server may choose to convert those requests into = a standard protocol=20 for further processing (e.g. SQL), or may deal with the request = internally. =20 Note, I'm not ruling out the use of SIP, but as I=F1aki Baz Castillo = has demonstrated, that too can be accomplished purely with existing web technologies. =20 I'm not favor Inaki solution of SIP over websocket because it = is overkill for signaling protocol. Websocket solves routing issues = between browser-webserver- browser, so the lightweight protocol over = websocket will be sufficient and there is no need of complicated SIP = based Javascript stack.=20 =20 Also, I'm not believer of the downloading complete signaling protocol = script because it will delay the setup time which is crucial in lot of = real-time application. Of course, it may not be critical for free = application but not for professional services. =20 AFAIK, signaling protocol codebase expands very quickly with the = addition of new services and leads to more delay in the setup of the = session. =20 No embedded signalling code=20 is needed. =20 Tim. =20 ------_=_NextPart_001_01CC8CCD.3E90E198 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Tim,

 

Please read inline.

 

Thanks

Partha

 

From:= Tim Panton [mailto:tim@phonefromhere.com]
Sent: Monday, October 17, 2011 1:27 PM
To: Ravindran Parthasarathi
Cc: Neil Stratford; samuel; rtcweb@ietf.org
Subject: Re: [rtcweb] Review request for RTCWeb standard = signaling protocol

 

 

On 17 Oct 2011, at 08:45, Ravindran Parthasarathi = wrote:



RTCWeb server = signaling plays the key role which calls for standardization as browser & = RTCWebserver is not required from the same vendor.

 

And that is where we differ. The web server can = _serve_ it's javascript to the browser. 

<partha> Here, webserver acts as a configuration/provisional module to browser and dynamically load the = Javascript based signaling protocol in the endpoint. =A0Please note that Javascript = is a programming environment and not the signaling replacement. Apart from = this webserver needs to develop its own signaling protocol to acts as RTCWeb = server. =A0In case of Inaki SIP over websocket usecase, RTCWeb server acts as = SIP proxy or SIP B2BUA.

 

The argument here is whether the complete protocol & application has to be developed in each webserver vs the signaling = protocol API exists in browser, IETF defined standard signaling protocol in = webserver, web programmer invokes server API & client API to make the RTCWeb = application. I prefer the second approach because web developer has no need to = understand the underlying intricacies. =A0You can easily the understand the = complication involved in signaling protocol by the offer/answer discussion in RTCWeb = alias.

 

</partha>

 

So the only standards needed are the pre-existing = web standards of javascript and http.

<partha> HTTP is not replacement of SIP in RTCWeb. = I agree to the extend that websocket change the signaling paradigm in RTCWeb = because two communication established between client & server then routing = issue is resolved automatically which is one of the core function of signaling = protocol </partha>

 

The browser only has to be capable of running the = javascript served to ensure compatibility.

<partha> Javascript is the programming environment </partha>

That's the way that everything on the web works = these days, from shopping carts to realtime 

chat. The browser is given site-specific code to = run that interacts with site-specific code on

the web server. The web server may choose to = convert those requests into a standard protocol 

for further processing (e.g. SQL), or may deal with = the request internally.

 

Note, I'm not ruling out the use of SIP, but as  I=F1aki Baz Castillo has demonstrated, that = too

can be accomplished purely with existing web = technologies.

 

<partha> I’m not favor Inaki solution of SIP = over websocket because it is overkill for signaling protocol. Websocket = solves routing issues between browser-webserver- browser, so the lightweight = protocol over websocket will be sufficient and there is no need of complicated = SIP based Javascript stack.

 

Also, I’m not believer of the downloading complete signaling protocol script because it will delay the setup time which is = crucial in lot of real-time application. Of course, it may not be critical for = free application but not for professional services.

 

AFAIK, signaling protocol codebase expands very quickly = with the addition of new services and leads to more delay in the setup of the = session. =A0</partha>

=A0

=A0No embedded signalling code 

is needed.

 

Tim.

 

------_=_NextPart_001_01CC8CCD.3E90E198-- From radhika.r.roy.civ@mail.mil Mon Oct 17 06:51: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 B8C3921F8546 for ; Mon, 17 Oct 2011 06:51:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.433 X-Spam-Level: X-Spam-Status: No, score=-2.433 tagged_above=-999 required=5 tests=[AWL=0.166, 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 phQ1JSfBSKSh for ; Mon, 17 Oct 2011 06:51:00 -0700 (PDT) Received: from edge-cols.mail.mil (edge-cols.mail.mil [131.64.100.6]) by ietfa.amsl.com (Postfix) with ESMTP id B743821F85B9 for ; Mon, 17 Oct 2011 06:50:55 -0700 (PDT) Received: from UCOLHP3D.easf.csd.disa.mil (131.64.100.143) by UCOLHP4Z.easf.csd.disa.mil (131.64.100.6) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 17 Oct 2011 08:50:48 -0500 Received: from UCOLHP4D.easf.csd.disa.mil ([169.254.9.97]) by UCOLHP3D.easf.csd.disa.mil ([169.254.143.83]) with mapi id 14.01.0323.003; Mon, 17 Oct 2011 08:50:47 -0500 From: "Roy, Radhika R USA CIV (US)" To: Ravindran Parthasarathi , Neil Stratford Thread-Topic: [rtcweb] Review request for RTCWeb standard signaling protocol Thread-Index: AcyE58qiQsg22CmbRQ+ec/AyTlzr8wHt+TLwAAzwHoA= Date: Mon, 17 Oct 2011 13:50:44 +0000 Message-ID: <8486C8728176924BAF5BDB2F7D7EEDDF3E0917F9@ucolhp4d.easf.csd.disa.mil> References: <2E239D6FCD033C4BAF15F386A979BF510F1367@sonusinmail02.sonusnet.com><4E8AC222.4050308@alvestrand.no><2E239D6FCD033C4BAF15F386A979BF510F14CE@sonusinmail02.sonusnet.com><2E239D6FCD033C4BAF15F386A979BF510F14FD@sonusinmail02.sonusnet.com><393F1888-F834-4DAE-B6B1-1C5D35EE3292@phonefromhere.com><2E239D6FCD033C4BAF15F386A979BF510F152B@sonusinmail02.sonusnet.com><2E239D6FCD033C4BAF15F386A979BF510F1532@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF511598EE@sonusinmail02.sonusnet.com> In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF511598EE@sonusinmail02.sonusnet.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.64.77.9] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Review request for RTCWeb standard 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, 17 Oct 2011 13:51:02 -0000 Folks: If servers are intelligent enough to "route" the calls among themselves, th= ere are no need for any proxies. So, proxies are needed for "routing" in the application layer. BR/Radhika -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Ravindran Parthasarathi Sent: Monday, October 17, 2011 3:45 AM To: Neil Stratford Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Review request for RTCWeb standard signaling protocol My argument is that if we want the ultimate goal of simplicity for e= nd user web developers then we should minimise everything they have to touc= h - and that includes removing any requirement for server side infrastructu= re beyond the basic bare minimum, which would mean no SIP proxies, no webso= cket servers etc etc. =20 But as I said, we don't need to standardise a protocol at all, so we should= n't. If we are lucky we'll see a whole spectrum of solutions. =20 Without server interaction, it is not possible for browser to establish the= session with other browser. Unlike other endpoint, browser needs server to= provide routing or perform the authentication or atleast configuration in= formation. AFAIK, RTCWeb client to RTCWeb client is not the motive of the w= ork. If so, SIP is the IETF protocol between RTCWeb client to RTCWeb client= which MUST be recommended because of the UA to UA communication nature. IO= W, RTCWeb server signaling plays the key role which calls for standardizati= on as browser & RTCWebserver is not required from the same vendor. =20 Thanks Partha =20 From pravindran@sonusnet.com Mon Oct 17 06:56: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 961D821F8677 for ; Mon, 17 Oct 2011 06:56:59 -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 Nt8Xhg6CogbN for ; Mon, 17 Oct 2011 06:56:59 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 07F6E21F8672 for ; Mon, 17 Oct 2011 06:56: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 p9HDvV40020643; Mon, 17 Oct 2011 09:57:31 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail04.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 17 Oct 2011 09:56:57 -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, 17 Oct 2011 19:26:55 +0530 Message-ID: <2E239D6FCD033C4BAF15F386A979BF5115993F@sonusinmail02.sonusnet.com> In-Reply-To: <8486C8728176924BAF5BDB2F7D7EEDDF3E0917F9@ucolhp4d.easf.csd.disa.mil> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] Review request for RTCWeb standard signaling protocol Thread-Index: AcyE58qiQsg22CmbRQ+ec/AyTlzr8wHt+TLwAAzwHoAAADNJ4A== References: <2E239D6FCD033C4BAF15F386A979BF510F1367@sonusinmail02.sonusnet.com><4E8AC222.4050308@alvestrand.no><2E239D6FCD033C4BAF15F386A979BF510F14CE@sonusinmail02.sonusnet.com><2E239D6FCD033C4BAF15F386A979BF510F14FD@sonusinmail02.sonusnet.com><393F1888-F834-4DAE-B6B1-1C5D35EE3292@phonefromhere.com><2E239D6FCD033C4BAF15F386A979BF510F152B@sonusinmail02.sonusnet.com><2E239D6FCD033C4BAF15F386A979BF510F1532@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF511598EE@sonusinmail02.sonusnet.com> <8486C8728176924BAF5BDB2F7D7EEDDF3E0917F9@ucolhp4d.easf.csd.disa.mil> From: "Ravindran Parthasarathi" To: "Roy, Radhika R USA CIV (US)" , "Neil Stratford" X-OriginalArrivalTime: 17 Oct 2011 13:56:57.0476 (UTC) FILETIME=[A2893C40:01CC8CD4] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Review request for RTCWeb standard 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, 17 Oct 2011 13:56:59 -0000 Hi Radhika, I agree with you for "proxy" requirement and it is classified as "federation" in RTCWeb which is outside the scope of current discussion. IOW, single RTCWeb server knows where to route the session between any two known RTCWeb client but RTCweb client will not aware how to route to other RTCWeb client. Thanks Partha >-----Original Message----- >From: Roy, Radhika R USA CIV (US) [mailto:radhika.r.roy.civ@mail.mil] >Sent: Monday, October 17, 2011 7:21 PM >To: Ravindran Parthasarathi; Neil Stratford >Cc: rtcweb@ietf.org >Subject: RE: [rtcweb] Review request for RTCWeb standard signaling >protocol > >Folks: > >If servers are intelligent enough to "route" the calls among themselves, >there are no need for any proxies. > >So, proxies are needed for "routing" in the application layer. > >BR/Radhika > >-----Original Message----- >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf >Of Ravindran Parthasarathi >Sent: Monday, October 17, 2011 3:45 AM >To: Neil Stratford >Cc: rtcweb@ietf.org >Subject: Re: [rtcweb] Review request for RTCWeb standard signaling >protocol > > My argument is that if we want the ultimate goal of simplicity >for end user web developers then we should minimise everything they have >to touch - and that includes removing any requirement for server side >infrastructure beyond the basic bare minimum, which would mean no SIP >proxies, no websocket servers etc etc. > > > >But as I said, we don't need to standardise a protocol at all, so we >shouldn't. If we are lucky we'll see a whole spectrum of solutions. > > > > > >Without server interaction, it is not possible for browser to establish >the session with other browser. Unlike other endpoint, browser needs >server to provide routing or perform the authentication or atleast >configuration information. AFAIK, RTCWeb client to RTCWeb client is not >the motive of the work. If so, SIP is the IETF protocol between RTCWeb >client to RTCWeb client which MUST be recommended because of the UA to >UA communication nature. IOW, RTCWeb server signaling plays the key role >which calls for standardization as browser & RTCWebserver is not >required from the same vendor. > > > >Thanks > >Partha > > From randell-ietf@jesup.org Mon Oct 17 08:05: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 8D86121F8C44 for ; Mon, 17 Oct 2011 08:05:01 -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 L+mAKyOZkzk4 for ; Mon, 17 Oct 2011 08:05:01 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 1689621F8C3A for ; Mon, 17 Oct 2011 08:05:00 -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 1RFokO-00032U-6m for rtcweb@ietf.org; Mon, 17 Oct 2011 10:05:00 -0500 Message-ID: <4E9C430A.1070600@jesup.org> Date: Mon, 17 Oct 2011 11:00:26 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <92A553E5-107A-4987-A5F5-1F56FB5A7800@acmepacket.com> <4E996E80.6070500@alvestrand.no> <8486C8728176924BAF5BDB2F7D7EEDDF3E0906A2@ucolhp4d.easf.csd.disa.mil> <4E9BA235.3010808@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] Signalling, SDP, and the way we think about interconnecting RTCWEB 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, 17 Oct 2011 15:05:01 -0000 On 10/17/2011 2:14 AM, Wolfgang wrote: > On Mon, Oct 17, 2011 at 5:34 AM, Randell Jesup wrote: >>> In my model the server would know what type of call was set up as it >>> always controls both ends of the call. If some other application >>> controls the calling party, you need some standardized protocol like >>> SDP. >> >> So the server negotiates the parameters? I'm not sure what "my model" means >> here (and I reviewed earlier messages from you here). > I didn't have company email access during the weekend and I'm the author of > https://datatracker.ietf.org/doc/draft-beck-rtcweb-alt-ic/. The idea > is to always use > only one RTCWEB server and authenticate/authorize unknown users by 3rd party > authentication. Like commenting on a blog using OpenID. Ok, I looked at draft-beck-rtcweb-alt-ic. One huge problem with it: it's based on an assumption that for most cases of federation and cross-service calls won't hold: that clients will use the same client JS app, and the services are just providing different realms/methods of authentication and user-lookup. Also, your draft doesn't explain how A & B came to be talking to the same server in the first place. The draft seems mostly focused on how a single provider can use a shared authentication scheme (and I would suggest that we try to find a provider-agnostic way to leverage id systems such as BrowserID and/or OpenID to provide end-user identification). You should talk to ekr who's writing the security draft and see if you can merge some of these ideas into it. I don't think it in any way helps our signalling/SDP/etc discussion, my apologies. -- Randell Jesup randell-ietf@jesup.org From ibc@aliax.net Mon Oct 17 08:51: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 C58DA21F8CB8 for ; Mon, 17 Oct 2011 08:51:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.584 X-Spam-Level: X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.093, 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 YRqSs3kcGIlq for ; Mon, 17 Oct 2011 08:51: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 22BFE21F8CAB for ; Mon, 17 Oct 2011 08:51:07 -0700 (PDT) Received: by vws5 with SMTP id 5so3230254vws.31 for ; Mon, 17 Oct 2011 08:51:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.184.103 with SMTP id et7mr20854387vdc.35.1318866667280; Mon, 17 Oct 2011 08:51:07 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Mon, 17 Oct 2011 08:51:07 -0700 (PDT) In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF5115992E@sonusinmail02.sonusnet.com> References: <2E239D6FCD033C4BAF15F386A979BF510F1367@sonusinmail02.sonusnet.com> <4E8AC222.4050308@alvestrand.no> <2E239D6FCD033C4BAF15F386A979BF510F14CE@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF510F14FD@sonusinmail02.sonusnet.com> <393F1888-F834-4DAE-B6B1-1C5D35EE3292@phonefromhere.com> <2E239D6FCD033C4BAF15F386A979BF510F152B@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF510F1532@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF511598EE@sonusinmail02.sonusnet.com> <665A16AB-AAD8-42B3-AC17-7E629EA2DE35@phonefromhere.com> <2E239D6FCD033C4BAF15F386A979BF5115992E@sonusinmail02.sonusnet.com> Date: Mon, 17 Oct 2011 17:51:07 +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] Review request for RTCWeb standard 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, 17 Oct 2011 15:51:08 -0000 2011/10/17 Ravindran Parthasarathi : Again the same... Ravindran, you are repeating the *same* arguments in different mails/threads. You always *ignore* and don't reply to responses given to your arguments. You are also manipulating some given responses by making them to look as if their content agree with your insistent proposal. You are trying to manipulate this WG and that is dishonest. STOP please. Unfortunatelly for you, your mails will always receive the deserved respons= e: > I=E2=80=99m not favor Inaki solution of SIP over websocket becau= se it is > overkill for signaling protocol. Demonstrate it !!! I know that SIP over websocket is NOT an overkill (because I *use* it). You DONT KNOW the opposite. You CANNOT assert the opposite. Stop lying please! > Websocket solves routing issues between > browser-webserver- browser, so the lightweight protocol over websocket wi= ll > be sufficient and there is no need of complicated SIP based Javascript > stack. Use whatever you want but don't force me to use what you want. Neither insist on creating a "default signaling protocol" for the reaons given 1000 times in this maillist (those reasons you ignore again and again and you will NEVER reply to). > Also, I=E2=80=99m not believer of the downloading complete signaling prot= ocol script > because it will delay the setup time which is crucial in lot of real-time > application. Of course, it may not be critical for free application but n= ot > for professional services. So you don't understand how the WWW works. The user visits a web page, the browser downloads all the HTML, CSS, images and JavaScript stuff and, *after that*, the web application is ready to be used. It does not depend just on having a signaling protocol built-in the browser. Now the problem is downloading a ~150KB JavaScript file??? There are images taking more space in lot of webs! > AFAIK, signaling protocol codebase expands very quickly with the addition= of > new services and leads to more delay in the setup of the session. =C2=A0<= /partha> And how is supposed your proposed "default signaling protocol" to handle those "new services"? If you try NOW to make a "default signaling protocol" for RTCweb that means that you MUST know *NOW* all the possible requirements of any RTCweb future communication. You don't know them, I don't know them, nobody knows them! --=20 I=C3=B1aki Baz Castillo From pravindran@sonusnet.com Mon Oct 17 10:00: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 6301E21F8C1D for ; Mon, 17 Oct 2011 10:00:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.949 X-Spam-Level: X-Spam-Status: No, score=-2.949 tagged_above=-999 required=5 tests=[AWL=-0.650, 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 oiShRLnwvm-O for ; Mon, 17 Oct 2011 10:00:11 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 825EC21F8678 for ; Mon, 17 Oct 2011 10:00:11 -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 p9HH0gv6011023; Mon, 17 Oct 2011 13:00:42 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail05.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 17 Oct 2011 13:00:08 -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: Mon, 17 Oct 2011 22:30:06 +0530 Message-ID: <2E239D6FCD033C4BAF15F386A979BF51159950@sonusinmail02.sonusnet.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] Review request for RTCWeb standard signaling protocol Thread-Index: AcyM5Jfz3IeIkoa8S7WSCIWq+duQ2QAAeHWQ References: <2E239D6FCD033C4BAF15F386A979BF510F1367@sonusinmail02.sonusnet.com><4E8AC222.4050308@alvestrand.no><2E239D6FCD033C4BAF15F386A979BF510F14CE@sonusinmail02.sonusnet.com><2E239D6FCD033C4BAF15F386A979BF510F14FD@sonusinmail02.sonusnet.com><393F1888-F834-4DAE-B6B1-1C5D35EE3292@phonefromhere.com><2E239D6FCD033C4BAF15F386A979BF510F152B@sonusinmail02.sonusnet.com><2E239D6FCD033C4BAF15F386A979BF510F1532@sonusinmail02.sonusnet.com><2E239D6FCD033C4BAF15F386A979BF511598EE@sonusinmail02.sonusnet.com><665A16AB-AAD8-42B3-AC17-7E629EA2DE35@phonefromhere.com><2E239D6FCD033C4BAF15F386A979BF5115992E@sonusinmail02.sonusnet.com> From: "Ravindran Parthasarathi" To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= X-OriginalArrivalTime: 17 Oct 2011 17:00:08.0675 (UTC) FILETIME=[39CD1B30:01CC8CEE] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Review request for RTCWeb standard 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, 17 Oct 2011 17:00:12 -0000 VGhlIHBvaW50IHRvIGJlIG5vdGVkIGlzIGZvbGtzIHB1dCBmb3J0aCB0aGUgc2FtZSBhcmd1bWVu dCBhZ2FpbiAmIGFnYWluLi5lYWNoIHRpbWUsIGl0IGlzIG5vdCBwb3NzaWJsZSB0byBjb21lIHVw IG5ldyBhbnN3ZXIgOy0pIEkgbm90aWNlZCBvZnRlbiB5b3UgY29tcGxhaW4gYXMgaWYgeW91ciBp bXBvcnRhbnQgaXMgbWlzc2VkIG91dC4gV2UgYXJlIGFyZ3Vpbmcgb25seSBhYm91dCAibm90aGlu ZyIgdnMgInNvbWV0aGluZyIgYXMgYSBSVENXZWIgc2lnbmFsaW5nIHByb3RvY29sLg0KDQpJIGNs ZWFybHkgZXhwbGFpbmVkIHdoeSBTSVAgb3ZlciB3ZWJzb2NrZXQgaXMgYW4gb3ZlcmtpbGwgaW4g dGhlIGJlbG93IG1haWwgdGhyZWFkLiBQbGVhc2UgcmVhZCBpdCBhbmQgZG9uJ3QgYXJndWUgdGhh dCBpdCBpcyB3b3JraW5nLiBBbGwgdGhlIHdvcmtpbmcgc3R1ZmYgaXMgbm90IGdvb2QuIEluZmFj dCBmb3IgYW55IHByb3RvY29sLCB0aGUgZmlyc3QgaWRlYSBwb3AtdXAgaXMgdG8gdHVubmVsIHRo ZSBjb21wbGV0ZSBpbnNpZGUgKEZvciBFeDogSVNVUCBvdmVyIFNJUCkgYnV0IGFsd2F5cyBiZXR0 ZXIgd2F5cyB0byBzb2x2ZSBpdC4NCg0KSSB0aGluayB0aGF0IHlvdSBjb25mdXNpbmcgdGhlIGFy Z3VtZW50IHdpdGggc2NyaXB0ICYgcHJvdG9jb2wuIEkgYWdyZWUgdGhhdCBXV1cgd29ybGQgd29y a3Mgd2l0aCBQSFAgZm9yIHNlcnZlciBzaWRlIGFuZCBKYXZhc2NyaXB0LCBDU1MgZm9yIGNsaWVu dCBzaWRlIGJ1dCBJJ20gdGFsa2luZyBhYm91dCBIVFRQIHByb3RvY29sIGluIGNhc2Ugb2YgbGVn YWN5IHdlYi4gT2YgY291cnNlLCBIVFRQIGlzIG5vdCBkZXNpZ25lZCBmb3IgcmVhbC10aW1lIGNv bW11bmljYXRpb24uIFNvLCB3ZSBuZWVkIHNvbWUgc2lnbmFsaW5nIHByb3RvY29sIGxpa2UgSmlu Z2xlLCBXZWJzb2NrZXQgd2l0aCBvZmZlci9hbnN3ZXIgKFJPQVApIHRvIG1ha2UgaXQgd29yay4g TGV0IHVzIHRhbGsgYWJvdXQgdGhlIHByb3RvY29sIGFuZCBub3QgYWJvdXQgdGhlIHByb2dyYW1t aW5nIGVudmlyb25tZW50Lg0KDQpUaGUgYmFzZSBpZGVhIG9mIGRlZmluaW5nIHRoZSBwcm90b2Nv bCBpcyB0byBwcm92aWRlIHRoZSBiYXNpYyBidWlsZGluZyBibG9ja3MgYW5kIG5ldyBzZXJ2aWNl IHNoYWxsIGJlIGRldmVsb3BlZCB1c2luZyB0aGVzZSBidWlsZGluZyBibG9jay4gSW4gY2FzZSBi YXNpYyBidWlsZGluZyBibG9jayBpcyB3ZWxsIGRlZmluZWQsIGJ1aWxkaW5nIHRoZSBuZXcgc2Vy dmljZSB3aWxsIG5vdCBiZSBpbXBvc3NpYmxlLiBOb3JtYWxseSwgc3RhbmRhcmQgcHJvdG9jb2wg d2lsbCB1bmRlcmdvIHRocm91Z2ggcmV2aWV3IHdoaWNoIHRoZSBiYXNpYyBuZXcgc2VydmljZSBu ZWVkcy4gDQoNCkknbSB0YWxraW5nIGFib3V0IHRoZSBwZXJmb3JtYW5jZSBiZWNhdXNlIEkga25v dyB0aGF0IHN1Y2Nlc3Mgc3RvcnkgU0lQIHdyaXR0ZW4gaW4gQyBvdmVyIFNJUCB3cml0dGVuIGlu IEphdmEuIEluIGNhc2UgeW91IGFyZ3VlIGZvciBTSVAgcGx1Z2luIHZzIG5hdGl2ZSBTSVAsIHRo ZSBwZXJmb3JtYW5jZSBtYXkgbm90IGJlIG11Y2ggZGlmZmVyZW5jZS4gQWxzbywgdGhlIGRvd25s b2FkIG9mIHRoZSBlbnRpcmUgcHJvdG9jb2wgaXMgd29yc2UgdGhhbiBpbi1idWlsZCBwcm90b2Nv bCBieSBhbnkgbWVhbnMuDQoNCi1QYXJ0aGENCg0KPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+RnJvbTogScOxYWtpIEJheiBDYXN0aWxsbyBbbWFpbHRvOmliY0BhbGlheC5uZXRdDQo+U2Vu dDogTW9uZGF5LCBPY3RvYmVyIDE3LCAyMDExIDk6MjEgUE0NCj5UbzogUmF2aW5kcmFuIFBhcnRo YXNhcmF0aGkNCj5DYzogVGltIFBhbnRvbjsgcnRjd2ViQGlldGYub3JnDQo+U3ViamVjdDogUmU6 IFtydGN3ZWJdIFJldmlldyByZXF1ZXN0IGZvciBSVENXZWIgc3RhbmRhcmQgc2lnbmFsaW5nDQo+ cHJvdG9jb2wNCj4NCj4yMDExLzEwLzE3IFJhdmluZHJhbiBQYXJ0aGFzYXJhdGhpIDxwcmF2aW5k cmFuQHNvbnVzbmV0LmNvbT46DQo+DQo+QWdhaW4gdGhlIHNhbWUuLi4NCj4NCj5SYXZpbmRyYW4s IHlvdSBhcmUgcmVwZWF0aW5nIHRoZSAqc2FtZSogYXJndW1lbnRzIGluIGRpZmZlcmVudA0KPm1h aWxzL3RocmVhZHMuIFlvdSBhbHdheXMgKmlnbm9yZSogYW5kIGRvbid0IHJlcGx5IHRvIHJlc3Bv bnNlcyBnaXZlbg0KPnRvIHlvdXIgYXJndW1lbnRzLiBZb3UgYXJlIGFsc28gbWFuaXB1bGF0aW5n IHNvbWUgZ2l2ZW4gcmVzcG9uc2VzIGJ5DQo+bWFraW5nIHRoZW0gdG8gbG9vayBhcyBpZiB0aGVp ciBjb250ZW50IGFncmVlIHdpdGggeW91ciBpbnNpc3RlbnQNCj5wcm9wb3NhbC4NCj4NCj5Zb3Ug YXJlIHRyeWluZyB0byBtYW5pcHVsYXRlIHRoaXMgV0cgYW5kIHRoYXQgaXMgZGlzaG9uZXN0LiBT VE9QIHBsZWFzZS4NCj4NCj5VbmZvcnR1bmF0ZWxseSBmb3IgeW91LCB5b3VyIG1haWxzIHdpbGwg YWx3YXlzIHJlY2VpdmUgdGhlIGRlc2VydmVkDQo+cmVzcG9uc2U6DQo+DQo+DQo+DQo+PiA8cGFy dGhhPiBJ4oCZbSBub3QgZmF2b3IgSW5ha2kgc29sdXRpb24gb2YgU0lQIG92ZXIgd2Vic29ja2V0 IGJlY2F1c2UgaXQNCj5pcw0KPj4gb3ZlcmtpbGwgZm9yIHNpZ25hbGluZyBwcm90b2NvbC4NCj4N Cj5EZW1vbnN0cmF0ZSBpdCAhISENCj4NCj5JIGtub3cgdGhhdCBTSVAgb3ZlciB3ZWJzb2NrZXQg aXMgTk9UIGFuIG92ZXJraWxsIChiZWNhdXNlIEkgKnVzZSoNCj5pdCkuIFlvdSBET05UIEtOT1cg dGhlIG9wcG9zaXRlLiBZb3UgQ0FOTk9UIGFzc2VydCB0aGUgb3Bwb3NpdGUuDQo+U3RvcCBseWlu ZyBwbGVhc2UhDQo+DQo+DQo+PiBXZWJzb2NrZXQgc29sdmVzIHJvdXRpbmcgaXNzdWVzIGJldHdl ZW4NCj4+IGJyb3dzZXItd2Vic2VydmVyLSBicm93c2VyLCBzbyB0aGUgbGlnaHR3ZWlnaHQgcHJv dG9jb2wgb3ZlciB3ZWJzb2NrZXQNCj53aWxsDQo+PiBiZSBzdWZmaWNpZW50IGFuZCB0aGVyZSBp cyBubyBuZWVkIG9mIGNvbXBsaWNhdGVkIFNJUCBiYXNlZCBKYXZhc2NyaXB0DQo+PiBzdGFjay4N Cj4NCj5Vc2Ugd2hhdGV2ZXIgeW91IHdhbnQgYnV0IGRvbid0IGZvcmNlIG1lIHRvIHVzZSB3aGF0 IHlvdSB3YW50LiBOZWl0aGVyDQo+aW5zaXN0IG9uIGNyZWF0aW5nIGEgImRlZmF1bHQgc2lnbmFs aW5nIHByb3RvY29sIiBmb3IgdGhlIHJlYW9ucyBnaXZlbg0KPjEwMDAgdGltZXMgaW4gdGhpcyBt YWlsbGlzdCAodGhvc2UgcmVhc29ucyB5b3UgaWdub3JlIGFnYWluIGFuZCBhZ2Fpbg0KPmFuZCB5 b3Ugd2lsbCBORVZFUiByZXBseSB0bykuDQo+DQo+DQo+PiBBbHNvLCBJ4oCZbSBub3QgYmVsaWV2 ZXIgb2YgdGhlIGRvd25sb2FkaW5nIGNvbXBsZXRlIHNpZ25hbGluZyBwcm90b2NvbA0KPnNjcmlw dA0KPj4gYmVjYXVzZSBpdCB3aWxsIGRlbGF5IHRoZSBzZXR1cCB0aW1lIHdoaWNoIGlzIGNydWNp YWwgaW4gbG90IG9mIHJlYWwtDQo+dGltZQ0KPj4gYXBwbGljYXRpb24uIE9mIGNvdXJzZSwgaXQg bWF5IG5vdCBiZSBjcml0aWNhbCBmb3IgZnJlZSBhcHBsaWNhdGlvbg0KPmJ1dCBub3QNCj4+IGZv ciBwcm9mZXNzaW9uYWwgc2VydmljZXMuDQo+DQo+U28geW91IGRvbid0IHVuZGVyc3RhbmQgaG93 IHRoZSBXV1cgd29ya3MuIFRoZSB1c2VyIHZpc2l0cyBhIHdlYiBwYWdlLA0KPnRoZSBicm93c2Vy IGRvd25sb2FkcyBhbGwgdGhlIEhUTUwsIENTUywgaW1hZ2VzIGFuZCBKYXZhU2NyaXB0IHN0dWZm DQo+YW5kLCAqYWZ0ZXIgdGhhdCosIHRoZSB3ZWIgYXBwbGljYXRpb24gaXMgcmVhZHkgdG8gYmUg dXNlZC4gSXQgZG9lcw0KPm5vdCBkZXBlbmQganVzdCBvbiBoYXZpbmcgYSBzaWduYWxpbmcgcHJv dG9jb2wgYnVpbHQtaW4gdGhlIGJyb3dzZXIuDQo+DQo+Tm93IHRoZSBwcm9ibGVtIGlzIGRvd25s b2FkaW5nIGEgfjE1MEtCIEphdmFTY3JpcHQgZmlsZT8/PyBUaGVyZSBhcmUNCj5pbWFnZXMgdGFr aW5nIG1vcmUgc3BhY2UgaW4gbG90IG9mIHdlYnMhDQo+DQo+DQo+PiBBRkFJSywgc2lnbmFsaW5n IHByb3RvY29sIGNvZGViYXNlIGV4cGFuZHMgdmVyeSBxdWlja2x5IHdpdGggdGhlDQo+YWRkaXRp b24gb2YNCj4+IG5ldyBzZXJ2aWNlcyBhbmQgbGVhZHMgdG8gbW9yZSBkZWxheSBpbiB0aGUgc2V0 dXAgb2YgdGhlIHNlc3Npb24uDQo+wqA8L3BhcnRoYT4NCj4NCj5BbmQgaG93IGlzIHN1cHBvc2Vk IHlvdXIgcHJvcG9zZWQgImRlZmF1bHQgc2lnbmFsaW5nIHByb3RvY29sIiB0bw0KPmhhbmRsZSB0 aG9zZSAibmV3IHNlcnZpY2VzIj8gSWYgeW91IHRyeSBOT1cgdG8gbWFrZSBhICJkZWZhdWx0DQo+ c2lnbmFsaW5nIHByb3RvY29sIiBmb3IgUlRDd2ViIHRoYXQgbWVhbnMgdGhhdCB5b3UgTVVTVCBr bm93ICpOT1cqIGFsbA0KPnRoZSBwb3NzaWJsZSByZXF1aXJlbWVudHMgb2YgYW55IFJUQ3dlYiBm dXR1cmUgY29tbXVuaWNhdGlvbi4gWW91DQo+ZG9uJ3Qga25vdyB0aGVtLCBJIGRvbid0IGtub3cg dGhlbSwgbm9ib2R5IGtub3dzIHRoZW0hDQo+DQo+DQo+DQo+DQo+LS0NCj5Jw7Fha2kgQmF6IENh c3RpbGxvDQo+PGliY0BhbGlheC5uZXQ+DQo= From wolfgang.beck01@googlemail.com Mon Oct 17 10: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 6837421F8772 for ; Mon, 17 Oct 2011 10:10:52 -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 m0Jrjx-jlzJO for ; Mon, 17 Oct 2011 10:10:51 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5187121F86C1 for ; Mon, 17 Oct 2011 10:10:51 -0700 (PDT) Received: by qadb12 with SMTP id b12so2951719qad.31 for ; Mon, 17 Oct 2011 10:10:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=KiDnG8z6F305e8XqjRV8DKGx+YAW5xc5+j0m+wM2Mks=; b=r7aiaX390FwITvQ+2hRt+uC/7UTOXC1UMVqNrS5nT6bAc8TvUh9uAkQ4E5xfiwNDSF ItIJu+/wOIepqomh0TGwDsi3GA4wy2n/tCg17ph1bHpxC4ivMKu+4K5r6ognxPz1/Rk0 KcfLAJiDe9gh/a5YqpuhThf4jOJxZFefpTv5Q= MIME-Version: 1.0 Received: by 10.68.39.231 with SMTP id s7mr31630744pbk.33.1318871450443; Mon, 17 Oct 2011 10:10:50 -0700 (PDT) Received: by 10.68.55.230 with HTTP; Mon, 17 Oct 2011 10:10:50 -0700 (PDT) In-Reply-To: <4E9C430A.1070600@jesup.org> References: <92A553E5-107A-4987-A5F5-1F56FB5A7800@acmepacket.com> <4E996E80.6070500@alvestrand.no> <8486C8728176924BAF5BDB2F7D7EEDDF3E0906A2@ucolhp4d.easf.csd.disa.mil> <4E9BA235.3010808@jesup.org> <4E9C430A.1070600@jesup.org> Date: Mon, 17 Oct 2011 19:10:50 +0200 Message-ID: From: Wolfgang Beck To: Randell Jesup Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Signalling, SDP, and the way we think about interconnecting RTCWEB 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, 17 Oct 2011 17:10:52 -0000 On Mon, Oct 17, 2011 at 5:00 PM, Randell Jesup wro= te: > Ok, I looked at draft-beck-rtcweb-alt-ic. > > One huge problem with it: it's based on an assumption that for most cases= of > federation and cross-service calls won't hold: that clients will use the > same client JS app, and the services are just providing different > realms/methods of authentication and user-lookup. > > Also, your draft doesn't explain how A & B came to be talking to the same > server in the first place. =A0The draft seems mostly focused on how a sin= gle > provider can use a shared authentication scheme (and I would suggest that= we > try to find a provider-agnostic way to leverage id systems such as Browse= rID > and/or OpenID to provide end-user identification). > Ok, here's an example that works today. Let's assume you have a yahoo account and want to post a comment on stackexchange.com. You just point your browser to the stackexchange.com url [i.e. user location]. Now you log in using your yahoo account as OpenID. The browser loads the stackexchanges's JS client that enables you to post your text. There is no comment-posting-protocol required between yahoo and stackexchange. They only have to agree on an 3rd party authentication proto= col. If stackexchange extends its functionality, let's say with real-time chat (which they did), your browser will load the appropriate JS client the next time you load the page. All parties in the chat will use the same JS client under stackexchange's control, regardless whether people have used google, yahoo, or facebook to log in. There is no need to standardize anything that crosses stackexchange's servers. Now you want to make a comment on some blog at blogspot.com. You point your browser at the blog's URL and log in using your Yahoo OpenID. The browser loads blogspot's JS client. The GUI looks quite different but you can post your comment as well. With the current RTCWEB thinking, we would have to specify an intra server protocol that covered stackexchange's discussion and chat systems as well as blogspot comments. Such a protocol would soon get very complex. > You should talk to ekr who's writing the security draft and see if you ca= n > merge some of these ideas into it. > > I don't think it in any way helps our signalling/SDP/etc discussion, my > apologies. > Thanks for reading and commenting on the draft! Wolfgang From Ranjit.Avasarala@Polycom.com Mon Oct 17 10:13: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 7B10D21F8C80 for ; Mon, 17 Oct 2011 10:13:18 -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 yyCxFkbKTTzQ for ; Mon, 17 Oct 2011 10:13:16 -0700 (PDT) Received: from Hkgehubprd01.polycom.com (hkgehubprd01.polycom.com [140.242.6.225]) by ietfa.amsl.com (Postfix) with ESMTP id D6FD921F8C7D for ; Mon, 17 Oct 2011 10:13:15 -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; Tue, 18 Oct 2011 01:13:13 +0800 From: "Avasarala, Ranjit" To: Ravindran Parthasarathi , =?Windows-1252?Q?I=F1aki_Baz_Castillo?= Date: Tue, 18 Oct 2011 01:09:26 +0800 Thread-Topic: [rtcweb] Review request for RTCWeb standard signaling protocol Thread-Index: AcyM5Jfz3IeIkoa8S7WSCIWq+duQ2QAAeHWQAAJDGiU= Message-ID: <1F2A2C70609D9E41844A2126145FC0980416C9DD@HKGMBOXPRD22.polycom.com> References: <2E239D6FCD033C4BAF15F386A979BF510F1367@sonusinmail02.sonusnet.com><4E8AC222.4050308@alvestrand.no><2E239D6FCD033C4BAF15F386A979BF510F14CE@sonusinmail02.sonusnet.com><2E239D6FCD033C4BAF15F386A979BF510F14FD@sonusinmail02.sonusnet.com><393F1888-F834-4DAE-B6B1-1C5D35EE3292@phonefromhere.com><2E239D6FCD033C4BAF15F386A979BF510F152B@sonusinmail02.sonusnet.com><2E239D6FCD033C4BAF15F386A979BF510F1532@sonusinmail02.sonusnet.com><2E239D6FCD033C4BAF15F386A979BF511598EE@sonusinmail02.sonusnet.com><665A16AB-AAD8-42B3-AC17-7E629EA2DE35@phonefromhere.com><2E239D6FCD033C4BAF15F386A979BF5115992E@sonusinmail02.sonusnet.com> , <2E239D6FCD033C4BAF15F386A979BF51159950@sonusinmail02.sonusnet.com> In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF51159950@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="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Review request for RTCWeb standard 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, 17 Oct 2011 17:13:21 -0000 Hi Partha Though I agree with you that SIP over Websockets is an overkill on web brow= sers, there is a need for some kind of signaling protocol for communicating= offer / answer model between 2 web browser clients. This was one of my co= mments on Inaki's SIP over Websockets transport. =20 My point is there is a need for some kind of signaling protocol to be used = over Websockets - be it SIP or XMPP - but these should be used as Websocke= t sub protocol. Regards Ranjit ________________________________________ From: rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] On Behalf Of Ravind= ran Parthasarathi [pravindran@sonusnet.com] Sent: Monday, October 17, 2011 10:30 PM To: I=F1aki Baz Castillo Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Review request for RTCWeb standard signaling protocol The point to be noted is folks put forth the same argument again & again..e= ach time, it is not possible to come up new answer ;-) I noticed often you = complain as if your important is missed out. We are arguing only about "not= hing" vs "something" as a RTCWeb signaling protocol. I clearly explained why SIP over websocket is an overkill in the below mail= thread. Please read it and don't argue that it is working. All the working= stuff is not good. Infact for any protocol, the first idea pop-up is to tu= nnel the complete inside (For Ex: ISUP over SIP) but always better ways to = solve it. I think that you confusing the argument with script & protocol. I agree tha= t WWW world works with PHP for server side and Javascript, CSS for client s= ide but I'm talking about HTTP protocol in case of legacy web. Of course, H= TTP is not designed for real-time communication. So, we need some signaling= protocol like Jingle, Websocket with offer/answer (ROAP) to make it work. = Let us talk about the protocol and not about the programming environment. The base idea of defining the protocol is to provide the basic building blo= cks and new service shall be developed using these building block. In case = basic building block is well defined, building the new service will not be = impossible. Normally, standard protocol will undergo through review which t= he basic new service needs. I'm talking about the performance because I know that success story SIP wri= tten in C over SIP written in Java. In case you argue for SIP plugin vs nat= ive SIP, the performance may not be much difference. Also, the download of = the entire protocol is worse than in-build protocol by any means. -Partha >-----Original Message----- >From: I=F1aki Baz Castillo [mailto:ibc@aliax.net] >Sent: Monday, October 17, 2011 9:21 PM >To: Ravindran Parthasarathi >Cc: Tim Panton; rtcweb@ietf.org >Subject: Re: [rtcweb] Review request for RTCWeb standard signaling >protocol > >2011/10/17 Ravindran Parthasarathi : > >Again the same... > >Ravindran, you are repeating the *same* arguments in different >mails/threads. You always *ignore* and don't reply to responses given >to your arguments. You are also manipulating some given responses by >making them to look as if their content agree with your insistent >proposal. > >You are trying to manipulate this WG and that is dishonest. STOP please. > >Unfortunatelly for you, your mails will always receive the deserved >response: > > > >> I=92m not favor Inaki solution of SIP over websocket because it >is >> overkill for signaling protocol. > >Demonstrate it !!! > >I know that SIP over websocket is NOT an overkill (because I *use* >it). You DONT KNOW the opposite. You CANNOT assert the opposite. >Stop lying please! > > >> Websocket solves routing issues between >> browser-webserver- browser, so the lightweight protocol over websocket >will >> be sufficient and there is no need of complicated SIP based Javascript >> stack. > >Use whatever you want but don't force me to use what you want. Neither >insist on creating a "default signaling protocol" for the reaons given >1000 times in this maillist (those reasons you ignore again and again >and you will NEVER reply to). > > >> Also, I=92m not believer of the downloading complete signaling protocol >script >> because it will delay the setup time which is crucial in lot of real- >time >> application. Of course, it may not be critical for free application >but not >> for professional services. > >So you don't understand how the WWW works. The user visits a web page, >the browser downloads all the HTML, CSS, images and JavaScript stuff >and, *after that*, the web application is ready to be used. It does >not depend just on having a signaling protocol built-in the browser. > >Now the problem is downloading a ~150KB JavaScript file??? There are >images taking more space in lot of webs! > > >> AFAIK, signaling protocol codebase expands very quickly with the >addition of >> new services and leads to more delay in the setup of the session. > > >And how is supposed your proposed "default signaling protocol" to >handle those "new services"? If you try NOW to make a "default >signaling protocol" for RTCweb that means that you MUST know *NOW* all >the possible requirements of any RTCweb future communication. You >don't know them, I don't know them, nobody knows them! > > > > >-- >I=F1aki Baz Castillo > _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb= From ibc@aliax.net Mon Oct 17 10:19: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 5223F21F8CB6 for ; Mon, 17 Oct 2011 10:19:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.587 X-Spam-Level: X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=0.090, 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 y3vVzV-7-qlx for ; Mon, 17 Oct 2011 10:19: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 A95D621F8CB5 for ; Mon, 17 Oct 2011 10:19:19 -0700 (PDT) Received: by vws5 with SMTP id 5so3351284vws.31 for ; Mon, 17 Oct 2011 10:19:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.35.34 with SMTP id e2mr20941767vdj.52.1318871959042; Mon, 17 Oct 2011 10:19:19 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Mon, 17 Oct 2011 10:19:18 -0700 (PDT) In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF51159950@sonusinmail02.sonusnet.com> References: <2E239D6FCD033C4BAF15F386A979BF510F1367@sonusinmail02.sonusnet.com> <4E8AC222.4050308@alvestrand.no> <2E239D6FCD033C4BAF15F386A979BF510F14CE@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF510F14FD@sonusinmail02.sonusnet.com> <393F1888-F834-4DAE-B6B1-1C5D35EE3292@phonefromhere.com> <2E239D6FCD033C4BAF15F386A979BF510F152B@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF510F1532@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF511598EE@sonusinmail02.sonusnet.com> <665A16AB-AAD8-42B3-AC17-7E629EA2DE35@phonefromhere.com> <2E239D6FCD033C4BAF15F386A979BF5115992E@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF51159950@sonusinmail02.sonusnet.com> Date: Mon, 17 Oct 2011 19:19:18 +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] Review request for RTCWeb standard 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, 17 Oct 2011 17:19:20 -0000 2011/10/17 Ravindran Parthasarathi : > I clearly explained why SIP over websocket is an overkill in the below ma= il thread. Please read it and don't argue that it is working. I argue that it *works* and it is *not* an overkill. > All the working stuff is not good. Are you asserting that my software is not good??? who are you to say that??= ? Have I said that most probably all the software you have coded sucks? > Infact for any protocol, the first idea pop-up is to tunnel the complete = inside (For Ex: ISUP over SIP) but always better ways to solve it. So, why do you tunnel SIP over UDP or TCP? Instead create a new transport level protocol on top of the IP layer and call it SIP-Ravindran. > I think that you confusing the argument with script & protocol. I agree t= hat WWW world works with PHP for server side and Javascript, CSS for client= side but I'm talking about HTTP protocol in case of legacy web. Of course,= HTTP is not designed for real-time communication. So, we need some signali= ng protocol like Jingle, Websocket with offer/answer (ROAP) to make it work= . ROAP is just about negotiating media! You still need a signaling protocol (for example to tell the server "who you want to call"). Such signaling protocol can be a custom JSON over WebSocket, or can be SIP over WebSocket or whatever over WebSocket (or over HTTP with Comet). And you still don't understand that WebSocket is not an application protocol, but a transport protocol. You insist in saying "Websocket with offer/answer (ROAP)", so how to signal the destination of the audio/video call? You need a WebSocket subprotocol on top of the WebSocket transport for that, for example *SIP* (or whatever you choose). > The base idea of defining the protocol is to provide the basic building b= locks and new service shall be developed using these building block. In cas= e basic building block is well defined, building the new service will not b= e impossible. Normally, standard protocol will undergo through review which= the basic new service needs. > > I'm talking about the performance because I know that success story SIP w= ritten in C over SIP written in Java. In case you argue for SIP plugin vs n= ative SIP, the performance may not be much difference. Also, the download o= f the entire protocol is worse than in-build protocol by any means. Ok ok, say what you want (the same again and again). Good luck and bye. --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Mon Oct 17 10:21: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 F32B221F8BBB for ; Mon, 17 Oct 2011 10:21:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.086, 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 swwJIhWoZCRV for ; Mon, 17 Oct 2011 10:21: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 70CF221F8B94 for ; Mon, 17 Oct 2011 10:21:12 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so3329918vcb.31 for ; Mon, 17 Oct 2011 10:21:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.73.166 with SMTP id m6mr4632935vdv.18.1318872071649; Mon, 17 Oct 2011 10:21:11 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Mon, 17 Oct 2011 10:21:11 -0700 (PDT) In-Reply-To: <1F2A2C70609D9E41844A2126145FC0980416C9DD@HKGMBOXPRD22.polycom.com> References: <2E239D6FCD033C4BAF15F386A979BF510F1367@sonusinmail02.sonusnet.com> <4E8AC222.4050308@alvestrand.no> <2E239D6FCD033C4BAF15F386A979BF510F14CE@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF510F14FD@sonusinmail02.sonusnet.com> <393F1888-F834-4DAE-B6B1-1C5D35EE3292@phonefromhere.com> <2E239D6FCD033C4BAF15F386A979BF510F152B@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF510F1532@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF511598EE@sonusinmail02.sonusnet.com> <665A16AB-AAD8-42B3-AC17-7E629EA2DE35@phonefromhere.com> <2E239D6FCD033C4BAF15F386A979BF5115992E@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF51159950@sonusinmail02.sonusnet.com> <1F2A2C70609D9E41844A2126145FC0980416C9DD@HKGMBOXPRD22.polycom.com> Date: Mon, 17 Oct 2011 19:21:11 +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] Review request for RTCWeb standard 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, 17 Oct 2011 17:21:13 -0000 2011/10/17 Avasarala, Ranjit : > Though I agree with you that SIP over Websockets is an overkill on web br= owsers, And you can assert that because.... oh, you cannot! or have you tried it? > My point is there is a need for some kind of signaling protocol to be use= d over Websockets - be it SIP or XMPP - =C2=A0but these should be used as W= ebsocket sub protocol Sure. Check http://tools.ietf.org/html/draft-ibc-rtcweb-sip-websocket-00 ----------------------------------------- Abstract This document specifies a WebSocket subprotocol for a new transport in SIP (Session Initiation Protocol). [...] ------------------------------------------ --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Mon Oct 17 10:25: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 0CFAC21F8CCA for ; Mon, 17 Oct 2011 10:25:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.594 X-Spam-Level: X-Spam-Status: No, score=-2.594 tagged_above=-999 required=5 tests=[AWL=0.083, 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 LRTZTakWDnKH for ; Mon, 17 Oct 2011 10:25:08 -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 6F91121F8CC7 for ; Mon, 17 Oct 2011 10:25:08 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so3334465vcb.31 for ; Mon, 17 Oct 2011 10:25:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.25.75 with SMTP id a11mr21159752vdg.1.1318872307956; Mon, 17 Oct 2011 10:25:07 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Mon, 17 Oct 2011 10:25:07 -0700 (PDT) In-Reply-To: References: <92A553E5-107A-4987-A5F5-1F56FB5A7800@acmepacket.com> <4E996E80.6070500@alvestrand.no> <8486C8728176924BAF5BDB2F7D7EEDDF3E0906A2@ucolhp4d.easf.csd.disa.mil> <4E9BA235.3010808@jesup.org> <4E9C430A.1070600@jesup.org> Date: Mon, 17 Oct 2011 19:25:07 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Wolfgang Beck Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Randell Jesup , rtcweb@ietf.org Subject: Re: [rtcweb] Signalling, SDP, and the way we think about interconnecting RTCWEB 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, 17 Oct 2011 17:25:09 -0000 2011/10/17 Wolfgang Beck : > Now you want to make a comment on some blog at blogspot.com. You point > your browser at the blog's URL and log in using your Yahoo OpenID. > The browser loads blogspot's JS client. The GUI looks quite different > but you can post your comment as well. Exactly. Some people has argued that getting a different GUI is bad, but this is not about telephony world in which each person has a phone. This is about communicating with different services each one providing different features and capabilities so it does not make sense at all to share the same GUI for RTCweb communication with a second website. > With the current RTCWEB thinking, we would have to specify an intra > server protocol that covered stackexchange's discussion and chat > systems as well as blogspot comments. Such a protocol would soon get > very complex. Agreed. --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Mon Oct 17 10:35: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 654B421F8BF7 for ; Mon, 17 Oct 2011 10:35:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[AWL=0.080, 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 AbHomS+b+yOC for ; Mon, 17 Oct 2011 10:35: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 DAD6E21F8BC5 for ; Mon, 17 Oct 2011 10:35:30 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so3346274vcb.31 for ; Mon, 17 Oct 2011 10:35:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.117.81 with SMTP id p17mr1544695vcq.41.1318872928818; Mon, 17 Oct 2011 10:35:28 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Mon, 17 Oct 2011 10:35:28 -0700 (PDT) In-Reply-To: References: <2E239D6FCD033C4BAF15F386A979BF510F1367@sonusinmail02.sonusnet.com> <4E8AC222.4050308@alvestrand.no> <2E239D6FCD033C4BAF15F386A979BF510F14CE@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF510F14FD@sonusinmail02.sonusnet.com> <393F1888-F834-4DAE-B6B1-1C5D35EE3292@phonefromhere.com> <2E239D6FCD033C4BAF15F386A979BF510F152B@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF510F1532@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF511598EE@sonusinmail02.sonusnet.com> <665A16AB-AAD8-42B3-AC17-7E629EA2DE35@phonefromhere.com> <2E239D6FCD033C4BAF15F386A979BF5115992E@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF51159950@sonusinmail02.sonusnet.com> <1F2A2C70609D9E41844A2126145FC0980416C9DD@HKGMBOXPRD22.polycom.com> Date: Mon, 17 Oct 2011 19:35:28 +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] Review request for RTCWeb standard 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, 17 Oct 2011 17:35:31 -0000 2011/10/17 I=C3=B1aki Baz Castillo : >> My point is there is a need for some kind of signaling protocol to be us= ed over Websockets - be it SIP or XMPP - =C2=A0but these should be used as = Websocket sub protocol > > Sure. Check http://tools.ietf.org/html/draft-ibc-rtcweb-sip-websocket-00 > > ----------------------------------------- > Abstract > > =C2=A0 This document specifies a WebSocket subprotocol for a new transpor= t > =C2=A0 in SIP (Session Initiation Protocol). [...] > ------------------------------------------ And also check http://tools.ietf.org/html/draft-moffitt-xmpp-over-websocket= -00 ------------------ An XMPP Sub-protocol for WebSocket draft-moffitt-xmpp-over-websocket-00 ------------------ --=20 I=C3=B1aki Baz Castillo From ted.ietf@gmail.com Mon Oct 17 10:51: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 1C7B821F8A7A for ; Mon, 17 Oct 2011 10:51:03 -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.400, 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 AnqNF82sn80D for ; Mon, 17 Oct 2011 10:51:00 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id EE4B521F8663 for ; Mon, 17 Oct 2011 10:50:59 -0700 (PDT) Received: by ggnv1 with SMTP id v1so1793638ggn.31 for ; Mon, 17 Oct 2011 10:50:58 -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=Zfj7dTxlQXQ3QEFnBsdpiBijZK1HaFSZ2oZEwDlksHE=; b=YXn1qbjHTWTCwBTRuxkZ6i3C3BoRsG7GBPVZguMFOEhMztN0T8DsOLt6B1ymS5YkvY x5gupmhgKMsCrIUTbjmbqLewtenbqPLgQNZUQ3bqDpL1Ov+IL1qgDY10CcH06jDK9Zje HdWht1hQcfX9YyPFDVgDO3ZbsHc1aBtUbmaeM= MIME-Version: 1.0 Received: by 10.236.185.228 with SMTP id u64mr28349130yhm.91.1318873858380; Mon, 17 Oct 2011 10:50:58 -0700 (PDT) Received: by 10.236.105.169 with HTTP; Mon, 17 Oct 2011 10:50:58 -0700 (PDT) In-Reply-To: References: <92A553E5-107A-4987-A5F5-1F56FB5A7800@acmepacket.com> Date: Mon, 17 Oct 2011 10:50:58 -0700 Message-ID: From: Ted Hardie To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=20cf303f6bcad513ac04af823f4a Cc: "" Subject: Re: [rtcweb] Signalling, SDP, and the way we think about interconnecting RTCWEB 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, 17 Oct 2011 17:51:04 -0000 --20cf303f6bcad513ac04af823f4a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sat, Oct 15, 2011 at 1:43 AM, I=F1aki Baz Castillo wrote= : > > > Do you think you could support SIP identity with a javascript client? > > > Yes. The spec (RFC 4474) does NOT mandate that the SIP client MUST to > have a list of CA's and verify the retrieved certificate by itself. A > JavaScript client receiving an incoming INVITE with Identity and > Identity-Info header could make a webservice call (i.e. using AJAX) > and ask its web server to retrieve it and verify it in behalf of the > client. And still that is SIP. > > So yes, I could support SIP Indentity with a JavaScript client. > > I would say you did not do it within the JavaScript client, but built a JavaScript client that simply trusted the results of the webserver. This i= s significantly worse than even the SSH-style limited identity we've discusse= d before, because the Javascript client doesn't even check whether the identity matches previous uses of that identity. You also don't describe how you go about assuring the path over which the media flows, which is a part of sip identity. > > > > > Well, given that you don't believe in the need for a protocol here at > all, > > A protocol is needed, of course. But not a *specific* protocol. > > > > but only an incredibly flexible API, it seems a bit unclear why you're > not > > making these points on the W3C public mailing list for this activity. > > By "a protocol here", I meant "standardized in the IETF" sorry that was not clear. > I expect such work must come once the requirements for such API are > done in this WG. > > The work is ongoing now in both groups and the two are meant to coordinate. Presuming that all the work will go on there to provide a model-agnostic AP= I is not effective coordination, at least in my view. > > > A truly well structured API here will imply, at least in my view, at > least a > > common model for negotiation and a common set of structured data to be > > passed via this javascript-implemented protocol. Doing that without > > defining a standard protocol is actually harder than doing it while > defining > > a protocol. > > > > I've heard the various arguments against defining one, but none of them > > seems to stand up against the base fact that you can have a standard > > protocol--known to be available--without restricting the ability to > create > > proprietary protocols using the same API. > > There have been lot of arguments contrary to defining a "default > signaling protocol". I don't want to repeat them again, but neither > answer as if they don't exist. > > There have been a lot of arguments, but speaking personally, they seem to boil down to a preference for inferring a model (offer/answer) along with a slow realization that much of the negotiation here (e.g. codec parameters) cannot really be punted. As I said before, if you go down the route of creating a common model for negotiation and a common set of structured data for the negotiation and security assurances, you have done the semantic wor= k of creating a protocol. Failing to choose a common in syntax in that situation is, in my experience, both odd and likely to decrease the amount of deployment and increase the failure rate. My personal opinion, Ted Hardie --20cf303f6bcad513ac04af823f4a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sat, Oct 15, 2011 at 1:43 AM, I=F1aki Baz Castillo <= ;ibc@aliax.net> wrote:

> Do you think you could support SIP identity with a javascript client?<= br>

Yes. The spec (RFC 4474) does NOT mandate that the SIP client MUS= T to
have a list of CA's and verify the retrieved certificate by itself. A JavaScript client receiving an incoming INVITE with Identity and
Identity-Info header could make a webservice call (i.e. using AJAX)
and ask its web server to retrieve it and verify it in behalf of the
client. And still that is SIP.

So yes, I could support SIP Indentity with a JavaScript client.


I would say you did not d= o it within the JavaScript client, but built a JavaScript client that simpl= y trusted the results of the webserver.=A0 This is significantly worse than= even the SSH-style limited identity we've discussed before, because th= e Javascript client doesn't even check whether the identity matches pre= vious uses of that identity.=A0 You also don't describe how you go abou= t assuring the path over which the media flows, which is a part of sip iden= tity.

=A0

=
>
> Well, given that you don't believe in the need for a protocol here= at all,

A protocol is needed, of course. But not a *specific* protocol.


> but only an incredibly flexible API, it seems a bit unclear why you= 9;re not
> making these points on the W3C public mailing list for this activity.<= br>

By "a protocol here", I meant &qu= ot;standardized in the IETF" sorry that was not clear.
=A0
I expect such work must come once the requirements for such API are done in this WG.


The work is ongoing now i= n both groups and the two are meant to coordinate.=A0 Presuming that all th= e work will go on there to provide a model-agnostic API is not effective co= ordination, at least in my view.
=A0

> A truly well structured API here will imply, at least in my view, at l= east a
> common model for negotiation and a common set of structured data to be=
> passed via this javascript-implemented protocol.=A0 Doing that without=
> defining a standard protocol is actually harder than doing it while de= fining
> a protocol.
>
> I've heard the various arguments against defining one, but none of= them
> seems to stand up against the base fact that you can have a standard > protocol--known to be available--without restricting the ability to cr= eate
> proprietary protocols using the same API.

There have been lot of arguments contrary to defining a "default=
signaling protocol". I don't want to repeat them again, but neithe= r
answer as if they don't exist.


The= re have been a lot of arguments, but speaking personally, they seem to boil= down to a preference for inferring a model (offer/answer) along with a slo= w realization that much of the negotiation here (e.g. codec parameters) can= not really be punted.=A0 As I said before, if you go down the route of crea= ting a common model for negotiation and a common set of structured data for= the negotiation and security assurances, you have done the semantic work o= f creating a protocol.=A0 Failing to choose a common in syntax in that situ= ation is, in my experience, both odd and likely to decrease the amount of d= eployment and increase the failure rate.=A0

My personal opinion,

Ted Hardie



--20cf303f6bcad513ac04af823f4a-- From dzonatas@gmail.com Mon Oct 17 10:52: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 8CA5511E8082 for ; Mon, 17 Oct 2011 10:52:43 -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 jIinPFSHrKsy for ; Mon, 17 Oct 2011 10:52:40 -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 037D711E8073 for ; Mon, 17 Oct 2011 10:52:39 -0700 (PDT) Received: by vws5 with SMTP id 5so3387883vws.31 for ; Mon, 17 Oct 2011 10:52:39 -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=Dqz77QYDM7lbf8sLmdzSSCD6XDU20sLBoKWmX3nl1pg=; b=Z8A8wBWVh72RB4/0OgqysRLs0B7XuwJwdLJigEAgFW/Hq1QLnVc1ltRqLcqngiBqd6 dlWNnPzAAycIbgaKHwOg9jT94i464/q0C+6Ttue2bJXw51J80IJ79dNPK8871uyU7v52 QgoB0GpGDW1o20JpE+41jj30qFu/kk0QFLOh8= MIME-Version: 1.0 Received: by 10.52.21.232 with SMTP id y8mr21065198vde.83.1318873959494; Mon, 17 Oct 2011 10:52:39 -0700 (PDT) Received: by 10.52.107.202 with HTTP; Mon, 17 Oct 2011 10:52:39 -0700 (PDT) In-Reply-To: References: <92A553E5-107A-4987-A5F5-1F56FB5A7800@acmepacket.com> <4E996E80.6070500@alvestrand.no> <8486C8728176924BAF5BDB2F7D7EEDDF3E0906A2@ucolhp4d.easf.csd.disa.mil> <4E9BA235.3010808@jesup.org> <4E9C430A.1070600@jesup.org> Date: Mon, 17 Oct 2011 10:52:39 -0700 Message-ID: From: Dzonatas Sol To: Wolfgang Beck Content-Type: multipart/alternative; boundary=20cf3079babadbf53304af824555 Cc: Randell Jesup , rtcweb@ietf.org Subject: Re: [rtcweb] Signalling, SDP, and the way we think about interconnecting RTCWEB 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, 17 Oct 2011 17:52:43 -0000 --20cf3079babadbf53304af824555 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Oct 17, 2011 at 10:10 AM, Wolfgang Beck < wolfgang.beck01@googlemail.com> wrote: > On Mon, Oct 17, 2011 at 5:00 PM, Randell Jesup > wrote: > > > Ok, I looked at draft-beck-rtcweb-alt-ic. > > > > One huge problem with it: it's based on an assumption that for most cases > of > > federation and cross-service calls won't hold: that clients will use the > > same client JS app, and the services are just providing different > > realms/methods of authentication and user-lookup. > > > > Also, your draft doesn't explain how A & B came to be talking to the same > > server in the first place. The draft seems mostly focused on how a > single > > provider can use a shared authentication scheme (and I would suggest that > we > > try to find a provider-agnostic way to leverage id systems such as > BrowserID > > and/or OpenID to provide end-user identification). > > > Ok, here's an example that works today. Let's assume you have a yahoo > account and want to post a comment on stackexchange.com. > You just point your browser to the stackexchange.com url [i.e. user > location]. Now you log in using your yahoo account as OpenID. The > browser loads the stackexchanges's JS client that enables you to post > your text. There is no comment-posting-protocol required between > yahoo and > stackexchange. They only have to agree on an 3rd party authentication > protocol. > > If stackexchange extends its functionality, let's say with real-time > chat (which they did), your browser will load the appropriate JS > client > the next time you load the page. All parties in the chat will use the > same JS client under stackexchange's control, regardless whether > people have > used google, yahoo, or facebook to log in. There is no need to > standardize anything that crosses stackexchange's servers. > > Now you want to make a comment on some blog at blogspot.com. You point > your browser at the blog's URL and log in using your Yahoo OpenID. > The browser loads blogspot's JS client. The GUI looks quite different > but you can post your comment as well. > > With the current RTCWEB thinking, we would have to specify an intra > server protocol that covered stackexchange's discussion and chat > systems as well as blogspot comments. Such a protocol would soon get > very complex. > Such protocol is not possible across domains unless the host is the same. Only when the host is the same does intra- faces makes sense. --20cf3079babadbf53304af824555 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Oct 17, 2011 at 10:10 AM, Wolfgang Beck = <wol= fgang.beck01@googlemail.com> wrote:
On Mon, Oct 17, 2011 at 5:00 PM, Randell Jesup <randell-ietf@jesup.org> wrote:
> Ok, I looked at draft-beck-rtcweb-alt-ic.
>
> One huge problem with it: it's based on an assumption that for mos= t cases of
> federation and cross-service calls won't hold: that clients will u= se the
> same client JS app, and the services are just providing different
> realms/methods of authentication and user-lookup.
>
> Also, your draft doesn't explain how A & B came to be talking = to the same
> server in the first place. =A0The draft seems mostly focused on how a = single
> provider can use a shared authentication scheme (and I would suggest t= hat we
> try to find a provider-agnostic way to leverage id systems such as Bro= wserID
> and/or OpenID to provide end-user identification).
>
Ok, here's an example that works today. Let's assume you have= a yahoo
account and want to post a comment on stackexchange.com.
You just point your browser to the stackexchange.com url [i.e. user
location]. Now you log in using your yahoo account as OpenID. The
browser loads the stackexchanges's JS client that enables you to post your text. =A0There is no comment-posting-protocol required between
yahoo and
stackexchange. They only have to agree on an 3rd party authentication proto= col.

If stackexchange extends its functionality, let's say with real-time chat (which they did), your browser will load the appropriate JS
client
the next time you load the page. =A0All parties in the chat will use the same JS client under stackexchange's control, regardless whether
people have
used google, yahoo, or facebook to log in. There is no need to
standardize anything that crosses stackexchange's servers.

Now you want to make a comment on some blog at blogspot.com. You point
your browser at the blog's URL and log in using your Yahoo OpenID.
The browser loads blogspot's JS client. The GUI looks quite different but you can post your comment as well.

With the current RTCWEB thinking, we would have to specify an intra
server protocol that covered stackexchange's discussion and chat
systems as well as blogspot comments. Such a protocol would soon get
very complex.


Such proto= col is not possible across domains unless the host is the same.
<= br>
Only when the host is the same does intra- faces makes sense.=

--20cf3079babadbf53304af824555-- From randell-ietf@jesup.org Mon Oct 17 13:50: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 BA48F11E8073 for ; Mon, 17 Oct 2011 13:50:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.055, 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 90rN2fRRvIcw for ; Mon, 17 Oct 2011 13:50: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 D49AB21F8B79 for ; Mon, 17 Oct 2011 13:50: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 1RFu8X-00088a-Fi for rtcweb@ietf.org; Mon, 17 Oct 2011 15:50:17 -0500 Message-ID: <4E9C93F5.5070906@jesup.org> Date: Mon, 17 Oct 2011 16:45:41 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4E996E80.6070500@alvestrand.no> <8486C8728176924BAF5BDB2F7D7EEDDF3E0906A2@ucolhp4d.easf.csd.disa.mil> <4E9BA235.3010808@jesup.org> <4E9C430A.1070600@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] Signalling, SDP, and the way we think about interconnecting RTCWEB 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, 17 Oct 2011 20:50:21 -0000 On 10/17/2011 1:10 PM, Wolfgang Beck wrote: > On Mon, Oct 17, 2011 at 5:00 PM, Randell Jesup wrote: > >> Ok, I looked at draft-beck-rtcweb-alt-ic. >> >> One huge problem with it: it's based on an assumption that for most cases of >> federation and cross-service calls won't hold: that clients will use the >> same client JS app, and the services are just providing different >> realms/methods of authentication and user-lookup. >> >> Also, your draft doesn't explain how A& B came to be talking to the same >> server in the first place. The draft seems mostly focused on how a single >> provider can use a shared authentication scheme (and I would suggest that we >> try to find a provider-agnostic way to leverage id systems such as BrowserID >> and/or OpenID to provide end-user identification). >> > Ok, here's an example that works today. Let's assume you have a yahoo > account and want to post a comment on stackexchange.com. > You just point your browser to the stackexchange.com url [i.e. user > location]. Now you log in using your yahoo account as OpenID. The > browser loads the stackexchanges's JS client that enables you to post > your text. There is no comment-posting-protocol required between > yahoo and > stackexchange. They only have to agree on an 3rd party authentication protocol. Right; you're talking entirely about open/shared ID systems (ala BrowserID, OpenID, Facebook login (ugh), etc). > If stackexchange extends its functionality, let's say with real-time > chat (which they did), your browser will load the appropriate JS > client > the next time you load the page. All parties in the chat will use the > same JS client under stackexchange's control, regardless whether > people have > used google, yahoo, or facebook to log in. There is no need to > standardize anything that crosses stackexchange's servers. You're making the argument that no federation is needed, because to contact someone on stackexchange you'd browse to stackexchange first. I don't think that handles the use-cases of, from within say gmail, you try to call someone on Stackexchange - or even more unavoidable, you try to invite someone from stackexchange to join your already-running call. You can't exit out and load the stackexchange JS client. -- Randell Jesup randell-ietf@jesup.org From dzonatas@gmail.com Mon Oct 17 13:58: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 34F0E21F8BA8 for ; Mon, 17 Oct 2011 13:58:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.156 X-Spam-Level: X-Spam-Status: No, score=-3.156 tagged_above=-999 required=5 tests=[AWL=-0.442, 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 R-sAr85fF1gQ for ; Mon, 17 Oct 2011 13:58: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 13FD521F8B9F for ; Mon, 17 Oct 2011 13:58:12 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so3554437vcb.31 for ; Mon, 17 Oct 2011 13:58:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=2kaL5BllWpsE6eizemPnU4prBsOp38N12dUm+N1hxSA=; b=HH9W0n+C45rQsa6xPZ9vXo5o9vuioDWTeKVWW2C1V+8MOKEgCBbgzXpZssRwmI32Vw AcJ1ZrJbm0cLdgEzqHmbvDNkrPhnCy/DGYDlY4Mi8I5sLR0MGC+rjKKJey5xJCjuslyD uZgS64MRYDaVsJZyTZF9Yr5UPN+ZHsaX/wSzU= MIME-Version: 1.0 Received: by 10.52.37.72 with SMTP id w8mr21878108vdj.32.1318885092363; Mon, 17 Oct 2011 13:58:12 -0700 (PDT) Received: by 10.52.107.202 with HTTP; Mon, 17 Oct 2011 13:58:11 -0700 (PDT) In-Reply-To: <4E27EE6E.30600@alvestrand.no> References: <4E27EE6E.30600@alvestrand.no> Date: Mon, 17 Oct 2011 13:58:11 -0700 Message-ID: From: Dzonatas Sol To: rtcweb@ietf.org Content-Type: multipart/alternative; boundary=20cf307ac7836e0bb104af84ddb9 Subject: Re: [rtcweb] How to multiplex between peers X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 20:58:14 -0000 --20cf307ac7836e0bb104af84ddb9 Content-Type: text/plain; charset=ISO-8859-1 I got this Quantum Vibe link from an /. ad: http://shar.es/bqNgs I think that be a link-in-a-link, a meta-link, or a canonical multiplexer in pix#4; it applies to B2B and the server-to-server paradigm is not obvious. ...anymore. ;) On Thu, Jul 21, 2011 at 2:16 AM, Harald Alvestrand wrote: > On 07/21/11 02:41, Henry Sinnreich wrote: > >> +1 >> >> If anything this is an argument for ignoring RTP and RTCP and doing >>> something entirely new that is actually appropriate for what we're >>> trying to build, not living with crap just because there's an RFC for it. >>> >> Not to forget disposing of ancient SDP as well. >> Use standard metadata instead, since it is equally usable for all apps, >> not >> only for RTC apps. >> > Henry, which standard? > http://www.xkcd.com/927/ applies to metadata too, I think. > > > --20cf307ac7836e0bb104af84ddb9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I got this Quantum Vibe link from an /. ad:=A0http://shar.es/bqNgs
I think that be a link-in-a-link, a meta-link, or a c= anonical multiplexer in pix#4; it applies to B2B and the server-to-server p= aradigm is not obvious.

...anymore. ;)

On Thu, Jul 21, 2011 at 2:16 AM, Harald Alvestrand <harald@alvestrand.no> w= rote:
On 07/21/11 02:41, Henry Sinnreich wrote:
+1

If anything this is an argument for ignoring RTP and RTCP and doing
something entirely new that is actually appropriate for what we're
trying to build, not living with crap just because there's an RFC for i= t.
Not to forget disposing of ancient SDP as well.
Use standard metadata instead, since it is equally usable for all apps, not=
only for RTC apps.
Henry, which standard?
http://www.xkcd.com/= 927/ applies to metadata too, I think.


--20cf307ac7836e0bb104af84ddb9-- From pravindran@sonusnet.com Mon Oct 17 14:44: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 11DF81F0C45 for ; Mon, 17 Oct 2011 14:44:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.877 X-Spam-Level: X-Spam-Status: No, score=-2.877 tagged_above=-999 required=5 tests=[AWL=-0.578, 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 210v59uXuKlJ for ; Mon, 17 Oct 2011 14:44:12 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 045D41F0C36 for ; Mon, 17 Oct 2011 14:44:11 -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 p9HLihu5002134; Mon, 17 Oct 2011 17:44:43 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail06.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 17 Oct 2011 17:44:08 -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, 18 Oct 2011 03:13:57 +0530 Message-ID: <2E239D6FCD033C4BAF15F386A979BF51159954@sonusinmail02.sonusnet.com> In-Reply-To: <1F2A2C70609D9E41844A2126145FC0980416C9DD@HKGMBOXPRD22.polycom.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] Review request for RTCWeb standard signaling protocol Thread-Index: AcyM5Jfz3IeIkoa8S7WSCIWq+duQ2QAAeHWQAAJDGiUACYxAkA== References: <2E239D6FCD033C4BAF15F386A979BF510F1367@sonusinmail02.sonusnet.com><4E8AC222.4050308@alvestrand.no><2E239D6FCD033C4BAF15F386A979BF510F14CE@sonusinmail02.sonusnet.com><2E239D6FCD033C4BAF15F386A979BF510F14FD@sonusinmail02.sonusnet.com><393F1888-F834-4DAE-B6B1-1C5D35EE3292@phonefromhere.com><2E239D6FCD033C4BAF15F386A979BF510F152B@sonusinmail02.sonusnet.com><2E239D6FCD033C4BAF15F386A979BF510F1532@sonusinmail02.sonusnet.com><2E239D6FCD033C4BAF15F386A979BF511598EE@sonusinmail02.sonusnet.com><665A16AB-AAD8-42B3-AC17-7E629EA2DE35@phonefromhere.com><2E239D6FCD033C4BAF15F386A979BF5115992E@sonusinmail02.sonusnet.com>, <2E239D6FCD033C4BAF15F38 6A979BF5 1159950@sonu sinmail02.sonusnet.com> <1F2A2C70609D9E41844A2126145FC0980416C9DD@HKGMBOXPRD22.polycom.com> From: "Ravindran Parthasarathi" To: "Avasarala, Ranjit" , =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= X-OriginalArrivalTime: 17 Oct 2011 21:44:08.0875 (UTC) FILETIME=[E68D47B0:01CC8D15] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Review request for RTCWeb standard 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, 17 Oct 2011 21:44:13 -0000 Hi Ranjit, I agree with you for using signaling protocol to be used over websocket. Thanks Partha >-----Original Message----- >From: Avasarala, Ranjit [mailto:Ranjit.Avasarala@Polycom.com] >Sent: Monday, October 17, 2011 10:39 PM >To: Ravindran Parthasarathi; I=F1aki Baz Castillo >Cc: rtcweb@ietf.org >Subject: RE: [rtcweb] Review request for RTCWeb standard signaling >protocol > >Hi Partha > >Though I agree with you that SIP over Websockets is an overkill on web >browsers, there is a need for some kind of signaling protocol for >communicating offer / answer model between 2 web browser clients. This >was one of my comments on Inaki's SIP over Websockets transport. > >My point is there is a need for some kind of signaling protocol to be >used over Websockets - be it SIP or XMPP - but these should be used as >Websocket sub protocol. > >Regards >Ranjit >________________________________________ >From: rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] On Behalf Of >Ravindran Parthasarathi [pravindran@sonusnet.com] >Sent: Monday, October 17, 2011 10:30 PM >To: I=F1aki Baz Castillo >Cc: rtcweb@ietf.org >Subject: Re: [rtcweb] Review request for RTCWeb standard signaling >protocol > >The point to be noted is folks put forth the same argument again & >again..each time, it is not possible to come up new answer ;-) I = noticed >often you complain as if your important is missed out. We are arguing >only about "nothing" vs "something" as a RTCWeb signaling protocol. > >I clearly explained why SIP over websocket is an overkill in the below >mail thread. Please read it and don't argue that it is working. All the >working stuff is not good. Infact for any protocol, the first idea pop- >up is to tunnel the complete inside (For Ex: ISUP over SIP) but always >better ways to solve it. > >I think that you confusing the argument with script & protocol. I agree >that WWW world works with PHP for server side and Javascript, CSS for >client side but I'm talking about HTTP protocol in case of legacy web. >Of course, HTTP is not designed for real-time communication. So, we = need >some signaling protocol like Jingle, Websocket with offer/answer (ROAP) >to make it work. Let us talk about the protocol and not about the >programming environment. > >The base idea of defining the protocol is to provide the basic building >blocks and new service shall be developed using these building block. = In >case basic building block is well defined, building the new service = will >not be impossible. Normally, standard protocol will undergo through >review which the basic new service needs. > >I'm talking about the performance because I know that success story SIP >written in C over SIP written in Java. In case you argue for SIP plugin >vs native SIP, the performance may not be much difference. Also, the >download of the entire protocol is worse than in-build protocol by any >means. > >-Partha > >>-----Original Message----- >>From: I=F1aki Baz Castillo [mailto:ibc@aliax.net] >>Sent: Monday, October 17, 2011 9:21 PM >>To: Ravindran Parthasarathi >>Cc: Tim Panton; rtcweb@ietf.org >>Subject: Re: [rtcweb] Review request for RTCWeb standard signaling >>protocol >> >>2011/10/17 Ravindran Parthasarathi : >> >>Again the same... >> >>Ravindran, you are repeating the *same* arguments in different >>mails/threads. You always *ignore* and don't reply to responses given >>to your arguments. You are also manipulating some given responses by >>making them to look as if their content agree with your insistent >>proposal. >> >>You are trying to manipulate this WG and that is dishonest. STOP >please. >> >>Unfortunatelly for you, your mails will always receive the deserved >>response: >> >> >> >>> I'm not favor Inaki solution of SIP over websocket because >it >>is >>> overkill for signaling protocol. >> >>Demonstrate it !!! >> >>I know that SIP over websocket is NOT an overkill (because I *use* >>it). You DONT KNOW the opposite. You CANNOT assert the opposite. >>Stop lying please! >> >> >>> Websocket solves routing issues between >>> browser-webserver- browser, so the lightweight protocol over >websocket >>will >>> be sufficient and there is no need of complicated SIP based >Javascript >>> stack. >> >>Use whatever you want but don't force me to use what you want. Neither >>insist on creating a "default signaling protocol" for the reaons given >>1000 times in this maillist (those reasons you ignore again and again >>and you will NEVER reply to). >> >> >>> Also, I'm not believer of the downloading complete signaling = protocol >>script >>> because it will delay the setup time which is crucial in lot of = real- >>time >>> application. Of course, it may not be critical for free application >>but not >>> for professional services. >> >>So you don't understand how the WWW works. The user visits a web page, >>the browser downloads all the HTML, CSS, images and JavaScript stuff >>and, *after that*, the web application is ready to be used. It does >>not depend just on having a signaling protocol built-in the browser. >> >>Now the problem is downloading a ~150KB JavaScript file??? There are >>images taking more space in lot of webs! >> >> >>> AFAIK, signaling protocol codebase expands very quickly with the >>addition of >>> new services and leads to more delay in the setup of the session. >> >> >>And how is supposed your proposed "default signaling protocol" to >>handle those "new services"? If you try NOW to make a "default >>signaling protocol" for RTCweb that means that you MUST know *NOW* all >>the possible requirements of any RTCweb future communication. You >>don't know them, I don't know them, nobody knows them! >> >> >> >> >>-- >>I=F1aki Baz Castillo >> >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb From ted.ietf@gmail.com Mon Oct 17 14:51: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 ABB6B21F8AAA for ; Mon, 17 Oct 2011 14:51:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[AWL=0.028, 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 rzViaqutFDGU for ; Mon, 17 Oct 2011 14:51:01 -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 DF90621F84D1 for ; Mon, 17 Oct 2011 14:51:00 -0700 (PDT) Received: by ywa8 with SMTP id 8so1178551ywa.31 for ; Mon, 17 Oct 2011 14:51:00 -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=02KRVjS1j7Z93D7rVZ/hzIyZSTWKT8m6cKwvlT7o7OY=; b=szMcPCScamwuCkpe7ZFEK2ckwBOqKWufa89xmhIUEdyu8CKNEJDqOVAxyRN8xlKqHU RYJffVqAtOVzhHTCNyVry5edu9XOXSrXe5K4cxXLnKLImpmjrmhzMPFrrDSbFYlY8nec ut5a8Cziqaqhd5PUREP7DHqljUhmrlx6YZJc8= MIME-Version: 1.0 Received: by 10.236.186.102 with SMTP id v66mr13033299yhm.108.1318888260464; Mon, 17 Oct 2011 14:51:00 -0700 (PDT) Received: by 10.236.105.169 with HTTP; Mon, 17 Oct 2011 14:51:00 -0700 (PDT) In-Reply-To: References: <4E27EE6E.30600@alvestrand.no> Date: Mon, 17 Oct 2011 14:51:00 -0700 Message-ID: From: Ted Hardie To: Dzonatas Sol Content-Type: multipart/alternative; boundary=20cf30563e17436e6104af859a4f Cc: rtcweb@ietf.org Subject: Re: [rtcweb] How to multiplex between peers X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 21:51:02 -0000 --20cf30563e17436e6104af859a4f Content-Type: text/plain; charset=ISO-8859-1 Dzonatas, Your emails to the group have become less and less on point over time. Please send email to the group only when you have substantive comments on the work going on. If you do not, the chairs may have to consider suspending your right to post. regards, Ted Hardie On Mon, Oct 17, 2011 at 1:58 PM, Dzonatas Sol wrote: > I got this Quantum Vibe link from an /. ad: http://shar.es/bqNgs > > I think that be a link-in-a-link, a meta-link, or a canonical multiplexer > in pix#4; it applies to B2B and the server-to-server paradigm is not > obvious. > > ...anymore. ;) > > On Thu, Jul 21, 2011 at 2:16 AM, Harald Alvestrand wrote: > >> On 07/21/11 02:41, Henry Sinnreich wrote: >> >>> +1 >>> >>> If anything this is an argument for ignoring RTP and RTCP and doing >>>> something entirely new that is actually appropriate for what we're >>>> trying to build, not living with crap just because there's an RFC for >>>> it. >>>> >>> Not to forget disposing of ancient SDP as well. >>> Use standard metadata instead, since it is equally usable for all apps, >>> not >>> only for RTC apps. >>> >> Henry, which standard? >> http://www.xkcd.com/927/ applies to metadata too, I think. >> >> >> > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --20cf30563e17436e6104af859a4f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dzonatas,

Your emails to the group have become less and less on poin= t over time.=A0 Please send email to the group only when you have substanti= ve comments on the work going on.=A0 If you do not, the chairs may have to = consider suspending your right to post.

regards,

Ted Hardie

On Mon, Oc= t 17, 2011 at 1:58 PM, Dzonatas Sol <dzonatas@gmail.com> wrote:
I got this Quantum Vibe link from an /. ad:=A0http://shar.es/bqNg= s

<= div>I think that be a lin= k-in-a-link, a meta-link, or a canonical multiplexer in pix#4; it applies t= o B2B and the server-to-server paradigm is not obvious.

...anymore. ;)

 On Thu, Jul 21, 2011 at 2:16 AM, Harald Alvestrand <harald@alvestrand.n= o> wrote:
On 07/21/11 02:41, Henry Sinnreich wrote:
+1

If anything this is an argument for ignoring RTP and RTCP and doing
something entirely new that is actually appropriate for what we're
trying to build, not living with crap just because there's an RFC for i= t.
Not to forget disposing of ancient SDP as well.
Use standard metadata instead, since it is equally usable for all apps, not=
only for RTC apps.
Henry, which standard?
http://www.xkcd.com/= 927/ applies to metadata too, I think.



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


--20cf30563e17436e6104af859a4f-- From roman@telurix.com Mon Oct 17 15:00: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 DE4F121F8B43 for ; Mon, 17 Oct 2011 15:00:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.422 X-Spam-Level: X-Spam-Status: No, score=-2.422 tagged_above=-999 required=5 tests=[AWL=-0.329, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 QhEBDbZA9Yc9 for ; Mon, 17 Oct 2011 15:00:05 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1323E21F8B3F for ; Mon, 17 Oct 2011 15:00:05 -0700 (PDT) Received: by gyh20 with SMTP id 20so4206701gyh.31 for ; Mon, 17 Oct 2011 15:00:04 -0700 (PDT) Received: by 10.68.38.74 with SMTP id e10mr12447559pbk.78.1318888804191; Mon, 17 Oct 2011 15:00:04 -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 z3sm206048pbu.7.2011.10.17.15.00.02 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 17 Oct 2011 15:00:03 -0700 (PDT) Received: by pzk34 with SMTP id 34so7984250pzk.9 for ; Mon, 17 Oct 2011 15:00:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.8.233 with SMTP id u9mr12123pba.30.1318888802028; Mon, 17 Oct 2011 15:00:02 -0700 (PDT) Received: by 10.68.47.40 with HTTP; Mon, 17 Oct 2011 15:00:01 -0700 (PDT) In-Reply-To: References: <4E27EE6E.30600@alvestrand.no> Date: Mon, 17 Oct 2011 18:00:01 -0400 Message-ID: From: Roman Shpount To: Ted Hardie Content-Type: multipart/alternative; boundary=bcaec5215a598b0d0f04af85bab8 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] How to multiplex between peers X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 22:00:06 -0000 --bcaec5215a598b0d0f04af85bab8 Content-Type: text/plain; charset=ISO-8859-1 In case you did not notice, Dzonatas Sol is a bot. I would suggest just spam filtering it. _____________ Roman Shpount On Mon, Oct 17, 2011 at 5:51 PM, Ted Hardie wrote: > Dzonatas, > > Your emails to the group have become less and less on point over time. > Please send email to the group only when you have substantive comments on > the work going on. If you do not, the chairs may have to consider > suspending your right to post. > > regards, > > Ted Hardie > > On Mon, Oct 17, 2011 at 1:58 PM, Dzonatas Sol wrote: > >> I got this Quantum Vibe link from an /. ad: http://shar.es/bqNgs >> >> I think that be a link-in-a-link, a meta-link, or a canonical multiplexer >> in pix#4; it applies to B2B and the server-to-server paradigm is not >> obvious. >> >> ...anymore. ;) >> >> On Thu, Jul 21, 2011 at 2:16 AM, Harald Alvestrand wrote: >> >>> On 07/21/11 02:41, Henry Sinnreich wrote: >>> >>>> +1 >>>> >>>> If anything this is an argument for ignoring RTP and RTCP and doing >>>>> something entirely new that is actually appropriate for what we're >>>>> trying to build, not living with crap just because there's an RFC for >>>>> it. >>>>> >>>> Not to forget disposing of ancient SDP as well. >>>> Use standard metadata instead, since it is equally usable for all apps, >>>> not >>>> only for RTC apps. >>>> >>> Henry, which standard? >>> http://www.xkcd.com/927/ applies to metadata too, I think. >>> >>> >>> >> _______________________________________________ >> 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 > > --bcaec5215a598b0d0f04af85bab8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable In case you did not notice, Dzonatas Sol is a bot. I would suggest just spa= m filtering it.
_____________
Roman Shpount


On Mon, Oct 17, 2011 at 5:51 PM, Ted Har= die <ted.ietf@gm= ail.com> wrote:
Dzonatas,

Your emails to the group have become less and less on poin= t over time.=A0 Please send email to the group only when you have substanti= ve comments on the work going on.=A0 If you do not, the chairs may have to = consider suspending your right to post.

regards,

Ted Hardie

On Mon, Oc= t 17, 2011 at 1:58 PM, Dzonatas Sol <dzonatas@gmail.com> wr= ote:
I got this Quantum Vibe link from an /. ad:=A0http://shar.es/bqNg= s

<= div>I think that be a lin= k-in-a-link, a meta-link, or a canonical multiplexer in pix#4; it applies t= o B2B and the server-to-server paradigm is not obvious.

...anymore. ;)

 On Thu, Jul 21, 2011 at 2:16 AM, Harald Alvestrand <harald@alvestrand.n= o> wrote:
On 07/21/11 02:41, Henry Sinnreich wrote:
+1

If anything this is an argument for ignoring RTP and RTCP and doing
something entirely new that is actually appropriate for what we're
trying to build, not living with crap just because there's an RFC for i= t.
Not to forget disposing of ancient SDP as well.
Use standard metadata instead, since it is equally usable for all apps, not=
only for RTC apps.
Henry, which standard?
http://www.xkcd.com/= 927/ applies to metadata too, I think.



_______________________________________________
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


--bcaec5215a598b0d0f04af85bab8-- From pravindran@sonusnet.com Mon Oct 17 15:28: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 2AF121F0C4C for ; Mon, 17 Oct 2011 15:28:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.908 X-Spam-Level: X-Spam-Status: No, score=-2.908 tagged_above=-999 required=5 tests=[AWL=-0.309, 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 5Al+8JskyIn8 for ; Mon, 17 Oct 2011 15:28:23 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 5B40F1F0C43 for ; Mon, 17 Oct 2011 15:28:23 -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 p9HMStnd030335; Mon, 17 Oct 2011 18:28:55 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail06.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 17 Oct 2011 18:28:21 -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, 18 Oct 2011 03:58:03 +0530 Message-ID: <2E239D6FCD033C4BAF15F386A979BF51159957@sonusinmail02.sonusnet.com> In-Reply-To: <15B0E3AD-3086-499A-8E79-7AE58B3376C4@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] SDP Offer/Answer draft-jennings-rtcweb-signaling Thread-Index: AcyK59gjnHrw6AUkQx6KmrMgad4vKACMb4Ng References: <15B0E3AD-3086-499A-8E79-7AE58B3376C4@cisco.com> From: "Ravindran Parthasarathi" To: "Cullen Jennings" , , X-OriginalArrivalTime: 17 Oct 2011 22:28:21.0388 (UTC) FILETIME=[1392A4C0:01CC8D1C] Cc: Jonathan Rosenberg Subject: Re: [rtcweb] SDP Offer/Answer draft-jennings-rtcweb-signaling X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 22:28:24 -0000 Cullen/Joanthan, I like your proposed idea as it is going in the direction of having "standard" signaling protocol for RTCWeb. I'm seeing your proposal as SDP offer/answer over websocket and the proposal helps to easy gateway development between RTCWeb server and legacy signaling protocols. I have fundamental question in the proposal as it proposes RTCWeb server as SIP proxy equivalent and in reality, unfortunately most of the SIP deployment work is based on B2BUA. The question is whether RTCWeb server shall be dialog-state or MUST be transaction-stateful only.=20 Also, session-id in the draft is used to uniquely understand the offerer and answerer in the transaction or session. In case it is session, how to indicate the termination of the session. Thanks Partha >-----Original Message----- >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf >Of Cullen Jennings >Sent: Saturday, October 15, 2011 8:39 AM >To: rtcweb@ietf.org; public-webrtc@w3.org >Cc: Jonathan Rosenberg >Subject: [rtcweb] SDP Offer/Answer draft-jennings-rtcweb-signaling > > >Jonathan and I submitted a new draft on setting up media based on the >SDP Offer/Answer model. The ASCII flows are a bit hard to read so until >I update them, I recommend reading the PDF version at > >http://tools.ietf.org/pdf/draft-jennings-rtcweb-signaling-00.pdf > >Clearly the draft is an early stage but we plan to revise it before the >deadline for the IETF 82. Love to get input - particularly on if this >looks like generally the right direction to go. > > >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb From ibc@aliax.net Mon Oct 17 15:41: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 13A8B21F87E2 for ; Mon, 17 Oct 2011 15:41: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=[AWL=0.078, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vNeK8sT5wTcc for ; Mon, 17 Oct 2011 15:41: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 7631421F8593 for ; Mon, 17 Oct 2011 15:41:06 -0700 (PDT) Received: by vws5 with SMTP id 5so3649584vws.31 for ; Mon, 17 Oct 2011 15:41:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.73.166 with SMTP id m6mr5850765vdv.18.1318891261698; Mon, 17 Oct 2011 15:41:01 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Mon, 17 Oct 2011 15:41:01 -0700 (PDT) In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF51159957@sonusinmail02.sonusnet.com> References: <15B0E3AD-3086-499A-8E79-7AE58B3376C4@cisco.com> <2E239D6FCD033C4BAF15F386A979BF51159957@sonusinmail02.sonusnet.com> Date: Tue, 18 Oct 2011 00:41: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: Jonathan Rosenberg , rtcweb@ietf.org, public-webrtc@w3.org Subject: Re: [rtcweb] SDP Offer/Answer draft-jennings-rtcweb-signaling X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 22:41:07 -0000 2011/10/18 Ravindran Parthasarathi : > I like your proposed idea as it is going in the direction of having > "standard" signaling protocol for RTCWeb. Please Ravindran, don't manipulate mails, text and draft given by other persons in this WG. The draft *clearly* says: -------------------- The protocol specified here defines the state machines, semantic behaviors, and messages that are exchanged between instances of the state machines. ***However, it does not specify the actual on-the-wire transport of these messages.*** Rather, it assumes that the implementation of this protocol would occur within the browser itself, and then browser APIs would allow the application's JavaScript to request creation of messages and insert messages into the state machine. ***The actual transfer of these messages would be the responsibility of the web application, and would utilize protocols such as HTTP and WebSockets.*** To facilitate implementation within a browser, JSON notation is used to describe the message -------------------- No, this is not a draft about a "default signaling protocol" for RTCweb. Wrong. This is just a protocol for communication between the JavaScript code and the RTCweb stack in the browser. It does NOT mandate how the signaling messages are sent on-the-wire. So this has nothing to do with your insistent proposal of having a "default signaling protocol" that all the RTCweb clients "should implement". Sorry. --=20 I=C3=B1aki Baz Castillo From dzonatas@gmail.com Mon Oct 17 15:41: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 3976221F8A58 for ; Mon, 17 Oct 2011 15:41:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.046 X-Spam-Level: X-Spam-Status: No, score=-3.046 tagged_above=-999 required=5 tests=[AWL=-0.331, 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 99IFkg78S2MH for ; Mon, 17 Oct 2011 15:41: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 12A2D21F87FC for ; Mon, 17 Oct 2011 15:41:09 -0700 (PDT) Received: by mail-vw0-f44.google.com with SMTP id 5so3649584vws.31 for ; Mon, 17 Oct 2011 15:41:09 -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 :content-type; bh=nMuyq9feN3AUGUzbtLkZ/GxHiZlNXKCfsTF13qOW0/s=; b=yCFWbTlEgwZM+DptkYmTN0nF9hLFCQ5/MGkBgJFQnTas25SFe0B/En37pIqUWvugYd 27pDlHPYq5z6xoBdg4Kmfcygb2lEeHdpzkw1po8XAebCoGB8GnQGREENajfTIXEmmeCu a1btuiY3UchJGNMAKRZk977GkjtzIuvFj9gpw= MIME-Version: 1.0 Received: by 10.52.117.233 with SMTP id kh9mr21893224vdb.117.1318891269769; Mon, 17 Oct 2011 15:41:09 -0700 (PDT) Received: by 10.52.107.202 with HTTP; Mon, 17 Oct 2011 15:41:09 -0700 (PDT) In-Reply-To: References: <4E27EE6E.30600@alvestrand.no> Date: Mon, 17 Oct 2011 15:41:09 -0700 Message-ID: From: Dzonatas Sol To: rtcweb@ietf.org Content-Type: multipart/alternative; boundary=bcaec547c579a1c89304af864db9 Subject: Re: [rtcweb] How to multiplex between peers X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 22:41:11 -0000 --bcaec547c579a1c89304af864db9 Content-Type: text/plain; charset=ISO-8859-1 Hi Ted, I consider my posts very appropriate and I weigh my posts in on security by obscurity within well-known physical limits. I respect that not everybody subscribes to like means of security. If you can't see in the pix, its shows the real-time link in much less obscure way that is drawn out than what others desire as plainly written. That link pointed to strip #216, yet pix #4 is the one I pointed out. I think that link I put may show "the web" yet not "the internet". We can not use "the web" in all practical sense of plain English; although, that's an obvious mobile bias we all want. I think my point that JSON is some codeword for websocket fits well even if it is less than best solution. Thanks for E911 heads up on this list. I thought it would help me find my lost children being real-time, yet at least people would listen to someone who really is going through these kinds of use-cases. Always... W.I.P.: draft-ballard-smile-some-how; intro: "the energy comes from somewhere." Abstract: composure. There are so many things I can think about how my child would not have been snatch away in real-time if such-n-such worked, yet technology today still really sucks for that, especially when people care about their own litigation and profit than what could have been done for home. P.S. Seriously, do I need to sign-up for a turing test, again, before I can get any body to help me solve issues with missing children instead of being called "bot", especially in real-time. I thought not, so that is why I am here to help improve the god damn lame duck situation. On Mon, Oct 17, 2011 at 2:51 PM, Ted Hardie wrote: > Dzonatas, > > Your emails to the group have become less and less on point over time. > Please send email to the group only when you have substantive comments on > the work going on. If you do not, the chairs may have to consider > suspending your right to post. > > regards, > > Ted Hardie > > On Mon, Oct 17, 2011 at 1:58 PM, Dzonatas Sol wrote: > >> I got this Quantum Vibe link from an /. ad: http://shar.es/bqNgs >> >> I think that be a link-in-a-link, a meta-link, or a canonical multiplexer >> in pix#4; it applies to B2B and the server-to-server paradigm is not >> obvious. >> >> ...anymore. ;) >> >> On Thu, Jul 21, 2011 at 2:16 AM, Harald Alvestrand wrote: >> >>> On 07/21/11 02:41, Henry Sinnreich wrote: >>> >>>> +1 >>>> >>>> If anything this is an argument for ignoring RTP and RTCP and doing >>>>> something entirely new that is actually appropriate for what we're >>>>> trying to build, not living with crap just because there's an RFC for >>>>> it. >>>>> >>>> Not to forget disposing of ancient SDP as well. >>>> Use standard metadata instead, since it is equally usable for all apps, >>>> not >>>> only for RTC apps. >>>> >>> Henry, which standard? >>> http://www.xkcd.com/927/ applies to metadata too, I think. >>> >>> >>> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> >> > --bcaec547c579a1c89304af864db9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Ted,

I consider my posts very appropriate and I weigh= my posts in on security by obscurity within well-known physical limits. I = respect that not everybody subscribes to like means of security.

If you can't see in the pix, its shows the real-time lin= k in much less obscure way that is drawn out than what others desire as pla= inly written. That link pointed to strip #216, yet pix #4 is the one I poin= ted out.

I think that link I put may show "the web" ye= t not "the internet". We can not use "the web" in all p= ractical sense of plain English; although, that's an obvious mobile bia= s we all want.

I think my point that JSON is some codeword for websock= et fits well even if it is less than best solution.

Thanks for E911 heads up on this list. I thought it would help me find my= lost children being real-time, yet at least people would listen to someone= who really is going through these kinds of use-cases. =A0Always... W.I.P.:= =A0draft-ballard-smile-some-how; intro: "the energy comes from somewh= ere." Abstract: composure.

There are so many things I can think about how my child= would not have been snatch away in real-time if such-n-such worked, yet te= chnology today still really sucks for that, especially when people care abo= ut their own litigation and profit than what could have been done for home.=

P.S. Seriously, do I need to sign-up for a turing test,= again, before I can get any body to help me solve issues with missing chil= dren instead of being called "bot", especially in real-time. I th= ought not, so that is why I am here to help improve the god damn lame duck = situation.

On Mon, Oct 17, 2011 at 2:51 PM, Ted Hardie <ted.ietf@gmail.com> wrote:
Dzonatas,

Your emails to the group have become less and less on poin= t over time.=A0 Please send email to the group only when you have substanti= ve comments on the work going on.=A0 If you do not, the chairs may have to = consider suspending your right to post.

regards,

Ted Hardie

I got this Quantum Vibe link from an /. ad:=A0http://shar.es/bqNg= s

<= div>I think that be a lin= k-in-a-link, a meta-link, or a canonical multiplexer in pix#4; it applies t= o B2B and the server-to-server paradigm is not obvious.

...anymore. ;)

 On Thu, Jul 21, 2011 at 2:16 AM, Harald Alvestrand <harald@alvestrand.n= o> wrote:
On 07/21/11 02:41, Henry Sinnreich wrote:
+1

If anything this is an argument for ignoring RTP and RTCP and doing
something entirely new that is actually appropriate for what we're
trying to build, not living with crap just because there's an RFC for i= t.
Not to forget disposing of ancient SDP as well.
Use standard metadata instead, since it is equally usable for all apps, not=
only for RTC apps.
Henry, which standard?
http://www.xkcd.com/= 927/ applies to metadata too, I think.



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



--bcaec547c579a1c89304af864db9-- From pravindran@sonusnet.com Mon Oct 17 16:00: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 3646C1F0C49 for ; Mon, 17 Oct 2011 16:00:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.687 X-Spam-Level: X-Spam-Status: No, score=-2.687 tagged_above=-999 required=5 tests=[AWL=-0.388, 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 1+cJJjrAXqag for ; Mon, 17 Oct 2011 16:00:14 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 4B12B1F0C43 for ; Mon, 17 Oct 2011 16:00:14 -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 p9HN0kfx018917; Mon, 17 Oct 2011 19:00:46 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail05.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 17 Oct 2011 19:00:11 -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, 18 Oct 2011 04:29:52 +0530 Message-ID: <2E239D6FCD033C4BAF15F386A979BF51159959@sonusinmail02.sonusnet.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] SDP Offer/Answer draft-jennings-rtcweb-signaling Thread-Index: AcyNHduOwxTHqnVzSKKXipjSzCRdYwAAZJCQ References: <15B0E3AD-3086-499A-8E79-7AE58B3376C4@cisco.com><2E239D6FCD033C4BAF15F386A979BF51159957@sonusinmail02.sonusnet.com> From: "Ravindran Parthasarathi" To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= X-OriginalArrivalTime: 17 Oct 2011 23:00:11.0961 (UTC) FILETIME=[865CF290:01CC8D20] Cc: Jonathan Rosenberg , rtcweb@ietf.org, public-webrtc@w3.org Subject: Re: [rtcweb] SDP Offer/Answer draft-jennings-rtcweb-signaling X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 23:00:15 -0000 SW5ha2ksDQoNCkhlYXZlbiBzYWtlLCBQbGVhc2UgcmVwbHkgd2l0aCBvcmlnaW5hbCB0ZXh0LiBZ b3UgYWx3YXlzIGN1dCB0aGUgdGV4dCBpbiByZXBseSBzbyBiYWRseSB0aGF0IEkgaGF2ZSB0byBy ZXBlYXQgd2hhdCBJIGhhdmUgc2FpZCBpbiB0aGUgb3JpZ2luYWwgbWFpbCBhZ2FpbiBpbiB0aGUg cmVwbHkuIFlvdXIgY3V0dGluZyBwcmFjdGljZSBsZWFkcyB0byBjaXJjdWxhciBkaXNjdXNzaW9u IGFuZCBsZXQgdXMgdHJ5IHRvIGF2b2lkIGl0Lg0KDQpPcmlnaW5hbCBtYWlsIHN0YXRlbWVudCBp cyBhcyBmb2xsb3dzOg0KPHNuaXA+DQpJJ20gc2VlaW5nIHlvdXIgcHJvcG9zYWwgYXMgU0RQIG9m ZmVyL2Fuc3dlciBvdmVyIHdlYnNvY2tldA0KPC9zbmlwPg0KDQpIb3BlIHRoaXMgY2xhcmlmeSB3 aGF0IEkgbWVhbnQuIEFsc28sIFBsZWFzZSBzZWUgYnVsbGV0IDIgaW4gc2VjIDYgb2YgZHJhZnQt cGFydGhhLXJ0Y3dlYi1zaWduYWxpbmctMDAgdG8gZ2V0IHRoZSB3aG9sZSBwaWN0dXJlLg0KDQpU aGFua3MsDQpQYXJ0aGENCg0KPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+RnJvbTogScOx YWtpIEJheiBDYXN0aWxsbyBbbWFpbHRvOmliY0BhbGlheC5uZXRdDQo+U2VudDogVHVlc2RheSwg T2N0b2JlciAxOCwgMjAxMSA0OjExIEFNDQo+VG86IFJhdmluZHJhbiBQYXJ0aGFzYXJhdGhpDQo+ Q2M6IEN1bGxlbiBKZW5uaW5nczsgcnRjd2ViQGlldGYub3JnOyBwdWJsaWMtd2VicnRjQHczLm9y ZzsgSm9uYXRoYW4NCj5Sb3NlbmJlcmcNCj5TdWJqZWN0OiBSZTogW3J0Y3dlYl0gU0RQIE9mZmVy L0Fuc3dlciBkcmFmdC1qZW5uaW5ncy1ydGN3ZWItc2lnbmFsaW5nDQo+DQo+MjAxMS8xMC8xOCBS YXZpbmRyYW4gUGFydGhhc2FyYXRoaSA8cHJhdmluZHJhbkBzb251c25ldC5jb20+Og0KPj4gSSBs aWtlIHlvdXIgcHJvcG9zZWQgaWRlYSBhcyBpdCBpcyBnb2luZyBpbiB0aGUgZGlyZWN0aW9uIG9m IGhhdmluZw0KPj4gInN0YW5kYXJkIiBzaWduYWxpbmcgcHJvdG9jb2wgZm9yIFJUQ1dlYi4NCj4N Cj5QbGVhc2UgUmF2aW5kcmFuLCBkb24ndCBtYW5pcHVsYXRlIG1haWxzLCB0ZXh0IGFuZCBkcmFm dCBnaXZlbiBieQ0KPm90aGVyIHBlcnNvbnMgaW4gdGhpcyBXRy4gVGhlIGRyYWZ0ICpjbGVhcmx5 KiBzYXlzOg0KPg0KPi0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+VGhlIHByb3RvY29sIHNwZWNpZmll ZCBoZXJlIGRlZmluZXMgdGhlIHN0YXRlIG1hY2hpbmVzLCBzZW1hbnRpYw0KPmJlaGF2aW9ycywg YW5kIG1lc3NhZ2VzIHRoYXQgYXJlIGV4Y2hhbmdlZCBiZXR3ZWVuIGluc3RhbmNlcyBvZiB0aGUN Cj5zdGF0ZSBtYWNoaW5lcy4gKioqSG93ZXZlciwgaXQgZG9lcyBub3Qgc3BlY2lmeSB0aGUgYWN0 dWFsIG9uLXRoZS13aXJlDQo+dHJhbnNwb3J0IG9mIHRoZXNlIG1lc3NhZ2VzLioqKiBSYXRoZXIs IGl0IGFzc3VtZXMgdGhhdCB0aGUNCj5pbXBsZW1lbnRhdGlvbiBvZiB0aGlzIHByb3RvY29sIHdv dWxkIG9jY3VyIHdpdGhpbiB0aGUgYnJvd3NlciBpdHNlbGYsDQo+YW5kIHRoZW4gYnJvd3NlciBB UElzIHdvdWxkIGFsbG93IHRoZSBhcHBsaWNhdGlvbidzIEphdmFTY3JpcHQgdG8NCj5yZXF1ZXN0 IGNyZWF0aW9uIG9mIG1lc3NhZ2VzIGFuZCBpbnNlcnQgbWVzc2FnZXMgaW50byB0aGUgc3RhdGUN Cj5tYWNoaW5lLiAqKipUaGUgYWN0dWFsIHRyYW5zZmVyIG9mIHRoZXNlIG1lc3NhZ2VzIHdvdWxk IGJlIHRoZQ0KPnJlc3BvbnNpYmlsaXR5IG9mIHRoZSB3ZWIgYXBwbGljYXRpb24sIGFuZCB3b3Vs ZCB1dGlsaXplIHByb3RvY29scw0KPnN1Y2ggYXMgSFRUUCBhbmQgV2ViU29ja2V0cy4qKiogVG8g ZmFjaWxpdGF0ZSBpbXBsZW1lbnRhdGlvbiB3aXRoaW4gYQ0KPmJyb3dzZXIsIEpTT04gbm90YXRp b24gaXMgdXNlZCB0byBkZXNjcmliZSB0aGUgbWVzc2FnZQ0KPi0tLS0tLS0tLS0tLS0tLS0tLS0t DQo+DQo+Tm8sIHRoaXMgaXMgbm90IGEgZHJhZnQgYWJvdXQgYSAiZGVmYXVsdCBzaWduYWxpbmcg cHJvdG9jb2wiIGZvcg0KPlJUQ3dlYi4gV3JvbmcuIFRoaXMgaXMganVzdCBhIHByb3RvY29sIGZv ciBjb21tdW5pY2F0aW9uIGJldHdlZW4gdGhlDQo+SmF2YVNjcmlwdCBjb2RlIGFuZCB0aGUgUlRD d2ViIHN0YWNrIGluIHRoZSBicm93c2VyLiBJdCBkb2VzIE5PVA0KPm1hbmRhdGUgaG93IHRoZSBz aWduYWxpbmcgbWVzc2FnZXMgYXJlIHNlbnQgb24tdGhlLXdpcmUuDQo+DQo+U28gdGhpcyBoYXMg bm90aGluZyB0byBkbyB3aXRoIHlvdXIgaW5zaXN0ZW50IHByb3Bvc2FsIG9mIGhhdmluZyBhDQo+ ImRlZmF1bHQgc2lnbmFsaW5nIHByb3RvY29sIiB0aGF0IGFsbCB0aGUgUlRDd2ViIGNsaWVudHMg InNob3VsZA0KPmltcGxlbWVudCIuIFNvcnJ5Lg0KPg0KPg0KPi0tDQo+ScOxYWtpIEJheiBDYXN0 aWxsbw0KPjxpYmNAYWxpYXgubmV0Pg0K From dzonatas@gmail.com Mon Oct 17 16:03: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 476B211E8095 for ; Mon, 17 Oct 2011 16:03:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.979 X-Spam-Level: X-Spam-Status: No, score=-2.979 tagged_above=-999 required=5 tests=[AWL=-0.265, 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 lT3m7D6NKdYN for ; Mon, 17 Oct 2011 16:02:59 -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 491C91F0C43 for ; Mon, 17 Oct 2011 16:02:59 -0700 (PDT) Received: by vws5 with SMTP id 5so3660829vws.31 for ; Mon, 17 Oct 2011 16:02:58 -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 :content-type; bh=AqAkGD0hsLyrwBgXCLcajd1wweHiYxRA931BxXCQZ58=; b=OvX6bucslRCbh5PzcCb7HumIm+cu0Gnrh2PDGabfONfgteXT/37WZup3eEYAaISOhI aFlFY16pddWzzhHicU4j1quqMNN+n4fBglda1d4h9tWVP8lmXdEUan6zSfN7khyws+b0 1iUGqgcFsqXu7DzlgRsXNp0xmMUVZ6/K2+PjY= MIME-Version: 1.0 Received: by 10.52.36.237 with SMTP id t13mr22449446vdj.45.1318892577756; Mon, 17 Oct 2011 16:02:57 -0700 (PDT) Received: by 10.52.107.202 with HTTP; Mon, 17 Oct 2011 16:02:57 -0700 (PDT) In-Reply-To: References: <4E27EE6E.30600@alvestrand.no> Date: Mon, 17 Oct 2011 16:02:57 -0700 Message-ID: From: Dzonatas Sol To: rtcweb@ietf.org Content-Type: multipart/alternative; boundary=20cf30780d009817db04af869be3 Subject: Re: [rtcweb] How to multiplex between peers X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 23:03:00 -0000 --20cf30780d009817db04af869be3 Content-Type: text/plain; charset=ISO-8859-1 Are you David420? The one that followed me all over websites just to make up, even /., just to tell people I'm a bot? I take that as a threat worthy of E911. If I have to tell people "I am not a bot" like demanded on "[B]itcoin" then you publicly harassed me. Is it normal to call people names and consider merit of standardization? I know it is standard in in the Hasbara Manual. Did you win your point? On Mon, Oct 17, 2011 at 3:00 PM, Roman Shpount wrote: > In case you did not notice, Dzonatas Sol is a bot. I would suggest just > spam filtering it. > _____________ > Roman Shpount > > > > On Mon, Oct 17, 2011 at 5:51 PM, Ted Hardie wrote: > >> Dzonatas, >> >> Your emails to the group have become less and less on point over time. >> Please send email to the group only when you have substantive comments on >> the work going on. If you do not, the chairs may have to consider >> suspending your right to post. >> >> regards, >> >> Ted Hardie >> >> On Mon, Oct 17, 2011 at 1:58 PM, Dzonatas Sol wrote: >> >>> I got this Quantum Vibe link from an /. ad: http://shar.es/bqNgs >>> >>> I think that be a link-in-a-link, a meta-link, or a canonical multiplexer >>> in pix#4; it applies to B2B and the server-to-server paradigm is not >>> obvious. >>> >>> ...anymore. ;) >>> >>> On Thu, Jul 21, 2011 at 2:16 AM, Harald Alvestrand >> > wrote: >>> >>>> On 07/21/11 02:41, Henry Sinnreich wrote: >>>> >>>>> +1 >>>>> >>>>> If anything this is an argument for ignoring RTP and RTCP and doing >>>>>> something entirely new that is actually appropriate for what we're >>>>>> trying to build, not living with crap just because there's an RFC for >>>>>> it. >>>>>> >>>>> Not to forget disposing of ancient SDP as well. >>>>> Use standard metadata instead, since it is equally usable for all apps, >>>>> not >>>>> only for RTC apps. >>>>> >>>> Henry, which standard? >>>> http://www.xkcd.com/927/ applies to metadata too, I think. >>>> >>>> >>>> >>> _______________________________________________ >>> 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 >> >> > --20cf30780d009817db04af869be3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Are you David420? The one that followed me all over websites just to m= ake up, even /., just to tell people I'm a bot?

I take that as a threat worthy of E911. If I have to tell people "I = am not a bot" like demanded on "[B]itcoin" then you=A0public= ly=A0harassed me.

Is it normal to call people names and consider merit of= standardization? I know it is standard in in the Hasbara Manual. Did you w= in your point?

On Mon, Oct 17, 201= 1 at 3:00 PM, Roman Shpount <roman@telurix.com> wrote:
In case you did not notice, Dzonatas Sol is= a bot. I would suggest just spam filtering it.
__________= ___
Roman Shpount



On Mon, Oct 17, 2011 at 5:51 PM, Ted Har= die <ted.ietf@gmail.com> wrote:
Dzonatas,

Your emails to the group have become less and less on poin= t over time.=A0 Please send email to the group only when you have substanti= ve comments on the work going on.=A0 If you do not, the chairs may have to = consider suspending your right to post.

regards,

Ted Hardie

On Mon, Oc= t 17, 2011 at 1:58 PM, Dzonatas Sol <dzonatas@gmail.com> wr= ote:
I got this Quantum Vibe link from an /. ad:=A0http://shar.es/bqNg= s

<= div>I think that be a lin= k-in-a-link, a meta-link, or a canonical multiplexer in pix#4; it applies t= o B2B and the server-to-server paradigm is not obvious.

...anymore. ;)

 On Thu, Jul 21, 2011 at 2:16 AM, Harald Alvestrand <harald@alvestrand.n= o> wrote:
On 07/21/11 02:41, Henry Sinnreich wrote:
+1

If anything this is an argument for ignoring RTP and RTCP and doing
something entirely new that is actually appropriate for what we're
trying to build, not living with crap just because there's an RFC for i= t.
Not to forget disposing of ancient SDP as well.
Use standard metadata instead, since it is equally usable for all apps, not=
only for RTC apps.
Henry, which standard?
http://www.xkcd.com/= 927/ applies to metadata too, I think.



_______________________________________________
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



--20cf30780d009817db04af869be3-- From ibc@aliax.net Mon Oct 17 16:45: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 7227A21F8509 for ; Mon, 17 Oct 2011 16:45:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.302 X-Spam-Level: X-Spam-Status: No, score=-3.302 tagged_above=-999 required=5 tests=[AWL=0.775, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_INVITATION=-2, 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 iHPSKOo1+1cs for ; Mon, 17 Oct 2011 16:45:53 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id C2B0F21F8505 for ; Mon, 17 Oct 2011 16:45:53 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so23498vcb.31 for ; Mon, 17 Oct 2011 16:45:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.73.166 with SMTP id m6mr26955vdv.18.1318895153038; Mon, 17 Oct 2011 16:45:53 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Mon, 17 Oct 2011 16:45:52 -0700 (PDT) In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF51159959@sonusinmail02.sonusnet.com> References: <15B0E3AD-3086-499A-8E79-7AE58B3376C4@cisco.com> <2E239D6FCD033C4BAF15F386A979BF51159957@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF51159959@sonusinmail02.sonusnet.com> Date: Tue, 18 Oct 2011 01:45:52 +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] SDP Offer/Answer draft-jennings-rtcweb-signaling X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 23:45:54 -0000 2011/10/18 Ravindran Parthasarathi : > Inaki, > > Heaven sake, Please reply with original text. You always cut the text in = reply so badly that I have to repeat what I have said in the original mail = again in the reply. Your cutting practice leads to circular discussion and = let us try to avoid it. Mail threads exist to avoid reading again an entire previous mail. I cut the exact text for which I'm replying my mail, this is the correct behavior. In the same way you could use a nice mail client so you would get the previous text beggining with ">" (and you don't need to add your strange symbols). Just as a suggestion. > Original mail statement is as follows: > > I'm seeing your proposal as SDP offer/answer over websocket > > > Hope this clarify what I meant. No. SDP ofer/answer over WebSocket is NOT enough. How do you tell the server/proxy *who* you want to call or where your SDP invitation must be sent? For that you need something else, something more than just a SDP exchange, right? So you also need a *signaling protocol*, and that can be SIP (SIP over WebSocket is signaling + SDP exchange), or XMPP+Jingle, or any custom JSON based signaling protocol. I don't want to mandate a specific signaling protocol, but you do. What you propose in *every* your mails is that such signaling protocol (which defines the format of messages sent on-the-wire) MUST be a RTCweb standard built-in every webv browser. And that has nothing to do with the ROAP draft which just defines a message exchange between the JavaScript client (the "overkill" as you said in other mail) and the RTCweb stack within the browser for handling *media* sessions. > Also, Please see bullet 2 in sec 6 of draft-partha-rtcweb-signaling-00 to= get the whole picture. ---------------------------- 6. Possible RTCWeb signaling protocols The following Signaling protocols will qualify for becoming standard RTCWeb signaling protocol 2. Websocket with SDP offer/answer ----------------------------- Do I need to explain again that WebSocket is not a signaling protocol by itself so you need to define a WebSocket subprotocol on top of it? Do you understand that sending a SDP to the remote peer is not enough? Probably you want to tell the remote peer "who you are". In the other side, I don't care whether your proposed "default signaling protocol for RTCweb" is based on WebSocket or whatever. That does not make me happy. Nobody else seems to be in favour of defining and *mandating* a default signaling protocol. Just you. --=20 I=C3=B1aki Baz Castillo From ted.ietf@gmail.com Mon Oct 17 17:56: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 A4DE321F87FC for ; Mon, 17 Oct 2011 17:56:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.983 X-Spam-Level: X-Spam-Status: No, score=-2.983 tagged_above=-999 required=5 tests=[AWL=0.315, 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 0yHm++VB0Geo for ; Mon, 17 Oct 2011 17:56:45 -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 28E5B21F8797 for ; Mon, 17 Oct 2011 17:56:45 -0700 (PDT) Received: by ywa8 with SMTP id 8so79280ywa.31 for ; Mon, 17 Oct 2011 17:56:44 -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=3jcLQOFPid/9v9OzeN7n3l42AuyPhmN2t4FczV9iOkk=; b=CDNQAis2NeacqbriTWjiAyWIq2MW8LEDyqfNnwDEcQFxzWUF2alewyY+LMNIelo4Pw V7ddbvudmEXgpSfC7v3T9I1oTvQC9WoXcuMnt+GW+Z3OvbFxl5B2TLct8VJnHb3k4eJJ Zyp0B3Jaw9cDKiU1vw4fi0T29P4MvHC58pS+I= MIME-Version: 1.0 Received: by 10.236.178.34 with SMTP id e22mr94357yhm.125.1318899404695; Mon, 17 Oct 2011 17:56:44 -0700 (PDT) Received: by 10.236.105.169 with HTTP; Mon, 17 Oct 2011 17:56:44 -0700 (PDT) In-Reply-To: References: <15B0E3AD-3086-499A-8E79-7AE58B3376C4@cisco.com> <2E239D6FCD033C4BAF15F386A979BF51159957@sonusinmail02.sonusnet.com> Date: Mon, 17 Oct 2011 17:56:44 -0700 Message-ID: From: Ted Hardie To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=20cf303f69b482e91304af8832fb Cc: Jonathan Rosenberg , rtcweb@ietf.org, public-webrtc@w3.org Subject: Re: [rtcweb] SDP Offer/Answer draft-jennings-rtcweb-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: Tue, 18 Oct 2011 00:56:45 -0000 --20cf303f69b482e91304af8832fb Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Oct 17, 2011 at 3:41 PM, I=F1aki Baz Castillo wrote= : > 2011/10/18 Ravindran Parthasarathi : > > I like your proposed idea as it is going in the direction of having > > "standard" signaling protocol for RTCWeb. > > Please Ravindran, don't manipulate mails, text and draft given by > other persons in this WG. The draft *clearly* says: > > I=F1aki, Ravindran's email clearly says "is going in the direction of", not "is a standard signalling protocol". In general, critiquing others' statement of support on vocabulary choices i= s not really helpful. Focus on your contributions, please, rather than assuming that others are "manipulations". This is not useful nor collegial behavior. regards, Ted Hardie --20cf303f69b482e91304af8832fb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Oct 17, 2011 at 3:41 PM, I=F1aki Baz Castillo <= ;ibc@aliax.net> wrote:
2011/10/18 Ravindran Parthasarathi <pravindran@sonusnet.com>:
> I like your proposed idea as it is going in the dire= ction of having
> "standard" signaling protocol for RTCWeb.

Please Ravindran, don't manipulate mails, text and draft given by=
other persons in this WG. The draft *clearly* says:


I=F1aki,


Ravindran's email clearl= y says "is going in the direction of", not "is a standard si= gnalling protocol".=A0

In general, critiquing others' stat= ement of support on vocabulary choices is not really helpful.=A0 Focus on y= our contributions, please, rather than assuming that others are "manip= ulations".=A0 This is not useful nor collegial behavior.

regards,

Ted Hardie
=A0
--20cf303f69b482e91304af8832fb-- From roman@telurix.com Mon Oct 17 17:58: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 663FF21F8A64 for ; Mon, 17 Oct 2011 17:58:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.798 X-Spam-Level: X-Spam-Status: No, score=-2.798 tagged_above=-999 required=5 tests=[AWL=0.178, 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 zqc+3QCTziB3 for ; Mon, 17 Oct 2011 17:58:44 -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 8584821F8A66 for ; Mon, 17 Oct 2011 17:58:43 -0700 (PDT) Received: by gyh20 with SMTP id 20so76966gyh.31 for ; Mon, 17 Oct 2011 17:58:43 -0700 (PDT) Received: by 10.150.144.7 with SMTP id r7mr308366ybd.35.1318899523154; Mon, 17 Oct 2011 17:58:43 -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 g38sm964671ann.4.2011.10.17.17.58.42 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 17 Oct 2011 17:58:43 -0700 (PDT) Received: by ggnv1 with SMTP id v1so75963ggn.31 for ; Mon, 17 Oct 2011 17:58:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.17.193 with SMTP id q1mr805507pbd.98.1318899520395; Mon, 17 Oct 2011 17:58:40 -0700 (PDT) Received: by 10.68.47.40 with HTTP; Mon, 17 Oct 2011 17:58:40 -0700 (PDT) In-Reply-To: <15B0E3AD-3086-499A-8E79-7AE58B3376C4@cisco.com> References: <15B0E3AD-3086-499A-8E79-7AE58B3376C4@cisco.com> Date: Mon, 17 Oct 2011 20:58:40 -0400 Message-ID: From: Roman Shpount To: Cullen Jennings Content-Type: multipart/alternative; boundary=bcaec520ea436860f504af8839cf Cc: Jonathan Rosenberg , rtcweb@ietf.org, public-webrtc@w3.org Subject: Re: [rtcweb] SDP Offer/Answer draft-jennings-rtcweb-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: Tue, 18 Oct 2011 00:58:45 -0000 --bcaec520ea436860f504af8839cf Content-Type: text/plain; charset=ISO-8859-1 Cullen, Did we decide to explicitly not support forking which generates multiple final answers? If this is not the case, how is this supposed to be implemented using your model? _____________ Roman Shpount On Fri, Oct 14, 2011 at 11:09 PM, Cullen Jennings wrote: > > Jonathan and I submitted a new draft on setting up media based on the SDP > Offer/Answer model. The ASCII flows are a bit hard to read so until I update > them, I recommend reading the PDF version at > > http://tools.ietf.org/pdf/draft-jennings-rtcweb-signaling-00.pdf > > Clearly the draft is an early stage but we plan to revise it before the > deadline for the IETF 82. Love to get input - particularly on if this looks > like generally the right direction to go. > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --bcaec520ea436860f504af8839cf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cullen,

Did we decide to explicitly not support forking which genera= tes multiple final answers? If this is not the case, how is this supposed t= o be implemented using your model?
_____________
Roman = Shpount


On Fri, Oct 14, 2011 at 11:09 PM, Cullen= Jennings <fluffy@= cisco.com> wrote:

Jonathan and I submitted a new draft on setting up media based on the SDP O= ffer/Answer model. The ASCII flows are a bit hard to read so until I update= them, I recommend reading the PDF version at

http://tools.ietf.org/pdf/draft-jennings-rtcweb-signali= ng-00.pdf

Clearly the draft is an early stage but we plan to revise it before the dea= dline for the IETF 82. Love to get input - particularly on if this looks li= ke generally the right direction to go.


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

--bcaec520ea436860f504af8839cf-- From wolfgang.beck01@googlemail.com Mon Oct 17 22: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 74A7111E80D1 for ; Mon, 17 Oct 2011 22:58:57 -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 99XwVwejQZtK for ; Mon, 17 Oct 2011 22:58:56 -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 411E111E80D0 for ; Mon, 17 Oct 2011 22:58:56 -0700 (PDT) Received: by ggnv1 with SMTP id v1so288354ggn.31 for ; Mon, 17 Oct 2011 22:58:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=HP6B9uYGlWrHCPzWsHVFS0ldBgsjWdprLxSFSUG0eaM=; b=DGpmpgfWLH3hkjZZBZFCJjvawtLCiV9g8uYFP+IOZ0rqfZAmaK7S4LgN+Vvg/Y0MSE W2V80qIHFpeNiybVejwHhcpiX7vw3LM7RBgIpDudnFVvVw3F40jJmPSVCRDGk7syO1CY i+VrGT6iI8Q0W4m/MdrM+NO9lKR5tpfbgqCys= MIME-Version: 1.0 Received: by 10.68.39.231 with SMTP id s7mr2687291pbk.33.1318917535233; Mon, 17 Oct 2011 22:58:55 -0700 (PDT) Received: by 10.68.55.230 with HTTP; Mon, 17 Oct 2011 22:58:55 -0700 (PDT) In-Reply-To: <4E9C93F5.5070906@jesup.org> References: <4E996E80.6070500@alvestrand.no> <8486C8728176924BAF5BDB2F7D7EEDDF3E0906A2@ucolhp4d.easf.csd.disa.mil> <4E9BA235.3010808@jesup.org> <4E9C430A.1070600@jesup.org> <4E9C93F5.5070906@jesup.org> Date: Tue, 18 Oct 2011 07:58:55 +0200 Message-ID: From: Wolfgang Beck To: Randell Jesup Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Signalling, SDP, and the way we think about interconnecting RTCWEB 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, 18 Oct 2011 05:58:57 -0000 > You're making the argument that no federation is needed, because to conta= ct > someone on stackexchange you'd browse to stackexchange first. > > I don't think that handles the use-cases of, from within say gmail, you t= ry > to call someone on Stackexchange - or even more unavoidable, you try to > invite someone from stackexchange to join your already-running call. =A0Y= ou > can't exit out and load the stackexchange JS client. > Good point. Browsers have iframes and tabs in which I can render web pages of different sites in parallel. The browser has to deal with the case when more than one JS client tries to access the microphone or speaker. Your first case is easy. I simply open a new tab or window and make the cal= l. Consultation calling should be easy, too: I have two browser windows, one with party B, one with party C. I could talk to them in turns by simply switching between win= dows. Conferencing would require that the browser can move media streams between its JS instances. I'll go through this old list of IN services and check where my model fails= . http://www.cs.columbia.edu/~library/TR-repository/reports/reports-1999/cucs= -002-99.ps.gz I still refuse to understand RTCWEB as a MEGACO with javascript syntax.. Wolfgang From saul@ag-projects.com Tue Oct 18 00: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 13BE11F0C6E for ; Tue, 18 Oct 2011 00:01:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.688 X-Spam-Level: X-Spam-Status: No, score=-1.688 tagged_above=-999 required=5 tests=[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 hjL-TGPT2+UE for ; Tue, 18 Oct 2011 00:01:58 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 72AE61F0C5D for ; Tue, 18 Oct 2011 00:01:54 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 42728B01B5; Tue, 18 Oct 2011 09:01:52 +0200 (CEST) Received: from [192.168.99.36] (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id 9A6D7B017D; Tue, 18 Oct 2011 09:01: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: <2E239D6FCD033C4BAF15F386A979BF51159950@sonusinmail02.sonusnet.com> Date: Tue, 18 Oct 2011 09:01:41 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0950F0E1-6E4B-407F-9563-654AFE79F64B@ag-projects.com> References: <2E239D6FCD033C4BAF15F386A979BF510F1367@sonusinmail02.sonusnet.com><4E8AC222.4050308@alvestrand.no><2E239D6FCD033C4BAF15F386A979BF510F14CE@sonusinmail02.sonusnet.com><2E239D6FCD033C4BAF15F386A979BF510F14FD@sonusinmail02.sonusnet.com><393F1888-F834-4DAE-B6B1-1C5D35EE3292@phonefromhere.com><2E239D6FCD033C4BAF15F386A979BF510F152B@sonusinmail02.sonusnet.com><2E239D6FCD033C4BAF15F386A979BF510F1532@sonusinmail02.sonusnet.com><2E239D6FCD033C4BAF15F386A979BF511598EE@sonusinmail02.sonusnet.com><665A16AB-AAD8-42B3-AC17-7E629EA2DE35@phonefromhere.com><2E239D6FCD033C4BAF15F386A979BF5115992E@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F3 86A979BF51159950@sonusinmail02.sonusnet.com> To: Ravindran Parthasarathi X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Review request for RTCWeb standard 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: Tue, 18 Oct 2011 07:01:59 -0000 On Oct 17, 2011, at 7:00 PM, Ravindran Parthasarathi wrote: > The point to be noted is folks put forth the same argument again & = again..each time, it is not possible to come up new answer ;-) I noticed = often you complain as if your important is missed out. We are arguing = only about "nothing" vs "something" as a RTCWeb signaling protocol. >=20 > I clearly explained why SIP over websocket is an overkill in the below = mail thread. Please read it and don't argue that it is working. All the = working stuff is not good. Infact for any protocol, the first idea = pop-up is to tunnel the complete inside (For Ex: ISUP over SIP) but = always better ways to solve it. >=20 Let me connect the dots: you are advocating for a new 'simple' protocol = instead of taking an existing one, SIP for example, which you called = 'overkill'. And earlier in this thread you mentioned that you are = interested in gateways. I now understand what you are trying to do. -- Sa=FAl Ibarra Corretg=E9 AG Projects From pravindran@sonusnet.com Tue Oct 18 01:15: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 D570521F85B1 for ; Tue, 18 Oct 2011 01:15:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.66 X-Spam-Level: X-Spam-Status: No, score=-2.66 tagged_above=-999 required=5 tests=[AWL=-0.361, 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 H9RxObEh9row for ; Tue, 18 Oct 2011 01:15:55 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 4D9A021F8532 for ; Tue, 18 Oct 2011 01:15:55 -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 p9I8GLL1023417; Tue, 18 Oct 2011 04:16:22 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail06.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 18 Oct 2011 04:15:47 -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, 18 Oct 2011 13:45:44 +0530 Message-ID: <2E239D6FCD033C4BAF15F386A979BF51159994@sonusinmail02.sonusnet.com> In-Reply-To: <0950F0E1-6E4B-407F-9563-654AFE79F64B@ag-projects.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] Review request for RTCWeb standard signaling protocol Thread-Index: AcyNY9RKUZtq4/TvTF2m8ihYBiTuMwACTO9Q References: <2E239D6FCD033C4BAF15F386A979BF510F1367@sonusinmail02.sonusnet.com><4E8AC222.4050308@alvestrand.no><2E239D6FCD033C4BAF15F386A979BF510F14CE@sonusinmail02.sonusnet.com><2E239D6FCD033C4BAF15F386A979BF510F14FD@sonusinmail02.sonusnet.com><393F1888-F834-4DAE-B6B1-1C5D35EE3292@phonefromhere.com><2E239D6FCD033C4BAF15F386A979BF510F152B@sonusinmail02.sonusnet.com><2E239D6FCD033C4BAF15F386A979BF510F1532@sonusinmail02.sonusnet.com><2E239D6FCD033C4BAF15F386A979BF511598EE@sonusinmail02.sonusnet.com><665A16AB-AAD8-42B3-AC17-7E629EA2DE35@phonefromhere.com><2E239D6FCD033C4BAF15F386A979BF5115992E@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F3 86A979B F51159950@so nusinmail02.sonusnet.com> <0950F0E1-6E4B-407F-9563-654AFE79F64B@ag-projects.com> From: "Ravindran Parthasarathi" To: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= X-OriginalArrivalTime: 18 Oct 2011 08:15:47.0730 (UTC) FILETIME=[24079F20:01CC8D6E] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Review request for RTCWeb standard 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: Tue, 18 Oct 2011 08:15:55 -0000 Saul, One minor correction in your mail: I have mentioned "SIP over websocket" = is an overkill and not SIP. Thanks Partha >-----Original Message----- >From: Sa=FAl Ibarra Corretg=E9 [mailto:saul@ag-projects.com] >Sent: Tuesday, October 18, 2011 12:32 PM >To: Ravindran Parthasarathi >Cc: I=F1aki Baz Castillo; rtcweb@ietf.org >Subject: Re: [rtcweb] Review request for RTCWeb standard signaling >protocol > > >On Oct 17, 2011, at 7:00 PM, Ravindran Parthasarathi wrote: > >> The point to be noted is folks put forth the same argument again & >again..each time, it is not possible to come up new answer ;-) I = noticed >often you complain as if your important is missed out. We are arguing >only about "nothing" vs "something" as a RTCWeb signaling protocol. >> >> I clearly explained why SIP over websocket is an overkill in the = below >mail thread. Please read it and don't argue that it is working. All the >working stuff is not good. Infact for any protocol, the first idea pop- >up is to tunnel the complete inside (For Ex: ISUP over SIP) but always >better ways to solve it. >> > >Let me connect the dots: you are advocating for a new 'simple' protocol >instead of taking an existing one, SIP for example, which you called >'overkill'. And earlier in this thread you mentioned that you are >interested in gateways. > >I now understand what you are trying to do. > >-- >Sa=FAl Ibarra Corretg=E9 >AG Projects > > From Ranjit.Avasarala@Polycom.com Tue Oct 18 01: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 82FAE21F8C7E for ; Tue, 18 Oct 2011 01:38:32 -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 jOm9Qzc8aFiM for ; Tue, 18 Oct 2011 01:38:32 -0700 (PDT) Received: from Hkgehubprd01.polycom.com (hkgehubprd01.polycom.com [140.242.6.225]) by ietfa.amsl.com (Postfix) with ESMTP id 786D821F8B28 for ; Tue, 18 Oct 2011 01:38:30 -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; Tue, 18 Oct 2011 16:38:29 +0800 From: "Avasarala, Ranjit" To: Ravindran Parthasarathi , =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= Date: Tue, 18 Oct 2011 16:38:27 +0800 Thread-Topic: [rtcweb] Review request for RTCWeb standard signaling protocol Thread-Index: AcyNY9RKUZtq4/TvTF2m8ihYBiTuMwACTO9QAAD+IPA= Message-ID: <1F2A2C70609D9E41844A2126145FC09804004302@HKGMBOXPRD22.polycom.com> References: <2E239D6FCD033C4BAF15F386A979BF510F1367@sonusinmail02.sonusnet.com><4E8AC222.4050308@alvestrand.no><2E239D6FCD033C4BAF15F386A979BF510F14CE@sonusinmail02.sonusnet.com><2E239D6FCD033C4BAF15F386A979BF510F14FD@sonusinmail02.sonusnet.com><393F1888-F834-4DAE-B6B1-1C5D35EE3292@phonefromhere.com><2E239D6FCD033C4BAF15F386A979BF510F152B@sonusinmail02.sonusnet.com><2E239D6FCD033C4BAF15F386A979BF510F1532@sonusinmail02.sonusnet.com><2E239D6FCD033C4BAF15F386A979BF511598EE@sonusinmail02.sonusnet.com><665A16AB-AAD8-42B3-AC17-7E629EA2DE35@phonefromhere.com><2E239D6FCD033C4BAF15F386A979BF5115992E@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F3 86A979B F51159950@so nusinmail02.sonusnet.com> <0950F0E1-6E4B-407F-9563-654AFE79F64B@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF51159994@sonusinmail02.sonusnet.com> In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF51159994@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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Review request for RTCWeb standard 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: Tue, 18 Oct 2011 08:38:32 -0000 That's the whole issue. We need some mechanism for web browsers to negotiat= e offer/answer and ICE candidates between each other. Using SIP for this ov= er websockets would bring in unnecessary overheads. But we still need some = mechanism. So something which is "simple" is needed. Regards Ranjit -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Ravindran Parthasarathi Sent: Tuesday, October 18, 2011 1:46 PM To: Sa=FAl Ibarra Corretg=E9 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Review request for RTCWeb standard signaling protocol Saul, One minor correction in your mail: I have mentioned "SIP over websocket" is= an overkill and not SIP. Thanks Partha >-----Original Message----- >From: Sa=FAl Ibarra Corretg=E9 [mailto:saul@ag-projects.com] >Sent: Tuesday, October 18, 2011 12:32 PM >To: Ravindran Parthasarathi >Cc: I=F1aki Baz Castillo; rtcweb@ietf.org >Subject: Re: [rtcweb] Review request for RTCWeb standard signaling >protocol > > >On Oct 17, 2011, at 7:00 PM, Ravindran Parthasarathi wrote: > >> The point to be noted is folks put forth the same argument again & >again..each time, it is not possible to come up new answer ;-) I noticed >often you complain as if your important is missed out. We are arguing >only about "nothing" vs "something" as a RTCWeb signaling protocol. >> >> I clearly explained why SIP over websocket is an overkill in the below >mail thread. Please read it and don't argue that it is working. All the >working stuff is not good. Infact for any protocol, the first idea pop- >up is to tunnel the complete inside (For Ex: ISUP over SIP) but always >better ways to solve it. >> > >Let me connect the dots: you are advocating for a new 'simple' protocol >instead of taking an existing one, SIP for example, which you called >'overkill'. And earlier in this thread you mentioned that you are >interested in gateways. > >I now understand what you are trying to do. > >-- >Sa=FAl Ibarra Corretg=E9 >AG Projects > > _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From ibc@aliax.net Tue Oct 18 01: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 C573121F8C84 for ; Tue, 18 Oct 2011 01:48:46 -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.051, 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 4UzsbvMLS747 for ; Tue, 18 Oct 2011 01:48:46 -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 3878D21F8C83 for ; Tue, 18 Oct 2011 01:48:46 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so352067vcb.31 for ; Tue, 18 Oct 2011 01:48:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.35.34 with SMTP id e2mr1332694vdj.52.1318927725609; Tue, 18 Oct 2011 01:48:45 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Tue, 18 Oct 2011 01:48:45 -0700 (PDT) In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF51159994@sonusinmail02.sonusnet.com> References: <2E239D6FCD033C4BAF15F386A979BF510F1367@sonusinmail02.sonusnet.com> <4E8AC222.4050308@alvestrand.no> <2E239D6FCD033C4BAF15F386A979BF510F14CE@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF510F14FD@sonusinmail02.sonusnet.com> <393F1888-F834-4DAE-B6B1-1C5D35EE3292@phonefromhere.com> <2E239D6FCD033C4BAF15F386A979BF510F152B@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF510F1532@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF511598EE@sonusinmail02.sonusnet.com> <665A16AB-AAD8-42B3-AC17-7E629EA2DE35@phonefromhere.com> <2E239D6FCD033C4BAF15F386A979BF5115992E@sonusinmail02.sonusnet.com> <0950F0E1-6E4B-407F-9563-654AFE79F64B@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF51159994@sonusinmail02.sonusnet.com> Date: Tue, 18 Oct 2011 10:48:45 +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] Review request for RTCWeb standard 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: Tue, 18 Oct 2011 08:48:46 -0000 2011/10/18 Ravindran Parthasarathi : > Saul, > > One minor correction in your mail: I have mentioned "SIP over websocket" = is an overkill and not SIP. Ravindran, please forget "SIP over WebSocket". I've never proposed it to be a default RTCweb signaling protocol, not at all, so if you don't like it just don't use it. BTW what I understand given your insistent proposal is that you need the RTCweb signaling protocol (messages in-the-wire) to be an IETF standard so you get a market for building and selling gateway boxes between such "IETF-RTCweb-Protocol" and other IETF standard protocols (as SIP). It's clear that you like gateways and you want gateways. Said that I apologize to this WG for some of my mails yesterday. It won't happen again. --=20 I=C3=B1aki Baz Castillo From harald@alvestrand.no Tue Oct 18 02:16: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 4176B21F8A4E for ; Tue, 18 Oct 2011 02:16:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QPmRPijuqQjx for ; Tue, 18 Oct 2011 02:16:04 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 4567821F8A35 for ; Tue, 18 Oct 2011 02:16:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 33CD539E0CD; Tue, 18 Oct 2011 11:16:03 +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 0fe0zqbE4yvQ; Tue, 18 Oct 2011 11:16:01 +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 8516839E082; Tue, 18 Oct 2011 11:16:01 +0200 (CEST) Message-ID: <4E9D43D2.9010804@alvestrand.no> Date: Tue, 18 Oct 2011 11:16:02 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: Roman Shpount References: <15B0E3AD-3086-499A-8E79-7AE58B3376C4@cisco.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------030601090504020304010703" Cc: Jonathan Rosenberg , rtcweb@ietf.org, public-webrtc@w3.org Subject: [rtcweb] API options for supporting fork with ROAP (Re: SDP Offer/Answer draft-jennings-rtcweb-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: Tue, 18 Oct 2011 09:16:05 -0000 This is a multi-part message in MIME format. --------------030601090504020304010703 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 10/18/2011 02:58 AM, Roman Shpount wrote: > Cullen, > > Did we decide to explicitly not support forking which generates > multiple final answers? If this is not the case, how is this supposed > to be implemented using your model? I and some people from Ericsson had a discussion about forking the other day (the ability to send out one request and have it generate multiple PeerConnections on the response). Options include: - Sending a request with no content for which state must be kept, creating new PeerConnection objects on answer that can handle an answer without generating an offer first, and then renegotiating stuff that needs state subsequently - Creating a new "PeerConnectionFactoryWithOffer" object that holds the state of the request, but has the ability to mint several PeerConnections on responses - Throwing away the initial PeerConnection, munge the incoming Answer to look like an Offer, create a PeerConnection from it, and throw away the resulting Answer - Create the ability to create a PeerConnection from an Offer + an Answer, together with the ability to create an Offer without creating a PeerConnection (this is a variant of the Factory method) - Do something different..... Of course there's always the option of not supporting forking, leading it to be a problem that only concerns those who write gateways into systems where it is required; SIP systems that don't support forking are in the same boat. It's not impossible, but it does have an overhead cost. > _____________ > Roman Shpount > > > On Fri, Oct 14, 2011 at 11:09 PM, Cullen Jennings > wrote: > > > Jonathan and I submitted a new draft on setting up media based on > the SDP Offer/Answer model. The ASCII flows are a bit hard to read > so until I update them, I recommend reading the PDF version at > > http://tools.ietf.org/pdf/draft-jennings-rtcweb-signaling-00.pdf > > Clearly the draft is an early stage but we plan to revise it > before the deadline for the IETF 82. Love to get input - > particularly on if this looks like generally the right direction > to go. > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --------------030601090504020304010703 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 10/18/2011 02:58 AM, Roman Shpount wrote:
Cullen,

Did we decide to explicitly not support forking which generates multiple final answers? If this is not the case, how is this supposed to be implemented using your model?

I and some people from Ericsson had a discussion about forking the other day (the ability to send out one request and have it generate multiple PeerConnections on the response).

Options include:

- Sending a request with no content for which state must be kept, creating new PeerConnection objects on answer that can handle an answer without generating an offer first, and then renegotiating stuff that needs state subsequently
- Creating a new "PeerConnectionFactoryWithOffer" object that holds the state of the request, but has the ability to mint several PeerConnections on responses
- Throwing away the initial PeerConnection, munge the incoming Answer to look like an Offer, create a PeerConnection from it, and throw away the resulting Answer
- Create the ability to create a PeerConnection from an Offer + an Answer, together with the ability to create an Offer without creating a PeerConnection (this is a variant of the Factory method)
- Do something different.....

Of course there's always the option of not supporting forking, leading it to be a problem that only concerns those who write gateways into systems where it is required; SIP systems that don't support forking are in the same boat.

It's not impossible, but it does have an overhead cost.

_____________
Roman Shpount


On Fri, Oct 14, 2011 at 11:09 PM, Cullen Jennings <fluffy@cisco.com> wrote:

Jonathan and I submitted a new draft on setting up media based on the SDP Offer/Answer model. The ASCII flows are a bit hard to read so until I update them, I recommend reading the PDF version at

http://tools.ietf.org/pdf/draft-jennings-rtcweb-signaling-00.pdf

Clearly the draft is an early stage but we plan to revise it before the deadline for the IETF 82. Love to get input - particularly on if this looks like generally the right direction to go.


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


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

--------------030601090504020304010703-- From saul@ag-projects.com Tue Oct 18 02:38: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 7190821F8C81 for ; Tue, 18 Oct 2011 02:38:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.688 X-Spam-Level: X-Spam-Status: No, score=-1.688 tagged_above=-999 required=5 tests=[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 LX+Q1z50hHZm for ; Tue, 18 Oct 2011 02:38:30 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 91B8721F8C4E for ; Tue, 18 Oct 2011 02:38:25 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 4A207B01B8; Tue, 18 Oct 2011 11:38: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 21A7BB017D; Tue, 18 Oct 2011 11:38:22 +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: <2E239D6FCD033C4BAF15F386A979BF51159994@sonusinmail02.sonusnet.com> Date: Tue, 18 Oct 2011 11:38:21 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6398F67A-5E41-44BB-ABB2-831AB7C48DCC@ag-projects.com> References: <2E239D6FCD033C4BAF15F386A979BF510F1367@sonusinmail02.sonusnet.com><4E8AC222.4050308@alvestrand.no><2E239D6FCD033C4BAF15F386A979BF510F14CE@sonusinmail02.sonusnet.com><2E239D6FCD033C4BAF15F386A979BF510F14FD@sonusinmail02.sonusnet.com><393F1888-F834-4DAE-B6B1-1C5D35EE3292@phonefromhere.com><2E239D6FCD033C4BAF15F386A979BF510F152B@sonusinmail02.sonusnet.com><2E239D6FCD033C4BAF15F386A979BF510F1532@sonusinmail02.sonusnet.com><2E239D6FCD033C4BAF15F386A979BF511598EE@sonusinmail02.sonusnet.com><665A16AB-AAD8-42B3-AC17-7E629EA2DE35@phonefromhere.com><2E239D6FCD033C4BAF15F386A979BF5115992E@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F3 86A979B F51159950@so nusinmail02.sonusnet.com> <0950F0E1-6E4B-407F-9563-654AFE79F64B@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF51159994@sonusinmail02.sonusnet.com> To: Ravindran Parthasarathi X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Review request for RTCWeb standard 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: Tue, 18 Oct 2011 09:38:30 -0000 On Oct 18, 2011, at 10:15 AM, Ravindran Parthasarathi wrote: > Saul, >=20 > One minor correction in your mail: I have mentioned "SIP over = websocket" is an overkill and not SIP. >=20 You confuse me. You said before that the JS libraries would take time to = download and all that, and now you say that SIP is not overkill. I don't = see another way of using SIP in a browser (without plugins) than using = JS for the stack and WebSocket as a transport. Either way, there seems to be a consensus that no signaling protocol = should be specified, time to move on. -- Sa=FAl Ibarra Corretg=E9 AG Projects From christer.holmberg@ericsson.com Tue Oct 18 03:18: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 580B321F8CA2 for ; Tue, 18 Oct 2011 03:18:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.4 X-Spam-Level: X-Spam-Status: No, score=-6.4 tagged_above=-999 required=5 tests=[AWL=-0.101, 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 k4RsK9HvYP3s for ; Tue, 18 Oct 2011 03:18:16 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 9562A21F8C98 for ; Tue, 18 Oct 2011 03:18:16 -0700 (PDT) X-AuditID: c1b4fb3d-b7c26ae0000035b9-b6-4e9d526709bc Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 4D.09.13753.7625D9E4; Tue, 18 Oct 2011 12:18:15 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Tue, 18 Oct 2011 12:18:14 +0200 From: Christer Holmberg To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= , Ravindran Parthasarathi Date: Tue, 18 Oct 2011 12:18:13 +0200 Thread-Topic: [rtcweb] SDP Offer/Answer draft-jennings-rtcweb-signaling - Scope Thread-Index: AcyNHd3XJm6MYjRVSSuZHGKO8+XjwwAWc/dg Message-ID: <7F2072F1E0DE894DA4B517B93C6A058522341F416A@ESESSCMS0356.eemea.ericsson.se> References: <15B0E3AD-3086-499A-8E79-7AE58B3376C4@cisco.com> <2E239D6FCD033C4BAF15F386A979BF51159957@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: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: Jonathan Rosenberg , "rtcweb@ietf.org" , "public-webrtc@w3.org" Subject: Re: [rtcweb] SDP Offer/Answer draft-jennings-rtcweb-signaling - Scope X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 10:18:17 -0000 Hi,=20 >No, this is not a draft about a "default signaling protocol"=20 >for RTCweb. Wrong. This is just a protocol for communication=20 >between the JavaScript code and the RTCweb stack in the=20 >browser. It does NOT mandate how the signaling messages are=20 >sent on-the-wire. Eventhough the draft does not suggest a default signaling protocol, I don't= think that is completely true that it is only between the JS app and brosw= er. At least it's not very clear. - Section 5.1 says: "ROAP messages are typically carried over a **reliable = transport** (likely HTTP via XMLHttpRequest or WebSockets),..." - Section 5.3.3 defines an "OK" message, which is used to cease **re-transm= issions** of the ANSWER. - In addition, there is text talking about **ROAP signaling messages** (and= gateways translating between those and SIP messages). So, while I support and offer/answer based approach, I think we need to get= a clearer understanding of the scope. Regards, Christer From ibc@aliax.net Tue Oct 18 03:24: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 BF4B321F8B21 for ; Tue, 18 Oct 2011 03:24:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.627 X-Spam-Level: X-Spam-Status: No, score=-2.627 tagged_above=-999 required=5 tests=[AWL=0.050, 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 72U2dlwlABwO for ; Tue, 18 Oct 2011 03:24:42 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id E01B421F8B2E for ; Tue, 18 Oct 2011 03:24:41 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so415021vcb.31 for ; Tue, 18 Oct 2011 03:24:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.184.103 with SMTP id et7mr1689874vdc.35.1318933481301; Tue, 18 Oct 2011 03:24:41 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Tue, 18 Oct 2011 03:24:41 -0700 (PDT) In-Reply-To: <4E9D43D2.9010804@alvestrand.no> References: <15B0E3AD-3086-499A-8E79-7AE58B3376C4@cisco.com> <4E9D43D2.9010804@alvestrand.no> Date: Tue, 18 Oct 2011 12:24:41 +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: Jonathan Rosenberg , rtcweb@ietf.org, public-webrtc@w3.org Subject: Re: [rtcweb] API options for supporting fork with ROAP (Re: SDP Offer/Answer draft-jennings-rtcweb-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: Tue, 18 Oct 2011 10:24:42 -0000 2011/10/18 Harald Alvestrand : > I and some people from Ericsson had a discussion about forking the other = day > (the ability to send out one request and have it generate multiple > PeerConnections on the response). > > Options include: > > - Sending a request with no content for which state must be kept, creatin= g > new PeerConnection objects on answer that can handle an answer without > generating an offer first, and then renegotiating stuff that needs state > subsequently > - Creating a new "PeerConnectionFactoryWithOffer" object that holds the > state of the request, but has the ability to mint several PeerConnections= on > responses > - Throwing away the initial PeerConnection, munge the incoming Answer to > look like an Offer, create a PeerConnection from it, and throw away the > resulting Answer > - Create the ability to create a PeerConnection from an Offer + an Answer= , > together with the ability to create an Offer without creating a > PeerConnection (this is a variant of the Factory method) > - Do something different..... Hi Harald, if I'm right the problem arises when the RTCweb client generates a SDP/ROAP offer, sends it to the proxy/server and receives more than one SDP/ROAP answer. The problem is that, currently, the PeerConnection object just expects a single answer, am I right? The above options 1 and 3 require the RTCweb client to generate an "INVITE" (let me name it INVITE) with no SDP/ROAP, which IMHO limits too much some possible scenarios. In SIP world, sending an empty INVITE means that the receiver could offer in the 200 OK response a SDP offer with codecs not supported by the caller, so the caller must send ACK and later a BYE. That's commonly ugly so I discourage its usage for RTCweb. Said that, I strongly like your option 2 "Creating a new PeerConnectionFactoryWithOffer". If I understand it properly, when a RTCweb environment allows media forking, the RTCweb client should create a PeerConnectionFactoryWithOffer object rather than a PeerConnection. Then it sends the offer over the wire. Upon receipt of each response with different ROAP/SDP answer, the object would internally generate different PeerConnection objects (but the state of all of them are governed by the PeerConnectionFactoryWithOffer object). Am I right? Regards. --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Tue Oct 18 03:36: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 ACACD21F84B0 for ; Tue, 18 Oct 2011 03:36:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.629 X-Spam-Level: X-Spam-Status: No, score=-2.629 tagged_above=-999 required=5 tests=[AWL=0.048, 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 pNHy6UNpF8H5 for ; Tue, 18 Oct 2011 03:36:19 -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 A408421F87E2 for ; Tue, 18 Oct 2011 03:36:17 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so422991vcb.31 for ; Tue, 18 Oct 2011 03:36:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.25.75 with SMTP id a11mr1746172vdg.1.1318934177121; Tue, 18 Oct 2011 03:36:17 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Tue, 18 Oct 2011 03:36:17 -0700 (PDT) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A058522341F416A@ESESSCMS0356.eemea.ericsson.se> References: <15B0E3AD-3086-499A-8E79-7AE58B3376C4@cisco.com> <2E239D6FCD033C4BAF15F386A979BF51159957@sonusinmail02.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A058522341F416A@ESESSCMS0356.eemea.ericsson.se> Date: Tue, 18 Oct 2011 12:36:17 +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: Jonathan Rosenberg , "rtcweb@ietf.org" , "public-webrtc@w3.org" Subject: Re: [rtcweb] SDP Offer/Answer draft-jennings-rtcweb-signaling - Scope X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 10:36:19 -0000 2011/10/18 Christer Holmberg : >>No, this is not a draft about a "default signaling protocol" >>for RTCweb. Wrong. This is just a protocol for communication >>between the JavaScript code and the RTCweb stack in the >>browser. It does NOT mandate how the signaling messages are >>sent on-the-wire. > > Eventhough the draft does not suggest a default signaling protocol, I don= 't think that is completely true that it is only between the JS app and bro= swer. At least it's not very clear. > > - Section 5.1 says: "ROAP messages are typically carried over a **reliabl= e transport** (likely HTTP via XMLHttpRequest or WebSockets),..." Yes, that is because JavaScript code running in a browser can only communicate via HTTP or WebSocket. > - Section 5.3.3 defines an "OK" message, which is used to cease **re-tran= smissions** of the ANSWER. I expect that is a "guideline" for the signaling protocol implementor. There is no need for such "OK" message to be received from the peer or server. The own JS code could generate it when appropriate and pass it to its RTCweb stack. > - In addition, there is text talking about **ROAP signaling messages** (a= nd gateways translating between those and SIP messages). That just means that, of course, ROAP must be carried within some signaling protocol (obvious) so, in case of interoperating with a SIP network a gateway is required (unless you use SIP over WebSocket). > So, while I support and offer/answer based approach, I think we need to g= et a clearer understanding of the scope. IMHO "ROAP" draft just suggests a generic signaling guidelines for future RTCweb protocol developers. It does define the communication between the JS code and its own RTCweb stack, but not the signaling on-the-wire (for that guidelines are provided). Regards. --=20 I=C3=B1aki Baz Castillo From christer.holmberg@ericsson.com Tue Oct 18 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 7F34821F8C13 for ; Tue, 18 Oct 2011 03:47:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.388 X-Spam-Level: X-Spam-Status: No, score=-6.388 tagged_above=-999 required=5 tests=[AWL=-0.089, 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 FciTi42kyLF3 for ; Tue, 18 Oct 2011 03:47:43 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 57FC121F8C11 for ; Tue, 18 Oct 2011 03:47:43 -0700 (PDT) X-AuditID: c1b4fb3d-b7c26ae0000035b9-b9-4e9d594df05c Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 50.DE.13753.D495D9E4; Tue, 18 Oct 2011 12:47:42 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Tue, 18 Oct 2011 12:47:41 +0200 From: Christer Holmberg To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= Date: Tue, 18 Oct 2011 12:47:40 +0200 Thread-Topic: [rtcweb] SDP Offer/Answer draft-jennings-rtcweb-signaling - Scope Thread-Index: AcyNgcTRxdBKcWXNQKyR1ulxQCxBnQAAHHyQ Message-ID: <7F2072F1E0DE894DA4B517B93C6A058522341F41B7@ESESSCMS0356.eemea.ericsson.se> References: <15B0E3AD-3086-499A-8E79-7AE58B3376C4@cisco.com> <2E239D6FCD033C4BAF15F386A979BF51159957@sonusinmail02.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A058522341F416A@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: Jonathan Rosenberg , "rtcweb@ietf.org" , "public-webrtc@w3.org" Subject: Re: [rtcweb] SDP Offer/Answer draft-jennings-rtcweb-signaling - Scope X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 10:47:44 -0000 Hi,=20 >>>No, this is not a draft about a "default signaling protocol" >>>for RTCweb. Wrong. This is just a protocol for=20 >>>communication between the JavaScript code and the RTCweb stack in the br= owser. It=20 >>>does NOT mandate how the signaling messages are sent on-the-wire. >> >> Eventhough the draft does not suggest a default signaling=20 >> protocol, I don't think that is completely true that it is=20 >> only between the JS app and broswer. At least it's not very clear. >> >> - Section 5.1 says: "ROAP messages are typically carried=20 >> over a **reliable transport** (likely HTTP via XMLHttpRequest=20 >> or WebSockets),..." >=20 > Yes, that is because JavaScript code running in a browser can=20 > only communicate via HTTP or WebSocket. Yes, but the JS app and browser don't communicate with each other using HTT= P or WebSockets. >> - Section 5.3.3 defines an "OK" message, which is used to cease **re-tra= nsmissions** of the ANSWER. >=20 > I expect that is a "guideline" for the signaling protocol implementor. > There is no need for such "OK" message to be received from=20 > the peer or server. The own JS code could generate it when=20 > appropriate and pass it to its RTCweb stack. Why? The browser is not going to re-transmit anything, is it? >> - In addition, there is text talking about **ROAP signaling=20 >> messages** (and gateways translating between those and SIP messages). >=20 > That just means that, of course, ROAP must be carried within=20 > some signaling protocol (obvious) so, in case of=20 > interoperating with a SIP network a gateway is required=20 > (unless you use SIP over WebSocket). Yes, so that means ROAP messages will be carried over some signaling protoc= ol - meaning ROAP is not only a protocol between the JS app and browser. I just want to make sure everybody has the same understanding of the scope,= because at least to me it is a little unclear. Regards, Christer From ibc@aliax.net Tue Oct 18 03: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 3B98821F85A1 for ; Tue, 18 Oct 2011 03:53:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.63 X-Spam-Level: X-Spam-Status: No, score=-2.63 tagged_above=-999 required=5 tests=[AWL=0.047, 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 nYPlcqbFu+0a for ; Tue, 18 Oct 2011 03:53: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 48D6021F86FF for ; Tue, 18 Oct 2011 03:53:08 -0700 (PDT) Received: by vws5 with SMTP id 5so261366vws.31 for ; Tue, 18 Oct 2011 03:53:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.184.103 with SMTP id et7mr1792426vdc.35.1318935187751; Tue, 18 Oct 2011 03:53:07 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Tue, 18 Oct 2011 03:53:07 -0700 (PDT) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A058522341F41B7@ESESSCMS0356.eemea.ericsson.se> References: <15B0E3AD-3086-499A-8E79-7AE58B3376C4@cisco.com> <2E239D6FCD033C4BAF15F386A979BF51159957@sonusinmail02.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A058522341F416A@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A058522341F41B7@ESESSCMS0356.eemea.ericsson.se> Date: Tue, 18 Oct 2011 12:53:07 +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: Jonathan Rosenberg , "rtcweb@ietf.org" , "public-webrtc@w3.org" Subject: Re: [rtcweb] SDP Offer/Answer draft-jennings-rtcweb-signaling - Scope X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 10:53:09 -0000 2011/10/18 Christer Holmberg : >>> - Section 5.1 says: "ROAP messages are typically carried >>> over a **reliable transport** (likely HTTP via XMLHttpRequest >>> or WebSockets),..." >> >> Yes, that is because JavaScript code running in a browser can >> only communicate via HTTP or WebSocket. > > Yes, but the JS app and browser don't communicate with each other using H= TTP or WebSockets. Of course, the signaling must go over a server. >>> - Section 5.3.3 defines an "OK" message, which is used to cease **re-tr= ansmissions** of the ANSWER. >> >> I expect that is a "guideline" for the signaling protocol implementor. >> There is no need for such "OK" message to be received from >> the peer or server. The own JS code could generate it when >> appropriate and pass it to its RTCweb stack. > > Why? The browser is not going to re-transmit anything, is it? That depends on the chosen signaling protocol. ROAP gives guidelines to make a like-VoIP protocol and in VoIP networks retransmissions are sometimes needed. So it's resposability of the JavaScript code to send a retransmission when required. >>> - In addition, there is text talking about **ROAP signaling >>> messages** (and gateways translating between those and SIP messages). >> >> That just means that, of course, ROAP must be carried within >> some signaling protocol (obvious) so, in case of >> interoperating with a SIP network a gateway is required >> (unless you use SIP over WebSocket). > > Yes, so that means ROAP messages will be carried over some signaling prot= ocol - meaning ROAP is not only a protocol between the JS app and browser. Right, but ROAP does not define the protocol and the message exchange on the wire. Just gives some requirements for it (requirements that are common to any VoIP protocol). > I just want to make sure everybody has the same understanding of the scop= e, because at least to me it is a little unclear. IMHO it's clear by reading "Introduction" section: ------------------ The protocol specified here defines the state machines, semantic behaviors, and messages that are exchanged between instances of the state machines. However, it does not specify the actual on-the-wire transport of these messages. Rather, it assumes that the implementation of this protocol would occur within the browser itself, and then browser APIs would allow the application's JavaScript to request creation of messages and insert messages into the state machine. The actual transfer of these messages would be the responsibility of the web application, and would utilize protocols such as HTTP and WebSockets. ------------------ But maybe it could be improved so there are no doubts about what ROAP involves/specifies. Regards. --=20 I=C3=B1aki Baz Castillo From harald@alvestrand.no Tue Oct 18 04: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 E964721F8B43 for ; Tue, 18 Oct 2011 04:10:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.449 X-Spam-Level: X-Spam-Status: No, score=-110.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bY-DqMvfgw0a for ; Tue, 18 Oct 2011 04:10:21 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 0B32021F8B0E for ; Tue, 18 Oct 2011 04:10:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4BF3539E0CD; Tue, 18 Oct 2011 13:10:19 +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 FqMzOQHaVTnA; Tue, 18 Oct 2011 13:10:18 +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 78CAD39E082; Tue, 18 Oct 2011 13:10:18 +0200 (CEST) Message-ID: <4E9D5E9A.7090308@alvestrand.no> Date: Tue, 18 Oct 2011 13:10:18 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= References: <15B0E3AD-3086-499A-8E79-7AE58B3376C4@cisco.com> <4E9D43D2.9010804@alvestrand.no> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: Jonathan Rosenberg , rtcweb@ietf.org, public-webrtc@w3.org Subject: Re: [rtcweb] API options for supporting fork with ROAP (Re: SDP Offer/Answer draft-jennings-rtcweb-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: Tue, 18 Oct 2011 11:10:22 -0000 On 10/18/11 12:24, Iñaki Baz Castillo wrote: > 2011/10/18 Harald Alvestrand: >> I and some people from Ericsson had a discussion about forking the other day >> (the ability to send out one request and have it generate multiple >> PeerConnections on the response). >> >> Options include: >> >> - Sending a request with no content for which state must be kept, creating >> new PeerConnection objects on answer that can handle an answer without >> generating an offer first, and then renegotiating stuff that needs state >> subsequently >> - Creating a new "PeerConnectionFactoryWithOffer" object that holds the >> state of the request, but has the ability to mint several PeerConnections on >> responses >> - Throwing away the initial PeerConnection, munge the incoming Answer to >> look like an Offer, create a PeerConnection from it, and throw away the >> resulting Answer >> - Create the ability to create a PeerConnection from an Offer + an Answer, >> together with the ability to create an Offer without creating a >> PeerConnection (this is a variant of the Factory method) >> - Do something different..... > > Hi Harald, if I'm right the problem arises when the RTCweb client > generates a SDP/ROAP offer, sends it to the proxy/server and receives > more than one SDP/ROAP answer. The problem is that, currently, the > PeerConnection object just expects a single answer, am I right? Yes. My note was intended to point out that there's a number of API solutions here, but they all cost in terms of complexity. > The above options 1 and 3 require the RTCweb client to generate an > "INVITE" (let me name it INVITE) with no SDP/ROAP, which IMHO limits > too much some possible scenarios. In SIP world, sending an empty > INVITE means that the receiver could offer in the 200 OK response a > SDP offer with codecs not supported by the caller, so the caller must > send ACK and later a BYE. That's commonly ugly so I discourage its > usage for RTCweb. > > Said that, I strongly like your option 2 "Creating a new > PeerConnectionFactoryWithOffer". If I understand it properly, when a > RTCweb environment allows media forking, the RTCweb client should > create a PeerConnectionFactoryWithOffer object rather than a > PeerConnection. Then it sends the offer over the wire. Upon receipt of > each response with different ROAP/SDP answer, the object would > internally generate different PeerConnection objects (but the state of > all of them are governed by the PeerConnectionFactoryWithOffer > object). Am I right? Yes, that's right. One advantage of this approach is that the new class comes in addition to the normal PeerConnection class, so the interface for this functionality does not clutter up the interface for applications that don't want to deal with forking; they just never create such objects, and will reply to subsequent answers with "ERROR" (as they're always free to do). There are a number of additional details that need specification before this can be implemented, of course; we might want to delay that functionality beyond the first wave of releases. From ibc@aliax.net Tue Oct 18 04:19:01 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4C1621F8B54 for ; Tue, 18 Oct 2011 04:19:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[AWL=0.045, 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 9eqFPkRIXQgN for ; Tue, 18 Oct 2011 04:19:01 -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 1A3C621F8B53 for ; Tue, 18 Oct 2011 04:19:01 -0700 (PDT) Received: by vws5 with SMTP id 5so283506vws.31 for ; Tue, 18 Oct 2011 04:19:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.25.75 with SMTP id a11mr1901344vdg.1.1318936739922; Tue, 18 Oct 2011 04:18:59 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Tue, 18 Oct 2011 04:18:59 -0700 (PDT) In-Reply-To: <4E9D5E9A.7090308@alvestrand.no> References: <15B0E3AD-3086-499A-8E79-7AE58B3376C4@cisco.com> <4E9D43D2.9010804@alvestrand.no> <4E9D5E9A.7090308@alvestrand.no> Date: Tue, 18 Oct 2011 13:18:59 +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: Jonathan Rosenberg , rtcweb@ietf.org, public-webrtc@w3.org Subject: Re: [rtcweb] API options for supporting fork with ROAP (Re: SDP Offer/Answer draft-jennings-rtcweb-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: Tue, 18 Oct 2011 11:19:01 -0000 2011/10/18 Harald Alvestrand : >> Said that, I strongly like your option 2 "Creating a new >> PeerConnectionFactoryWithOffer". If I understand it properly, when a >> RTCweb environment allows media forking, the RTCweb client should >> create a PeerConnectionFactoryWithOffer object rather than a >> PeerConnection. Then it sends the offer over the wire. Upon receipt of >> each response with different ROAP/SDP answer, the object would >> internally generate different PeerConnection objects (but the state of >> all of them are governed by the PeerConnectionFactoryWithOffer >> object). Am I right? > > Yes, that's right. > > One advantage of this approach is that the new class comes in addition to > the normal PeerConnection class, so the interface for this functionality > does not clutter up the interface for applications that don't want to dea= l > with forking; they just never create such objects, and will reply to > subsequent answers with "ERROR" (as they're always free to do). I like the idea. > There are a number of additional details that need specification before t= his > can be implemented, of course; we might want to delay that functionality > beyond the first wave of releases. As you noted, the point is that this advanced feature can be added later over the existing stack. So I support this proposal. Regards. --=20 I=C3=B1aki Baz Castillo From pravindran@sonusnet.com Tue Oct 18 04:31: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 9148221F89B8 for ; Tue, 18 Oct 2011 04:31:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.749 X-Spam-Level: X-Spam-Status: No, score=-2.749 tagged_above=-999 required=5 tests=[AWL=-0.450, 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 n44SW9uDG3Du for ; Tue, 18 Oct 2011 04:31:30 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 07C9721F899F for ; Tue, 18 Oct 2011 04:31:29 -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 p9IBVxpj021010; Tue, 18 Oct 2011 07:32:00 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail07.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 18 Oct 2011 07:31:25 -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, 18 Oct 2011 17:01:22 +0530 Message-ID: <2E239D6FCD033C4BAF15F386A979BF511599C3@sonusinmail02.sonusnet.com> In-Reply-To: <1F2A2C70609D9E41844A2126145FC09804004302@HKGMBOXPRD22.polycom.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] Review request for RTCWeb standard signaling protocol Thread-Index: AcyNY9RKUZtq4/TvTF2m8ihYBiTuMwACTO9QAAD+IPAABhdKMA== References: <2E239D6FCD033C4BAF15F386A979BF510F1367@sonusinmail02.sonusnet.com><4E8AC222.4050308@alvestrand.no><2E239D6FCD033C4BAF15F386A979BF510F14CE@sonusinmail02.sonusnet.com><2E239D6FCD033C4BAF15F386A979BF510F14FD@sonusinmail02.sonusnet.com><393F1888-F834-4DAE-B6B1-1C5D35EE3292@phonefromhere.com><2E239D6FCD033C4BAF15F386A979BF510F152B@sonusinmail02.sonusnet.com><2E239D6FCD033C4BAF15F386A979BF510F1532@sonusinmail02.sonusnet.com><2E239D6FCD033C4BAF15F386A979BF511598EE@sonusinmail02.sonusnet.com><665A16AB-AAD8-42B3-AC17-7E629EA2DE35@phonefromhere.com><2E239D6FCD033C4BAF15F386A979BF5115992E@sonusinmail02.sonusnet.com><2E239D6FCD033C4BAF15F3 8 6A979B F 51159950@so nusinmail02.sonusnet.com><0950F0E1-6E4B-407F-9563-654AFE79F64B@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF51159994@sonusinmail02.sonusnet.com> <1F2A2C70609D9E41844A2126145FC09804004302@HKGMBOXPRD22.polycom.com> From: "Ravindran Parthasarathi" To: "Avasarala, Ranjit" , =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= X-OriginalArrivalTime: 18 Oct 2011 11:31:25.0742 (UTC) FILETIME=[786E1CE0:01CC8D89] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Review request for RTCWeb standard 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: Tue, 18 Oct 2011 11:31:30 -0000 Agreed Ranjit. >-----Original Message----- >From: Avasarala, Ranjit [mailto:Ranjit.Avasarala@Polycom.com] >Sent: Tuesday, October 18, 2011 2:08 PM >To: Ravindran Parthasarathi; Sa=FAl Ibarra Corretg=E9 >Cc: rtcweb@ietf.org >Subject: RE: [rtcweb] Review request for RTCWeb standard signaling >protocol > >That's the whole issue. We need some mechanism for web browsers to >negotiate offer/answer and ICE candidates between each other. Using SIP >for this over websockets would bring in unnecessary overheads. But we >still need some mechanism. So something which is "simple" is needed. > >Regards >Ranjit > >-----Original Message----- >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On = Behalf >Of Ravindran Parthasarathi >Sent: Tuesday, October 18, 2011 1:46 PM >To: Sa=FAl Ibarra Corretg=E9 >Cc: rtcweb@ietf.org >Subject: Re: [rtcweb] Review request for RTCWeb standard signaling >protocol > >Saul, > >One minor correction in your mail: I have mentioned "SIP over = websocket" >is an overkill and not SIP. > >Thanks >Partha > >>-----Original Message----- >>From: Sa=FAl Ibarra Corretg=E9 [mailto:saul@ag-projects.com] >>Sent: Tuesday, October 18, 2011 12:32 PM >>To: Ravindran Parthasarathi >>Cc: I=F1aki Baz Castillo; rtcweb@ietf.org >>Subject: Re: [rtcweb] Review request for RTCWeb standard signaling >>protocol >> >> >>On Oct 17, 2011, at 7:00 PM, Ravindran Parthasarathi wrote: >> >>> The point to be noted is folks put forth the same argument again & >>again..each time, it is not possible to come up new answer ;-) I >noticed >>often you complain as if your important is missed out. We are arguing >>only about "nothing" vs "something" as a RTCWeb signaling protocol. >>> >>> I clearly explained why SIP over websocket is an overkill in the >below >>mail thread. Please read it and don't argue that it is working. All = the >>working stuff is not good. Infact for any protocol, the first idea = pop- >>up is to tunnel the complete inside (For Ex: ISUP over SIP) but always >>better ways to solve it. >>> >> >>Let me connect the dots: you are advocating for a new 'simple' = protocol >>instead of taking an existing one, SIP for example, which you called >>'overkill'. And earlier in this thread you mentioned that you are >>interested in gateways. >> >>I now understand what you are trying to do. >> >>-- >>Sa=FAl Ibarra Corretg=E9 >>AG Projects >> >> > >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb From harald@alvestrand.no Tue Oct 18 04:43: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 CF1C921F8B64 for ; Tue, 18 Oct 2011 04:43:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.577 X-Spam-Level: X-Spam-Status: No, score=-110.577 tagged_above=-999 required=5 tests=[AWL=0.022, 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 Sb0SWkCx2I+m for ; Tue, 18 Oct 2011 04:43:57 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id D20CA21F8B14 for ; Tue, 18 Oct 2011 04:43:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C23DE39E151 for ; Tue, 18 Oct 2011 13:43: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 Rf4+EGXMP303 for ; Tue, 18 Oct 2011 13:43:55 +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 1B44A39E0CD for ; Tue, 18 Oct 2011 13:43:55 +0200 (CEST) Message-ID: <4E9D667A.2040703@alvestrand.no> Date: Tue, 18 Oct 2011 13:43:54 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: "rtcweb@ietf.org" Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: [rtcweb] My Opinion: Why I think a negotiating protocol is a Good Thing X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 11:43:57 -0000 (Apologies for the length of this note - but I wanted to follow this argument a bit deeply) In the discussions about RTCWEB signalling, Ive had a change of heart. Or perhaps its just a change of terminology. The high bit is this: I believe we need to standardize a negotiation protocol as part of RTCWEB. This needs to be described as a protocol, and cannot usefully be described as an API. This note is to explain to my fellow WG members what led me to this conclusion, and - in some detail - what I think the words in the above paragraph mean. Those who don't want to read a long message can stop here. ---------------------------------------------------------------------------- The context of RTCWEB is the well known trapezoid: +-----------+ +-----------+ | Web | | Web | | | Signalling | | | |-------------| | | Server | path | Server | | | | | +-----------+ +-----------+ / \ / \ Proprietary over / \ HTTP/Websockets / \ / Proprietary over \ / HTTP/Websockets \ / \ +-----------+ +-----------+ |JS/HTML/CSS| |JS/HTML/CSS| +-----------+ +-----------+ +-----------+ +-----------+ | | | | | | | | | Browser | ------------------------- | Browser | | | Media path | | | | | | +-----------+ +-----------+ or even the triangle, where the triangle is formed when the two Web severs on top are collapsed into one. A design criterion for RTCWEB has been that it should be possible to write applications on top of RTCWEB simply - that is, without deep knowledge about the world of codecs, RTP sessions and the like. Another design criterion is that interworking should be possible - which means that SOMEWHERE in the system, deep knowledge about the world of codecs, RTP sessions and the like must be embedded; we cant just simplify our options until everythings simple. Theres one place in the ecosystem where this knowledge HAS to be - and that is within the browser, the component that takes care of implementing the codecs, the RTP sessions and the related features. If we can avoid requiring embedding it twice, thats a feature. It used to be that I was a believer in APIs - that we should make the API the king, and describe the way you generate an RTP session as you turn this knob, and get this effect. After looking at the problem of Web applications that dont have domain knowledge for a while, Ive concluded that this doesnt work. Theres the need for one browser to communicate with the other browser, and if the intermediate components are to have the ability to ignore the details, whats communicated has to be treated like a blob - something passed out of one browsers API and into another browsers API, unchanged by the application - because the application must be able to ignore the details. OK, now we have the API with blobs. We also have to make some assumptions about how those blobs are transported, whos responsible for acting on them, and so on. And we have to make sure different browsers implement the blob the same way - that is, it has to be standardized. Whats more - we DO want to enable applications that are NOT simple. Including gateways, which are not browsers. So applications must be free to look inside the blob - break the blob boundary - when they need to. So this pulls in the same direction as the need for interoperability - the format, semantics and handling rules for these blobs has to be specified. In some detail. So we have: - a data format - a transmission path - a set of handling rules, in the form of states, processes and timers This doesnt look like an API any more. This looks like a protocol. Weve got experience in describing protocols - but it becomes much easier to apply that experience when we call it a protocol. Lets do that. But - you did not address my point... ---------------------------------------------- No, I didnt. But here are some points that might bear watching. We shouldnt mandate a new protocol on the wire. Were not. Were specifying one, and mandating it for a specific point: The browser/JS interface. We can have applications that parse it locally using a JS library; in that case, the protocol runs between the browser and the local JS application. We can have applications that pass the blobs to a server for gatewaying into something else; in that case, the protocol runs between the browser and the server. We can have applications that pass the blobs (possibly via a very simple server) to another browser, unchanged; in that case, the protocol runs between the two browsers. In no case does the browser need to know where the other end is; all it cares about is that the messages flow according to protocol. We should build knobs and let JS libraries take care of whats on top of them. Well - we could. But it violates the idea of only having the domain knowledge present once. If you have to have a browser that implements codec A, and a JS library that knows how to control codec A, you are *requiring* knowledge in two places. Thats not optimal. Things may change in the future - once downloadable codecs actually work, downloadable negotiation blobs may be a reasonable counterpart. But were not there now. We should use existing protocol X We could. But then, wed buy into all the baggage of protocol X - both the things it requires us to do and the things that it wont let us do. Doesnt sound too good to me. From ibc@aliax.net Tue Oct 18 05: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 1C5E821F8B82 for ; Tue, 18 Oct 2011 05:03:13 -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.044, 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 VB4QfwZxApYL for ; Tue, 18 Oct 2011 05:03: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 7E89421F8B39 for ; Tue, 18 Oct 2011 05:03:12 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so494574vcb.31 for ; Tue, 18 Oct 2011 05:03:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.73.166 with SMTP id m6mr2047907vdv.18.1318939391908; Tue, 18 Oct 2011 05:03:11 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Tue, 18 Oct 2011 05:03:11 -0700 (PDT) In-Reply-To: <4E9D667A.2040703@alvestrand.no> References: <4E9D667A.2040703@alvestrand.no> Date: Tue, 18 Oct 2011 14:03:11 +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] My Opinion: Why I think a negotiating protocol is a Good Thing X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 12:03:13 -0000 2011/10/18 Harald Alvestrand : > There=E2=80=99s the need for one browser to communicate with the other br= owser, and > if the intermediate components are to have the ability to ignore the > details, what=E2=80=99s communicated has to be treated like a blob - some= thing > passed out of one browser=E2=80=99s API and into another browser=E2=80=99= s API, unchanged by > the application - because the application must be able to ignore the > details. > > OK, now we have the API with blobs. We also have to make some assumptions > about how those blobs are transported, who=E2=80=99s responsible for acti= ng on them, > and so on. And we have to make sure different browsers implement the blob > the same way - that is, it has to be standardized. Is not that covered win ROAP draft? AFAIK ROAP defines how the SDP are communicated from the JS to the RTCweb stack and viceversa. > What=E2=80=99s more - we DO want to enable applications that are NOT simp= le. > Including gateways, which are not browsers. So applications must be free = to > look inside the blob - break the blob boundary - when they need to. So th= is > pulls in the same direction as the need for interoperability - the format= , > semantics and handling rules for these blobs has to be specified. Of course they must be specificied, but do you mean that such specification must be a single one? In order to understand what you are proposing let me ask a question: I use SIP over WebSocket, I just need RTCweb API's to be defined. Does your proposal mean that I won't be able to use SIP over WebSocket and instead I must use some specific protocol between the JS client and the server? I hope the answer is not... Regards. --=20 I=C3=B1aki Baz Castillo From neils@vipadia.com Tue Oct 18 05:20: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 6CB4521F8B39 for ; Tue, 18 Oct 2011 05:20:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.955 X-Spam-Level: X-Spam-Status: No, score=-2.955 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pvGMEaHHjVif for ; Tue, 18 Oct 2011 05:20:13 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id AEED721F8B37 for ; Tue, 18 Oct 2011 05:20:06 -0700 (PDT) Received: by iabn5 with SMTP id n5so752156iab.31 for ; Tue, 18 Oct 2011 05:20:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.24.96 with SMTP id u32mr970450ibb.61.1318940404701; Tue, 18 Oct 2011 05:20:04 -0700 (PDT) Sender: neils@vipadia.com Received: by 10.231.199.4 with HTTP; Tue, 18 Oct 2011 05:20:04 -0700 (PDT) In-Reply-To: <4E9D667A.2040703@alvestrand.no> References: <4E9D667A.2040703@alvestrand.no> Date: Tue, 18 Oct 2011 13:20:04 +0100 X-Google-Sender-Auth: kGWo55iLuMOqk8tp7S2Ceu4_0Rc Message-ID: From: Neil Stratford To: Harald Alvestrand Content-Type: multipart/alternative; boundary=0015177414284d594204af91becd Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] My Opinion: Why I think a negotiating protocol is a Good Thing X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 12:20:14 -0000 --0015177414284d594204af91becd Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Tue, Oct 18, 2011 at 12:43 PM, Harald Alvestrand w= rote: > I believe we need to standardize a negotiation protocol as part of RTCWEB= . > This needs to be described as a protocol, and cannot usefully be describe= d > as an API. > I strongly disagree. We need an API, not a protocol. This is a fundamentall= y different problem to traditional RTC due to the presence of the javascript execution engine that can implement the protocol. > A design criterion for RTCWEB has been that it should be possible to writ= e > applications on top of RTCWEB simply - that is, without deep knowledge ab= out > the world of codecs, RTP sessions and the like. > Which can be achieved even with a low-level javascript API by leveraging library code. We do not need to embed every bit of intelligence into the browser to enable that to happen. > Another design criterion is that interworking should be possible - which > means that SOMEWHERE in the system, deep knowledge about the world of > codecs, RTP sessions and the like must be embedded; we can=92t just simpl= ify > our options until everything=92s simple. > > There=92s one place in the ecosystem where this knowledge HAS to be - and > that is within the browser, the component that takes care of implementing > the codecs, the RTP sessions and the related features. If we can avoid > requiring embedding it twice, that=92s a feature. > Agreed - the browser handles RTP and codecs, and the javascript should handle negotiation and protocol state machines. > It used to be that I was a believer in APIs - that we should make the API > the =93king=94, and describe the way you generate an RTP session as =93yo= u turn > this knob, and get this effect=94. > After looking at the problem of Web applications that don=92t have domain > knowledge for a while, I=92ve concluded that this doesn=92t work. There= =92s the > need for one browser to communicate with the other browser, and if the > intermediate components are to have the ability to ignore the details, > what=92s communicated has to be treated like a blob - something passed ou= t of > one browser=92s API and into another browser=92s API, unchanged by the > application - because the application must be able to ignore the details. > The application can equally ignore what a library does if it wants to, but it's not tied to one library, it can pick the one most suited to the task i= n hand. > What=92s more - we DO want to enable applications that are NOT simple. > Including gateways, which are not browsers. So applications must be free = to > look inside the blob - break the blob boundary - when they need to. So th= is > pulls in the same direction as the need for interoperability - the format= , > semantics and handling rules for these blobs has to be specified. In some > detail. > This is the problem with passing blobs through an API. If we had a low-leve= l API we wouldn't be passing blobs. Neil --0015177414284d594204af91becd Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On Tue, Oct 18, 2011 at 12:43 PM, Harald Alvestr= and <harald@al= vestrand.no> wrote:
I believe we need to standardize a negotiation protocol as part of RTCWEB.<= br> This needs to be described as a protocol, and cannot usefully be described = as an API.

I strongly disagree. We need= an API, not a protocol. This is a fundamentally different problem to tradi= tional RTC due to the presence of the javascript execution engine that can = implement the protocol.
=A0
A design criterion for RTCWEB has been that it should be possible to write = applications on top of RTCWEB simply - that is, without deep knowledge abou= t the world of codecs, RTP sessions and the like.

Which can be achieved even with a low-level javascript API b= y leveraging library code. We do not need to embed every bit of intelligenc= e into the browser to enable that to happen.
=A0
Another design criterion is that interworking should be possible - which me= ans that SOMEWHERE in the system, deep knowledge about the world of codecs,= RTP sessions and the like must be embedded; we can=92t just simplify our o= ptions until everything=92s simple.

There=92s one place in the ecosystem where this knowledge HAS to be - and t= hat is within the browser, the component that takes care of implementing th= e codecs, the RTP sessions and the related features. If we can avoid requir= ing embedding it twice, that=92s a feature.

Agreed - the browser handles RTP and codec= s, and the javascript should handle negotiation and protocol state machines= .
=A0
It used to be that I was a believer in APIs - that we should make the API t= he =93king=94, and describe the way you generate an RTP session as =93you t= urn this knob, and get this effect=94.
After looking at the problem of Web applications that don=92t have domain k= nowledge for a while, I=92ve concluded that this doesn=92t work. There=92s = the need for one browser to communicate with the other browser, and if the = intermediate components are to have the ability to ignore the details, what= =92s communicated has to be treated like a blob - something passed out of o= ne browser=92s API and into another browser=92s API, unchanged by the appli= cation - because the application must be able to ignore the details.

The application can equally ignore what a = library does if it wants to, but it's not tied to one library, it can p= ick the one most suited to the task in hand.
=A0
What=92s more - we DO want to enable applications that are NOT simple. Incl= uding gateways, which are not browsers. So applications must be free to loo= k inside the blob - break the blob boundary - when they need to. So this pu= lls in the same direction as the need for interoperability - the format, se= mantics and handling rules for these blobs has to be specified. In some det= ail.

This is the problem with passing blobs thr= ough an API. If we had a low-level API we wouldn't be passing blobs.
=A0
Neil
--0015177414284d594204af91becd-- From ibc@aliax.net Tue Oct 18 05: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 C147121F8B43 for ; Tue, 18 Oct 2011 05:21:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.634 X-Spam-Level: X-Spam-Status: No, score=-2.634 tagged_above=-999 required=5 tests=[AWL=0.043, 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 ZiuNYuA74l+C for ; Tue, 18 Oct 2011 05:21:24 -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 7076821F84B8 for ; Tue, 18 Oct 2011 05:20:51 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so513621vcb.31 for ; Tue, 18 Oct 2011 05:20:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.117.81 with SMTP id p17mr155582vcq.41.1318940450608; Tue, 18 Oct 2011 05:20:50 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Tue, 18 Oct 2011 05:20:50 -0700 (PDT) In-Reply-To: References: <4E9D667A.2040703@alvestrand.no> Date: Tue, 18 Oct 2011 14:20:50 +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] My Opinion: Why I think a negotiating protocol is a Good Thing X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 12:21:26 -0000 2011/10/18 I=C3=B1aki Baz Castillo : > I use SIP over WebSocket, I just need RTCweb API's to be defined. Does > your proposal mean that I won't be able to use SIP over WebSocket and > instead I must use some specific protocol between the JS client and > the server? I hope the answer is not... After re-reading your mail, I'm less afraid: ----------------- =E2=80=9CWe shouldn=E2=80=99t mandate a new protocol on the wire=E2=80=9D. We=E2=80=99re not. We=E2=80=99re specifying one, and mandating it for a spe= cific point: The browser/JS interface. We can have applications that parse it locally using a JS library; in that case, the protocol runs between the browser and the local JS application. We can have applications that pass the blobs to a server for gatewaying into something else; in that case, the protocol runs between the browser and the server. We can have applications that pass the blobs (possibly via a very simple server) to another browser, unchanged; in that case, the protocol runs between the two browsers. ----------------- So line 3 allows me to sleep tonigh :) However, I don't fully understand why ROAP is not enough. =C2=BFDoes not it specify the *signaling* communication between the JS and the browser (RTCweb stack)? --=20 I=C3=B1aki Baz Castillo From stefan.lk.hakansson@ericsson.com Tue Oct 18 05:25:01 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7073521F8BAA for ; Tue, 18 Oct 2011 05:25:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_24=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 dxI5UESUf04w for ; Tue, 18 Oct 2011 05:25: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 0E9CD21F8B43 for ; Tue, 18 Oct 2011 05:24:59 -0700 (PDT) X-AuditID: c1b4fb3d-b7c26ae0000035b9-7d-4e9d701a1799 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id B2.82.13753.A107D9E4; Tue, 18 Oct 2011 14:24:58 +0200 (CEST) Received: from [150.132.142.226] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.137.0; Tue, 18 Oct 2011 14:24:58 +0200 Message-ID: <4E9D7019.2020303@ericsson.com> Date: Tue, 18 Oct 2011 14:24:57 +0200 From: =?UTF-8?B?U3RlZmFuIEjDpWthbnNzb24gTEs=?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110922 Lightning/1.0b2 Thunderbird/3.1.15 MIME-Version: 1.0 To: rtcweb@ietf.org References: <15B0E3AD-3086-499A-8E79-7AE58B3376C4@cisco.com> <4E9D43D2.9010804@alvestrand.no> <4E9D5E9A.7090308@alvestrand.no> In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [rtcweb] API options for supporting fork with ROAP (Re: SDP Offer/Answer draft-jennings-rtcweb-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: Tue, 18 Oct 2011 12:25:01 -0000 Our idea is basically that whenever you create a new PeerConnection in the same context as you have already created one or more PeerConnection's, the same local candidates should be re-used. Of course the 5-tuple must remain unique so that different connections don't collapse into one, but this is quite simple to resolve. For clarity, the above would be requirements on the implementation (in browsers). This means that support of forking would be simple as the IP+port's to send media to (for the remote end) remains also for the new PeerConnection. Another advantage is that creating new PeerConnections will be faster as new candidates does not need to be gathered. I think this is quite a clean solution since there is no need for API changes, or any additional factory layer. Stefan On 10/18/2011 01:18 PM, Iñaki Baz Castillo wrote: > 2011/10/18 Harald Alvestrand: >>> Said that, I strongly like your option 2 "Creating a new >>> PeerConnectionFactoryWithOffer". If I understand it properly, when a >>> RTCweb environment allows media forking, the RTCweb client should >>> create a PeerConnectionFactoryWithOffer object rather than a >>> PeerConnection. Then it sends the offer over the wire. Upon receipt of >>> each response with different ROAP/SDP answer, the object would >>> internally generate different PeerConnection objects (but the state of >>> all of them are governed by the PeerConnectionFactoryWithOffer >>> object). Am I right? >> >> Yes, that's right. >> >> One advantage of this approach is that the new class comes in addition to >> the normal PeerConnection class, so the interface for this functionality >> does not clutter up the interface for applications that don't want to deal >> with forking; they just never create such objects, and will reply to >> subsequent answers with "ERROR" (as they're always free to do). > > I like the idea. > > > >> There are a number of additional details that need specification before this >> can be implemented, of course; we might want to delay that functionality >> beyond the first wave of releases. > > As you noted, the point is that this advanced feature can be added > later over the existing stack. So I support this proposal. > > > Regards. > > > > From stefan.lk.hakansson@ericsson.com Tue Oct 18 05:34: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 79D3221F8B6F for ; Tue, 18 Oct 2011 05:34:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.149 X-Spam-Level: X-Spam-Status: No, score=-6.149 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 qJ7TZwm9Fq+J for ; Tue, 18 Oct 2011 05:34: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 41C4421F8BAA for ; Tue, 18 Oct 2011 05:34:51 -0700 (PDT) X-AuditID: c1b4fb3d-b7c26ae0000035b9-20-4e9d726aebd8 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id A1.44.13753.A627D9E4; Tue, 18 Oct 2011 14:34:50 +0200 (CEST) Received: from [150.132.142.226] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.137.0; Tue, 18 Oct 2011 14:34:50 +0200 Message-ID: <4E9D7269.8000501@ericsson.com> Date: Tue, 18 Oct 2011 14:34:49 +0200 From: =?windows-1252?Q?Stefan_H=E5kansson_LK?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110922 Lightning/1.0b2 Thunderbird/3.1.15 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4E9D667A.2040703@alvestrand.no> In-Reply-To: <4E9D667A.2040703@alvestrand.no> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [rtcweb] My Opinion: Why I think a negotiating protocol is a Good Thing X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 12:34:53 -0000 If "negotiation protocol" means something that resembles ROAP (i.e. more or less a wrapper on SDP o/a that enables negotiation of session/streams), then I agree. I really like that the application does not need to bother, all knowledge of state, codecs, RTP, .... can be limited to the browser as long as the app passes the blobs on. On 10/18/2011 01:43 PM, Harald Alvestrand wrote: > (Apologies for the length of this note - but I wanted to follow this > argument a bit deeply) > > In the discussions about RTCWEB signalling, Ive had a change of heart. > Or perhaps its just a change of terminology. > > The high bit is this: > I believe we need to standardize a negotiation protocol as part of RTCWEB. > This needs to be described as a protocol, and cannot usefully be > described as an API. > > This note is to explain to my fellow WG members what led me to this > conclusion, and - in some detail - what I think the words in the above > paragraph mean. > Those who don't want to read a long message can stop here. > ---------------------------------------------------------------------------- > > The context of RTCWEB is the well known trapezoid: > > +-----------+ +-----------+ > | Web | | Web | > | | Signalling | | > | |-------------| | > | Server | path | Server | > | | | | > +-----------+ +-----------+ > / \ > / \ Proprietary over > / \ HTTP/Websockets > / \ > / Proprietary over \ > / HTTP/Websockets \ > / \ > +-----------+ +-----------+ > |JS/HTML/CSS| |JS/HTML/CSS| > +-----------+ +-----------+ > +-----------+ +-----------+ > | | | | > | | | | > | Browser | ------------------------- | Browser | > | | Media path | | > | | | | > +-----------+ +-----------+ > > or even the triangle, where the triangle is formed when the two Web > severs on top are collapsed into one. > > A design criterion for RTCWEB has been that it should be possible to > write applications on top of RTCWEB simply - that is, without deep > knowledge about the world of codecs, RTP sessions and the like. > Another design criterion is that interworking should be possible - which > means that SOMEWHERE in the system, deep knowledge about the world of > codecs, RTP sessions and the like must be embedded; we cant just > simplify our options until everythings simple. > > Theres one place in the ecosystem where this knowledge HAS to be - and > that is within the browser, the component that takes care of > implementing the codecs, the RTP sessions and the related features. If > we can avoid requiring embedding it twice, thats a feature. > > It used to be that I was a believer in APIs - that we should make the > API the king, and describe the way you generate an RTP session as you > turn this knob, and get this effect. > After looking at the problem of Web applications that dont have domain > knowledge for a while, Ive concluded that this doesnt work. Theres > the need for one browser to communicate with the other browser, and if > the intermediate components are to have the ability to ignore the > details, whats communicated has to be treated like a blob - something > passed out of one browsers API and into another browsers API, > unchanged by the application - because the application must be able to > ignore the details. > > OK, now we have the API with blobs. We also have to make some > assumptions about how those blobs are transported, whos responsible for > acting on them, and so on. And we have to make sure different browsers > implement the blob the same way - that is, it has to be standardized. > Whats more - we DO want to enable applications that are NOT simple. > Including gateways, which are not browsers. So applications must be free > to look inside the blob - break the blob boundary - when they need to. > So this pulls in the same direction as the need for interoperability - > the format, semantics and handling rules for these blobs has to be > specified. In some detail. > > So we have: > - a data format > - a transmission path > - a set of handling rules, in the form of states, processes and timers > > This doesnt look like an API any more. This looks like a protocol. > Weve got experience in describing protocols - but it becomes much > easier to apply that experience when we call it a protocol. > > Lets do that. > > But - you did not address my point... > ---------------------------------------------- > No, I didnt. But here are some points that might bear watching. > > We shouldnt mandate a new protocol on the wire. > Were not. Were specifying one, and mandating it for a specific point: > The browser/JS interface. > We can have applications that parse it locally using a JS library; in > that case, the protocol runs between the browser and the local JS > application. > We can have applications that pass the blobs to a server for gatewaying > into something else; in that case, the protocol runs between the browser > and the server. > We can have applications that pass the blobs (possibly via a very simple > server) to another browser, unchanged; in that case, the protocol runs > between the two browsers. > > In no case does the browser need to know where the other end is; all it > cares about is that the messages flow according to protocol. > > We should build knobs and let JS libraries take care of whats on top > of them. > Well - we could. But it violates the idea of only having the domain > knowledge present once. > If you have to have a browser that implements codec A, and a JS library > that knows how to control codec A, you are *requiring* knowledge in two > places. Thats not optimal. > Things may change in the future - once downloadable codecs actually > work, downloadable negotiation blobs may be a reasonable counterpart. > But were not there now. > > We should use existing protocol X > We could. But then, wed buy into all the baggage of protocol X - both > the things it requires us to do and the things that it wont let us do. > Doesnt sound too good to me. > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From harald@alvestrand.no Tue Oct 18 05: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 4A86221F8B21 for ; Tue, 18 Oct 2011 05:40:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.43 X-Spam-Level: X-Spam-Status: No, score=-110.43 tagged_above=-999 required=5 tests=[AWL=-0.131, 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 A+LZuurwsAmA for ; Tue, 18 Oct 2011 05:40:00 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 4D9D821F8A58 for ; Tue, 18 Oct 2011 05:40:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9BC1339E151; Tue, 18 Oct 2011 14:39: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 a8ts154sN029; Tue, 18 Oct 2011 14:39:59 +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 2124D39E082; Tue, 18 Oct 2011 14:39:59 +0200 (CEST) Message-ID: <4E9D739E.6020906@alvestrand.no> Date: Tue, 18 Oct 2011 14:39:58 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= References: <4E9D667A.2040703@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] My Opinion: Why I think a negotiating protocol is a Good Thing X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 12:40:01 -0000 On 10/18/11 14:20, Iñaki Baz Castillo wrote: > 2011/10/18 Iñaki Baz Castillo: >> I use SIP over WebSocket, I just need RTCweb API's to be defined. Does >> your proposal mean that I won't be able to use SIP over WebSocket and >> instead I must use some specific protocol between the JS client and >> the server? I hope the answer is not... > After re-reading your mail, I'm less afraid: > > ----------------- > “We shouldn’t mandate a new protocol on the wire”. > > We’re not. We’re specifying one, and mandating it for a specific > point: The browser/JS interface. > > We can have applications that parse it locally using a JS library; in > that case, the protocol runs between the browser and the local JS > application. > > We can have applications that pass the blobs to a server for > gatewaying into something else; in that case, the protocol runs > between the browser and the server. > > We can have applications that pass the blobs (possibly via a very > simple server) to another browser, unchanged; in that case, the > protocol runs between the two browsers. > ----------------- > > So line 3 allows me to sleep tonigh :) > > However, I don't fully understand why ROAP is not enough. ¿Does not it > specify the *signaling* communication between the JS and the browser > (RTCweb stack)? > To be clear: I believe that ROAP is a good candidate specification for the "blob protocol". I support the ROAP approach; in this note, I'm trying to lay out my thinking for why I support it. Harald From radhika.r.roy.civ@mail.mil Tue Oct 18 05: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 8DA6421F8B85 for ; Tue, 18 Oct 2011 05:49:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.445 X-Spam-Level: X-Spam-Status: No, score=-2.445 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 LHfZzsd8HhGI for ; Tue, 18 Oct 2011 05:49:21 -0700 (PDT) Received: from edge-cols.mail.mil (edge-cols.mail.mil [131.64.100.6]) by ietfa.amsl.com (Postfix) with ESMTP id EF8C421F8B7E for ; Tue, 18 Oct 2011 05:49:20 -0700 (PDT) Received: from UCOLHP3F.easf.csd.disa.mil (131.64.100.145) by UCOLHP4Z.easf.csd.disa.mil (131.64.100.6) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 18 Oct 2011 07:49:08 -0500 Received: from UCOLHP4D.easf.csd.disa.mil ([169.254.9.97]) by UCOLHP3F.easf.csd.disa.mil ([169.254.56.193]) with mapi id 14.01.0323.003; Tue, 18 Oct 2011 07:49:07 -0500 From: "Roy, Radhika R USA CIV (US)" To: Ravindran Parthasarathi , Cullen Jennings , "rtcweb@ietf.org" , "public-webrtc@w3.org" Thread-Topic: [rtcweb] SDP Offer/Answer draft-jennings-rtcweb-signaling Thread-Index: AcyK59gjnHrw6AUkQx6KmrMgad4vKACMb4NgAB6cXnA= Date: Tue, 18 Oct 2011 12:49:06 +0000 Message-ID: <8486C8728176924BAF5BDB2F7D7EEDDF3E091C38@ucolhp4d.easf.csd.disa.mil> References: <15B0E3AD-3086-499A-8E79-7AE58B3376C4@cisco.com> <2E239D6FCD033C4BAF15F386A979BF51159957@sonusinmail02.sonusnet.com> In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF51159957@sonusinmail02.sonusnet.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.64.77.9] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Jonathan Rosenberg Subject: Re: [rtcweb] SDP Offer/Answer draft-jennings-rtcweb-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: Tue, 18 Oct 2011 12:49:21 -0000 Partha: I believe it may be B2BUA along with proxy-capability that a Web server mig= ht have. However, Cullen and Jonathan might clearify this. BR/Radhika -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Ravindran Parthasarathi Sent: Monday, October 17, 2011 6:28 PM To: Cullen Jennings; rtcweb@ietf.org; public-webrtc@w3.org Cc: Jonathan Rosenberg Subject: Re: [rtcweb] SDP Offer/Answer draft-jennings-rtcweb-signaling Cullen/Joanthan, I like your proposed idea as it is going in the direction of having "standa= rd" signaling protocol for RTCWeb. I'm seeing your proposal as SDP offer/an= swer over websocket and the proposal helps to easy gateway development betw= een RTCWeb server and legacy signaling protocols. I have fundamental question in the proposal as it proposes RTCWeb server as= SIP proxy equivalent and in reality, unfortunately most of the SIP deploym= ent work is based on B2BUA. The question is whether RTCWeb server shall be = dialog-state or MUST be transaction-stateful only.=20 Also, session-id in the draft is used to uniquely understand the offerer an= d answerer in the transaction or session. In case it is session, how to ind= icate the termination of the session. Thanks Partha From tim@phonefromhere.com Tue Oct 18 05:53: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 1D16421F8B7E for ; Tue, 18 Oct 2011 05:53:45 -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 xmF93UT9+eNi for ; Tue, 18 Oct 2011 05:53:44 -0700 (PDT) Received: from zimbra.westhawk.co.uk (zimbra.westhawk.co.uk [192.67.4.167]) by ietfa.amsl.com (Postfix) with ESMTP id 8DD5B21F8B43 for ; Tue, 18 Oct 2011 05:53:43 -0700 (PDT) Received: from [192.168.0.14] (unknown [93.89.81.113]) by zimbra.westhawk.co.uk (Postfix) with ESMTP id 82B1137A902; Tue, 18 Oct 2011 14:06:28 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-5--814682935 From: Tim Panton In-Reply-To: <4E9D667A.2040703@alvestrand.no> Date: Tue, 18 Oct 2011 13:53:36 +0100 Message-Id: <9B03E9E2-4376-465E-84F5-EDAC51390408@phonefromhere.com> References: <4E9D667A.2040703@alvestrand.no> To: Harald Alvestrand X-Mailer: Apple Mail (2.1084) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] My Opinion: Why I think a negotiating protocol is a Good Thing X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 12:53:45 -0000 --Apple-Mail-5--814682935 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 18 Oct 2011, at 12:43, Harald Alvestrand wrote: > (Apologies for the length of this note - but I wanted to follow this = argument a bit deeply) >=20 > In the discussions about RTCWEB signalling, I=92ve had a change of = heart. > Or perhaps it=92s just a change of terminology. >=20 > The high bit is this: > I believe we need to standardize a negotiation protocol as part of = RTCWEB. > This needs to be described as a protocol, and cannot usefully be = described as an API. >=20 > This note is to explain to my fellow WG members what led me to this = conclusion, and - in some detail - what I think the words in the above = paragraph mean. > Those who don't want to read a long message can stop here. > = --------------------------------------------------------------------------= -- >=20 > The context of RTCWEB is the well known trapezoid: >=20 > +-----------+ +-----------+ > | Web | | Web | > | | Signalling | | > | |-------------| | > | Server | path | Server | > | | | | > +-----------+ +-----------+ > / \ > / \ Proprietary over > / \ HTTP/Websockets > / \ > / Proprietary over \ > / HTTP/Websockets \ > / \ > +-----------+ +-----------+ > |JS/HTML/CSS| |JS/HTML/CSS| > +-----------+ +-----------+ > +-----------+ +-----------+ > | | | | > | | | | > | Browser | ------------------------- | Browser | > | | Media path | | > | | | | > +-----------+ +-----------+ >=20 > or even the triangle, where the triangle is formed when the two Web = severs on top are collapsed into one. >=20 > A design criterion for RTCWEB has been that it should be possible to = write applications on top of RTCWEB simply - that is, without deep = knowledge about the world of codecs, RTP sessions and the like. > Another design criterion is that interworking should be possible - = which means that SOMEWHERE in the system, deep knowledge about the world = of codecs, RTP sessions and the like must be embedded; we can=92t just = simplify our options until everything=92s simple. I've generally found that "simplify our options until everything=92s = simple" is a very good policy for Version one of anything.=20 But instead we have a complex set of PSTN-interop centric requirements, = it is no surprise that we will come up with a complex PSTN centric = solution. Sadly this will be such a straight-jacket that no other new uses will = flourish. >=20 > There=92s one place in the ecosystem where this knowledge HAS to be - = and that is within the browser, the component that takes care of = implementing the codecs, the RTP sessions and the related features. If = we can avoid requiring embedding it twice, that=92s a feature. Actually it isn't a universally desired feature. The web is full of = multiple ways of manipulating the same object. an HTML table can be specified in HTML, manipulated in a DOM via = javascript, and styled in CSS .=20 The writer of each of those bits of code needs to understand what a = table is or does at least partially. >=20 > It used to be that I was a believer in APIs - that we should make the = API the =93king=94, and describe the way you generate an RTP session as = =93you turn this knob, and get this effect=94. > After looking at the problem of Web applications that don=92t have = domain knowledge for a while, I=92ve concluded that this doesn=92t work. = There=92s the need for one browser to communicate with the other = browser, and if the intermediate components are to have the ability to = ignore the details, what=92s communicated has to be treated like a blob = - something passed out of one browser=92s API and into another browser=92s= API, unchanged by the application - because the application must be = able to ignore the details. Extend that argument a bit further - the codecs at each end can agree = about their mutual compatibility very simply - without involving the = rest of the stack. All they have to do is expose a method on the decoder that = can check the self-description sent by the encoder. Instead we are making a monolithic codec/network/negotiation/(signalling = soon) hunk of code instead of splitting out the parts and (for=20 example ) exposing the codecs as objects with behaviours. >=20 > OK, now we have the API with blobs. We also have to make some = assumptions about how those blobs are transported, who=92s responsible = for acting on them, and so on. And we have to make sure different = browsers implement the blob the same way - that is, it has to be = standardized. > What=92s more - we DO want to enable applications that are NOT simple. = Including gateways, which are not browsers. So applications must be free = to look inside the blob - break the blob boundary - when they need to. = So this pulls in the same direction as the need for interoperability - = the format, semantics and handling rules for these blobs has to be = specified. In some detail. We have an API with blobs only because we chose to stick with the = ugliness that is SDP. Once you take that decision, the rest follows. >=20 > So we have: > - a data format > - a transmission path > - a set of handling rules, in the form of states, processes and timers >=20 > This doesn=92t look like an API any more. This looks like a protocol. = We=92ve got experience in describing protocols - but it becomes much = easier to apply that experience when we call it a protocol. Ok, lets design a protocol (if we must), but let's base it on the real = capabilities of browsers, web coders abilities and the real needs of web = users,=20 not constantly looking over our shoulders at a legacy protocol that = barely works in the environment it was designed for. And will this new protocol have a standard API ? >=20 Tim.=20 --Apple-Mail-5--814682935 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
(Apologies for the length of this note - but I wanted = to follow this argument a bit deeply)

In the discussions about = RTCWEB signalling, I=92ve had a change of heart.
Or perhaps it=92s = just a change of terminology.

The high bit is this:
I believe = we need to standardize a negotiation protocol as part of RTCWEB.
This = needs to be described as a protocol, and cannot usefully be described as = an API.

This note is to explain to my fellow WG members what led = me to this conclusion, and - in some detail - what I think the words in = the above paragraph mean.
Those who don't want to read a long message = can stop = here.
-----------------------------------------------------------------= -----------

The context of RTCWEB is the well known = trapezoid:

+-----------+ +-----------+
| Web | | Web |
| | = Signalling | |
| |-------------| |
| Server | path | Server |
| = | | |
+-----------+ +-----------+
/ \
/ \ Proprietary over
/ = \ HTTP/Websockets
/ \
/ Proprietary over \
/ HTTP/Websockets = \
/ \
+-----------+ +-----------+
|JS/HTML/CSS| = |JS/HTML/CSS|
+-----------+ +-----------+
+-----------+ = +-----------+
| | | |
| | | |
| Browser | = ------------------------- | Browser |
| | Media path | |
| | | = |
+-----------+ +-----------+

or even the triangle, where the = triangle is formed when the two Web severs on top are collapsed into = one.

A design criterion for RTCWEB has been that it should be = possible to write applications on top of RTCWEB simply - that is, = without deep knowledge about the world of codecs, RTP sessions and the = like.
Another design criterion is that interworking should be = possible - which means that SOMEWHERE in the system, deep knowledge = about the world of codecs, RTP sessions and the like must be embedded; = we can=92t just simplify our options until everything=92s = simple.

I've generally found = that "simplify our options until everything=92s simple" is a very good = policy for Version one of anything. 
But instead we have = a complex set of PSTN-interop centric requirements, it is no surprise = that we will come up with a complex PSTN centric = solution.

Sadly this will be such a = straight-jacket that no other new uses will = flourish.


There=92s one = place in the ecosystem where this knowledge HAS to be - and that is = within the browser, the component that takes care of implementing the = codecs, the RTP sessions and the related features. If we can avoid = requiring embedding it twice, that=92s a = feature.

Actually it isn't a = universally desired feature. The web is full of multiple ways of = manipulating the same object.
an HTML table can be specified = in HTML, manipulated in a DOM via javascript, and styled in CSS = . 
The writer of each of those bits of code needs to = understand what a table is or does at least = partially.


It = used to be that I was a believer in APIs - that we should make the API = the =93king=94, and describe the way you generate an RTP session as =93you= turn this knob, and get this effect=94.
After looking at the problem = of Web applications that don=92t have domain knowledge for a while, I=92ve= concluded that this doesn=92t work. There=92s the need for one browser = to communicate with the other browser, and if the intermediate = components are to have the ability to ignore the details, what=92s = communicated has to be treated like a blob - something passed out of one = browser=92s API and into another browser=92s API, unchanged by the = application - because the application must be able to ignore the = details.

Extend that argument = a bit further - the codecs  at each end can agree about their = mutual compatibility very simply - without involving the rest = of
the stack. All they have to do is expose a method on the = decoder that can check the self-description sent by the = encoder.

Instead we are making a monolithic = codec/network/negotiation/(signalling soon) hunk of code instead of = splitting out the parts and (for 
example ) exposing the = codecs as objects with behaviours.


OK, now we have the API with blobs. We also have = to make some assumptions about how those blobs are transported, who=92s = responsible for acting on them, and so on. And we have to make sure = different browsers implement the blob the same way - that is, it has to = be standardized.
What=92s more - we DO want to enable applications = that are NOT simple. Including gateways, which are not browsers. So = applications must be free to look inside the blob - break the blob = boundary - when they need to. So this pulls in the same direction as the = need for interoperability - the format, semantics and handling rules for = these blobs has to be specified. In some = detail.

We have an API with = blobs only because we chose to stick with the ugliness that is SDP. Once = you take that decision, the rest follows.


So we have:
- a data format
- a = transmission path
- a set of handling rules, in the form of states, = processes and timers

This doesn=92t look like an API any more. = This looks like a protocol. We=92ve got experience in describing = protocols - but it becomes much easier to apply that experience when we = call it a = protocol.


Ok, = lets design a protocol (if we must), but let's base it on the real = capabilities of browsers, web coders abilities and the real needs of web = users, 
not constantly looking over our shoulders at a = legacy protocol that barely works in the environment it was designed = for.

And will this new protocol have a standard = API ?


Tim. <= /div>
= --Apple-Mail-5--814682935-- From magnus.westerlund@ericsson.com Tue Oct 18 05:55: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 33FA821F8B9C for ; Tue, 18 Oct 2011 05:55:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.549 X-Spam-Level: X-Spam-Status: No, score=-106.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 L63HHm+QzQqd for ; Tue, 18 Oct 2011 05:55:26 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 59BDC21F8B9B for ; Tue, 18 Oct 2011 05:55:26 -0700 (PDT) X-AuditID: c1b4fb3d-b7c26ae0000035b9-e2-4e9d773dc9a4 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 27.38.13753.D377D9E4; Tue, 18 Oct 2011 14:55:25 +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, 18 Oct 2011 14:55:25 +0200 Message-ID: <4E9D773A.4010705@ericsson.com> Date: Tue, 18 Oct 2011 14:55:22 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "rtcweb@ietf.org" X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: [rtcweb] Current state of signaling discussion X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 12:55:27 -0000 WG, This is an attempt of me as WG chair to try to summarize the state of the discussion as it was when I wrote this. As usual please speak up against any miss-characterization of the state from my side. The Chairs request for identifying who like to provide input for a signaling discussion two weeks and to follow up this with a Internet draft has resulted in that we now have two drafts. a) RTCWeb Offer/Answer Protocol (ROAP) https://datatracker.ietf.org/doc/draft-jennings-rtcweb-signaling/ b) RTCWeb standard signaling protocol https://datatracker.ietf.org/doc/draft-partha-rtcweb-signaling/ We also have a third proposal that want to be included in the considerations: c) RTCWEB does not define any signaling behavior at all, instead W3C is tasked to develop an API that allows the application to establish the media session between peers. I have as WG chair requested that the proponents for C to produce a Internet draft that provides requirements on the API and its capability. This is to ensure that this proposal can be properly evaluated. So far no such contribution has occurred. Without a willingness from the proponents of this style of solution to contribute and evolve their thinking in such way that the other WG members can gain a better understanding of the implications of this solution I find it difficult for us include it in the up coming consensus call. We intended to have a phone conference on Friday to enable some direct discussion on the topic of signaling between the WG members. Details to follow. This is not an interim, only a possibility for the WG members to further their understanding in preparation for the decision. In addition to signaling proposals the WG have received two other I-Ds. 1) Real-Time Web Communication Simplified Interconnection https://datatracker.ietf.org/doc/draft-beck-rtcweb-alt-ic/ Which I interpret as a discussion piece around the federation and interconnect usages. 2) WebSocket Transport for Session Initiation Protocol (SIP) https://datatracker.ietf.org/doc/draft-ibc-rtcweb-sip-websocket/ This is a demonstration that SIP could be implemented in Java script and be transported over web-socket to enable the cases where SIP want to be used between a browser instance and a SIP system and its user agents. This has some requirements on the API to either provide SDP in O/A style or something that enables the SIP stack to create SIP messages with SDP O/A messages. There has been lively discussion around these documents which I hope continues but it does need to come to some conclusions. 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 radhika.r.roy.civ@mail.mil Tue Oct 18 06:08: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 21D5F21F8B57 for ; Tue, 18 Oct 2011 06:08:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.304 X-Spam-Level: X-Spam-Status: No, score=-2.304 tagged_above=-999 required=5 tests=[AWL=-0.005, 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 H4yQi9K8Uz6s for ; Tue, 18 Oct 2011 06:08:11 -0700 (PDT) Received: from edge-cols.mail.mil (edge-cols.mail.mil [131.64.100.6]) by ietfa.amsl.com (Postfix) with ESMTP id 35D3B21F8B55 for ; Tue, 18 Oct 2011 06:08:11 -0700 (PDT) Received: from UCOLHP3H.easf.csd.disa.mil (131.64.100.149) by UCOLHP4Z.easf.csd.disa.mil (131.64.100.6) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 18 Oct 2011 08:08:10 -0500 Received: from UCOLHP4D.easf.csd.disa.mil ([169.254.9.97]) by UCOLHP3H.easf.csd.disa.mil ([169.254.169.168]) with mapi id 14.01.0323.003; Tue, 18 Oct 2011 08:08:10 -0500 From: "Roy, Radhika R USA CIV (US)" To: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= , Ravindran Parthasarathi Thread-Topic: [rtcweb] Review request for RTCWeb standard signaling protocol Thread-Index: AQHMjWPJQsg22CmbRQ+ec/AyTlzr85WCFU0AgAAXFYD//+Y8kA== Date: Tue, 18 Oct 2011 13:08:08 +0000 Message-ID: <8486C8728176924BAF5BDB2F7D7EEDDF3E091CA3@ucolhp4d.easf.csd.disa.mil> References: <2E239D6FCD033C4BAF15F386A979BF510F1367@sonusinmail02.sonusnet.com><4E8AC222.4050308@alvestrand.no><2E239D6FCD033C4BAF15F386A979BF510F14CE@sonusinmail02.sonusnet.com><2E239D6FCD033C4BAF15F386A979BF510F14FD@sonusinmail02.sonusnet.com><393F1888-F834-4DAE-B6B1-1C5D35EE3292@phonefromhere.com><2E239D6FCD033C4BAF15F386A979BF510F152B@sonusinmail02.sonusnet.com><2E239D6FCD033C4BAF15F386A979BF510F1532@sonusinmail02.sonusnet.com><2E239D6FCD033C4BAF15F386A979BF511598EE@sonusinmail02.sonusnet.com><665A16AB-AAD8-42B3-AC17-7E629EA2DE35@phonefromhere.com><2E239D6FCD033C4BAF15F386A979BF5115992E@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F3 86A979B F51159950@so nusinmail02.sonusnet.com> <0950F0E1-6E4B-407F-9563-654AFE79F64B@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF51159994@sonusinmail02.sonusnet.com> <6398F67A-5E41-44BB-ABB2-831AB7C48DCC@ag-projects.com> In-Reply-To: <6398F67A-5E41-44BB-ABB2-831AB7C48DCC@ag-projects.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.64.77.9] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Review request for RTCWeb standard 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: Tue, 18 Oct 2011 13:08:12 -0000 Hi, Sa=FAl Is there a way to do negotiations with different codec types and different = features of a given codec without using a signaling protocol between the tw= o functional entities? BR/Radhika -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Sa=FAl Ibarra Corretg=E9 Sent: Tuesday, October 18, 2011 5:38 AM To: Ravindran Parthasarathi Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Review request for RTCWeb standard signaling protocol On Oct 18, 2011, at 10:15 AM, Ravindran Parthasarathi wrote: > Saul, >=20 > One minor correction in your mail: I have mentioned "SIP over websocket" = is an overkill and not SIP. >=20 You confuse me. You said before that the JS libraries would take time to do= wnload and all that, and now you say that SIP is not overkill. I don't see = another way of using SIP in a browser (without plugins) than using JS for t= he stack and WebSocket as a transport. Either way, there seems to be a consensus that no signaling protocol should= be specified, time to move on. -- Sa=FAl Ibarra Corretg=E9 AG Projects _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From tasveren@sonusnet.com Tue Oct 18 06:17: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 C415121F899F for ; Tue, 18 Oct 2011 06:17:32 -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 UKBRANtLsulq for ; Tue, 18 Oct 2011 06:17:32 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 30B7F21F8997 for ; Tue, 18 Oct 2011 06:17:31 -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 p9IDHXr1024899; Tue, 18 Oct 2011 09:17: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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 18 Oct 2011 09:16:57 -0400 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E703DBF614@sonusmail04.sonusnet.com> In-Reply-To: <1F2A2C70609D9E41844A2126145FC09804004302@HKGMBOXPRD22.polycom.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] Review request for RTCWeb standard signaling protocol Thread-Index: AcyNY9RKUZtq4/TvTF2m8ihYBiTuMwACTO9QAAD+IPAACbPC0A== References: <2E239D6FCD033C4BAF15F386A979BF510F1367@sonusinmail02.sonusnet.com><4E8AC222.4050308@alvestrand.no><2E239D6FCD033C4BAF15F386A979BF510F14CE@sonusinmail02.sonusnet.com><2E239D6FCD033C4BAF15F386A979BF510F14FD@sonusinmail02.sonusnet.com><393F1888-F834-4DAE-B6B1-1C5D35EE3292@phonefromhere.com><2E239D6FCD033C4BAF15F386A979BF510F152B@sonusinmail02.sonusnet.com><2E239D6FCD033C4BAF15F386A979BF510F1532@sonusinmail02.sonusnet.com><2E239D6FCD033C4BAF15F386A979BF511598EE@sonusinmail02.sonusnet.com><665A16AB-AAD8-42B3-AC17-7E629EA2DE35@phonefromhere.com><2E239D6FCD033C4BAF15F386A979BF5115992E@sonusinmail02.sonusnet.com><2E239D6FCD033C4BAF15F3 8 6A979B F 51159950@so nusinmail02.sonusnet.com><0950F0E1-6E4B-407F-9563-654AFE79F64B@ag-projects.com><2E239D6FCD033C4BAF15F386A979BF51159994@sonusinmail02.sonusnet.com> <1F2A2C70609D9E41844A2126145FC09804004302@HKGMBOXPRD22.polycom.com> From: "Asveren, Tolga" To: "Avasarala, Ranjit" , "Ravindran Parthasarathi" , =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Review request for RTCWeb standard 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: Tue, 18 Oct 2011 13:17:32 -0000 Yes, something "simple" would be nice but the definition of "simple = enough but still allowing me to do what I want to achieve" is very much = dependent on the needs of each specific use case/service. There is no = universal definition of "simple" here. So, I guess this is yet another = argument in favor of not standardizing the protocol between browser and = webserver so that everybody can design/use whatever is "simple but good = enough" from their perspective. Thanks, Tolga > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On = Behalf > Of Avasarala, Ranjit > Sent: Tuesday, October 18, 2011 4:38 AM > To: Ravindran Parthasarathi; Sa=FAl Ibarra Corretg=E9 > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] Review request for RTCWeb standard signaling > protocol >=20 > That's the whole issue. We need some mechanism for web browsers to > negotiate offer/answer and ICE candidates between each other. Using = SIP > for this over websockets would bring in unnecessary overheads. But we > still need some mechanism. So something which is "simple" is needed. >=20 > Regards > Ranjit >=20 > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On = Behalf > Of Ravindran Parthasarathi > Sent: Tuesday, October 18, 2011 1:46 PM > To: Sa=FAl Ibarra Corretg=E9 > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] Review request for RTCWeb standard signaling > protocol >=20 > Saul, >=20 > One minor correction in your mail: I have mentioned "SIP over = websocket" > is an overkill and not SIP. >=20 > Thanks > Partha >=20 > >-----Original Message----- > >From: Sa=FAl Ibarra Corretg=E9 [mailto:saul@ag-projects.com] > >Sent: Tuesday, October 18, 2011 12:32 PM > >To: Ravindran Parthasarathi > >Cc: I=F1aki Baz Castillo; rtcweb@ietf.org > >Subject: Re: [rtcweb] Review request for RTCWeb standard signaling > >protocol > > > > > >On Oct 17, 2011, at 7:00 PM, Ravindran Parthasarathi wrote: > > > >> The point to be noted is folks put forth the same argument again & > >again..each time, it is not possible to come up new answer ;-) I = noticed > >often you complain as if your important is missed out. We are arguing > >only about "nothing" vs "something" as a RTCWeb signaling protocol. > >> > >> I clearly explained why SIP over websocket is an overkill in the = below > >mail thread. Please read it and don't argue that it is working. All = the > >working stuff is not good. Infact for any protocol, the first idea = pop- > >up is to tunnel the complete inside (For Ex: ISUP over SIP) but = always > >better ways to solve it. > >> > > > >Let me connect the dots: you are advocating for a new 'simple' = protocol > >instead of taking an existing one, SIP for example, which you called > >'overkill'. And earlier in this thread you mentioned that you are > >interested in gateways. > > > >I now understand what you are trying to do. > > > >-- > >Sa=FAl Ibarra Corretg=E9 > >AG Projects > > > > >=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 Oct 18 06: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 245B121F8B1C for ; Tue, 18 Oct 2011 06:25:38 -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 tdgh-iRv6enc for ; Tue, 18 Oct 2011 06:25:37 -0700 (PDT) Received: from zimbra.westhawk.co.uk (zimbra.westhawk.co.uk [192.67.4.167]) by ietfa.amsl.com (Postfix) with ESMTP id 712E621F8B08 for ; Tue, 18 Oct 2011 06:25:37 -0700 (PDT) Received: from [192.168.0.14] (unknown [93.89.81.113]) by zimbra.westhawk.co.uk (Postfix) with ESMTP id D356D37A902; Tue, 18 Oct 2011 14:38:22 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Tim Panton In-Reply-To: <8486C8728176924BAF5BDB2F7D7EEDDF3E091CA3@ucolhp4d.easf.csd.disa.mil> Date: Tue, 18 Oct 2011 14:25:31 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2E2B1F85-1DED-460D-B17D-0850DB3ACBA9@phonefromhere.com> References: <2E239D6FCD033C4BAF15F386A979BF510F1367@sonusinmail02.sonusnet.com><4E8AC222.4050308@alvestrand.no><2E239D6FCD033C4BAF15F386A979BF510F14CE@sonusinmail02.sonusnet.com><2E239D6FCD033C4BAF15F386A979BF510F14FD@sonusinmail02.sonusnet.com><393F1888-F834-4DAE-B6B1-1C5D35EE3292@phonefromhere.com><2E239D6FCD033C4BAF15F386A979BF510F152B@sonusinmail02.sonusnet.com><2E239D6FCD033C4BAF15F386A979BF510F1532@sonusinmail02.sonusnet.com><2E239D6FCD033C4BAF15F386A979BF511598EE@sonusinmail02.sonusnet.com><665A16AB-AAD8-42B3-AC17-7E629EA2DE35@phonefromhere.com><2E239D6FCD033C4BAF15F386A979BF5115992E@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F3 86A979B F51159950@so nusinmail02.sonusnet.com> <0950F0E1-6E4B-407F-9563-654AFE79F64B@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF51159994@sonusinmail02.sonusnet.com> <6398F67A-5E41-44BB-ABB2-831AB7C48DCC@ag-projects.com> <8486C8728176924BAF5BDB2F7D7EEDDF3E091CA3@ucolhp4d.easf.csd.disa.mil> To: "Roy, Radhika R USA CIV (US)" X-Mailer: Apple Mail (2.1084) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Review request for RTCWeb standard 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: Tue, 18 Oct 2011 13:25:38 -0000 On 18 Oct 2011, at 14:08, Roy, Radhika R USA CIV (US) wrote: > Hi, Sa=FAl >=20 > Is there a way to do negotiations with different codec types and = different features of a given codec without using a signaling protocol = between the two functional entities? >=20 > BR/Radhika No, you always need a transport to get the supported codec description = list from one end to the other.=20 What you don't have to specify is the protocol that the transport uses, = or the decision making process that each end uses to select the capabilities it wants to employ in this instance of this = web app. Here is an example that illustrates how it could work in a 'protocol = free' way. User A could query the browser for the codec description list at the = start of a web game session, the web=20 app could upload that to the session storage on the game server.=20 User B does the same thing. At some point later users A and B encounter each other in the game. - = the server _already_knows_ the capabilites=20 of their respective browsers and instructs them to do an ice negotiation = to find a transport between them. Once that is done it informs them _both_ of it's codec selection - which = may be based on their game status. The video session proceeds as part of the game until the 2 users part, = at which point the session is torn down. I'm by no means saying that this is the _only_ way connections can be = made, just that if we get this API right we can do things this way. Tim. From ibc@aliax.net Tue Oct 18 06:27: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 6CE5721F8B61 for ; Tue, 18 Oct 2011 06:27:50 -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 nbQnqVsG3nJE for ; Tue, 18 Oct 2011 06:27:49 -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 83EB021F8B21 for ; Tue, 18 Oct 2011 06:27:49 -0700 (PDT) Received: by vws5 with SMTP id 5so416993vws.31 for ; Tue, 18 Oct 2011 06:27:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.73.166 with SMTP id m6mr2393272vdv.18.1318944463259; Tue, 18 Oct 2011 06:27:43 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Tue, 18 Oct 2011 06:27:43 -0700 (PDT) In-Reply-To: <4E9D773A.4010705@ericsson.com> References: <4E9D773A.4010705@ericsson.com> Date: Tue, 18 Oct 2011 15:27:43 +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] Current state of signaling discussion X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 13:27:50 -0000 2011/10/18 Magnus Westerlund : > This is an attempt of me as WG chair to try to summarize the state of > the discussion as it was when I wrote this. As usual please speak up > against any miss-characterization of the state from my side. > > The Chairs request for identifying who like to provide input for a > signaling discussion two weeks and to follow up this with a Internet > draft has resulted in that we now have two drafts. > > a) RTCWeb Offer/Answer Protocol (ROAP) > https://datatracker.ietf.org/doc/draft-jennings-rtcweb-signaling/ > > b) RTCWeb standard signaling protocol > https://datatracker.ietf.org/doc/draft-partha-rtcweb-signaling/ > > We also have a third proposal that want to be included in the > considerations: > c) RTCWEB does not define any signaling behavior at all, instead W3C is > tasked to develop an API that allows the application to establish the > media session between peers. > > I have as WG chair requested that the proponents for C to produce a > Internet draft that provides requirements on the API and its capability. > This is to ensure that this proposal can be properly evaluated. So far > no such contribution has occurred. Without a willingness from the > proponents of this style of solution to contribute and evolve their > thinking in such way that the other WG members can gain a better > understanding of the implications of this solution I find it difficult > for us include it in the up coming consensus call. > > We intended to have a phone conference on Friday to enable some direct > discussion on the topic of signaling between the WG members. Details to > follow. This is not an interim, only a possibility for the WG members to > further their understanding in preparation for the decision. > > In addition to signaling proposals the WG have received two other I-Ds. > > 1) Real-Time Web Communication Simplified Interconnection > https://datatracker.ietf.org/doc/draft-beck-rtcweb-alt-ic/ > > Which I interpret as a discussion piece around the federation and > interconnect usages. > > 2) WebSocket Transport for Session Initiation Protocol (SIP) > https://datatracker.ietf.org/doc/draft-ibc-rtcweb-sip-websocket/ > > This is a demonstration that SIP could be implemented in Java script and > be transported over web-socket to enable the cases where SIP want to be > used between a browser instance and a SIP system and its user agents. > This has some requirements on the API to either provide SDP in O/A style > or something that enables the SIP stack to create SIP messages with SDP > O/A messages. > > There has been lively discussion around these documents which I hope > continues but it does need to come to some conclusions. Hi Magnus. My concerns: - I don't like option B (defining a default signaling protocol) as it stops innovation (we will be limited and constrained to the limitations of such protocol, and will depend on how good each browser implements it). Upgrading the signaling stack would require a new version of every browsers in the world. Unfeasible IMHO. - Initially I advocated for option C, but such option is so flexible that I cannot imagine how a draft can describe it. But a real example of such a custom signaling protocol is present in https://datatracker.ietf.org/doc/draft-ibc-rtcweb-sip-websocket/. - I don't think that options C and A (ROAP) are mutually exclusive, not at all. IMHO ROAP defines a communication between the JS code and the browser RTCweb stack, just it. It does not define a signaling protocol on-the-wire (but just gives some guidelines which are present in any existing VoIP protocol). For example a JS code could use SIP over WebSocket for the wire communication and generate ROAP "objects" upon receipt of a INVITE/200 with SDP prior to talk with the browser RTCweb stack. - ROAP defines itself as a "protocol" because indeed it contains states, so it's not an API (or it's more than just an API), but it just covers the communication between the JS code and the browser RTCweb stack, leaving the door open to any custom signaling protocol on the wire. So IMHO this is the way to go. About SDP or media info management there is an open debate about the responsability (or not) of the JS code in doing such task. My opinion is that, given that RTCweb is based on SDP: - RTCweb should define a specific (JSON) format that includes SDP information in some structured way. It does not need to be a SDP 1:1 mapping. Let's call it RTCweb.MediaInfo JSON object. - Since interoperability with SIP and XMPP/Jingle is desired (is not?), RTCweb JS API should include some helper functions: - RTCweb.parsePlainSDP(string) Receives as argument a string containing a plain SDP body and returns= a RTCweb.MediaInfo object. - RTCweb.parseXmlSDP(string) Receives as argument a string containing a XML SDP body (Jingle) and returns a RTCweb.MediaInfo object. - RTCweb.generatePlainSDP(mediaInfo) Receives as argument a RTCweb.MediaInfo object and generates a plain SDP string. - RTCweb.generateXmlSDP(mediaInfo) Receives as argument a RTCweb.MediaInfo object and generates a XML SDP string. - Custom signaling protocols not using SIP or XMPP would not need such helpers and could directly work with the MediaInfo JSON structure (by also passing it verbatim on-the-wire). So my proposal is using ROAP but, instead of inserting a plain SDP string within the ROAP Offer and Answer structures, inserting a RTCweb.MediaInfo JSON object. In this way, there is no need for the JavaScript code for dealing with plain SDP's. Regards. --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Tue Oct 18 06: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 86BCA21F8B6C for ; Tue, 18 Oct 2011 06:30:07 -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_24=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 21LdmxJB5o-H for ; Tue, 18 Oct 2011 06: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 0A56221F8B63 for ; Tue, 18 Oct 2011 06:30:06 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so594062vcb.31 for ; Tue, 18 Oct 2011 06:30:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.120.12 with SMTP id b12mr179038vcr.111.1318944606455; Tue, 18 Oct 2011 06:30:06 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Tue, 18 Oct 2011 06:30:06 -0700 (PDT) In-Reply-To: <4E9D7019.2020303@ericsson.com> References: <15B0E3AD-3086-499A-8E79-7AE58B3376C4@cisco.com> <4E9D43D2.9010804@alvestrand.no> <4E9D5E9A.7090308@alvestrand.no> <4E9D7019.2020303@ericsson.com> Date: Tue, 18 Oct 2011 15:30:06 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: =?UTF-8?Q?Stefan_H=C3=A5kansson_LK?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] API options for supporting fork with ROAP (Re: SDP Offer/Answer draft-jennings-rtcweb-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: Tue, 18 Oct 2011 13:30:07 -0000 2011/10/18 Stefan H=C3=A5kansson LK : > Our idea is basically that whenever you create a new PeerConnection in > the same context as you have already created one or more > PeerConnection's, the same local candidates should be re-used. Of course = the > 5-tuple must remain unique so that different connections don't collapse i= nto > one, but this is quite simple to resolve. > > For clarity, the above would be requirements on the implementation (in > browsers). > > This means that support of forking would be simple as the IP+port's to > send media to (for the remote end) remains also for the new PeerConnectio= n. > > Another advantage is that creating new PeerConnections will be faster as = new > candidates does not need to be gathered. > > I think this is quite a clean solution since there is no need for API > changes, or any additional factory layer. Hi Stefan, that looks nice, but could you explain what does it mean "in the same context as you have already created one or more PeerConnection's"? Could you please translate it into a theorical JS API? Regards. --=20 I=C3=B1aki Baz Castillo From HKaplan@acmepacket.com Tue Oct 18 06:34: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 4B40921F8B6F for ; Tue, 18 Oct 2011 06:34:51 -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.110, 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 RH+O6pXXqHl7 for ; Tue, 18 Oct 2011 06:34:50 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 551B621F8B56 for ; Tue, 18 Oct 2011 06:34: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; Tue, 18 Oct 2011 09:34:48 -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; Tue, 18 Oct 2011 09:34:48 -0400 From: Hadriel Kaplan To: Magnus Westerlund Thread-Topic: [rtcweb] Current state of signaling discussion Thread-Index: AQHMjZq01pQrrm9gDkqkt90EPmbj/A== Date: Tue, 18 Oct 2011 13:34:48 +0000 Message-ID: <753A5B5E-45A7-46F0-98F9-B4503F4A0EF2@acmepacket.com> References: <4E9D773A.4010705@ericsson.com> In-Reply-To: <4E9D773A.4010705@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.0.0.30] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Current state of signaling discussion X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 13:34:51 -0000 On Oct 18, 2011, at 8:55 AM, Magnus Westerlund wrote: > We also have a third proposal that want to be included in the > considerations: > c) RTCWEB does not define any signaling behavior at all, instead W3C is > tasked to develop an API that allows the application to establish the > media session between peers. >=20 > I have as WG chair requested that the proponents for C to produce a > Internet draft that provides requirements on the API and its capability. > This is to ensure that this proposal can be properly evaluated. So far > no such contribution has occurred. Without a willingness from the > proponents of this style of solution to contribute and evolve their > thinking in such way that the other WG members can gain a better > understanding of the implications of this solution I find it difficult > for us include it in the up coming consensus call. That was not my understanding of what you (the WG Chairs) were asking for. = The email from Ted asking for drafts was this: http://www.ietf.org/mail-archive/web/rtcweb/current/msg01761.html My reading of that is it was asking for a concrete solution in the signalin= g solutions discussion. For those of us who feel there needs to be *no* st= andard-defined signaling, it was asking us for the empty set. We delivered= . :) Now it sounds like you're asking for something different: requirements for = the (W3C-defined) API. I had assumed that's what draft-ietf-rtcweb-use-cas= es-and-requirements was supposed to cover. No? -hadriel From radhika.r.roy.civ@mail.mil Tue Oct 18 06:48: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 DD85621F8B74 for ; Tue, 18 Oct 2011 06:48:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.304 X-Spam-Level: X-Spam-Status: No, score=-2.304 tagged_above=-999 required=5 tests=[AWL=-0.005, 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 pMd6bPFd9DkI for ; Tue, 18 Oct 2011 06:48:54 -0700 (PDT) Received: from edge-cols.mail.mil (edge-cols.mail.mil [131.64.100.9]) by ietfa.amsl.com (Postfix) with ESMTP id 47F7921F8B5D for ; Tue, 18 Oct 2011 06:48:54 -0700 (PDT) Received: from UCOLHP3I.easf.csd.disa.mil (131.64.100.150) by ucolhp2w.easf.csd.disa.mil (131.64.100.9) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 18 Oct 2011 08:48:38 -0500 Received: from UCOLHP4D.easf.csd.disa.mil ([169.254.9.97]) by UCOLHP3I.easf.csd.disa.mil ([169.254.63.236]) with mapi id 14.01.0323.003; Tue, 18 Oct 2011 08:48:38 -0500 From: "Roy, Radhika R USA CIV (US)" To: "Asveren, Tolga" , "Avasarala, Ranjit" , Ravindran Parthasarathi , =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= Thread-Topic: [rtcweb] Review request for RTCWeb standard signaling protocol Thread-Index: AQHMjWPJQsg22CmbRQ+ec/AyTlzr85WCFU0AgAAGWYCAAE3QgP//tE4Q Date: Tue, 18 Oct 2011 13:48:37 +0000 Message-ID: <8486C8728176924BAF5BDB2F7D7EEDDF3E091D13@ucolhp4d.easf.csd.disa.mil> References: <2E239D6FCD033C4BAF15F386A979BF510F1367@sonusinmail02.sonusnet.com><4E8AC222.4050308@alvestrand.no><2E239D6FCD033C4BAF15F386A979BF510F14CE@sonusinmail02.sonusnet.com><2E239D6FCD033C4BAF15F386A979BF510F14FD@sonusinmail02.sonusnet.com><393F1888-F834-4DAE-B6B1-1C5D35EE3292@phonefromhere.com><2E239D6FCD033C4BAF15F386A979BF510F152B@sonusinmail02.sonusnet.com><2E239D6FCD033C4BAF15F386A979BF510F1532@sonusinmail02.sonusnet.com><2E239D6FCD033C4BAF15F386A979BF511598EE@sonusinmail02.sonusnet.com><665A16AB-AAD8-42B3-AC17-7E629EA2DE35@phonefromhere.com><2E239D6FCD033C4BAF15F386A979BF5115992E@sonusinmail02.sonusnet.com><2E239D6FCD033C4BAF15F3 8 6A979B F 51159950@so nusinmail02.sonusnet.com><0950F0E1-6E4B-407F-9563-654AFE79F64B@ag-projects.com><2E239D6FCD033C4BAF15F386A979BF51159994@sonusinmail02.sonusnet.com> <1F2A2C70609D9E41844A2126145FC09804004302@HKGMBOXPRD22.polycom.com> <033458F56EC2A64E8D2D7B759FA3E7E703DBF614@sonusmail04.sonusnet.com> In-Reply-To: <033458F56EC2A64E8D2D7B759FA3E7E703DBF614@sonusmail04.sonusnet.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.64.77.9] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Review request for RTCWeb standard 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: Tue, 18 Oct 2011 13:48:55 -0000 Folks: Tolga is right. We have a very complex problem to solve. It is called negotiations between = different types of codecs and between different features of each codec type= . Let us see how simple a protocol can be based on these simple requirements. BR/Radhika -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Asveren, Tolga Sent: Tuesday, October 18, 2011 9:17 AM To: Avasarala, Ranjit; Ravindran Parthasarathi; Sa=FAl Ibarra Corretg=E9 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Review request for RTCWeb standard signaling protocol Yes, something "simple" would be nice but the definition of "simple enough = but still allowing me to do what I want to achieve" is very much dependent = on the needs of each specific use case/service. There is no universal defin= ition of "simple" here. So, I guess this is yet another argument in favor o= f not standardizing the protocol between browser and webserver so that ever= ybody can design/use whatever is "simple but good enough" from their perspe= ctive. Thanks, Tolga From magnus.westerlund@ericsson.com Tue Oct 18 06: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 5B2BC21F8AF5 for ; Tue, 18 Oct 2011 06:57:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.556 X-Spam-Level: X-Spam-Status: No, score=-106.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 W-2dC1m3eKzU for ; Tue, 18 Oct 2011 06:57: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 1F0CC21F8AE1 for ; Tue, 18 Oct 2011 06:57:07 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-39-4e9d85b3f14c Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 6E.AB.20773.3B58D9E4; Tue, 18 Oct 2011 15:57:07 +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, 18 Oct 2011 15:57:06 +0200 Message-ID: <4E9D85B0.6070008@ericsson.com> Date: Tue, 18 Oct 2011 15:57:04 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Hadriel Kaplan References: <4E9D773A.4010705@ericsson.com> <753A5B5E-45A7-46F0-98F9-B4503F4A0EF2@acmepacket.com> In-Reply-To: <753A5B5E-45A7-46F0-98F9-B4503F4A0EF2@acmepacket.com> X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Current state of signaling discussion X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 13:57:09 -0000 On 2011-10-18 15:34, Hadriel Kaplan wrote: > > On Oct 18, 2011, at 8:55 AM, Magnus Westerlund wrote: > >> We also have a third proposal that want to be included in the >> considerations: c) RTCWEB does not define any signaling behavior at >> all, instead W3C is tasked to develop an API that allows the >> application to establish the media session between peers. >> >> I have as WG chair requested that the proponents for C to produce >> a Internet draft that provides requirements on the API and its >> capability. This is to ensure that this proposal can be properly >> evaluated. So far no such contribution has occurred. Without a >> willingness from the proponents of this style of solution to >> contribute and evolve their thinking in such way that the other WG >> members can gain a better understanding of the implications of this >> solution I find it difficult for us include it in the up coming >> consensus call. > > That was not my understanding of what you (the WG Chairs) were asking > for. The email from Ted asking for drafts was this: > http://www.ietf.org/mail-archive/web/rtcweb/current/msg01761.html > > My reading of that is it was asking for a concrete solution in the > signaling solutions discussion. For those of us who feel there needs > to be *no* standard-defined signaling, it was asking us for the empty > set. We delivered. :) > In the following message I included my clarified request on that there is still need to have an I-D on the "no signalling" proposal: http://www.ietf.org/mail-archive/web/rtcweb/current/msg01794.html > Now it sounds like you're asking for something different: > requirements for the (W3C-defined) API. I had assumed that's what > draft-ietf-rtcweb-use-cases-and-requirements was supposed to cover. > No? No, that is the general use cases for the complete solution. What I am asking is for something that makes it clear what the API need to contain to initiate and configure ICE negotiation, media transport etc. Saying we don't need no protocol is not sufficient. It doesn't make it clear what it actually means to have no standardized protocol and the implications this have on what the API needs to expose. What we are trying to accomplish is that we go from general hand waving on the different approaches to something that is reasonably well explained. Thus enabling everyone to better understand the proposals. 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 stefan.lk.hakansson@ericsson.com Tue Oct 18 06:57: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 DFD5421F8AD9 for ; Tue, 18 Oct 2011 06:57:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_24=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 uQAPGiJJZLJM for ; Tue, 18 Oct 2011 06:57:34 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 1F10221F84FA for ; Tue, 18 Oct 2011 06:57:33 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-a2-4e9d85cd2a71 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id DF.BB.20773.DC58D9E4; Tue, 18 Oct 2011 15:57:33 +0200 (CEST) Received: from [150.132.141.126] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.137.0; Tue, 18 Oct 2011 15:57:33 +0200 Message-ID: <4E9D85CB.6030503@ericsson.com> Date: Tue, 18 Oct 2011 15:57:31 +0200 From: =?UTF-8?B?U3RlZmFuIEjDpWthbnNzb24gTEs=?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110922 Lightning/1.0b2 Thunderbird/3.1.15 MIME-Version: 1.0 To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= References: <15B0E3AD-3086-499A-8E79-7AE58B3376C4@cisco.com> <4E9D43D2.9010804@alvestrand.no> <4E9D5E9A.7090308@alvestrand.no> <4E9D7019.2020303@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] API options for supporting fork with ROAP (Re: SDP Offer/Answer draft-jennings-rtcweb-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: Tue, 18 Oct 2011 13:57:35 -0000 On 10/18/2011 03:30 PM, Iñaki Baz Castillo wrote: > 2011/10/18 Stefan Håkansson LK: >> Our idea is basically that whenever you create a new PeerConnection in >> the same context as you have already created one or more >> PeerConnection's, the same local candidates should be re-used. Of course the >> 5-tuple must remain unique so that different connections don't collapse into >> one, but this is quite simple to resolve. >> >> For clarity, the above would be requirements on the implementation (in >> browsers). >> >> This means that support of forking would be simple as the IP+port's to >> send media to (for the remote end) remains also for the new PeerConnection. >> >> Another advantage is that creating new PeerConnections will be faster as new >> candidates does not need to be gathered. >> >> I think this is quite a clean solution since there is no need for API >> changes, or any additional factory layer. > > > Hi Stefan, that looks nice, but could you explain what does it mean > "in the same context as you have already created one or more > PeerConnection's"? What I mean is: if this web app has already created a PeerConncection, and is about to open another one (e.g. for a new fork), the new PeerConnection should use the same local candidates as the one already created collected. > > Could you please translate it into a theorical JS API? Even better, I can point to the current API proposal: . I think no changes would be required to the API per se, but some text on how the user agent should act need to be added. (I'm sure I've overlooked some aspect, but hopefully it would be possible to fix) Br, Stefan > > Regards. > > From radhika.r.roy.civ@mail.mil Tue Oct 18 06: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 212B621F8B84 for ; Tue, 18 Oct 2011 06:59:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.454 X-Spam-Level: X-Spam-Status: No, score=-2.454 tagged_above=-999 required=5 tests=[AWL=0.145, 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 7K5E0jUI-Cvl for ; Tue, 18 Oct 2011 06:59:48 -0700 (PDT) Received: from edge-cols.mail.mil (edge-cols.mail.mil [131.64.100.6]) by ietfa.amsl.com (Postfix) with ESMTP id 72A5421F8B78 for ; Tue, 18 Oct 2011 06:59:48 -0700 (PDT) Received: from UCOLHP3F.easf.csd.disa.mil (131.64.100.145) by UCOLHP4Z.easf.csd.disa.mil (131.64.100.6) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 18 Oct 2011 08:59:41 -0500 Received: from UCOLHP4D.easf.csd.disa.mil ([169.254.9.97]) by UCOLHP3F.easf.csd.disa.mil ([169.254.56.193]) with mapi id 14.01.0323.003; Tue, 18 Oct 2011 08:59:41 -0500 From: "Roy, Radhika R USA CIV (US)" To: Tim Panton Thread-Topic: [rtcweb] Review request for RTCWeb standard signaling protocol Thread-Index: AQHMjWPJQsg22CmbRQ+ec/AyTlzr85WCFU0AgAAXFYD//+Y8kIAAWT2A//+zcOA= Date: Tue, 18 Oct 2011 13:59:41 +0000 Message-ID: <8486C8728176924BAF5BDB2F7D7EEDDF3E091D31@ucolhp4d.easf.csd.disa.mil> References: <2E239D6FCD033C4BAF15F386A979BF510F1367@sonusinmail02.sonusnet.com><4E8AC222.4050308@alvestrand.no><2E239D6FCD033C4BAF15F386A979BF510F14CE@sonusinmail02.sonusnet.com><2E239D6FCD033C4BAF15F386A979BF510F14FD@sonusinmail02.sonusnet.com><393F1888-F834-4DAE-B6B1-1C5D35EE3292@phonefromhere.com><2E239D6FCD033C4BAF15F386A979BF510F152B@sonusinmail02.sonusnet.com><2E239D6FCD033C4BAF15F386A979BF510F1532@sonusinmail02.sonusnet.com><2E239D6FCD033C4BAF15F386A979BF511598EE@sonusinmail02.sonusnet.com><665A16AB-AAD8-42B3-AC17-7E629EA2DE35@phonefromhere.com><2E239D6FCD033C4BAF15F386A979BF5115992E@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F3 86A979B F51159950@so nusinmail02.sonusnet.com> <0950F0E1-6E4B-407F-9563-654AFE79F64B@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF51159994@sonusinmail02.sonusnet.com> <6398F67A-5E41-44BB-ABB2-831AB7C48DCC@ag-projects.com> <8486C8728176924BAF5BDB2F7D7EEDDF3E091CA3@ucolhp4d.easf.csd.disa.mil> <2E2B1F85-1DED-460D-B17D-0850DB3ACBA9@phonefromhere.com> In-Reply-To: <2E2B1F85-1DED-460D-B17D-0850DB3ACBA9@phonefromhere.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.64.77.9] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Review request for RTCWeb standard 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: Tue, 18 Oct 2011 13:59:49 -0000 Tim: The puzzle is this. The other user may not agree completely with the offer = of the first user. Even the other user may agree with a given codec type, h= e/she may not agree other features including bandwidth of the codec. It simple turns out that a freedom needs to be given for negotiations some-= like offer/answer. Well, if we can avoid these complexities, let us find out (e.g. Pre-defined= some constraints etc.). Or, if an API is good enough exposing all the codec parameters and offer/an= swer signaling can be avoided, let us find it out. BR/Radhika -----Original Message----- From: Tim Panton [mailto:tim@phonefromhere.com]=20 Sent: Tuesday, October 18, 2011 9:26 AM To: Roy, Radhika R USA CIV (US) Cc: Sa=FAl Ibarra Corretg=E9; Ravindran Parthasarathi; rtcweb@ietf.org Subject: Re: [rtcweb] Review request for RTCWeb standard signaling protocol On 18 Oct 2011, at 14:08, Roy, Radhika R USA CIV (US) wrote: > Hi, Sa=FAl >=20 > Is there a way to do negotiations with different codec types and differen= t features of a given codec without using a signaling protocol between the = two functional entities? >=20 > BR/Radhika No, you always need a transport to get the supported codec description lis= t from one end to the other.=20 What you don't have to specify is the protocol that the transport uses, or = the decision making process that each end uses to select the capabilities i= t wants to employ in this instance of this web app. Here is an example that illustrates how it could work in a 'protocol free' = way. User A could query the browser for the codec description list at the start = of a web game session, the web app could upload that to the session storage= on the game server.=20 User B does the same thing. At some point later users A and B encounter each other in the game. - the s= erver _already_knows_ the capabilites of their respective browsers and inst= ructs them to do an ice negotiation to find a transport between them. Once that is done it informs them _both_ of it's codec selection - which ma= y be based on their game status. The video session proceeds as part of the game until the 2 users part, at w= hich point the session is torn down. I'm by no means saying that this is the _only_ way connections can be made,= just that if we get this API right we can do things this way. Tim. From HKaplan@acmepacket.com Tue Oct 18 07: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 980D121F8B2D for ; Tue, 18 Oct 2011 07:12:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.501 X-Spam-Level: X-Spam-Status: No, score=-2.501 tagged_above=-999 required=5 tests=[AWL=0.098, 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 PngEouR32C1J for ; Tue, 18 Oct 2011 07:12:40 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 124C421F8B28 for ; Tue, 18 Oct 2011 07:12:39 -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, 18 Oct 2011 10:12:38 -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; Tue, 18 Oct 2011 10:12:39 -0400 From: Hadriel Kaplan To: Magnus Westerlund Thread-Topic: [rtcweb] Current state of signaling discussion Thread-Index: AQHMjZ/9v/MVYdTFIUm+RaPRMyDYcQ== Date: Tue, 18 Oct 2011 14:12:37 +0000 Message-ID: References: <4E9D773A.4010705@ericsson.com> <753A5B5E-45A7-46F0-98F9-B4503F4A0EF2@acmepacket.com> <4E9D85B0.6070008@ericsson.com> In-Reply-To: <4E9D85B0.6070008@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.0.0.30] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Current state of signaling discussion X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 14:12:40 -0000 On Oct 18, 2011, at 9:57 AM, Magnus Westerlund wrote: > In the following message I included my clarified request on that there > is still need to have an I-D on the "no signalling" proposal: >=20 > http://www.ietf.org/mail-archive/web/rtcweb/current/msg01794.html Ahhh. Sorry I did not see that email. (I don't know how I could have misse= d an email in such a low-volume mailing list ;) OK, I'll try and submit one before Friday if no one else is going to. -hadriel From tim@phonefromhere.com Tue Oct 18 07:19: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 78AB721F8B95 for ; Tue, 18 Oct 2011 07:19:59 -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 gntKDSW48+bZ for ; Tue, 18 Oct 2011 07:19: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 83ABA21F8B5B for ; Tue, 18 Oct 2011 07:19:58 -0700 (PDT) Received: from [192.168.0.14] (unknown [93.89.81.113]) by zimbra.westhawk.co.uk (Postfix) with ESMTP id B6A5F37A902; Tue, 18 Oct 2011 15:32:41 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Tim Panton In-Reply-To: <8486C8728176924BAF5BDB2F7D7EEDDF3E091D31@ucolhp4d.easf.csd.disa.mil> Date: Tue, 18 Oct 2011 15:19:50 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <7357A569-83A3-43B6-80A7-E2374D78CE28@phonefromhere.com> References: <2E239D6FCD033C4BAF15F386A979BF510F1367@sonusinmail02.sonusnet.com><4E8AC222.4050308@alvestrand.no><2E239D6FCD033C4BAF15F386A979BF510F14CE@sonusinmail02.sonusnet.com><2E239D6FCD033C4BAF15F386A979BF510F14FD@sonusinmail02.sonusnet.com><393F1888-F834-4DAE-B6B1-1C5D35EE3292@phonefromhere.com><2E239D6FCD033C4BAF15F386A979BF510F152B@sonusinmail02.sonusnet.com><2E239D6FCD033C4BAF15F386A979BF510F1532@sonusinmail02.sonusnet.com><2E239D6FCD033C4BAF15F386A979BF511598EE@sonusinmail02.sonusnet.com><665A16AB-AAD8-42B3-AC17-7E629EA2DE35@phonefromhere.com><2E239D6FCD033C4BAF15F386A979BF5115992E@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F3 86A979B F51159950@so nusinmail02.sonusnet.com> <0950F0E1-6E4B-407F-9563-654AFE79F64B@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF51159994@sonusinmail02.sonusnet.com> <6398F67A-5E41-44BB-ABB2-831AB7C48DCC@ag-projects.com> <8486C8728176924BAF5BDB2F7D7EEDDF3E091CA3@ucolhp4d.easf.csd.disa.mil> <2E2B1F85-1DED-460D-B17D-0850DB3ACBA9@phonefromhere.com> <8486C8728176924BAF5BDB2F7D7EEDDF3E091D31@ucolhp4d.easf.csd.disa.mil> To: "Roy, Radhika R USA CIV (US)" X-Mailer: Apple Mail (2.1084) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Review request for RTCWeb standard 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: Tue, 18 Oct 2011 14:19:59 -0000 On 18 Oct 2011, at 14:59, Roy, Radhika R USA CIV (US) wrote: > Tim: >=20 > The puzzle is this. The other user may not agree completely with the = offer of the first user. Even the other user may agree with a given = codec type, he/she may not agree other features including bandwidth of = the codec. >=20 > It simple turns out that a freedom needs to be given for negotiations = some-like offer/answer. The example I gave had _no_ negotiation, no back and forth, because the = application's webserver was told all the capabilities in advance, (at login in my example), it = simply _decided_ based on it's view of the union of the capabilities of the two ends. It then = informed them of the choice (which may have been asymmetric by the way) and told them to get on with = it. To the extent that there was a 'negotiation', it took place in a single = thread on the web server,=20 with no propagation delays or locks needed. >=20 > Well, if we can avoid these complexities, let us find out (e.g. = Pre-defined some constraints etc.). >=20 > Or, if an API is good enough exposing all the codec parameters and = offer/answer signaling can be avoided, let us find it out. Offer - Answer really only crops up because there is a requirement = (which I personally put very low on our priorities) to be able to interop with legacy video phones without needing a media gateway.=20 Tim. >=20 > BR/Radhika >=20 > -----Original Message----- > From: Tim Panton [mailto:tim@phonefromhere.com]=20 > Sent: Tuesday, October 18, 2011 9:26 AM > To: Roy, Radhika R USA CIV (US) > Cc: Sa=FAl Ibarra Corretg=E9; Ravindran Parthasarathi; rtcweb@ietf.org > Subject: Re: [rtcweb] Review request for RTCWeb standard signaling = protocol >=20 >=20 > On 18 Oct 2011, at 14:08, Roy, Radhika R USA CIV (US) wrote: >=20 >> Hi, Sa=FAl >>=20 >> Is there a way to do negotiations with different codec types and = different features of a given codec without using a signaling protocol = between the two functional entities? >>=20 >> BR/Radhika >=20 > No, you always need a transport to get the supported codec = description list from one end to the other.=20 > What you don't have to specify is the protocol that the transport = uses, or the decision making process that each end uses to select the = capabilities it wants to employ in this instance of this web app. >=20 > Here is an example that illustrates how it could work in a 'protocol = free' way. >=20 > User A could query the browser for the codec description list at the = start of a web game session, the web app could upload that to the = session storage on the game server.=20 > User B does the same thing. > At some point later users A and B encounter each other in the game. - = the server _already_knows_ the capabilites of their respective browsers = and instructs them to do an ice negotiation to find a transport between = them. > Once that is done it informs them _both_ of it's codec selection - = which may be based on their game status. >=20 > The video session proceeds as part of the game until the 2 users part, = at which point the session is torn down. >=20 >=20 > I'm by no means saying that this is the _only_ way connections can be = made, just that if we get this API right we can do things this way. > Tim. >=20 From magnus.westerlund@ericsson.com Tue Oct 18 07: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 A6F7821F8C0F for ; Tue, 18 Oct 2011 07:30:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.562 X-Spam-Level: X-Spam-Status: No, score=-106.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5zliK9MSeCTc for ; Tue, 18 Oct 2011 07:30: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 7412121F8C0E for ; Tue, 18 Oct 2011 07:30:29 -0700 (PDT) X-AuditID: c1b4fb3d-b7c26ae0000035b9-07-4e9d8d832a5f Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id C3.49.13753.38D8D9E4; Tue, 18 Oct 2011 16:30:28 +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, 18 Oct 2011 16:30:27 +0200 Message-ID: <4E9D8D82.707@ericsson.com> Date: Tue, 18 Oct 2011 16:30:26 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org, Cullen Jennings , Jonathan Rosenberg References: <15B0E3AD-3086-499A-8E79-7AE58B3376C4@cisco.com> In-Reply-To: <15B0E3AD-3086-499A-8E79-7AE58B3376C4@cisco.com> X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [rtcweb] SDP Offer/Answer draft-jennings-rtcweb-signaling: Glare handling X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 14:30:30 -0000 Cullen, I would like to bring back my proposal for glare handling and propose that it be included in ROAP. The reason is that I don't think the SIP time based solution interact well with RTCWEB requirements at all. The biggest issue is that one is likely to end up in glare condition again due to that the transport of the ROAP messages between end-points/Gateways can have properties that erases the randomization of the timer. For example an JS application that uses short polling for retrieving any incomming ROAP messages, as that is timer based and done lets say every 5 seconds, then the polling is clearly done on a longer time scales, many times longer than what the random glare resolution happens at. Thus timer based solutions for resolving glare is use-less in RTCWEB context where we don't know how timely the transport is. Thus I would propose that the following mechanism is include in ROAP. When generating an offer a 32-bit unsigned random integer value is generated (GlareResolution) and attached to the ROAP message. The random value may not be 0 and MAX_uint32. What ever mechanism that inspects the message and is on the path of the ROAP message and sees a second offer in the opposite direction when one offer is outstanding in either direction can detect a glare. If the glare condition is detected the two offer's GlareResolution values are compared. The offer with the greater value wins. The other is discarded. As long as the winning offer is forwarded all the way to the offerer we can be certain that one signaling message wins. In the case the two values are equal, both are discarded, but a error message must be returned for both messages to cause the end-points to generate new resolution values. When interacting with a SIP gateway, the SIP gateway that create a ROAP message can chose how to generate the tie-breaker. Either it can pick MAX_uint32 to ensure that the message from the SIP side always wins, or it can select to always loose using 0 or have a random value be sent. Which is the right depends on where the glare occurs. But unless a glare condition already have been detected, a random value is used. This mechanism could also be retrofitted into SIP by adding either a SIP header or a attribute in the SDP. That is what is referred as Cullen's proposal below. Secondly the glare condition will be detected in various cases depending on in what state of signaling 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. 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. Assuming the GW sent a random value: 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 SIP 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. 2) IF A sends an offer that has passed the GW, while B's are on its way between B and the GW. 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. 3) Both A and Bs Offers are at the GW while neither has been forwarded. 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. 4) Like 2) but B supports Cullen's behavior. 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. 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 ted.ietf@gmail.com Tue Oct 18 07:46: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 2412921F8B22 for ; Tue, 18 Oct 2011 07:46:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.178 X-Spam-Level: X-Spam-Status: No, score=-3.178 tagged_above=-999 required=5 tests=[AWL=0.420, 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 D9SD72z2iwwV for ; Tue, 18 Oct 2011 07:46: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 1BAEC21F8B1F for ; Tue, 18 Oct 2011 07:46:28 -0700 (PDT) Received: by yxj19 with SMTP id 19so818092yxj.31 for ; Tue, 18 Oct 2011 07:46:24 -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=HVUQQP6MAx20gL7LNm+u/ZLRVSTY04d4c56xbeUNoFw=; b=rF03YWz43ROoRU5GEkDbL/8Qz5milsaJ5tQBXglAHayvWcHt4xGfUi74KSOdl/0nsU sk58jnVTsywNOiPk0h40Q2yxwNUF00BFpasb9EK37SXS6xPQUw89+4axumJ9sTwntB+6 e8qDtI+oqsOAwOFUOjgudBRw1dnN3kWO8M3u0= MIME-Version: 1.0 Received: by 10.236.73.130 with SMTP id v2mr3666206yhd.57.1318949184717; Tue, 18 Oct 2011 07:46:24 -0700 (PDT) Received: by 10.236.105.169 with HTTP; Tue, 18 Oct 2011 07:46:24 -0700 (PDT) In-Reply-To: <7357A569-83A3-43B6-80A7-E2374D78CE28@phonefromhere.com> References: <2E239D6FCD033C4BAF15F386A979BF510F1367@sonusinmail02.sonusnet.com> <4E8AC222.4050308@alvestrand.no> <2E239D6FCD033C4BAF15F386A979BF510F14CE@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF510F14FD@sonusinmail02.sonusnet.com> <393F1888-F834-4DAE-B6B1-1C5D35EE3292@phonefromhere.com> <2E239D6FCD033C4BAF15F386A979BF510F152B@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF510F1532@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF511598EE@sonusinmail02.sonusnet.com> <665A16AB-AAD8-42B3-AC17-7E629EA2DE35@phonefromhere.com> <2E239D6FCD033C4BAF15F386A979BF5115992E@sonusinmail02.sonusnet.com> <0950F0E1-6E4B-407F-9563-654AFE79F64B@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF51159994@sonusinmail02.sonusnet.com> <6398F67A-5E41-44BB-ABB2-831AB7C48DCC@ag-projects.com> <8486C8728176924BAF5BDB2F7D7EEDDF3E091CA3@ucolhp4d.easf.csd.disa.mil> <2E2B1F85-1DED-460D-B17D-0850DB3ACBA9@phonefromhere.com> <8486C8728176924BAF5BDB2F7D7EEDDF3E091D31@ucolhp4d.easf.csd.disa.mil> <7357A569-83A3-43B6-80A7-E2374D78CE28@phonefromhere.com> Date: Tue, 18 Oct 2011 07:46:24 -0700 Message-ID: From: Ted Hardie To: Tim Panton Content-Type: multipart/alternative; boundary=20cf30051518a1c2ab04af93c9c9 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Review request for RTCWeb standard 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: Tue, 18 Oct 2011 14:46:29 -0000 --20cf30051518a1c2ab04af93c9c9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Oct 18, 2011 at 7:19 AM, Tim Panton wrote: > > > The example I gave had _no_ negotiation, no back and forth, because the > application's webserver was > told all the capabilities in advance, (at login in my example), it simply > _decided_ based on > it's view of the union of the capabilities of the two ends. It then > informed them of the choice > (which may have been asymmetric by the way) and told them to get on with > it. > > The working group decided very early on to require a mandatory-to-implement codec to ensure that there were no negotiation failures. If the web server always selects the mandatory to implement codec, then this should work. It may be sub-optimal (a better codec might have been available for this session), but it would cause a complete connection. The issue comes when you use a pair of codec sets from time T and run the intersection algorithm at some later time. The risk is that the overall resource set available at one or more of the nodes may have changed, and this can have an impact on its ability or preferences. The classic example is battery life on mobiles. If I send you a capability set when I have a fully charged battery, it may include computationally expensive algorithms that take a lot of energy; those might be lower preference or elided from the set after hours of game play in which I drew the battery down. I also note that this is not really protocol free, it's just that the forma= t by which the API results are returned to the webserver running the intersection algorithm are not standard; there's still a (private) protocol in use. regards, Ted > To the extent that there was a 'negotiation', it took place in a single > thread on the web server, > with no propagation delays or locks needed. > > > > > > Well, if we can avoid these complexities, let us find out (e.g. > Pre-defined some constraints etc.). > > > > Or, if an API is good enough exposing all the codec parameters and > offer/answer signaling can be avoided, let us find it out. > > Offer - Answer really only crops up because there is a requirement (which= I > personally put very low on our priorities) to be able > to interop with legacy video phones without needing a media gateway. > > Tim. > > > > > BR/Radhika > > > > -----Original Message----- > > From: Tim Panton [mailto:tim@phonefromhere.com] > > Sent: Tuesday, October 18, 2011 9:26 AM > > To: Roy, Radhika R USA CIV (US) > > Cc: Sa=FAl Ibarra Corretg=E9; Ravindran Parthasarathi; rtcweb@ietf.org > > Subject: Re: [rtcweb] Review request for RTCWeb standard signaling > protocol > > > > > > On 18 Oct 2011, at 14:08, Roy, Radhika R USA CIV (US) wrote: > > > >> Hi, Sa=FAl > >> > >> Is there a way to do negotiations with different codec types and > different features of a given codec without using a signaling protocol > between the two functional entities? > >> > >> BR/Radhika > > > > No, you always need a transport to get the supported codec description > list from one end to the other. > > What you don't have to specify is the protocol that the transport uses, > or the decision making process that each end uses to select the capabilit= ies > it wants to employ in this instance of this web app. > > > > Here is an example that illustrates how it could work in a 'protocol > free' way. > > > > User A could query the browser for the codec description list at the > start of a web game session, the web app could upload that to the session > storage on the game server. > > User B does the same thing. > > At some point later users A and B encounter each other in the game. - t= he > server _already_knows_ the capabilites of their respective browsers and > instructs them to do an ice negotiation to find a transport between them. > > Once that is done it informs them _both_ of it's codec selection - whic= h > may be based on their game status. > > > > The video session proceeds as part of the game until the 2 users part, = at > which point the session is torn down. > > > > > > I'm by no means saying that this is the _only_ way connections can be > made, just that if we get this API right we can do things this way. > > Tim. > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --20cf30051518a1c2ab04af93c9c9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Oct 18, 2011 at 7:19 AM, Tim Panton <tim@phonefromhere.com> wrot= e:


The example I gave had _no_ negotiation, no back and forth, because t= he application's webserver was
told all the capabilities in advance, (at login in my example), it simply _= decided_ based on
it's view of the union of the capabilities of the two ends. It then inf= ormed them of the choice
(which may have been asymmetric by the way) and told them to get on with it= .


The working group decided very early on to requir= e a mandatory-to-implement codec to ensure that there were no negotiation f= ailures.=A0 If the web server always selects the mandatory to implement cod= ec, then this should work.=A0 It may be sub-optimal (a better codec might h= ave been available for this session), but it would cause a complete connect= ion.

The issue comes when you use a pair of codec sets from time T and run t= he intersection algorithm at some later time.=A0 The risk is that the overa= ll resource set available at one or more of the nodes may have changed, and= this can have an impact on its ability or preferences.=A0 The classic exam= ple is battery life on mobiles.=A0 If I send you a capability set when I ha= ve a fully charged battery, it may include computationally expensive algori= thms that take a lot of energy; those might be lower preference or elided f= rom the set after hours of game play in which I drew the battery down.=A0 <= br>
I also note that this is not really protocol free, it's just that t= he format by which the API results are returned to the webserver running th= e intersection algorithm are not standard; there's still a (private) pr= otocol in use.

regards,

Ted
To the extent that there was a 'negotiation', =A0it took place in a= single thread on the web server,
with no propagation delays or locks needed.


>
> Well, if we can avoid these complexities, let us find out (e.g. Pre-de= fined some constraints etc.).
>
> Or, if an API is good enough exposing all the codec parameters and off= er/answer signaling can be avoided, let us find it out.

Offer - Answer really only crops up because there is a requirement (w= hich I personally put very low on our priorities) to be able
to interop with legacy video phones without =A0needing a media gateway.

Tim.

>
> BR/Radhika
>
> -----Original Message-----
> From: Tim Panton [mailto:tim@= phonefromhere.com]
> Sent: Tuesday, October 18, 2011 9:26 AM
> To: Roy, Radhika R USA CIV (US)
> Cc: Sa=FAl Ibarra Corretg=E9; Ravindran Parthasarathi; rtcweb@ietf.org
> Subject: Re: [rtcweb] Review request for RTCWeb standard signaling pro= tocol
>
>
> On 18 Oct 2011, at 14:08, Roy, Radhika R USA CIV (US) wrote:
>
>> Hi, Sa=FAl
>>
>> Is there a way to do negotiations with different codec types and d= ifferent features of a given codec without using a signaling protocol betwe= en the two functional entities?
>>
>> BR/Radhika
>
> No, you always need =A0a transport to get the supported codec descript= ion list from one end to the other.
> What you don't have to specify is the protocol that the transport = uses, or the decision making process that each end uses to select the capab= ilities it wants to employ in this instance of this web app.
>
> Here is an example that illustrates how it could work in a 'protoc= ol free' way.
>
> User A could query the browser for the codec description list at the s= tart of a web game session, the web app could upload that to the session st= orage on the game server.
> User B does the same thing.
> At some point later users A and B encounter each other in the game. - = the server _already_knows_ the capabilites of their respective browsers and= instructs them to do an ice negotiation to find a transport between them.<= br> > Once that is done it informs them _both_ of it's codec selection -= which may be based on their game status.
>
> The video session proceeds as part of the game until the 2 users part,= at which point the session is torn down.
>
>
> I'm by no means saying that this is the _only_ way connections can= be made, just that if we get this API right we can do things this way.
> Tim.
>

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

--20cf30051518a1c2ab04af93c9c9-- From tim@phonefromhere.com Tue Oct 18 08: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 5AD8721F8B7E for ; Tue, 18 Oct 2011 08:02:11 -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 EkT-IyXPCcor for ; Tue, 18 Oct 2011 08:02:10 -0700 (PDT) Received: from zimbra.westhawk.co.uk (zimbra.westhawk.co.uk [192.67.4.167]) by ietfa.amsl.com (Postfix) with ESMTP id 2B89021F8B5C for ; Tue, 18 Oct 2011 08:02:09 -0700 (PDT) Received: from [192.168.0.14] (unknown [93.89.81.113]) by zimbra.westhawk.co.uk (Postfix) with ESMTP id 7CEFB37A902; Tue, 18 Oct 2011 16:14:54 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-6--806976963 From: Tim Panton In-Reply-To: Date: Tue, 18 Oct 2011 16:02:02 +0100 Message-Id: <73409596-7D52-495B-92F5-4C917364EEDC@phonefromhere.com> References: <2E239D6FCD033C4BAF15F386A979BF510F1367@sonusinmail02.sonusnet.com> <4E8AC222.4050308@alvestrand.no> <2E239D6FCD033C4BAF15F386A979BF510F14CE@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF510F14FD@sonusinmail02.sonusnet.com> <393F1888-F834-4DAE-B6B1-1C5D35EE3292@phonefromhere.com> <2E239D6FCD033C4BAF15F386A979BF510F152B@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF510F1532@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF511598EE@sonusinmail02.sonusnet.com> <665A16AB-AAD8-42B3-AC17-7E629EA2DE35@phonefromhere.com> <2E239D6FCD033C4BAF15F386A979BF5115992E@sonusinmail02.sonusnet.com> <0950F0E1- 6E4B-407F-9563-654AFE79F64B@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF51159994@sonusinmail02.sonusnet.com> <6398F67A-5E41-44BB-ABB2-831AB7C48DCC@ag-projects.com> <8486C8728176924BAF5BDB2F7D7EEDDF3E091CA3@ucolhp4d.easf.csd.disa.mil> <2E2B1F85-1DED-460D-B17D-0850DB3ACBA9@phonefromhere.com> <8486C8728176924BAF5BDB2F7D7EEDDF3E091D31@ucolhp4d.easf.csd.disa.mil> <7357A569-83A3-43B6-80A7-E2374D78CE28@phonefromhere.com> To: Ted Hardie X-Mailer: Apple Mail (2.1084) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Review request for RTCWeb standard 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: Tue, 18 Oct 2011 15:02:11 -0000 --Apple-Mail-6--806976963 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 18 Oct 2011, at 15:46, Ted Hardie wrote: > On Tue, Oct 18, 2011 at 7:19 AM, Tim Panton = wrote: >=20 >=20 > The example I gave had _no_ negotiation, no back and forth, because = the application's webserver was > told all the capabilities in advance, (at login in my example), it = simply _decided_ based on > it's view of the union of the capabilities of the two ends. It then = informed them of the choice > (which may have been asymmetric by the way) and told them to get on = with it. >=20 >=20 > The working group decided very early on to require a = mandatory-to-implement codec to ensure that there were no negotiation = failures. If the web server always selects the mandatory to implement = codec, then this should work. It may be sub-optimal (a better codec = might have been available for this session), but it would cause a = complete connection. That would be the trivial case of the intersection algorithm. >=20 > The issue comes when you use a pair of codec sets from time T and run = the intersection algorithm at some later time. The risk is that the = overall resource set available at one or more of the nodes may have = changed, and this can have an impact on its ability or preferences. The = classic example is battery life on mobiles. If I send you a capability = set when I have a fully charged battery, it may include computationally = expensive algorithms that take a lot of energy; those might be lower = preference or elided from the set after hours of game play in which I = drew the battery down. =20 On the other hand, As a user I might find the next 20 seconds of play = critical and opt to go 'hi-def' despite the low battery warning. Some of = the current proposals would make that very hard to do. >=20 > I also note that this is not really protocol free, it's just that the = format by which the API results are returned to the webserver running = the intersection algorithm are not standard; there's still a (private) = protocol in use. Agreed, the data has to move somehow. I'm not sure I dignify sending = some JSON object over HTTP as a 'protocol', I see it as a pre-existing = transport. There is indeed a private (in the sense that it isn't standardized) = intersection algorithm running, but my point was that it wouldn't _have_ = to run in the browser, it might well run in the server. The current round = of proposals seem to me to preclude that almost completely , which very = much goes against the grain in the context of a web service. Tim. >=20 > regards, >=20 > Ted=20 > To the extent that there was a 'negotiation', it took place in a = single thread on the web server, > with no propagation delays or locks needed. >=20 >=20 > > > > Well, if we can avoid these complexities, let us find out (e.g. = Pre-defined some constraints etc.). > > > > Or, if an API is good enough exposing all the codec parameters and = offer/answer signaling can be avoided, let us find it out. >=20 > Offer - Answer really only crops up because there is a requirement = (which I personally put very low on our priorities) to be able > to interop with legacy video phones without needing a media gateway. >=20 > Tim. >=20 > > > > BR/Radhika > > > > -----Original Message----- > > From: Tim Panton [mailto:tim@phonefromhere.com] > > Sent: Tuesday, October 18, 2011 9:26 AM > > To: Roy, Radhika R USA CIV (US) > > Cc: Sa=FAl Ibarra Corretg=E9; Ravindran Parthasarathi; = rtcweb@ietf.org > > Subject: Re: [rtcweb] Review request for RTCWeb standard signaling = protocol > > > > > > On 18 Oct 2011, at 14:08, Roy, Radhika R USA CIV (US) wrote: > > > >> Hi, Sa=FAl > >> > >> Is there a way to do negotiations with different codec types and = different features of a given codec without using a signaling protocol = between the two functional entities? > >> > >> BR/Radhika > > > > No, you always need a transport to get the supported codec = description list from one end to the other. > > What you don't have to specify is the protocol that the transport = uses, or the decision making process that each end uses to select the = capabilities it wants to employ in this instance of this web app. > > > > Here is an example that illustrates how it could work in a 'protocol = free' way. > > > > User A could query the browser for the codec description list at the = start of a web game session, the web app could upload that to the = session storage on the game server. > > User B does the same thing. > > At some point later users A and B encounter each other in the game. = - the server _already_knows_ the capabilites of their respective = browsers and instructs them to do an ice negotiation to find a transport = between them. > > Once that is done it informs them _both_ of it's codec selection - = which may be based on their game status. > > > > The video session proceeds as part of the game until the 2 users = part, at which point the session is torn down. > > > > > > I'm by no means saying that this is the _only_ way connections can = be made, just that if we get this API right we can do things this way. > > Tim. > > >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 --Apple-Mail-6--806976963 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
On Tue, = Oct 18, 2011 at 7:19 AM, Tim Panton <tim@phonefromhere.com>= wrote:


The example I gave had _no_ negotiation, no back and forth, = because the application's webserver was
told all the capabilities in advance, (at login in my example), it = simply _decided_ based on
it's view of the union of the capabilities of the two ends. It then = informed them of the choice
(which may have been asymmetric by the way) and told them to get on with = it.


The working group decided very early on to = require a mandatory-to-implement codec to ensure that there were no = negotiation failures.  If the web server always selects the = mandatory to implement codec, then this should work.  It may be = sub-optimal (a better codec might have been available for this session), = but it would cause a complete = connection.

That would = be the trivial case of the = intersection algorithm.


The issue comes when you use a pair of codec sets from time T and = run the intersection algorithm at some later time.  The risk is = that the overall resource set available at one or more of the nodes may = have changed, and this can have an impact on its ability or = preferences.  The classic example is battery life on mobiles.  = If I send you a capability set when I have a fully charged battery, it = may include computationally expensive algorithms that take a lot of = energy; those might be lower preference or elided from the set after = hours of game play in which I drew the battery down.  =

On the other hand, As a user = I might find the next 20 seconds of play critical and opt to go = 'hi-def' despite the low battery warning. Some of the current proposals = would make that very hard to do.


I also note that this is not really protocol free, it's just that = the format by which the API results are returned to the webserver = running the intersection algorithm are not standard; there's still a = (private) protocol in = use.

Agreed, the data = has to move somehow. I'm not sure I dignify sending some JSON object = over HTTP as a 'protocol', I see it as a pre-existing = transport.
There is indeed a private (in the sense that it = isn't standardized) intersection algorithm running, but my point was = that it wouldn't _have_ to
run in the browser, it might well = run in the server. The current round of proposals seem to me to preclude = that almost completely , which very much
goes against the = grain in the context of a web = service.

Tim.

regards,

Ted
To the extent that there was a 'negotiation',  it took place in a = single thread on the web server,
with no propagation delays or locks needed.


>
> Well, if we can avoid these complexities, let us find out (e.g. = Pre-defined some constraints etc.).
>
> Or, if an API is good enough exposing all the codec parameters and = offer/answer signaling can be avoided, let us find it out.

Offer - Answer really only crops up because there is a requirement = (which I personally put very low on our priorities) to be able
to interop with legacy video phones without  needing a media = gateway.

Tim.

>
> BR/Radhika
>
> -----Original Message-----
> From: Tim Panton [mailto:tim@phonefromhere.com]
> Sent: Tuesday, October 18, 2011 9:26 AM
> To: Roy, Radhika R USA CIV (US)
> Cc: Sa=FAl Ibarra Corretg=E9; Ravindran Parthasarathi; rtcweb@ietf.org
> Subject: Re: [rtcweb] Review request for RTCWeb standard signaling = protocol
>
>
> On 18 Oct 2011, at 14:08, Roy, Radhika R USA CIV (US) wrote:
>
>> Hi, Sa=FAl
>>
>> Is there a way to do negotiations with different codec types = and different features of a given codec without using a signaling = protocol between the two functional entities?
>>
>> BR/Radhika
>
> No, you always need  a transport to get the supported codec = description list from one end to the other.
> What you don't have to specify is the protocol that the transport = uses, or the decision making process that each end uses to select the = capabilities it wants to employ in this instance of this web app.
>
> Here is an example that illustrates how it could work in a = 'protocol free' way.
>
> User A could query the browser for the codec description list at = the start of a web game session, the web app could upload that to the = session storage on the game server.
> User B does the same thing.
> At some point later users A and B encounter each other in the game. = - the server _already_knows_ the capabilites of their respective = browsers and instructs them to do an ice negotiation to find a transport = between them.
> Once that is done it informs them _both_ of it's codec selection - = which may be based on their game status.
>
> The video session proceeds as part of the game until the 2 users = part, at which point the session is torn down.
>
>
> I'm by no means saying that this is the _only_ way connections can = be made, just that if we get this API right we can do things this = way.
> Tim.
>

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


= --Apple-Mail-6--806976963-- From ibc@aliax.net Tue Oct 18 08:40: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 61A6A21F8AAF for ; Tue, 18 Oct 2011 08:40:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.63 X-Spam-Level: X-Spam-Status: No, score=-2.63 tagged_above=-999 required=5 tests=[AWL=0.047, 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 pP-HGK+x04k5 for ; Tue, 18 Oct 2011 08:40: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 D16E421F8A97 for ; Tue, 18 Oct 2011 08:40:48 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so760507vcb.31 for ; Tue, 18 Oct 2011 08:40:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.117.81 with SMTP id p17mr222627vcq.41.1318952447397; Tue, 18 Oct 2011 08:40:47 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Tue, 18 Oct 2011 08:40:47 -0700 (PDT) In-Reply-To: <4E9D8D82.707@ericsson.com> References: <15B0E3AD-3086-499A-8E79-7AE58B3376C4@cisco.com> <4E9D8D82.707@ericsson.com> Date: Tue, 18 Oct 2011 17:40:47 +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: Jonathan Rosenberg , rtcweb@ietf.org Subject: Re: [rtcweb] SDP Offer/Answer draft-jennings-rtcweb-signaling: Glare handling X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 15:40:49 -0000 2011/10/18 Magnus Westerlund : > For example an JS application that uses short polling for retrieving any > incomming ROAP messages, as that is timer based and done lets say every > 5 seconds Hi. This is RTC, so *realtime* is required for media sessions. I expect that people should assume WebSocket usage rather than HTTP polling. --=20 I=C3=B1aki Baz Castillo From dzonatas@gmail.com Tue Oct 18 08:42: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 D9C2121F8B9A for ; Tue, 18 Oct 2011 08:42:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=-0.612, BAYES_00=-2.599, 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 5Eu7jsDgZfeJ for ; Tue, 18 Oct 2011 08:42:14 -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 B4DB221F8AF7 for ; Tue, 18 Oct 2011 08:42:14 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so762338vcb.31 for ; Tue, 18 Oct 2011 08:42:14 -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=ix9HkHIGMX7rL8ahHvP89j6+k5u+UPLG1zQnAVOROKk=; b=pjPttkjfk07fdV7coWZTXmR5Yb1LtJiiH29U7kltCxUOyk6yg3x0hN2i/Cjs+wLvIp GGvJvIXvG4wxtt8bEUfbOEIHDeSfhD9UaUycz45hgy6Hx7e2+6D7qk/famkMX3F2olT2 CnYEYIKLZ72MnQALkF+nQizR5UEGv98dsbD8c= MIME-Version: 1.0 Received: by 10.52.34.100 with SMTP id y4mr2978038vdi.66.1318952533992; Tue, 18 Oct 2011 08:42:13 -0700 (PDT) Received: by 10.52.107.202 with HTTP; Tue, 18 Oct 2011 08:42:13 -0700 (PDT) In-Reply-To: <4E9D667A.2040703@alvestrand.no> References: <4E9D667A.2040703@alvestrand.no> Date: Tue, 18 Oct 2011 08:42:13 -0700 Message-ID: From: Dzonatas Sol To: Harald Alvestrand Content-Type: multipart/alternative; boundary=20cf3079bb0643a4c204af9491e2 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] My Opinion: Why I think a negotiating protocol is a Good Thing X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 15:42:16 -0000 --20cf3079bb0643a4c204af9491e2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Tue, Oct 18, 2011 at 4:43 AM, Harald Alvestrand wr= ote: > (Apologies for the length of this note - but I wanted to follow this > argument a bit deeply) > > In the discussions about RTCWEB signalling, I=92ve had a change of heart. > Or perhaps it=92s just a change of terminology. > > The high bit is this: > I believe we need to standardize a negotiation protocol as part of RTCWEB= . > This needs to be described as a protocol, and cannot usefully be describe= d > as an API. > > This note is to explain to my fellow WG members what led me to this > conclusion, and - in some detail - what I think the words in the above > paragraph mean. > Those who don't want to read a long message can stop here. > ------------------------------**------------------------------** > ---------------- > > The context of RTCWEB is the well known trapezoid: > > +-----------+ +-----------+ > | Web | | Web | > | | Signalling | | > | |-------------| | > | Server | path | Server | > | | | | > +-----------+ +-----------+ > / \ > / \ Proprietary over > / \ HTTP/Websockets > / \ > / Proprietary over \ > / HTTP/Websockets \ > / \ > +-----------+ +-----------+ > |JS/HTML/CSS| |JS/HTML/CSS| > +-----------+ +-----------+ > +-----------+ +-----------+ > | | | | > | | | | > | Browser | ------------------------- | Browser | > | | Media path | | > | | | | > +-----------+ +-----------+ > > or even the triangle, where the triangle is formed when the two Web sever= s > on top are collapsed into one. > > A design criterion for RTCWEB has been that it should be possible to writ= e > applications on top of RTCWEB simply - that is, without deep knowledge ab= out > the world of codecs, RTP sessions and the like. > Another design criterion is that interworking should be possible - which > means that SOMEWHERE in the system, deep knowledge about the world of > codecs, RTP sessions and the like must be embedded; we can=92t just simpl= ify > our options until everything=92s simple. > > There=92s one place in the ecosystem where this knowledge HAS to be - and > that is within the browser, the component that takes care of implementing > the codecs, the RTP sessions and the related features. If we can avoid > requiring embedding it twice, that=92s a feature. > > It used to be that I was a believer in APIs - that we should make the API > the =93king=94, and describe the way you generate an RTP session as =93yo= u turn > this knob, and get this effect=94. > After looking at the problem of Web applications that don=92t have domain > knowledge for a while, I=92ve concluded that this doesn=92t work. There= =92s the > need for one browser to communicate with the other browser, and if the > intermediate components are to have the ability to ignore the details, > what=92s communicated has to be treated like a blob - something passed ou= t of > one browser=92s API and into another browser=92s API, unchanged by the > application - because the application must be able to ignore the details. > > OK, now we have the API with blobs. We also have to make some assumptions > about how those blobs are transported, who=92s responsible for acting on = them, > and so on. And we have to make sure different browsers implement the blob > the same way - that is, it has to be standardized. > What=92s more - we DO want to enable applications that are NOT simple. > Including gateways, which are not browsers. So applications must be free = to > look inside the blob - break the blob boundary - when they need to. So th= is > pulls in the same direction as the need for interoperability - the format= , > semantics and handling rules for these blobs has to be specified. In some > detail. > > So we have: > - a data format > - a transmission path > - a set of handling rules, in the form of states, processes and timers > > This doesn=92t look like an API any more. This looks like a protocol. We= =92ve > got experience in describing protocols - but it becomes much easier to ap= ply > that experience when we call it a protocol. > I like the idea that expands the FILE: protocol such that it would work wit= h an audio-only codec already available. I guess that would be a blob instead of an image. > > Let=92s do that. > > But - you did not address my point... > ------------------------------**---------------- > No, I didn=92t. But here are some points that might bear watching. > > =93We shouldn=92t mandate a new protocol on the wire=94. > We=92re not. We=92re specifying one, and mandating it for a specific poin= t: The > browser/JS interface. > We can have applications that parse it locally using a JS library; in tha= t > case, the protocol runs between the browser and the local JS application. > We can have applications that pass the blobs to a server for gatewaying > into something else; in that case, the protocol runs between the browser = and > the server. > We can have applications that pass the blobs (possibly via a very simple > server) to another browser, unchanged; in that case, the protocol runs > between the two browsers. > > In no case does the browser need to know where the other end is; all it > cares about is that the messages flow according to protocol. > > =93We should build knobs and let JS libraries take care of what=92s on to= p of > them=94. > Well - we could. But it violates the idea of only having the domain > knowledge present once. > If you have to have a browser that implements codec A, and a JS library > that knows how to control codec A, you are *requiring* knowledge in two > places. That=92s not optimal. > Things may change in the future - once downloadable codecs actually work, > downloadable negotiation blobs may be a reasonable counterpart. But we=92= re > not there now. > > =93We should use existing protocol X=94 > We could. But then, we=92d buy into all the baggage of protocol X - both = the > things it requires us to do and the things that it won=92t let us do. Doe= sn=92t > sound too good to me. > ______________________________**_________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/**listinfo/rtcweb > --20cf3079bb0643a4c204af9491e2 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On Tue, Oct 18, 2011 at 4:43 AM, Harald Alvestra= nd <harald@alv= estrand.no> wrote:
(Apologies for the length of this note - but I wanted to follow this argume= nt a bit deeply)

In the discussions about RTCWEB signalling, I=92ve had a change of heart. Or perhaps it=92s just a change of terminology.

The high bit is this:
I believe we need to standardize a negotiation protocol as part of RTCWEB.<= br> This needs to be described as a protocol, and cannot usefully be described = as an API.

This note is to explain to my fellow WG members what led me to this conclus= ion, and - in some detail - what I think the words in the above paragraph m= ean.
Those who don't want to read a long message can stop here.
-------------------------------------------------------------= ---------------

The context of RTCWEB is the well known trapezoid:

+-----------+ +-----------+
| Web | | Web |
| | Signalling | |
| |-------------| |
| Server | path | Server |
| | | |
+-----------+ +-----------+
/ \
/ \ Proprietary over
/ \ HTTP/Websockets
/ \
/ Proprietary over \
/ HTTP/Websockets \
/ \
+-----------+ +-----------+
|JS/HTML/CSS| |JS/HTML/CSS|
+-----------+ +-----------+
+-----------+ +-----------+
| | | |
| | | |
| Browser | ------------------------- | Browser |
| | Media path | |
| | | |
+-----------+ +-----------+

or even the triangle, where the triangle is formed when the two Web severs = on top are collapsed into one.

A design criterion for RTCWEB has been that it should be possible to write = applications on top of RTCWEB simply - that is, without deep knowledge abou= t the world of codecs, RTP sessions and the like.
Another design criterion is that interworking should be possible - which me= ans that SOMEWHERE in the system, deep knowledge about the world of codecs,= RTP sessions and the like must be embedded; we can=92t just simplify our o= ptions until everything=92s simple.

There=92s one place in the ecosystem where this knowledge HAS to be - and t= hat is within the browser, the component that takes care of implementing th= e codecs, the RTP sessions and the related features. If we can avoid requir= ing embedding it twice, that=92s a feature.

It used to be that I was a believer in APIs - that we should make the API t= he =93king=94, and describe the way you generate an RTP session as =93you t= urn this knob, and get this effect=94.
After looking at the problem of Web applications that don=92t have domain k= nowledge for a while, I=92ve concluded that this doesn=92t work. There=92s = the need for one browser to communicate with the other browser, and if the = intermediate components are to have the ability to ignore the details, what= =92s communicated has to be treated like a blob - something passed out of o= ne browser=92s API and into another browser=92s API, unchanged by the appli= cation - because the application must be able to ignore the details.

OK, now we have the API with blobs. We also have to make some assumptions a= bout how those blobs are transported, who=92s responsible for acting on the= m, and so on. And we have to make sure different browsers implement the blo= b the same way - that is, it has to be standardized.
What=92s more - we DO want to enable applications that are NOT simple. Incl= uding gateways, which are not browsers. So applications must be free to loo= k inside the blob - break the blob boundary - when they need to. So this pu= lls in the same direction as the need for interoperability - the format, se= mantics and handling rules for these blobs has to be specified. In some det= ail.

So we have:
- a data format
- a transmission path
- a set of handling rules, in the form of states, processes and timers

This doesn=92t look like an API any more. This looks like a protocol. We=92= ve got experience in describing protocols - but it becomes much easier to a= pply that experience when we call it a protocol.


I like the idea that expands the FILE: protocol s= uch that it would work with an audio-only codec already available. I guess = that would be a blob instead of an image.



=A0

Let=92s do that.

But - you did not address my point...
----------------------------------------------
No, I didn=92t. But here are some points that might bear watching.

=93We shouldn=92t mandate a new protocol on the wire=94.
We=92re not. We=92re specifying one, and mandating it for a specific point:= The browser/JS interface.
We can have applications that parse it locally using a JS library; in that = case, the protocol runs between the browser and the local JS application. We can have applications that pass the blobs to a server for gatewaying int= o something else; in that case, the protocol runs between the browser and t= he server.
We can have applications that pass the blobs (possibly via a very simple se= rver) to another browser, unchanged; in that case, the protocol runs betwee= n the two browsers.

In no case does the browser need to know where the other end is; all it car= es about is that the messages flow according to protocol.

=93We should build knobs and let JS libraries take care of what=92s on top = of them=94.
Well - we could. But it violates the idea of only having the domain knowled= ge present once.
If you have to have a browser that implements codec A, and a JS library tha= t knows how to control codec A, you are *requiring* knowledge in two places= . That=92s not optimal.
Things may change in the future - once downloadable codecs actually work, d= ownloadable negotiation blobs may be a reasonable counterpart. But we=92re = not there now.

=93We should use existing protocol X=94
We could. But then, we=92d buy into all the baggage of protocol X - both th= e things it requires us to do and the things that it won=92t let us do. Doe= sn=92t sound too good to me.
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org = https://www.ietf.org/mailman/listinfo/rtcweb

--20cf3079bb0643a4c204af9491e2-- From ekr@rtfm.com Tue Oct 18 08:45: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 A1C2E21F8BC3 for ; Tue, 18 Oct 2011 08:45:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.827 X-Spam-Level: X-Spam-Status: No, score=-102.827 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T1KNpxlb3LIS for ; Tue, 18 Oct 2011 08:45:08 -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 1FD7A21F8BBD for ; Tue, 18 Oct 2011 08:45:08 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so765969vcb.31 for ; Tue, 18 Oct 2011 08:45:07 -0700 (PDT) Received: by 10.220.147.201 with SMTP id m9mr211710vcv.210.1318952707451; Tue, 18 Oct 2011 08:45:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.161.20 with HTTP; Tue, 18 Oct 2011 08:44:27 -0700 (PDT) In-Reply-To: References: <15B0E3AD-3086-499A-8E79-7AE58B3376C4@cisco.com> <4E9D8D82.707@ericsson.com> From: Eric Rescorla Date: Tue, 18 Oct 2011 08:44:27 -0700 Message-ID: To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Jonathan Rosenberg , rtcweb@ietf.org Subject: Re: [rtcweb] SDP Offer/Answer draft-jennings-rtcweb-signaling: Glare handling X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 15:45:08 -0000 I'm not sure I agree with this. 2-5 seconds isn't really that long to wait for the interval between the caller starting the call and the callee being alerted.= I'm not saying it's optimal, but I don't think it's unacceptable either. Moreov= er, even if we agree that we're using something other than short poll, I suspect there will be many applications that use long poll rather than WS. -Ekr On Tue, Oct 18, 2011 at 8:40 AM, I=F1aki Baz Castillo wrote= : > 2011/10/18 Magnus Westerlund : >> For example an JS application that uses short polling for retrieving any >> incomming ROAP messages, as that is timer based and done lets say every >> 5 seconds > > Hi. This is RTC, so *realtime* is required for media sessions. I > expect that people should assume WebSocket usage rather than HTTP > polling. > > > > -- > I=F1aki Baz Castillo > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From BeckW@telekom.de Tue Oct 18 08:47: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 0681521F8B6F for ; Tue, 18 Oct 2011 08:47:52 -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_DE=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 04JnwQUApHOJ for ; Tue, 18 Oct 2011 08:47:51 -0700 (PDT) Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by ietfa.amsl.com (Postfix) with ESMTP id ECFFE21F8B4A for ; Tue, 18 Oct 2011 08:47:50 -0700 (PDT) Received: from he110889.emea1.cds.t-internal.com ([10.134.92.130]) by tcmail51.telekom.de with ESMTP/TLS/AES128-SHA; 18 Oct 2011 17:47:48 +0200 Received: from HE111644.EMEA1.CDS.T-INTERNAL.COM ([169.254.4.223]) by HE110889.emea1.cds.t-internal.com ([fe80::841f:f92c:15ca:8526%16]) with mapi; Tue, 18 Oct 2011 17:47:47 +0200 From: To: , Date: Tue, 18 Oct 2011 17:47:46 +0200 Thread-Topic: [rtcweb] Current state of signaling discussion Thread-Index: AQHMjZ/9v/MVYdTFIUm+RaPRMyDYcZWCPp5A Message-ID: References: <4E9D773A.4010705@ericsson.com> <753A5B5E-45A7-46F0-98F9-B4503F4A0EF2@acmepacket.com> <4E9D85B0.6070008@ericsson.com> In-Reply-To: Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Current state of signaling discussion X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 15:47:52 -0000 > In the following message I included my clarified request on that there > is still need to have an I-D on the "no signalling" proposal: > https://datatracker.ietf.org/doc/draft-beck-rtcweb-alt-ic/ is such a draft. I missed the 7. October dead-line to announce it, but subm= itted it the 14th. It proposes an interconnection model that does not require standardized sig= nalling. Wolfgang Beck Deutsche Telekom Netzproduktion GmbH Fixed Mobile Engineering Deutschland Wolfgang Beck Heinrich-Hertz-Stra=DFe 3-7, 64295 Darmstadt +49 6151 628 2832 (Tel.) http://www.telekom.de Erleben, was verbindet. Deutsche Telekom Netzproduktion GmbH Aufsichtsrat: Dr. Thomas Knoll (Vorsitzender) Gesch=E4ftsf=FChrung: Dr. Bruno Jacobfeuerborn (Vorsitzender), Albert Mathe= is, Klaus Peren Handelsregister: Amtsgericht Bonn HRB 14190 Sitz der Gesellschaft Bonn USt-IdNr. DE 814645262 Gro=DFe Ver=E4nderungen fangen klein an - Ressourcen schonen und nicht jede= E-Mail drucken. -----Urspr=FCngliche Nachricht----- Von: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] Im Auftrag vo= n Hadriel Kaplan Gesendet: Dienstag, 18. Oktober 2011 16:13 An: Magnus Westerlund Cc: rtcweb@ietf.org Betreff: Re: [rtcweb] Current state of signaling discussion On Oct 18, 2011, at 9:57 AM, Magnus Westerlund wrote: > http://www.ietf.org/mail-archive/web/rtcweb/current/msg01794.html Ahhh. Sorry I did not see that email. (I don't know how I could have misse= d an email in such a low-volume mailing list ;) OK, I'll try and submit one before Friday if no one else is going to. -hadriel _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From BeckW@telekom.de Tue Oct 18 08:56: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 B6B1121F8AFD for ; Tue, 18 Oct 2011 08:56:37 -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_DE=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 DjUgmNSsTmpa for ; Tue, 18 Oct 2011 08:56:37 -0700 (PDT) Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by ietfa.amsl.com (Postfix) with ESMTP id D544F21F8AFB for ; Tue, 18 Oct 2011 08:56:36 -0700 (PDT) Received: from he111629.emea1.cds.t-internal.com ([10.134.93.21]) by tcmail51.telekom.de with ESMTP/TLS/AES128-SHA; 18 Oct 2011 17:56:08 +0200 Received: from HE111644.EMEA1.CDS.T-INTERNAL.COM ([169.254.4.223]) by HE111629.emea1.cds.t-internal.com ([::1]) with mapi; Tue, 18 Oct 2011 17:56:07 +0200 From: To: , Date: Tue, 18 Oct 2011 17:56:06 +0200 Thread-Topic: [rtcweb] SDP Offer/Answer draft-jennings-rtcweb-signaling: Glare handling Thread-Index: AcyNrOQayO/sOZz8Rs+kZz00rSvUdwAAKs0A Message-ID: References: <15B0E3AD-3086-499A-8E79-7AE58B3376C4@cisco.com> <4E9D8D82.707@ericsson.com> In-Reply-To: Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: jonathan.rosenberg@skype.net, rtcweb@ietf.org Subject: Re: [rtcweb] SDP Offer/Answer draft-jennings-rtcweb-signaling: Glare handling X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 15:56:37 -0000 Ekr wrote: > I'm not sure I agree with this. 2-5 seconds isn't really that long to > wait for the interval between the caller starting the call and the callee= being alerted. I consider 2-5 s a quite horrible call setup time, and I can tell that cust= omers really care about it. Of course it's acceptable if such a long setup = delay only occurs occasionally. Wolfgang Beck Deutsche Telekom Netzproduktion GmbH Fixed Mobile Engineering Deutschland Wolfgang Beck Heinrich-Hertz-Stra=DFe 3-7, 64295 Darmstadt +49 6151 628 2832 (Tel.) http://www.telekom.de Erleben, was verbindet. Deutsche Telekom Netzproduktion GmbH Aufsichtsrat: Dr. Thomas Knoll (Vorsitzender) Gesch=E4ftsf=FChrung: Dr. Bruno Jacobfeuerborn (Vorsitzender), Albert Mathe= is, Klaus Peren Handelsregister: Amtsgericht Bonn HRB 14190 Sitz der Gesellschaft Bonn USt-IdNr. DE 814645262 Gro=DFe Ver=E4nderungen fangen klein an - Ressourcen schonen und nicht jede= E-Mail drucken. From roman@telurix.com Tue Oct 18 09:07: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 75CD121F8C0F for ; Tue, 18 Oct 2011 09:07:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[AWL=-0.001, 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 kC4XNMSuEBwi for ; Tue, 18 Oct 2011 09:07:18 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id F1D4A21F8C0C for ; Tue, 18 Oct 2011 09:07:15 -0700 (PDT) Received: by ywa8 with SMTP id 8so905076ywa.31 for ; Tue, 18 Oct 2011 09:07:15 -0700 (PDT) Received: by 10.68.1.230 with SMTP id 6mr6000998pbp.27.1318954035100; Tue, 18 Oct 2011 09:07:15 -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 ji3sm8668608pbc.2.2011.10.18.09.07.12 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 18 Oct 2011 09:07:13 -0700 (PDT) Received: by pzk34 with SMTP id 34so1997772pzk.9 for ; Tue, 18 Oct 2011 09:07:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.8.233 with SMTP id u9mr5917408pba.30.1318954032379; Tue, 18 Oct 2011 09:07:12 -0700 (PDT) Received: by 10.68.47.40 with HTTP; Tue, 18 Oct 2011 09:07:12 -0700 (PDT) In-Reply-To: <4E9D85CB.6030503@ericsson.com> References: <15B0E3AD-3086-499A-8E79-7AE58B3376C4@cisco.com> <4E9D43D2.9010804@alvestrand.no> <4E9D5E9A.7090308@alvestrand.no> <4E9D7019.2020303@ericsson.com> <4E9D85CB.6030503@ericsson.com> Date: Tue, 18 Oct 2011 12:07:12 -0400 Message-ID: From: Roman Shpount To: =?ISO-8859-1?Q?Stefan_H=E5kansson_LK?= Content-Type: multipart/alternative; boundary=bcaec5215a5993366604af94eaf9 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] API options for supporting fork with ROAP (Re: SDP Offer/Answer draft-jennings-rtcweb-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: Tue, 18 Oct 2011 16:07:18 -0000 --bcaec5215a5993366604af94eaf9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Oct 18, 2011 at 9:57 AM, Stefan H=E5kansson LK < stefan.lk.hakansson@ericsson.com> wrote: > What I mean is: if this web app has already created a PeerConncection, an= d > is about to open another one (e.g. for a new fork), the new PeerConnectio= n > should use the same local candidates as the one already created collected= . > > What would happen if new PeerConnection has a different set of codecs/media streams? Do we just add/remove local candidates based on how many different streams are needed? Overall I do like this idea since it not only addresses the forking issue, but suggest a good resource usage policy. _____________ Roman Shpount --bcaec5215a5993366604af94eaf9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Oct 18, 2011 at 9:57 AM, Stefan H=E5kans= son LK <stefan.lk.hakansson@ericsson.com> wrote:
What I mean is: if this web app has already created a PeerConncection, and = is about to open another one (e.g. for a new fork), the new PeerConnection = should use the same local candidates as the one already created collected.<= div class=3D"im">

What would happen if new PeerConnection ha= s a different set of codecs/media streams? Do we just add/remove local cand= idates based on how many different streams are needed?

Overall I do = like this idea since it not only addresses the forking issue, but suggest a= good resource usage policy.
_____________
Roman Shpount

--bcaec5215a5993366604af94eaf9-- From ekr@rtfm.com Tue Oct 18 09: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 7B0BA21F8BF6 for ; Tue, 18 Oct 2011 09:24:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.94 X-Spam-Level: X-Spam-Status: No, score=-102.94 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rBl1WtB1Smo9 for ; Tue, 18 Oct 2011 09:24:29 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 016B321F8AE1 for ; Tue, 18 Oct 2011 09:24:28 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so815479vcb.31 for ; Tue, 18 Oct 2011 09:24:28 -0700 (PDT) Received: by 10.52.182.39 with SMTP id eb7mr2192670vdc.12.1318955068370; Tue, 18 Oct 2011 09:24:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.161.20 with HTTP; Tue, 18 Oct 2011 09:23:48 -0700 (PDT) In-Reply-To: References: <15B0E3AD-3086-499A-8E79-7AE58B3376C4@cisco.com> <4E9D8D82.707@ericsson.com> From: Eric Rescorla Date: Tue, 18 Oct 2011 09:23:48 -0700 Message-ID: To: BeckW@telekom.de Content-Type: text/plain; charset=ISO-8859-1 Cc: jonathan.rosenberg@skype.net, rtcweb@ietf.org Subject: Re: [rtcweb] SDP Offer/Answer draft-jennings-rtcweb-signaling: Glare handling X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 16:24:29 -0000 2011/10/18 : > > Ekr wrote: >> I'm not sure I agree with this. 2-5 seconds isn't really that long to >> wait for the interval between the caller starting the call and the callee being alerted. > > I consider 2-5 s a quite horrible call setup time, and I can tell that customers really care about it. Of course it's acceptable if such a long setup delay only occurs occasionally. Maybe I'm being unclear: it's not great, but there are plenty of settings (e.g., online game setup) where it's not really that big a deal. My point isn't that I wish to design a system with a lot of delay but merely that (as I think Magnus's message implies) one shouldn't design a system that only works if the signaling does not have even modest amounts of delay. -Ekr From wolfgang.beck01@googlemail.com Tue Oct 18 10:54: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 5710421F8BE9 for ; Tue, 18 Oct 2011 10:54:21 -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 yicZEOQEONFk for ; Tue, 18 Oct 2011 10:54:20 -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 8E4DC21F8BA8 for ; Tue, 18 Oct 2011 10:54:20 -0700 (PDT) Received: by qyk34 with SMTP id 34so2205960qyk.10 for ; Tue, 18 Oct 2011 10:54:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WDyImixOFMtdaOPwq8kig00IcCKGj6EkwNa3MMlDkFo=; b=k0MuV1bnzFrbYusu2NWmXGPSsrqlyAbOa0T093cnmubnK9IzNMK21o74n5hRjVC8VE qtttypBRDRGeAY7najj8/fiUre+Tw7DPfw5nfpft5zW3IEX/Tl+lMTHVE8pnvhog/9mU q647Uy0Ayf64Ja6Ww62PWWjNNJBtIU+bIrk5c= MIME-Version: 1.0 Received: by 10.68.73.73 with SMTP id j9mr6444842pbv.67.1318960459125; Tue, 18 Oct 2011 10:54:19 -0700 (PDT) Received: by 10.68.55.230 with HTTP; Tue, 18 Oct 2011 10:54:18 -0700 (PDT) In-Reply-To: <4E9D667A.2040703@alvestrand.no> References: <4E9D667A.2040703@alvestrand.no> Date: Tue, 18 Oct 2011 19:54:18 +0200 Message-ID: From: Wolfgang Beck To: Harald Alvestrand Content-Type: text/plain; charset=ISO-8859-1 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] My Opinion: Why I think a negotiating protocol is a Good Thing X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 17:54:21 -0000 On Tue, Oct 18, 2011 at 1:43 PM, Harald Alvestrand wrote: > The context of RTCWEB is the well known trapezoid: > > +-----------+ +-----------+ > | Web | | Web | > | | Signalling | | > | |-------------| | > | Server | path | Server | > | | | | > +-----------+ +-----------+ > / \ > / \ Proprietary over > / \ HTTP/Websockets > / \ > / Proprietary over \ > / HTTP/Websockets \ > / \ > +-----------+ +-----------+ > |JS/HTML/CSS| |JS/HTML/CSS| > +-----------+ +-----------+ > +-----------+ +-----------+ > | | | | > | | | | > | Browser | ------------------------- | Browser | > | | Media path | | > | | | | > +-----------+ +-----------+ > > or even the triangle, where the triangle is formed when the two Web severs > on top are collapsed into one. I'll nag you again about my draft where there is only one single web server and one JS client that runs on both browsers. If you can make sure that all parties in a call use the same RTCWEB server and -client, you don't need to standardize a protocol. We startet RCTWEB to overcome the slow innovation pace associated with protocol standardization. If RTCWEB relies on a standardized protocol for its key functionality, we have gained very little. > Another design criterion is that interworking should be possible I'm not convinced that we need this, at least not at the signaling level of RTCWEB clients and servers. Wolfgang Beck From harald@alvestrand.no Tue Oct 18 11:00: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 54FE421F8513 for ; Tue, 18 Oct 2011 11:00:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.566 X-Spam-Level: X-Spam-Status: No, score=-110.566 tagged_above=-999 required=5 tests=[AWL=0.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 Dr3HZR-h4ybT for ; Tue, 18 Oct 2011 11:00:47 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 3556721F8593 for ; Tue, 18 Oct 2011 11:00:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 791571EC026; Tue, 18 Oct 2011 20: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 xDofDaAzdIFn; Tue, 18 Oct 2011 20:00:44 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id C21881EC025; Tue, 18 Oct 2011 20:00:44 +0200 (CEST) Message-ID: <4E9DBECC.6000206@alvestrand.no> Date: Tue, 18 Oct 2011 20:00:44 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: Wolfgang Beck References: <4E9D667A.2040703@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] My Opinion: Why I think a negotiating protocol is a Good Thing X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 18:00:48 -0000 On 10/18/11 19:54, Wolfgang Beck wrote: > On Tue, Oct 18, 2011 at 1:43 PM, Harald Alvestrand wrote: > > >> The context of RTCWEB is the well known trapezoid: >> >> +-----------+ +-----------+ >> | Web | | Web | >> | | Signalling | | >> | |-------------| | >> | Server | path | Server | >> | | | | >> +-----------+ +-----------+ >> / \ >> / \ Proprietary over >> / \ HTTP/Websockets >> / \ >> / Proprietary over \ >> / HTTP/Websockets \ >> / \ >> +-----------+ +-----------+ >> |JS/HTML/CSS| |JS/HTML/CSS| >> +-----------+ +-----------+ >> +-----------+ +-----------+ >> | | | | >> | | | | >> | Browser | ------------------------- | Browser | >> | | Media path | | >> | | | | >> +-----------+ +-----------+ >> >> or even the triangle, where the triangle is formed when the two Web severs >> on top are collapsed into one. > I'll nag you again about my draft where there is only one single web > server and one JS client that runs on both browsers. > If you can make sure that all parties in a call use the same RTCWEB > server and -client, you don't need to standardize a protocol. I disagree with both of your assertions. 1) we have to support both the case of one web server and the case of 2 web servers. 2) when there is only one web server, one of the browsers is Firefox and the other one is Chrome, the JS needs to have a standard means of communication with the browser. This means a standard. I have explained in my long note why I think it makes sense to describe this as a protocol. > We startet RCTWEB to overcome the slow innovation pace associated with > protocol standardization. > If RTCWEB relies on a standardized protocol for its key functionality, > we have gained very little. > >> Another design criterion is that interworking should be possible > I'm not convinced that we need this, at least not at the signaling > level of RTCWEB clients and servers. I agree that we disagree. > > Wolfgang Beck > From pravindran@sonusnet.com Tue Oct 18 11:05: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 41B2C21F8BBB for ; Tue, 18 Oct 2011 11:05:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.818 X-Spam-Level: X-Spam-Status: No, score=-2.818 tagged_above=-999 required=5 tests=[AWL=-0.519, 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 wiJeR8Of5hu3 for ; Tue, 18 Oct 2011 11:05:31 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 0BA6621F8BB7 for ; Tue, 18 Oct 2011 11:05:30 -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 p9II62IW019632; Tue, 18 Oct 2011 14:06:02 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail05.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 18 Oct 2011 14:05:27 -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, 18 Oct 2011 23:35:22 +0530 Message-ID: <2E239D6FCD033C4BAF15F386A979BF511599F3@sonusinmail02.sonusnet.com> In-Reply-To: <8486C8728176924BAF5BDB2F7D7EEDDF3E091D13@ucolhp4d.easf.csd.disa.mil> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] Review request for RTCWeb standard signaling protocol Thread-Index: AQHMjWPJQsg22CmbRQ+ec/AyTlzr85WCFU0AgAAGWYCAAE3QgP//tE4QgABB3qA= References: <2E239D6FCD033C4BAF15F386A979BF510F1367@sonusinmail02.sonusnet.com><4E8AC222.4050308@alvestrand.no><2E239D6FCD033C4BAF15F386A979BF510F14CE@sonusinmail02.sonusnet.com><2E239D6FCD033C4BAF15F386A979BF510F14FD@sonusinmail02.sonusnet.com><393F1888-F834-4DAE-B6B1-1C5D35EE3292@phonefromhere.com><2E239D6FCD033C4BAF15F386A979BF510F152B@sonusinmail02.sonusnet.com><2E239D6FCD033C4BAF15F386A979BF510F1532@sonusinmail02.sonusnet.com><2E239D6FCD033C4BAF15F386A979BF511598EE@sonusinmail02.sonusnet.com><665A16AB-AAD8-42B3-AC17-7E629EA2DE35@phonefromhere.com><2E239D6FCD033C4BAF15F386A979BF5115992E@sonusinmail02.sonusnet.com><2E239D6FCD033C4BAF15F38 6A979B F 51159950@so nusinmail02.sonusnet.com><0950F0E1-6E4B-407F-9563-654AFE79F64B@ag-projects.com><2E239D6FCD033C4BAF15F386A979BF51159994@sonusinmail02.sonusnet.com><1F2A2C70609D9E41844A2126145FC09804004302@HKGMBOXPRD22.polycom.com> <033458F56EC2A64E8D2D7B759FA3E7E703DBF614@sonusmail04.sonusnet.com> <8486C8728176924BAF5BDB2F7D7EEDDF3E091D13@ucolhp4d.easf.csd.disa.mil> From: "Ravindran Parthasarathi" To: "Roy, Radhika R USA CIV (US)" , "Asveren, Tolga" , "Avasarala, Ranjit" , =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= X-OriginalArrivalTime: 18 Oct 2011 18:05:27.0723 (UTC) FILETIME=[84261FB0:01CC8DC0] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Review request for RTCWeb standard 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: Tue, 18 Oct 2011 18:05:32 -0000 Tolga/Radhika, In case I read Ranjit mail correctly, the "simpler" protocol than "SIP = over websocket" is required which does not require to perform signaling = routing functionality like via header, route header handling as two-way = communication between browser to RTCWeb server is established using = websocket. But, It does not mean that media negotiation ("offer/answer") = is not required. I have mentioned this media negotiation requirement for = signaling in Bullet 2 of Sec 5 in draft-partha-rtcweb-signaling-00 draft = as=20 " The mechanism has to provide the way to pass description about the media transmission between two RTCweb clients" Also, the attempt for "standard" signaling protocol is not an attempt to = stop custom-build signaling protocol and Sec 4 of = draft-partha-rtcweb-signaling-00 draft explains this as "The defining signaling protocol is not a hindrance for any innovative RTCWeb signaling protocol development as it is complementary solution." but standard signaling protocol facilities for the quick development of = the generic RTCWeb usecase without the need of developing of new = signaling protocol per website. In case you still feel that my draft = does not reflect this notion, Please let me know. Thanks Partha >-----Original Message----- >From: Roy, Radhika R USA CIV (US) [mailto:radhika.r.roy.civ@mail.mil] >Sent: Tuesday, October 18, 2011 7:19 PM >To: Asveren, Tolga; Avasarala, Ranjit; Ravindran Parthasarathi; Sa=FAl >Ibarra Corretg=E9 >Cc: rtcweb@ietf.org >Subject: RE: [rtcweb] Review request for RTCWeb standard signaling >protocol > >Folks: > >Tolga is right. > >We have a very complex problem to solve. It is called negotiations >between different types of codecs and between different features of = each >codec type. > >Let us see how simple a protocol can be based on these simple >requirements. > >BR/Radhika > >-----Original Message----- >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On = Behalf >Of Asveren, Tolga >Sent: Tuesday, October 18, 2011 9:17 AM >To: Avasarala, Ranjit; Ravindran Parthasarathi; Sa=FAl Ibarra = Corretg=E9 >Cc: rtcweb@ietf.org >Subject: Re: [rtcweb] Review request for RTCWeb standard signaling >protocol > >Yes, something "simple" would be nice but the definition of "simple >enough but still allowing me to do what I want to achieve" is very much >dependent on the needs of each specific use case/service. There is no >universal definition of "simple" here. So, I guess this is yet another >argument in favor of not standardizing the protocol between browser and >webserver so that everybody can design/use whatever is "simple but good >enough" from their perspective. > >Thanks, >Tolga > From ibc@aliax.net Tue Oct 18 11:16: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 5C91321F8ABB for ; Tue, 18 Oct 2011 11:16:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.631 X-Spam-Level: X-Spam-Status: No, score=-2.631 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6UnsAlnNPMPV for ; Tue, 18 Oct 2011 11:16:06 -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 C8C1D21F858C for ; Tue, 18 Oct 2011 11:16:05 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so951468vcb.31 for ; Tue, 18 Oct 2011 11:16:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.35.34 with SMTP id e2mr3713555vdj.52.1318961763497; Tue, 18 Oct 2011 11:16:03 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Tue, 18 Oct 2011 11:16:03 -0700 (PDT) In-Reply-To: <4E9DBECC.6000206@alvestrand.no> References: <4E9D667A.2040703@alvestrand.no> <4E9DBECC.6000206@alvestrand.no> Date: Tue, 18 Oct 2011 20:16:03 +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] My Opinion: Why I think a negotiating protocol is a Good Thing X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 18:16:06 -0000 2011/10/18 Harald Alvestrand : > 2) when there is only one web server, one of the browsers is Firefox and = the > other one is Chrome, the JS needs to have a standard means of communicati= on > with the browser. This means a standard. > I have explained in my long note why I think it makes sense to describe t= his > as a protocol. If that just involves communication between the JS and the browser than IMHO that's an API rather than a protocol. However, if such signaling between JS and the browser (the RTCweb stack) mantains state, then I could agree on naming it "protocol". Anyhow, the point here is: are you advocating for having a default signaling protocol in-the-wire or not? It's a bit unclear from your first mail given the ammount of signaling fragments in the whole RTCweb picture. --=20 I=C3=B1aki Baz Castillo From tasveren@sonusnet.com Tue Oct 18 11:18: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 C9ADC21F8AC9 for ; Tue, 18 Oct 2011 11:18:40 -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 oDJs-iStOZgA for ; Tue, 18 Oct 2011 11:18:40 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id C73A421F8AC3 for ; Tue, 18 Oct 2011 11:18:39 -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 p9IIJBMr028296; Tue, 18 Oct 2011 14:19:11 -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, 18 Oct 2011 14:18:34 -0400 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E703DBF698@sonusmail04.sonusnet.com> In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF511599F3@sonusinmail02.sonusnet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] Review request for RTCWeb standard signaling protocol Thread-Index: AQHMjWPJQsg22CmbRQ+ec/AyTlzr85WCFU0AgAAGWYCAAE3QgP//tE4QgABB3qCAAAffsA== References: <2E239D6FCD033C4BAF15F386A979BF510F1367@sonusinmail02.sonusnet.com><4E8AC222.4050308@alvestrand.no><2E239D6FCD033C4BAF15F386A979BF510F14CE@sonusinmail02.sonusnet.com><2E239D6FCD033C4BAF15F386A979BF510F14FD@sonusinmail02.sonusnet.com><393F1888-F834-4DAE-B6B1-1C5D35EE3292@phonefromhere.com><2E239D6FCD033C4BAF15F386A979BF510F152B@sonusinmail02.sonusnet.com><2E239D6FCD033C4BAF15F386A979BF510F1532@sonusinmail02.sonusnet.com><2E239D6FCD033C4BAF15F386A979BF511598EE@sonusinmail02.sonusnet.com><665A16AB-AAD8-42B3-AC17-7E629EA2DE35@phonefromhere.com><2E239D6FCD033C4BAF15F386A979BF5115992E@sonusinmail02.sonusnet.com><2E239D6FCD033C4BAF15F38 6A979B F 51159950@so nusinmail02.sonusnet.com><0950F0E1-6E4B-407F-9563-654AFE79F64B@ag-projects.com><2E239D6FCD033C4BAF15F386A979BF51159994@sonusinmail02.sonusnet.com><1F2A2C70609D9E41844A2126145FC09804004302@HKGMBOXPRD22.polycom.com> <033458F56EC2A64E8D2D7B759FA3E7E703DBF614@sonusmail04.sonusnet.com> <8486C8728176924BAF5BDB2F7D7EEDDF3E091D13@ucolhp4d.easf.csd.disa.mil> <2E239D6FCD033C4BAF15F386A979BF511599F3@sonusinmail02.sonusnet.com> From: "Asveren, Tolga" To: "Ravindran Parthasarathi" , "Roy, Radhika R USA CIV (US)" , "Avasarala, Ranjit" , =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Review request for RTCWeb standard 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: Tue, 18 Oct 2011 18:18:40 -0000 Just for clarity, my use of the term "simple" in this thread was a bit = rhetorical to indicate that I do not agree with Ranjit's view that a = "simple standard protocol" is needed between browser and webserver. I am even not sure whether full offer/answer semantics need to be = supported between webserver and JS (or better said, whether that needs = to be the only way of doing things). I would think that supporting what = Tim Panton describes in another thread (codec selection done in = webserver) could be nice to achieve -among other models- if possible.=20 Thanks, Tolga > -----Original Message----- > From: Ravindran Parthasarathi > Sent: Tuesday, October 18, 2011 2:05 PM > To: Roy, Radhika R USA CIV (US); Asveren, Tolga; Avasarala, Ranjit; = Sa=FAl > Ibarra Corretg=E9 > Cc: rtcweb@ietf.org > Subject: RE: [rtcweb] Review request for RTCWeb standard signaling > protocol >=20 > Tolga/Radhika, >=20 > In case I read Ranjit mail correctly, the "simpler" protocol than "SIP > over websocket" is required which does not require to perform = signaling > routing functionality like via header, route header handling as = two-way > communication between browser to RTCWeb server is established using > websocket. But, It does not mean that media negotiation = ("offer/answer") > is not required. I have mentioned this media negotiation requirement = for > signaling in Bullet 2 of Sec 5 in draft-partha-rtcweb-signaling-00 = draft > as >=20 > " The mechanism has to provide the way to pass description about = the > media transmission between two RTCweb clients" >=20 > Also, the attempt for "standard" signaling protocol is not an attempt = to > stop custom-build signaling protocol and Sec 4 of draft-partha-rtcweb- > signaling-00 draft explains this as >=20 > "The defining signaling protocol is not a hindrance for any innovative > RTCWeb signaling protocol development as it is complementary > solution." >=20 > but standard signaling protocol facilities for the quick development = of > the generic RTCWeb usecase without the need of developing of new = signaling > protocol per website. In case you still feel that my draft does not > reflect this notion, Please let me know. >=20 >=20 > Thanks > Partha >=20 > >-----Original Message----- > >From: Roy, Radhika R USA CIV (US) [mailto:radhika.r.roy.civ@mail.mil] > >Sent: Tuesday, October 18, 2011 7:19 PM > >To: Asveren, Tolga; Avasarala, Ranjit; Ravindran Parthasarathi; = Sa=FAl > >Ibarra Corretg=E9 > >Cc: rtcweb@ietf.org > >Subject: RE: [rtcweb] Review request for RTCWeb standard signaling > >protocol > > > >Folks: > > > >Tolga is right. > > > >We have a very complex problem to solve. It is called negotiations > >between different types of codecs and between different features of = each > >codec type. > > > >Let us see how simple a protocol can be based on these simple > >requirements. > > > >BR/Radhika > > > >-----Original Message----- > >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On = Behalf > >Of Asveren, Tolga > >Sent: Tuesday, October 18, 2011 9:17 AM > >To: Avasarala, Ranjit; Ravindran Parthasarathi; Sa=FAl Ibarra = Corretg=E9 > >Cc: rtcweb@ietf.org > >Subject: Re: [rtcweb] Review request for RTCWeb standard signaling > >protocol > > > >Yes, something "simple" would be nice but the definition of "simple > >enough but still allowing me to do what I want to achieve" is very = much > >dependent on the needs of each specific use case/service. There is no > >universal definition of "simple" here. So, I guess this is yet = another > >argument in favor of not standardizing the protocol between browser = and > >webserver so that everybody can design/use whatever is "simple but = good > >enough" from their perspective. > > > >Thanks, > >Tolga > > From ibc@aliax.net Tue Oct 18 11:19: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 38D5521F8BA2 for ; Tue, 18 Oct 2011 11:19:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[AWL=0.045, 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 oHgA5xaSwPzI for ; Tue, 18 Oct 2011 11:19: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 9D1B021F8AC3 for ; Tue, 18 Oct 2011 11:19:45 -0700 (PDT) Received: by vws5 with SMTP id 5so774460vws.31 for ; Tue, 18 Oct 2011 11:19:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.73.166 with SMTP id m6mr3805477vdv.18.1318961984684; Tue, 18 Oct 2011 11:19:44 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Tue, 18 Oct 2011 11:19:44 -0700 (PDT) In-Reply-To: <033458F56EC2A64E8D2D7B759FA3E7E703DBF698@sonusmail04.sonusnet.com> References: <2E239D6FCD033C4BAF15F386A979BF510F1367@sonusinmail02.sonusnet.com> <4E8AC222.4050308@alvestrand.no> <2E239D6FCD033C4BAF15F386A979BF510F14CE@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF510F14FD@sonusinmail02.sonusnet.com> <393F1888-F834-4DAE-B6B1-1C5D35EE3292@phonefromhere.com> <2E239D6FCD033C4BAF15F386A979BF510F152B@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF510F1532@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF511598EE@sonusinmail02.sonusnet.com> <665A16AB-AAD8-42B3-AC17-7E629EA2DE35@phonefromhere.com> <2E239D6FCD033C4BAF15F386A979BF5115992E@sonusinmail02.sonusnet.com> <0950F0E1-6E4B-407F-9563-654AFE79F64B@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF51159994@sonusinmail02.sonusnet.com> <1F2A2C70609D9E41844A2126145FC09804004302@HKGMBOXPRD22.polycom.com> <033458F56EC2A64E8D2D7B759FA3E7E703DBF614@sonusmail04.sonusnet.com> <8486C8728176924BAF5BDB2F7D7EEDDF3E091D13@ucolhp4d.easf.csd.disa.mil> <2E239D6FCD033C4BAF15F386A979BF511599F3@sonusinmail02.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E703DBF698@sonusmail04.sonusnet.com> Date: Tue, 18 Oct 2011 20:19:44 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: "Asveren, Tolga" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Review request for RTCWeb standard 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: Tue, 18 Oct 2011 18:19:46 -0000 2011/10/18 Asveren, Tolga : > I would think that supporting what Tim Panton describes in another thread= (codec selection done in webserver) could be nice to achieve -among other = models- if possible. I hope the intelligence is NOT required to be in the web server. --=20 I=C3=B1aki Baz Castillo From tasveren@sonusnet.com Tue Oct 18 11: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 AFB1321F8BBB for ; Tue, 18 Oct 2011 11:28:50 -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 qM-pwFUn5Fjn for ; Tue, 18 Oct 2011 11:28:50 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id EDFAF21F8BBA for ; Tue, 18 Oct 2011 11:28: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 p9IITF8D002448; Tue, 18 Oct 2011 14:29: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: Tue, 18 Oct 2011 14:28:32 -0400 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E703DBF6A5@sonusmail04.sonusnet.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] Review request for RTCWeb standard signaling protocol Thread-Index: AcyNwoSExd405w78RDClJKPsqwaUtAAAJ+ew References: <2E239D6FCD033C4BAF15F386A979BF510F1367@sonusinmail02.sonusnet.com><4E8AC222.4050308@alvestrand.no><2E239D6FCD033C4BAF15F386A979BF510F14CE@sonusinmail02.sonusnet.com><2E239D6FCD033C4BAF15F386A979BF510F14FD@sonusinmail02.sonusnet.com><393F1888-F834-4DAE-B6B1-1C5D35EE3292@phonefromhere.com><2E239D6FCD033C4BAF15F386A979BF510F152B@sonusinmail02.sonusnet.com><2E239D6FCD033C4BAF15F386A979BF510F1532@sonusinmail02.sonusnet.com><2E239D6FCD033C4BAF15F386A979BF511598EE@sonusinmail02.sonusnet.com><665A16AB-AAD8-42B3-AC17-7E629EA2DE35@phonefromhere.com><2E239D6FCD033C4BAF15F386A979BF5115992E@sonusinmail02.sonusnet.com><0950F0E1-6E4B-407F-9563- 654AFE79 F64B@ag-proj ects.com><2E239D6FCD033C4BAF15F386A979BF51159994@sonusinmail02.sonusnet.com><1F2A2C70609D9E41844A2126145FC09804004302@HKGMBOXPRD22.polycom.com><033458F56EC2A64E8D2D7B759FA3E7E703DBF614@sonusmail04.sonusnet.com><8486C8728176924BAF5BDB2F7D7EEDDF3E091D13@ucolhp4d.easf.csd.disa.mil><2E239D6FCD033C4BAF15F386A979BF511599F3@sonusinmail02.sonusnet.com><033458F56EC2A64E8D2D7B759FA3E7E703DBF698@sonusmail04.sonusnet.com> From: "Asveren, Tolga" To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Review request for RTCWeb standard 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: Tue, 18 Oct 2011 18:28:50 -0000 Yes, not required, but possible -if we can achieve that level of = flexibility-. Overall, there are two models here: i- Webbrowser/JS as signaling/media entity ii- Webbrowser/JS as a media entity controlled by webserver It seems focus is on i- but I heard a few people mentioning about ii- = and no direct rejection yet. Supporting both models would require a = careful design of RTCWeb stack/JS interface so that it is flexible = enough but also can be used easily for simple variations of each model. Thanks, Tolga > -----Original Message----- > From: I=F1aki Baz Castillo [mailto:ibc@aliax.net] > Sent: Tuesday, October 18, 2011 2:20 PM > To: Asveren, Tolga > Cc: Ravindran Parthasarathi; Roy, Radhika R USA CIV (US); Avasarala, > Ranjit; Sa=FAl Ibarra Corretg=E9; rtcweb@ietf.org > Subject: Re: [rtcweb] Review request for RTCWeb standard signaling > protocol >=20 > 2011/10/18 Asveren, Tolga : > > I would think that supporting what Tim Panton describes in another > thread (codec selection done in webserver) could be nice to achieve = -among > other models- if possible. >=20 > I hope the intelligence is NOT required to be in the web server. >=20 > -- > I=F1aki Baz Castillo > From harald@alvestrand.no Tue Oct 18 11:29: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 1BD2821F8BDB for ; Tue, 18 Oct 2011 11:29:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.419 X-Spam-Level: X-Spam-Status: No, score=-110.419 tagged_above=-999 required=5 tests=[AWL=-0.120, 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 yN83RSv6QOwS for ; Tue, 18 Oct 2011 11:29:20 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 70D0621F8BBA for ; Tue, 18 Oct 2011 11:29:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B842A39E151; Tue, 18 Oct 2011 20:29:19 +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 KT+IMS3JInwT; Tue, 18 Oct 2011 20:29:18 +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 841CE39E082; Tue, 18 Oct 2011 20:29:18 +0200 (CEST) Message-ID: <4E9DC57E.3070102@alvestrand.no> Date: Tue, 18 Oct 2011 20:29:18 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= References: <4E9D667A.2040703@alvestrand.no> <4E9DBECC.6000206@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] My Opinion: Why I think a negotiating protocol is a Good Thing X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 18:29:21 -0000 On 10/18/11 20:16, Iñaki Baz Castillo wrote: > 2011/10/18 Harald Alvestrand: >> 2) when there is only one web server, one of the browsers is Firefox and the >> other one is Chrome, the JS needs to have a standard means of communication >> with the browser. This means a standard. >> I have explained in my long note why I think it makes sense to describe this >> as a protocol. > If that just involves communication between the JS and the browser > than IMHO that's an API rather than a protocol. > However, if such signaling between JS and the browser (the RTCweb > stack) mantains state, then I could agree on naming it "protocol". ROAP does. > Anyhow, the point here is: are you advocating for having a default > signaling protocol in-the-wire or not? It's a bit unclear from your > first mail given the ammount of signaling fragments in the whole > RTCweb picture. > I'm advocating a single protocol between the Javascript and the Web browser. It's a viable option for some applications to run that protocol from one browser to the other browser over a mechanism of their choice; many applications will make other choices, including those who choose to implement SIP in Javascript. From wolfgang.beck01@googlemail.com Tue Oct 18 11:29: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 3A58B21F8BBB for ; Tue, 18 Oct 2011 11:29:45 -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 3VZcIkSdGqog for ; Tue, 18 Oct 2011 11:29: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 3493E21F8BBA for ; Tue, 18 Oct 2011 11:29:44 -0700 (PDT) Received: by yxj19 with SMTP id 19so1076372yxj.31 for ; Tue, 18 Oct 2011 11:29:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wwPlXTV7l4I+DIYHdJoe8NZhwEhVDsWVr0nLlcUa+Bk=; b=YBkpFblJlb2hc4ZhvHKmXJRarezGAklk26ySy0uIIu5uit5LQVjpO0GJO2jMKzhXZG oBOokluiJZDJ4Xvb5nljNWsjd7Zv2bX89D2VLpNEgKU4VqB7Fr1P+Bzo5NeML/9wUqdO Ml7wOuhglve3WdJ5JYHH1FvpNjmSfK+NiyAjs= MIME-Version: 1.0 Received: by 10.68.20.41 with SMTP id k9mr6656089pbe.90.1318962582175; Tue, 18 Oct 2011 11:29:42 -0700 (PDT) Received: by 10.68.55.230 with HTTP; Tue, 18 Oct 2011 11:29:42 -0700 (PDT) In-Reply-To: <4E9DBECC.6000206@alvestrand.no> References: <4E9D667A.2040703@alvestrand.no> <4E9DBECC.6000206@alvestrand.no> Date: Tue, 18 Oct 2011 20:29:42 +0200 Message-ID: From: Wolfgang Beck To: Harald Alvestrand Content-Type: text/plain; charset=ISO-8859-1 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] My Opinion: Why I think a negotiating protocol is a Good Thing X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 18:29:45 -0000 > 1) we have to support both the case of one web server and the case of 2 web > servers. > If we look at SIP, the trapezoid model hasn't been too sucessful. Depressingly few SIP providers do interconnection, after all those years. Instead, even simple SIP clients support more than one SIP account so people can reach their contact on different SIP providers. > 2) when there is only one web server, one of the browsers is Firefox and the > other one is Chrome, the JS needs to have a standard means of communication > with the browser. This means a standard. The chat function of stackexchange.com has Firefox and Chrome users. I'm not aware of any standardized signalling protocol to exchange the capabilities between the browsers. Instead the JS chat client queries the browser's capabilities locally and sends them in a non-standard format to the web server. Wolfgang Beck From ibc@aliax.net Tue Oct 18 11:34: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 5290921F8C90 for ; Tue, 18 Oct 2011 11:34:56 -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.044, 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 CQyIydK+0J1A for ; Tue, 18 Oct 2011 11:34:55 -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 ADDFD21F8C8E for ; Tue, 18 Oct 2011 11:34:55 -0700 (PDT) Received: by vws5 with SMTP id 5so792261vws.31 for ; Tue, 18 Oct 2011 11:34:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.73.166 with SMTP id m6mr3859756vdv.18.1318962894979; Tue, 18 Oct 2011 11:34:54 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Tue, 18 Oct 2011 11:34:54 -0700 (PDT) In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF511599F3@sonusinmail02.sonusnet.com> References: <2E239D6FCD033C4BAF15F386A979BF510F1367@sonusinmail02.sonusnet.com> <4E8AC222.4050308@alvestrand.no> <2E239D6FCD033C4BAF15F386A979BF510F14CE@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF510F14FD@sonusinmail02.sonusnet.com> <393F1888-F834-4DAE-B6B1-1C5D35EE3292@phonefromhere.com> <2E239D6FCD033C4BAF15F386A979BF510F152B@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF510F1532@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF511598EE@sonusinmail02.sonusnet.com> <665A16AB-AAD8-42B3-AC17-7E629EA2DE35@phonefromhere.com> <2E239D6FCD033C4BAF15F386A979BF5115992E@sonusinmail02.sonusnet.com> <0950F0E1-6E4B-407F-9563-654AFE79F64B@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF51159994@sonusinmail02.sonusnet.com> <1F2A2C70609D9E41844A2126145FC09804004302@HKGMBOXPRD22.polycom.com> <033458F56EC2A64E8D2D7B759FA3E7E703DBF614@sonusmail04.sonusnet.com> <8486C8728176924BAF5BDB2F7D7EEDDF3E091D13@ucolhp4d.easf.csd.disa.mil> <2E239D6FCD033C4BAF15F386A979BF511599F3@sonusinmail02.sonusnet.com> Date: Tue, 18 Oct 2011 20:34:54 +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] Review request for RTCWeb standard 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: Tue, 18 Oct 2011 18:34:56 -0000 2011/10/18 Ravindran Parthasarathi : > Also, the attempt for "standard" signaling protocol is not an attempt to = stop custom-build signaling protocol and Sec 4 of draft-partha-rtcweb-signa= ling-00 draft explains this as > > "The defining signaling protocol is not a hindrance for any innovative > =C2=A0 RTCWeb signaling protocol development as it is complementary > =C2=A0 solution." > > but standard signaling protocol facilities for the quick development of t= he generic RTCWeb usecase without the need of developing of new signaling p= rotocol per website. In case you still feel that my draft does not reflect = this notion, Please let me know. When RTCweb becomes a reality there will appear thousands of JavaScript libraries implementing different RTCweb signaling protocols, each one with its own features and capabilities. Do you understand that a website admin will be able to choose the one he prefers? Visit 100 random cool websites. Probably 50% of them use JQuery JS library. Does it mean that each web developer had to build his own JS library? not at all, they use JQuery. Now your reply will be "downloading the JS library everytime is not efficient". Ok, visit 100 random cool websites. Probably 50% of them use JQuery JS library. How many times have you downloaded the JQuery library (assuming that every site has its own copy of the .js)? ... 50 times. Is that a problem? not for the rest of the humans in the world. So please stop making up issues that don't exist. The WWW world does not work as you propose, and anyhow it has succeeded. --=20 I=C3=B1aki Baz Castillo From fluffy@cisco.com Tue Oct 18 11:40: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 01D2B21F85A8 for ; Tue, 18 Oct 2011 11:40:51 -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 D+10HFnLuDDU for ; Tue, 18 Oct 2011 11:40:50 -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 DF1E121F8573 for ; Tue, 18 Oct 2011 11:40:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=7644; q=dns/txt; s=iport; t=1318963249; x=1320172849; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=RjajiCUO0T8ncVKNtrW6u7LZlD8Tp+ecvUA1qYvZUyM=; b=kv9fFj3u5yJLL5GN32OyDy297D1jZLqYG+G2BKVCvENQvEBJsRp/wfCu L7OZc0KmfspoDDIAg4QeFIFcqZnLLClFqNYKSszb4F4WU7hQ4uj3rRyBs JV71gllllboIfKwIDMgiApdrXH9WJoxapMlUzpeuE19lShlumYoeg+zBi 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAL7HnU6rRDoH/2dsb2JhbABEqG6BBYFuAQEBAwEMBgFmBQkCCz8HGysRBhMbBAOHXpgBAZ5gAoc4YQSIAot7kXY X-IronPort-AV: E=Sophos;i="4.69,366,1315180800"; d="scan'208";a="8659539" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 18 Oct 2011 18:40:49 +0000 Received: from dhcp-171-70-217-213.cisco.com (dhcp-171-70-217-213.cisco.com [171.70.217.213]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p9IIemxa027916; Tue, 18 Oct 2011 18:40:48 GMT Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=windows-1252 From: Cullen Jennings In-Reply-To: <4E9D8D82.707@ericsson.com> Date: Tue, 18 Oct 2011 11:40:47 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8A0B9A1A-6877-4B60-87E4-2F5BEE09F3E0@cisco.com> References: <15B0E3AD-3086-499A-8E79-7AE58B3376C4@cisco.com> <4E9D8D82.707@ericsson.com> To: Magnus Westerlund X-Mailer: Apple Mail (2.1251.1) Cc: Jonathan Rosenberg , rtcweb@ietf.org Subject: Re: [rtcweb] SDP Offer/Answer draft-jennings-rtcweb-signaling: Glare handling X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 18:40:51 -0000 I'm going to slowly reply to a bunch of these comments in backwards = order =85=20 But main thing on how to handle glare =85 I would love to see something = better but I don't want to describe it in this draft so we just pointed = at what we had. If we can come up with a better way I'd like to have = ROAP point at the draft that describes how to do with for things that = use SDP offer / answer.=20 End summary is however we decide to handle glare, I think we can fit = that into ROAP but as we did not really have have a scheme written down = yet, we just reused the existing stuff for now. Glad to update as we = sort out what we need to do.=20 On Oct 18, 2011, at 7:30 , Magnus Westerlund wrote: > Cullen, >=20 > I would like to bring back my proposal for glare handling and propose > that it be included in ROAP. The reason is that I don't think the SIP > time based solution interact well with RTCWEB requirements at all. >=20 > The biggest issue is that one is likely to end up in glare condition > again due to that the transport of the ROAP messages between > end-points/Gateways can have properties that erases the randomization = of > the timer. >=20 > For example an JS application that uses short polling for retrieving = any > incomming ROAP messages, as that is timer based and done lets say = every > 5 seconds, then the polling is clearly done on a longer time scales, > many times longer than what the random glare resolution happens at. = Thus > timer based solutions for resolving glare is use-less in RTCWEB = context > where we don't know how timely the transport is. >=20 > Thus I would propose that the following mechanism is include in ROAP. > When generating an offer a 32-bit unsigned random integer value is > generated (GlareResolution) and attached to the ROAP message. The = random > value may not be 0 and MAX_uint32. So I like this types of scheme, but it seems if we put the random number = in the SDP would allow this work for things beyond just RTCWeb. >=20 > What ever mechanism that inspects the message and is on the path of = the > ROAP message and sees a second offer in the opposite direction when = one > offer is outstanding in either direction can detect a glare. If the > glare condition is detected the two offer's GlareResolution values are > compared. The offer with the greater value wins. The other is = discarded. > As long as the winning offer is forwarded all the way to the offerer = we > can be certain that one signaling message wins. >=20 > In the case the two values are equal, both are discarded, but a error > message must be returned for both messages to cause the end-points to > generate new resolution values. >=20 > When interacting with a SIP gateway, the SIP gateway that create a = ROAP > message can chose how to generate the tie-breaker. Either it can pick > MAX_uint32 to ensure that the message from the SIP side always wins, = or > it can select to always loose using 0 or have a random value be sent. > Which is the right depends on where the glare occurs. But unless a = glare > condition already have been detected, a random value is used. >=20 > This mechanism could also be retrofitted into SIP by adding either a = SIP > header or a attribute in the SDP. That is what is referred as Cullen's > proposal below. >=20 > Secondly the glare condition will be detected in various cases = depending > on in what state of signaling the glare occurs. >=20 > 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. >=20 > 2) IF A sends an offer that has passed the GW, while B's are on its = way > between B and the GW. >=20 > 3) Both A and Bs Offers are at the GW while neither has been = forwarded. >=20 > 4) Like 2) but B supports Cullen's behavior. >=20 >=20 > 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. >=20 > Assuming the GW sent a random value: >=20 > 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. >=20 > 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 SIP 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. >=20 > 2) IF A sends an offer that has passed the GW, while B's are on its = way > between B and the GW. >=20 > 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. >=20 > 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. >=20 > 3) Both A and Bs Offers are at the GW while neither has been = forwarded. >=20 > 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. >=20 > 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. >=20 > 4) Like 2) but B supports Cullen's behavior. >=20 > 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. >=20 >=20 > 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. >=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 From fluffy@cisco.com Tue Oct 18 11:41: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 9B43F21F8BDC for ; Tue, 18 Oct 2011 11:41:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.449 X-Spam-Level: X-Spam-Status: No, score=-106.449 tagged_above=-999 required=5 tests=[AWL=-0.150, 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 9pQm5sUyIyWQ for ; Tue, 18 Oct 2011 11:41:17 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 1829D21F8BDB for ; Tue, 18 Oct 2011 11:41:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=2547; q=dns/txt; s=iport; t=1318963277; x=1320172877; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=n+v2pMwdCOGgBjKwfNV8cgs0ED1fg12C89r1x3ZcULQ=; b=hbyXlpUzc6FXw0fHPOSRyir04WfMBdNW796ydiHq3qQHtEXDBTyzc8EE A18g9vQFaPX9Vz4p25qlGXfcVCIwwvSGFeqtIhhEvkfxPjlES70xsmjeB cVIqz+XbKa5dgskYrVuASMRBEVzBkgGfLFQ1Ob2EEKQS/AF4dMn/BUKgN o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAHHHnU6rRDoH/2dsb2JhbABEqG6BBYFuAQEBAgEBEgFhBQULOBlXBhMih14Il3kBnmCEf4I7YQSIAot7kXY X-IronPort-AV: E=Sophos;i="4.69,366,1315180800"; d="scan'208";a="8641431" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 18 Oct 2011 18:41:16 +0000 Received: from dhcp-171-70-217-213.cisco.com (dhcp-171-70-217-213.cisco.com [171.70.217.213]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p9IIemxb027916; Tue, 18 Oct 2011 18:41:16 GMT Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Cullen Jennings In-Reply-To: Date: Tue, 18 Oct 2011 11:41:15 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <15B0E3AD-3086-499A-8E79-7AE58B3376C4@cisco.com> To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= X-Mailer: Apple Mail (2.1251.1) Cc: Jonathan Rosenberg , rtcweb@ietf.org, public-webrtc@w3.org Subject: [rtcweb] =?windows-1252?q?Why_SDP_answer_needs_and_ack_=85_was_Re?= =?windows-1252?q?=3A__SDP_Offer/Answer_draft-jennings-rtcweb-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: Tue, 18 Oct 2011 18:41:17 -0000 Hi - glad to hear you see this going the right direction. On the topic = of why we have an OK, let me provide a bit of the motivation.=20 When one side sends and answer that says it wants to receive VP8 instead = of H.264, it's probably useful to know when the other side got that = information. This might impact the timing of when o send things or user = interface that provides feedback about the status of the other side. We = are also dealing with a web transaction model where transaction are not = guarantee to happen even if they are sent over TCP. So you need to get = back a response to request. It also helps with mapping to SIP but even = if you were not mapping to another protocol, I suspect you would still = need to be able to have an confirmation than and answer was received.=20 On Oct 15, 2011, at 2:20 , I=F1aki Baz Castillo wrote: > 2011/10/15 Cullen Jennings : >> Jonathan and I submitted a new draft on setting up media based on the = SDP Offer/Answer model. The ASCII flows are a bit hard to read so until = I update them, I recommend reading the PDF version at >>=20 >> http://tools.ietf.org/pdf/draft-jennings-rtcweb-signaling-00.pdf >>=20 >> Clearly the draft is an early stage but we plan to revise it before = the deadline for the IETF 82. Love to get input - particularly on if = this looks like generally the right direction to go. >=20 >=20 > Hi, thanks for this work. IMHO this is clearly the way to go, and the > proposal that could make everyone happy. Let me just a comment: >=20 >=20 > ----------------------------- > 5.3.3. OK > The OK message is used by the receiver of an ANSWER message to > indicate that it has received the ANSWER message. It has no contents > itself and is merely used to stop the retransmissions of the ANSWER > ----------------------------- >=20 > I wonder how much needed is the OK message taking into account that > the transport will always be reliable. So, instead of retransmiting > the ANSWER until an OK arrives, why not retransmit the OFFER until an > ANSWER arrives and drop the OK message from the spec? >=20 > Probably I miss something here as in the case the offered wants to > signal ringing (a 180 in SIP) it conveys no media so there would be no > ANSWER message for long time until the offered human user decides to > accept or reject the incoming call. If so, please forget this comment > :) >=20 >=20 >=20 >=20 >=20 >=20 > 2) >=20 > --=20 > I=F1aki Baz Castillo > From fluffy@cisco.com Tue Oct 18 11:41: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 2FFD021F8B32 for ; Tue, 18 Oct 2011 11:41:55 -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 qxTVOzVtDj61 for ; Tue, 18 Oct 2011 11:41:54 -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 5F5D821F85A8 for ; Tue, 18 Oct 2011 11:41:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=2559; q=dns/txt; s=iport; t=1318963314; x=1320172914; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=s3NiElx7qhxisya0PZbyviapxm9IAZIzRVdNmxDlaYM=; b=aJwVyljPcC0fL5onK6S9pVYXYNPGfSf23zyVQ1gqG6kHA2tRFnDC8ue8 QYCXACeXHtcbtMtsezzB1o+IAu0HlT0IH0K55XsRdShdVcUO0CLMfm6t+ LL7jrXXUVbBFcCrU+2wrkD4j+sOmZydW2uPvn/PmkjmY3EkMg81k1XN36 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArQAAL7HnU6rRDoH/2dsb2JhbABEmT6PMIEFgW4BAQECAQEBAQEPASc0BgUFBwQLDgMEAQEoBycfCQgGEyKHXgiXeQGeYIc6YQSIAot7kXY X-IronPort-AV: E=Sophos;i="4.69,366,1315180800"; d="scan'208";a="8659868" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 18 Oct 2011 18:41:54 +0000 Received: from dhcp-171-70-217-213.cisco.com (dhcp-171-70-217-213.cisco.com [171.70.217.213]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p9IIemxc027916; Tue, 18 Oct 2011 18:41:54 GMT Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF51159957@sonusinmail02.sonusnet.com> Date: Tue, 18 Oct 2011 11:41:52 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <01441535-7FF6-4C88-AA28-53B5CB68374F@cisco.com> References: <15B0E3AD-3086-499A-8E79-7AE58B3376C4@cisco.com> <2E239D6FCD033C4BAF15F386A979BF51159957@sonusinmail02.sonusnet.com> To: Ravindran Parthasarathi X-Mailer: Apple Mail (2.1251.1) Cc: Jonathan Rosenberg , rtcweb@ietf.org, public-webrtc@w3.org Subject: Re: [rtcweb] SDP Offer/Answer draft-jennings-rtcweb-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: Tue, 18 Oct 2011 18:41:55 -0000 So I might have messed up the draft a bit. I'm fine with things can be = implemented as dialog statefull, what I want is that it is possible to = make a signaling gateway that is only transaction statefull. I'm fine if = some signaling gateways are built as dialog statefull. (As a side note, some B2BUA are effectively transaction statefull but = that is pretty rare ) On Oct 17, 2011, at 15:28 , Ravindran Parthasarathi wrote: > Cullen/Joanthan, >=20 > I like your proposed idea as it is going in the direction of having > "standard" signaling protocol for RTCWeb. I'm seeing your proposal as > SDP offer/answer over websocket and the proposal helps to easy gateway > development between RTCWeb server and legacy signaling protocols. >=20 > I have fundamental question in the proposal as it proposes RTCWeb = server > as SIP proxy equivalent and in reality, unfortunately most of the SIP > deployment work is based on B2BUA. The question is whether RTCWeb = server > shall be dialog-state or MUST be transaction-stateful only.=20 >=20 > Also, session-id in the draft is used to uniquely understand the = offerer > and answerer in the transaction or session. In case it is session, how > to indicate the termination of the session. >=20 My personal opinion is that to be able to clean up all the state in a = clean an easy way, we should add some message to indicate the SDP offer = / answer state and related media streams can be discarded. I'd like to = add that to the next version.=20 > Thanks > Partha >=20 >> -----Original Message----- >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf >> Of Cullen Jennings >> Sent: Saturday, October 15, 2011 8:39 AM >> To: rtcweb@ietf.org; public-webrtc@w3.org >> Cc: Jonathan Rosenberg >> Subject: [rtcweb] SDP Offer/Answer draft-jennings-rtcweb-signaling >>=20 >>=20 >> Jonathan and I submitted a new draft on setting up media based on the >> SDP Offer/Answer model. The ASCII flows are a bit hard to read so = until >> I update them, I recommend reading the PDF version at >>=20 >> http://tools.ietf.org/pdf/draft-jennings-rtcweb-signaling-00.pdf >>=20 >> Clearly the draft is an early stage but we plan to revise it before = the >> deadline for the IETF 82. Love to get input - particularly on if this >> looks like generally the right direction to go. >>=20 >>=20 >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb From fluffy@cisco.com Tue Oct 18 11:42: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 478E621F8C9C for ; Tue, 18 Oct 2011 11:42:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.549 X-Spam-Level: X-Spam-Status: No, score=-106.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 jLr0-xXt9pkx for ; Tue, 18 Oct 2011 11:42:09 -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 D313B21F8AF5 for ; Tue, 18 Oct 2011 11:42:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=1946; q=dns/txt; s=iport; t=1318963329; x=1320172929; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=0jT+PS6w8G/glJ74yqdhDGqB1erAcX8zIFShTndbbgM=; b=AZJH6MPzHShlLog5O6ubCOzejXXG2777PMT1ZpdFKKcOOx1xw+aV3m9V 1EhlTeDcn54355lKCG61Qr20RKxb3imgC5dzAFwqCLfSrmnPn3ijNSX+z PDR4wvtUc5FMT3cRL03UT0UWO44cvlRbxG7EAZVcdra9VVMIoTbQPNmmR 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAHHHnU6rRDoH/2dsb2JhbABEqG6BBYFuAQEBAgEBAQEBDwFbBgUFCyMuJzAGEyKHXgiXeQGeYIc6YQSIAot7kXY X-IronPort-AV: E=Sophos;i="4.69,366,1315180800"; d="scan'208";a="8641705" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 18 Oct 2011 18:42:04 +0000 Received: from dhcp-171-70-217-213.cisco.com (dhcp-171-70-217-213.cisco.com [171.70.217.213]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p9IIemxd027916; Tue, 18 Oct 2011 18:42:04 GMT Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Cullen Jennings In-Reply-To: Date: Tue, 18 Oct 2011 11:42:02 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5D0FFCB8-8059-4C54-843B-46F1EC720B10@cisco.com> References: <15B0E3AD-3086-499A-8E79-7AE58B3376C4@cisco.com> To: Roman Shpount X-Mailer: Apple Mail (2.1251.1) Cc: Jonathan Rosenberg , rtcweb@ietf.org, public-webrtc@w3.org Subject: [rtcweb] Forking -Re: SDP Offer/Answer draft-jennings-rtcweb-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: Tue, 18 Oct 2011 18:42:10 -0000 On Oct 17, 2011, at 17:58 , Roman Shpount wrote: > Cullen, >=20 > Did we decide to explicitly not support forking which generates = multiple final answers? If this is not the case, how is this supposed to = be implemented using your model? I think that it is critical that we support what is needed to make a = call that goes to 1-800-go-fedex work. So=20 consider the following use case: A browser calls through a signaling GW = to a sip that forks the call to an SIP to PSTN gateway and also to a = voicemail server. The PSTN gateway generates an 180 with ringback tone = but the SIP call is eventually answered by the voicemail server that = sends a 200.=20 =20 So 3264 supports forking by an single offer may result in say two = answers. In the case above, an single offer resulted in two different = answers. Roap would support this type of transaction by allowing two = answers to be received. There are two ways this can happen - one is with = different answererSessionId in the the answers. Another is the use of = the More-coming flag. We think with these, one can support the range of = what 3264 allows for offer/ answer.=20 > _____________ > Roman Shpount >=20 >=20 > On Fri, Oct 14, 2011 at 11:09 PM, Cullen Jennings = wrote: >=20 > Jonathan and I submitted a new draft on setting up media based on the = SDP Offer/Answer model. The ASCII flows are a bit hard to read so until = I update them, I recommend reading the PDF version at >=20 > http://tools.ietf.org/pdf/draft-jennings-rtcweb-signaling-00.pdf >=20 > Clearly the draft is an early stage but we plan to revise it before = the deadline for the IETF 82. Love to get input - particularly on if = this looks like generally the right direction to go. >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 From fluffy@cisco.com Tue Oct 18 11:42: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 24BBC21F8C9C for ; Tue, 18 Oct 2011 11:42:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.412 X-Spam-Level: X-Spam-Status: No, score=-106.412 tagged_above=-999 required=5 tests=[AWL=-0.112, 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 JSdP4qGAZR5K for ; Tue, 18 Oct 2011 11:42:10 -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 B966021F8AF5 for ; Tue, 18 Oct 2011 11:42:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=800; q=dns/txt; s=iport; t=1318963330; x=1320172930; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=jvyG4+ug3AMU3HCFHJ1WBFdwZetgDe2km0rehn0fIPQ=; b=K1AYpGITP/h2Im1TvJzkfk0jSyh5pqjyzhHqpxhbxfAcvqUYgThy+udJ ggxoG78Jh6BxTnsCdMIZqjA75mGcOokMPq1IbW2fT/OkLwlsRp4X0X9G5 jbISEUfAPSfJzfFkuk8CbVljuxyWNUK+mQMrYe06rDeUocR/4ZhHK6e0R I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAHHHnU6rRDoH/2dsb2JhbABEqG6BBYFuAQEBAwESAWYFCwtGVwYTIodemAEBnmCHOmEEiAKLe5F2 X-IronPort-AV: E=Sophos;i="4.69,366,1315180800"; d="scan'208";a="8674343" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 18 Oct 2011 18:42:10 +0000 Received: from dhcp-171-70-217-213.cisco.com (dhcp-171-70-217-213.cisco.com [171.70.217.213]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p9IIemxe027916; Tue, 18 Oct 2011 18:42:10 GMT Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Cullen Jennings In-Reply-To: Date: Tue, 18 Oct 2011 11:42:08 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <44B1D328-3875-4E82-9338-AB223E09BB8A@cisco.com> References: <15B0E3AD-3086-499A-8E79-7AE58B3376C4@cisco.com> <4E9D8D82.707@ericsson.com> To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= X-Mailer: Apple Mail (2.1251.1) Cc: Jonathan Rosenberg , rtcweb@ietf.org Subject: Re: [rtcweb] SDP Offer/Answer draft-jennings-rtcweb-signaling: Glare handling X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 18:42:11 -0000 People mean different things by realtime but when talking about it, I = think it is important to keep in mind it is mostly the media that needs = to be realtime and perhaps the signaling to set up such media is not as = does not have the same level of constraints.=20 On Oct 18, 2011, at 8:40 , I=F1aki Baz Castillo wrote: > 2011/10/18 Magnus Westerlund : >> For example an JS application that uses short polling for retrieving = any >> incomming ROAP messages, as that is timer based and done lets say = every >> 5 seconds >=20 > Hi. This is RTC, so *realtime* is required for media sessions. I > expect that people should assume WebSocket usage rather than HTTP > polling. >=20 >=20 >=20 > --=20 > I=F1aki Baz Castillo > From ibc@aliax.net Tue Oct 18 11:43: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 AD84321F8CA4 for ; Tue, 18 Oct 2011 11:43:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.634 X-Spam-Level: X-Spam-Status: No, score=-2.634 tagged_above=-999 required=5 tests=[AWL=0.043, 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 tyPRzvjNKvf9 for ; Tue, 18 Oct 2011 11:43:35 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1F6BA21F8B53 for ; Tue, 18 Oct 2011 11:43:35 -0700 (PDT) Received: by vws5 with SMTP id 5so800651vws.31 for ; Tue, 18 Oct 2011 11:43:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.184.103 with SMTP id et7mr3895014vdc.35.1318963414421; Tue, 18 Oct 2011 11:43:34 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Tue, 18 Oct 2011 11:43:34 -0700 (PDT) In-Reply-To: <4E9DC57E.3070102@alvestrand.no> References: <4E9D667A.2040703@alvestrand.no> <4E9DBECC.6000206@alvestrand.no> <4E9DC57E.3070102@alvestrand.no> Date: Tue, 18 Oct 2011 20:43:34 +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] My Opinion: Why I think a negotiating protocol is a Good Thing X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 18:43:35 -0000 2011/10/18 Harald Alvestrand : >> Anyhow, the point here is: are you advocating for having a default >> signaling protocol in-the-wire or not? It's a bit unclear from your >> first mail given the ammount of signaling fragments in the whole >> RTCweb picture. >> > I'm advocating a single protocol between the Javascript and the Web brows= er. Well, so instead of managing a simple JS API you mean a JS API with memory and state, so let's call it "protocol". Then I strongly think that what you suggest is the same as ROAP. And I do agree with such proposal. > It's a viable option for some applications to run that protocol from one > browser to the other browser over a mechanism of their choice; many > applications will make other choices, including those who choose to > implement SIP in Javascript. There is a risk here. If the specs and the API are based on that signaling protocol, maybe they just fullfit the requirements of that protocol and forget other possible solutions. Just wondering. But there will be people ensuring that does not happen ;) --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Tue Oct 18 11:47: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 1B8AE21F86C1 for ; Tue, 18 Oct 2011 11:47:52 -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 ENTtAXDeV72D for ; Tue, 18 Oct 2011 11:47:51 -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 828C821F8BDE for ; Tue, 18 Oct 2011 11:47:51 -0700 (PDT) Received: by vws5 with SMTP id 5so805323vws.31 for ; Tue, 18 Oct 2011 11:47:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.184.103 with SMTP id et7mr3909630vdc.35.1318963665957; Tue, 18 Oct 2011 11:47:45 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Tue, 18 Oct 2011 11:47:45 -0700 (PDT) In-Reply-To: <44B1D328-3875-4E82-9338-AB223E09BB8A@cisco.com> References: <15B0E3AD-3086-499A-8E79-7AE58B3376C4@cisco.com> <4E9D8D82.707@ericsson.com> <44B1D328-3875-4E82-9338-AB223E09BB8A@cisco.com> Date: Tue, 18 Oct 2011 20:47:45 +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: Jonathan Rosenberg , rtcweb@ietf.org Subject: Re: [rtcweb] SDP Offer/Answer draft-jennings-rtcweb-signaling: Glare handling X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 18:47:52 -0000 2011/10/18 Cullen Jennings : > People mean different things by realtime but when talking about it, I thi= nk it is important to keep in mind it is mostly the media that needs to be = realtime and perhaps the signaling to set up such media is not as does not = have the same level of constraints. Yes, but it's not just about signaling realtime. HTTP polling means unnecesary traffic from client to server. In the other side, WebSocket (bidirectional communication without polling) allow the server communicating to the client when it has something to say. Also I expect that WebSocket will be very common and extended the day RTCweb becomes a reality. Regards. --=20 I=C3=B1aki Baz Castillo From pravindran@sonusnet.com Tue Oct 18 12:00: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 2A6B221F848A for ; Tue, 18 Oct 2011 12:00:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.941 X-Spam-Level: X-Spam-Status: No, score=-2.941 tagged_above=-999 required=5 tests=[AWL=-0.342, 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 2NMpeFStSYVh for ; Tue, 18 Oct 2011 12:00:46 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 91AA321F8CE1 for ; Tue, 18 Oct 2011 12:00:36 -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 p9IJ18QL024089; Tue, 18 Oct 2011 15:01:08 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail04.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 18 Oct 2011 15:00: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="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 19 Oct 2011 00:30:29 +0530 Message-ID: <2E239D6FCD033C4BAF15F386A979BF511599F5@sonusinmail02.sonusnet.com> In-Reply-To: <01441535-7FF6-4C88-AA28-53B5CB68374F@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] SDP Offer/Answer draft-jennings-rtcweb-signaling Thread-Index: AcyNxZ5IL/uWdrh3TsW+PqFUMmkzlwAAPEpQ References: <15B0E3AD-3086-499A-8E79-7AE58B3376C4@cisco.com> <2E239D6FCD033C4BAF15F386A979BF51159957@sonusinmail02.sonusnet.com> <01441535-7FF6-4C88-AA28-53B5CB68374F@cisco.com> From: "Ravindran Parthasarathi" To: "Cullen Jennings" X-OriginalArrivalTime: 18 Oct 2011 19:00:33.0941 (UTC) FILETIME=[36CEF450:01CC8DC8] Cc: Jonathan Rosenberg , rtcweb@ietf.org, public-webrtc@w3.org Subject: Re: [rtcweb] SDP Offer/Answer draft-jennings-rtcweb-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: Tue, 18 Oct 2011 19:00:47 -0000 Cullen, Thanks for the clarification about ROAP dialog stateful in signaling gateway & Session-id usage. Please update this information in the next revision.=20 Thanks Partha >-----Original Message----- >From: Cullen Jennings [mailto:fluffy@cisco.com] >Sent: Wednesday, October 19, 2011 12:12 AM >To: Ravindran Parthasarathi >Cc: rtcweb@ietf.org; public-webrtc@w3.org; Jonathan Rosenberg >Subject: Re: [rtcweb] SDP Offer/Answer draft-jennings-rtcweb-signaling > > >So I might have messed up the draft a bit. I'm fine with things can be >implemented as dialog statefull, what I want is that it is possible to >make a signaling gateway that is only transaction statefull. I'm fine if >some signaling gateways are built as dialog statefull. > > (As a side note, some B2BUA are effectively transaction statefull but >that is pretty rare ) > > >On Oct 17, 2011, at 15:28 , Ravindran Parthasarathi wrote: > >> Cullen/Joanthan, >> >> I like your proposed idea as it is going in the direction of having >> "standard" signaling protocol for RTCWeb. I'm seeing your proposal as >> SDP offer/answer over websocket and the proposal helps to easy gateway >> development between RTCWeb server and legacy signaling protocols. >> >> I have fundamental question in the proposal as it proposes RTCWeb >server >> as SIP proxy equivalent and in reality, unfortunately most of the SIP >> deployment work is based on B2BUA. The question is whether RTCWeb >server >> shall be dialog-state or MUST be transaction-stateful only. >> >> Also, session-id in the draft is used to uniquely understand the >offerer >> and answerer in the transaction or session. In case it is session, how >> to indicate the termination of the session. >> > >My personal opinion is that to be able to clean up all the state in a >clean an easy way, we should add some message to indicate the SDP offer >/ answer state and related media streams can be discarded. I'd like to >add that to the next version. > > >> Thanks >> Partha >> >>> -----Original Message----- >>> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >> Behalf >>> Of Cullen Jennings >>> Sent: Saturday, October 15, 2011 8:39 AM >>> To: rtcweb@ietf.org; public-webrtc@w3.org >>> Cc: Jonathan Rosenberg >>> Subject: [rtcweb] SDP Offer/Answer draft-jennings-rtcweb-signaling >>> >>> >>> Jonathan and I submitted a new draft on setting up media based on the >>> SDP Offer/Answer model. The ASCII flows are a bit hard to read so >until >>> I update them, I recommend reading the PDF version at >>> >>> http://tools.ietf.org/pdf/draft-jennings-rtcweb-signaling-00.pdf >>> >>> Clearly the draft is an early stage but we plan to revise it before >the >>> deadline for the IETF 82. Love to get input - particularly on if this >>> looks like generally the right direction to go. >>> >>> >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb From fluffy@cisco.com Tue Oct 18 12:02: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 8D21D21F8C9C for ; Tue, 18 Oct 2011 12:02:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.539 X-Spam-Level: X-Spam-Status: No, score=-106.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 qHJG5GPamKs8 for ; Tue, 18 Oct 2011 12:02:24 -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 E0EA321F8C9A for ; Tue, 18 Oct 2011 12:02:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=566; q=dns/txt; s=iport; t=1318964544; x=1320174144; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=AxzQC77kmdcnPbDFsK4iouHPpLJBD8wN1jIeZSK4PrU=; b=Miwdy6hfqDsFLvdzj5+rzUo8/bscIk1eBsoSuqpEx4PZsl593unTW3te x+XK7KbJ1h1pT3FW01T9bzpPrgI8dkaPlfyt+leMvpuPuCrc9LHPNOV3A NtkRPMaF1Lc5Rf62oRYWPzgxqQP5TYxfoXp/MT8mAjKk/KiBGwSJP/bOP U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAMjLnU6rRDoG/2dsb2JhbABEqG6BBYFuAQEBAwESASc/EAtGVwY1h16XdwGeYoc6YQSIAot7kXY X-IronPort-AV: E=Sophos;i="4.69,366,1315180800"; d="scan'208";a="8678893" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 18 Oct 2011 19:02:23 +0000 Received: from dhcp-171-70-217-213.cisco.com (dhcp-171-70-217-213.cisco.com [171.70.217.213]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p9IJ2NOC016965; Tue, 18 Oct 2011 19:02:23 GMT Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A058522341F416A@ESESSCMS0356.eemea.ericsson.se> Date: Tue, 18 Oct 2011 12:02:21 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <10704DBF-9400-42BA-B9C5-209C338F042E@cisco.com> References: <15B0E3AD-3086-499A-8E79-7AE58B3376C4@cisco.com> <2E239D6FCD033C4BAF15F386A979BF51159957@sonusinmail02.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A058522341F416A@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1251.1) Cc: Jonathan Rosenberg , "rtcweb@ietf.org" , "public-webrtc@w3.org" Subject: Re: [rtcweb] SDP Offer/Answer draft-jennings-rtcweb-signaling - Scope X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 19:02:25 -0000 On Oct 18, 2011, at 3:18 , Christer Holmberg wrote: >=20 > So, while I support and offer/answer based approach, I think we need = to get a clearer understanding of the scope. My view is this is draft is a set of semantics and syntax that operates = over an abstract transport protocol. In most cases the transport with be = web sockets or HTTP based. If this looks like a reasonable protocol, it = would be likely to influence the W3C API. I'm not really sure how to = clear up the scope. I'm just not sure what the scope is I need to clear = up.=20 From fluffy@cisco.com Tue Oct 18 12:25: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 3D24021F8CA9 for ; Tue, 18 Oct 2011 12:25:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.399 X-Spam-Level: X-Spam-Status: No, score=-106.399 tagged_above=-999 required=5 tests=[AWL=-0.100, 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 4gEnoYCqI5DZ for ; Tue, 18 Oct 2011 12:25:08 -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 987AD21F8BFE for ; Tue, 18 Oct 2011 12:25:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=1257; q=dns/txt; s=iport; t=1318965908; x=1320175508; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=SwitDa4mJsei4Y24obowLZGk7sJY4ZbWXay5BcG3fGw=; b=VM+JY6k/DI6pFwv/TRUpgYcreuxjOl1/QeRM1Hq0DVu/qSsgXmdkm3Ap HynFqULjgrynnTyYZejAHrg+S4d0iOlLVTSR8TfoBMQRuMeYga5UFwBnN w/VVep52Z1t+vz9OncTHnDYK0nJXjWJv/PB6Q31zWzGDaURmBGnNjcpZt 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAP/RnU6rRDoH/2dsb2JhbABEqG6BBYFuAQEBAwESAWYFCwtGVwYTIodel2wBnl6HOmEEiAKLe5F2 X-IronPort-AV: E=Sophos;i="4.69,366,1315180800"; d="scan'208";a="8651057" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 18 Oct 2011 19:25:08 +0000 Received: from dhcp-171-70-217-213.cisco.com (dhcp-171-70-217-213.cisco.com [171.70.217.213]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p9IJP8eC019583; Tue, 18 Oct 2011 19:25:08 GMT Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Cullen Jennings In-Reply-To: Date: Tue, 18 Oct 2011 12:25:06 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9685EE86-535B-4E6E-A241-AE0865DFDCF3@cisco.com> References: <15B0E3AD-3086-499A-8E79-7AE58B3376C4@cisco.com> <4E9D8D82.707@ericsson.com> <44B1D328-3875-4E82-9338-AB223E09BB8A@cisco.com> To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= X-Mailer: Apple Mail (2.1251.1) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SDP Offer/Answer draft-jennings-rtcweb-signaling: Glare handling X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 19:25:09 -0000 On Oct 18, 2011, at 11:47 , I=F1aki Baz Castillo wrote: > 2011/10/18 Cullen Jennings : >> People mean different things by realtime but when talking about it, I = think it is important to keep in mind it is mostly the media that needs = to be realtime and perhaps the signaling to set up such media is not as = does not have the same level of constraints. >=20 > Yes, but it's not just about signaling realtime. HTTP polling means > unnecesary traffic from client to server. In the other side, WebSocket > (bidirectional communication without polling) allow the server > communicating to the client when it has something to say. All I'm trying to say is that I think there will be applications that = use websockets and there will be applications that don't - they will = have different impact on servers and performance. There are plenty of = web based IM systems operating today that get pretty good performance = without websockets. Clearly websockets will have a bunch of desirable = features for this sort of signaling. =20 >=20 > Also I expect that WebSocket will be very common and extended the day > RTCweb becomes a reality. >=20 > Regards. >=20 > --=20 > I=F1aki Baz Castillo > From jim.mceachern@genband.com Tue Oct 18 12:32: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 AE94821F8D29 for ; Tue, 18 Oct 2011 12:32:06 -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 h5Er2lVQF3Cd for ; Tue, 18 Oct 2011 12:32:06 -0700 (PDT) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by ietfa.amsl.com (Postfix) with ESMTP id 244EC21F8D1B for ; Tue, 18 Oct 2011 12:32:04 -0700 (PDT) Received: from mail.genband.com ([63.149.188.88]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP; Tue, 18 Oct 2011 12:32: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, 18 Oct 2011 14:31:42 -0500 Received: from GBPLMAIL02.genband.com ([fe80::9455:4039:582f:aee8]) by GBEX01.genband.com ([fe80::a0a8:7818:e701:2f58%13]) with mapi id 14.01.0289.001; Tue, 18 Oct 2011 14:31:41 -0500 From: Jim McEachern To: "Asveren, Tolga" Thread-Topic: [rtcweb] Review request for RTCWeb standard signaling protocol Thread-Index: AQHMjWPJ5Sh3naz7SPaFx9XGCjJhjZWCFU0AgAAGWYCAAE3QgIAACNmAgABHvACAAAOwAIAAAFQAgAACdQD//73Tbg== Date: Tue, 18 Oct 2011 19:31:41 +0000 Message-ID: <3BFE6ACE-7429-468A-9248-BAC8118030B4@genband.com> References: <2E239D6FCD033C4BAF15F386A979BF510F1367@sonusinmail02.sonusnet.com><4E8AC222.4050308@alvestrand.no><2E239D6FCD033C4BAF15F386A979BF510F14CE@sonusinmail02.sonusnet.com><2E239D6FCD033C4BAF15F386A979BF510F14FD@sonusinmail02.sonusnet.com><393F1888-F834-4DAE-B6B1-1C5D35EE3292@phonefromhere.com><2E239D6FCD033C4BAF15F386A979BF510F152B@sonusinmail02.sonusnet.com><2E239D6FCD033C4BAF15F386A979BF510F1532@sonusinmail02.sonusnet.com><2E239D6FCD033C4BAF15F386A979BF511598EE@sonusinmail02.sonusnet.com><665A16AB-AAD8-42B3-AC17-7E629EA2DE35@phonefromhere.com><2E239D6FCD033C4BAF15F386A979BF5115992E@sonusinmail02.sonusnet.com><0950F0E1-6E4B-407F-9563- 654AFE79 F64B@ag-proj ects.com><2E239D6FCD033C4BAF15F386A979BF51159994@sonusinmail02.sonusnet.com><1F2A2C70609D9E41844A2126145FC09804004302@HKGMBOXPRD22.polycom.com><033458F56EC2A64E8D2D7B759FA3E7E703DBF614@sonusmail04.sonusnet.com><8486C8728176924BAF5BDB2F7D7EEDDF3E091D13@ucolhp4d.easf.csd.disa.mil><2E239D6FCD033C4BAF15F386A979BF511599F3@sonusinmail02.sonusnet.com><033458F56EC2A64E8D2D7B759FA3E7E703DBF698@sonusmail04.sonusnet.com> , <033458F56EC2A64E8D2D7B759FA3E7E703DBF6A5@sonusmail04.sonusnet.com> In-Reply-To: <033458F56EC2A64E8D2D7B759FA3E7E703DBF6A5@sonusmail04.sonusnet.com> 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: 18 Oct 2011 19:31:42.0080 (UTC) FILETIME=[904E5800:01CC8DCC] X-TM-AS-Product-Ver: SMEX-8.0.0.4160-6.500.1024-18458.001 X-TM-AS-Result: No--20.997000-5.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Review request for RTCWeb standard 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: Tue, 18 Oct 2011 19:32:06 -0000 Tolga, I'm confused by your statement that "supporting both models would require a= careful design of RTCWeb stack/JS interface...". Surely the same informati= on would have to be supported by the API whether the intelligence was in th= e JS or in the web server. Other than a strong requirement for it being asy= nchronous (which has already been proposed for other reasons) I would have = thought the API could be the same whether the intelligence is in the JS or = the web server.=20 For the record, I am not arguing either way on where the intelligence shoul= d be. I'm simply trying to understand the requirements. Jim On Oct 18, 2011, at 2:28 PM, "Asveren, Tolga" wrote= : > Yes, not required, but possible -if we can achieve that level of flexibil= ity-. >=20 > Overall, there are two models here: > i- Webbrowser/JS as signaling/media entity > ii- Webbrowser/JS as a media entity controlled by webserver >=20 > It seems focus is on i- but I heard a few people mentioning about ii- and= no direct rejection yet. Supporting both models would require a careful de= sign of RTCWeb stack/JS interface so that it is flexible enough but also ca= n be used easily for simple variations of each model. >=20 > Thanks, > Tolga >=20 >> -----Original Message----- >> From: I=F1aki Baz Castillo [mailto:ibc@aliax.net] >> Sent: Tuesday, October 18, 2011 2:20 PM >> To: Asveren, Tolga >> Cc: Ravindran Parthasarathi; Roy, Radhika R USA CIV (US); Avasarala, >> Ranjit; Sa=FAl Ibarra Corretg=E9; rtcweb@ietf.org >> Subject: Re: [rtcweb] Review request for RTCWeb standard signaling >> protocol >>=20 >> 2011/10/18 Asveren, Tolga : >>> I would think that supporting what Tim Panton describes in another >> thread (codec selection done in webserver) could be nice to achieve -amo= ng >> other models- if possible. >>=20 >> I hope the intelligence is NOT required to be in the web server. >>=20 >> -- >> I=F1aki Baz Castillo >> > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From harald@alvestrand.no Tue Oct 18 12:33: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 993B121F8D82 for ; Tue, 18 Oct 2011 12:33:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ivxRMuv0lZ50 for ; Tue, 18 Oct 2011 12:33:25 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id D1A5821F8D1B for ; Tue, 18 Oct 2011 12:33:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3070539E151 for ; Tue, 18 Oct 2011 21:33:24 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kope1FThEepm for ; Tue, 18 Oct 2011 21:33:22 +0200 (CEST) Received: from [172.16.48.71] (unknown [74.125.121.33]) by eikenes.alvestrand.no (Postfix) with ESMTPS id C490C39E082 for ; Tue, 18 Oct 2011 21:33:22 +0200 (CEST) Message-ID: <4E9DD481.5020700@alvestrand.no> Date: Tue, 18 Oct 2011 21:33:21 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: rtcweb@ietf.org References: <15B0E3AD-3086-499A-8E79-7AE58B3376C4@cisco.com> <4E9D8D82.707@ericsson.com> <44B1D328-3875-4E82-9338-AB223E09BB8A@cisco.com> In-Reply-To: <44B1D328-3875-4E82-9338-AB223E09BB8A@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [rtcweb] SDP Offer/Answer draft-jennings-rtcweb-signaling: Glare handling X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 19:33:25 -0000 On 10/18/2011 08:42 PM, Cullen Jennings wrote: > People mean different things by realtime but when talking about it, I think it is important to keep in mind it is mostly the media that needs to be realtime and perhaps the signaling to set up such media is not as does not have the same level of constraints. The "overview" draft has the following definition: Real-time media: Media where generation of content and display of content are intended to occur closely together in time (on the order of no more than hundreds of milliseconds). The omission of a definition for "real-time" without "media" is not an accident; I don't think a consensus definition exists, and I don't think we need that term in our work. > > On Oct 18, 2011, at 8:40 , Iaki Baz Castillo wrote: > >> 2011/10/18 Magnus Westerlund: >>> For example an JS application that uses short polling for retrieving any >>> incomming ROAP messages, as that is timer based and done lets say every >>> 5 seconds >> Hi. This is RTC, so *realtime* is required for media sessions. I >> expect that people should assume WebSocket usage rather than HTTP >> polling. >> >> >> >> -- >> Iaki Baz Castillo >> > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From ibc@aliax.net Tue Oct 18 12:44: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 562F921F8DCA for ; Tue, 18 Oct 2011 12:44:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=-0.035, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JsXvR6of9FVt for ; Tue, 18 Oct 2011 12:44: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 4CC0F21F8DBA for ; Tue, 18 Oct 2011 12:44:07 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so1044122vcb.31 for ; Tue, 18 Oct 2011 12:44:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.25.75 with SMTP id a11mr4096809vdg.1.1318967046614; Tue, 18 Oct 2011 12:44:06 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Tue, 18 Oct 2011 12:44:06 -0700 (PDT) In-Reply-To: References: <15B0E3AD-3086-499A-8E79-7AE58B3376C4@cisco.com> Date: Tue, 18 Oct 2011 21:44:06 +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: Jonathan Rosenberg , rtcweb@ietf.org, public-webrtc@w3.org Subject: Re: [rtcweb] =?utf-8?q?Why_SDP_answer_needs_and_ack_=E2=80=A6_was_Re?= =?utf-8?q?=3A__SDP_Offer/Answer_draft-jennings-rtcweb-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: Tue, 18 Oct 2011 19:44:08 -0000 2011/10/18 Cullen Jennings : > Hi - glad to hear you see this going the right direction. On the topic of= why we have an OK, let me provide a bit of the motivation. > > When one side sends and answer that says it wants to receive VP8 instead = of H.264, it's probably useful to know when the other side got that informa= tion. This might impact the timing of when o send things or user interface = that provides feedback about the status of the other side. We are also deal= ing with a web transaction model where transaction are not guarantee to hap= pen even if they are sent over TCP. So you need to get back a response to r= equest. It also helps with mapping to SIP but even if you were not mapping = to another protocol, I suspect you would still need to be able to have an c= onfirmation than and answer was received. Hi Cullen. Let me put an example: - alice: JS client implementing pure SIP over WebSocket. - A proxy implementing SIP over UDP and WebSocket. - bob: SIP UDP client. The flows: - alice sends INVITE to bob with an empty body (no SDP). - bob replies a 200 with the SDP offer. - alice receives the 200. Its JS code internally generates a ROAP Offer. - alice generates a ROAP Answer and inserts its SDP into an ACK to be sent to bob. - In SIP we have ended. So how is supposed alice will receive the ROAP OK message? I don't understand yet if such ROAP OK message is mandatory to be sent to the RTCweb stack. If so, the JS code in alice could auto-generate it after sending the ACK, so the RTCweb stack becomes happy. But obviously the advantage of such auto-generated ROAP OK is null. Regards. --=20 I=C3=B1aki Baz Castillo From tasveren@sonusnet.com Tue Oct 18 12:45: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 953E321F8DBA for ; Tue, 18 Oct 2011 12:45:30 -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] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fV+tJPJIzWrB for ; Tue, 18 Oct 2011 12:45:29 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id A970B21F8D24 for ; Tue, 18 Oct 2011 12:45:29 -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 p9IJk1Bx020564; Tue, 18 Oct 2011 15:46: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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 18 Oct 2011 15:45:24 -0400 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E703DBF6C6@sonusmail04.sonusnet.com> In-Reply-To: <3BFE6ACE-7429-468A-9248-BAC8118030B4@genband.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] Review request for RTCWeb standard signaling protocol Thread-Index: AQHMjWPJ5Sh3naz7SPaFx9XGCjJhjZWCFU0AgAAGWYCAAE3QgIAACNmAgABHvACAAAOwAIAAAFQAgAACdQD//73TboAAA3Gg References: <2E239D6FCD033C4BAF15F386A979BF510F1367@sonusinmail02.sonusnet.com><4E8AC222.4050308@alvestrand.no><2E239D6FCD033C4BAF15F386A979BF510F14CE@sonusinmail02.sonusnet.com><2E239D6FCD033C4BAF15F386A979BF510F14FD@sonusinmail02.sonusnet.com><393F1888-F834-4DAE-B6B1-1C5D35EE3292@phonefromhere.com><2E239D6FCD033C4BAF15F386A979BF510F152B@sonusinmail02.sonusnet.com><2E239D6FCD033C4BAF15F386A979BF510F1532@sonusinmail02.sonusnet.com><2E239D6FCD033C4BAF15F386A979BF511598EE@sonusinmail02.sonusnet.com><665A16AB-AAD8-42B3-AC17-7E629EA2DE35@phonefromhere.com><2E239D6FCD033C4BAF15F386A979BF5115992E@sonusinmail02.sonusnet.com><0950F0E1-6E4B-407F-9563- 654AFE79 F64B@ag-pro jects.com><2E239D6FCD033C4BAF15F386A979BF51159994@sonusinmail02.sonusnet.com><1F2A2C70609D9E41844A2126145FC09804004302@HKGMBOXPRD22.polycom.com><033458F56EC2A64E8D2D7B759FA3E7E703DBF614@sonusmail04.sonusnet.com><8486C8728176924BAF5BDB2F7D7EEDDF3E091D13@ucolhp4d.easf.csd.disa.mil><2E239D6FCD033C4BAF15F386A979BF511599F3@sonusinmail02.sonusnet.com><033458F56EC2A64E8D2D7B759FA3E7E703DBF698@sonusmail04.sonusnet.com>, <033458F56EC2A64E8D2D7B759FA3E7E703DBF6A5@sonusmail04.sonusnet.com> <3BFE6ACE-7429-468A-9248-BAC8118030B4@genband.com> From: "Asveren, Tolga" To: "Jim McEachern" Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Review request for RTCWeb standard 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: Tue, 18 Oct 2011 19:45:30 -0000 Mea culpa, yes it is more about the nature of relationship between = RTCWeb in browser and JS/webserver. Thanks, Tolga > -----Original Message----- > From: Jim McEachern [mailto:jim.mceachern@genband.com] > Sent: Tuesday, October 18, 2011 3:32 PM > To: Asveren, Tolga > Cc: I=F1aki Baz Castillo; rtcweb@ietf.org > Subject: Re: [rtcweb] Review request for RTCWeb standard signaling > protocol >=20 > Tolga, > I'm confused by your statement that "supporting both models would = require > a careful design of RTCWeb stack/JS interface...". Surely the same > information would have to be supported by the API whether the = intelligence > was in the JS or in the web server. Other than a strong requirement = for it > being asynchronous (which has already been proposed for other reasons) = I > would have thought the API could be the same whether the intelligence = is > in the JS or the web server. >=20 > For the record, I am not arguing either way on where the intelligence > should be. I'm simply trying to understand the requirements. >=20 > Jim >=20 >=20 > On Oct 18, 2011, at 2:28 PM, "Asveren, Tolga" > wrote: >=20 > > Yes, not required, but possible -if we can achieve that level of > flexibility-. > > > > Overall, there are two models here: > > i- Webbrowser/JS as signaling/media entity > > ii- Webbrowser/JS as a media entity controlled by webserver > > > > It seems focus is on i- but I heard a few people mentioning about = ii- > and no direct rejection yet. Supporting both models would require a > careful design of RTCWeb stack/JS interface so that it is flexible = enough > but also can be used easily for simple variations of each model. > > > > Thanks, > > Tolga > > > >> -----Original Message----- > >> From: I=F1aki Baz Castillo [mailto:ibc@aliax.net] > >> Sent: Tuesday, October 18, 2011 2:20 PM > >> To: Asveren, Tolga > >> Cc: Ravindran Parthasarathi; Roy, Radhika R USA CIV (US); = Avasarala, > >> Ranjit; Sa=FAl Ibarra Corretg=E9; rtcweb@ietf.org > >> Subject: Re: [rtcweb] Review request for RTCWeb standard signaling > >> protocol > >> > >> 2011/10/18 Asveren, Tolga : > >>> I would think that supporting what Tim Panton describes in another > >> thread (codec selection done in webserver) could be nice to achieve = - > among > >> other models- if possible. > >> > >> I hope the intelligence is NOT required to be in the web server. > >> > >> -- > >> I=F1aki Baz Castillo > >> > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb From ted.ietf@gmail.com Tue Oct 18 12: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 A0ED921F8AEA for ; Tue, 18 Oct 2011 12:58:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.08 X-Spam-Level: X-Spam-Status: No, score=-3.08 tagged_above=-999 required=5 tests=[AWL=0.218, 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 Pizve9mpAduW for ; Tue, 18 Oct 2011 12:58:33 -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 D47C021F8ACA for ; Tue, 18 Oct 2011 12:58:32 -0700 (PDT) Received: by ywa8 with SMTP id 8so1154468ywa.31 for ; Tue, 18 Oct 2011 12:58:32 -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=p1G2m9BLxLZHSRvjI29tlSE6IVJZ1EE8+sdtGF5zqMs=; b=en7sFvIcLvJdJHoDsA7a0kNPzpsPE/bD/HcrxwPVTYO6mK5stDy3sA9NkBeFKqp2aX e54HcXSd6MM/bbBN1VAKf++sSTu0IrKYACkU0zsqikcPszE0WGH/qgxvuPwhVxVmR0Xf EaNVgK9mXUbfQx3M1JzN3H98bF2jL0kh4zpjc= MIME-Version: 1.0 Received: by 10.236.187.36 with SMTP id x24mr5808623yhm.74.1318967912473; Tue, 18 Oct 2011 12:58:32 -0700 (PDT) Received: by 10.236.105.169 with HTTP; Tue, 18 Oct 2011 12:58:32 -0700 (PDT) In-Reply-To: References: <2E239D6FCD033C4BAF15F386A979BF510F1367@sonusinmail02.sonusnet.com> <4E8AC222.4050308@alvestrand.no> <2E239D6FCD033C4BAF15F386A979BF510F14CE@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF510F14FD@sonusinmail02.sonusnet.com> <393F1888-F834-4DAE-B6B1-1C5D35EE3292@phonefromhere.com> <2E239D6FCD033C4BAF15F386A979BF510F152B@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF510F1532@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF511598EE@sonusinmail02.sonusnet.com> <665A16AB-AAD8-42B3-AC17-7E629EA2DE35@phonefromhere.com> <2E239D6FCD033C4BAF15F386A979BF5115992E@sonusinmail02.sonusnet.com> <0950F0E1-6E4B-407F-9563-654AFE79F64B@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF51159994@sonusinmail02.sonusnet.com> <1F2A2C70609D9E41844A2126145FC09804004302@HKGMBOXPRD22.polycom.com> <033458F56EC2A64E8D2D7B759FA3E7E703DBF614@sonusmail04.sonusnet.com> <8486C8728176924BAF5BDB2F7D7EEDDF3E091D13@ucolhp4d.easf.csd.disa.mil> <2E239D6FCD033C4BAF15F386A979BF511599F3@sonusinmail02.sonusnet.com> Date: Tue, 18 Oct 2011 12:58:32 -0700 Message-ID: From: Ted Hardie To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=20cf303dd9d0e4a6a304af98251a Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Review request for RTCWeb standard 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: Tue, 18 Oct 2011 19:58:33 -0000 --20cf303dd9d0e4a6a304af98251a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Oct 18, 2011 at 11:34 AM, I=F1aki Baz Castillo wrot= e: > > When RTCweb becomes a reality there will appear thousands of > JavaScript libraries implementing different RTCweb signaling > protocols, each one with its own features and capabilities. Do you > understand that a website admin will be able to choose the one he > prefers? > > You make this sound like you believe this to be an advantage. Having seen the bit-rot in quite a few libraries, I'm less included to assume that every library created will be feature complete and well-maintained. I'm equally leery of presuming that it is easy to chose among them. Checking for embedded malware, to take a simple example, makes the task longer and more fraught with issues than you might suppose. > Visit 100 random cool websites. Probably 50% of them use JQuery JS > library. Does it mean that each web developer had to build his own JS > library? not at all, they use JQuery. > > Now your reply will be "downloading the JS library everytime is not > efficient". Ok, visit 100 random cool websites. Probably 50% of them > use JQuery JS library. How many times have you downloaded the JQuery > library (assuming that every site has its own copy of the .js)? ... 50 > times. Is that a problem? not for the rest of the humans in the world. > > It's certainly less efficient and, given the majority of users now accessin= g the Internet via mobile devices which are power and bandwidth constrained, that sort of wastefulness should not be trivially dismissed. I > So please stop making up issues that don't exist. The WWW world does > not work as you propose, and anyhow it has succeeded. > > You set up a strawman that you attempted to knock down. He did not propose it, you did. I also don't think you scored even a TKO on the strawman. Again, please focus on your own points, thanks, Ted Hardie > > > -- > I=F1aki Baz Castillo > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --20cf303dd9d0e4a6a304af98251a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Oct 18, 2011 at 11:34 AM, I=F1aki Baz Castillo &l= t;ibc@aliax.net> wrote:
<= div class=3D"gmail_quote">

When RTCweb becomes a reality there will appear thousands of
JavaScript libraries implementing different RTCweb signaling
protocols, each one with its own features and capabilities. Do you
understand that a website admin will be able to choose the one he
prefers?


You make this sound like you believe this to be a= n advantage.=A0 Having seen the bit-rot in quite a few libraries,=A0 I'= m less included to assume that every library created will be feature comple= te and well-maintained.=A0 I'm equally leery of presuming that it is ea= sy to chose among them.=A0 Checking for embedded malware, to take a simple = example, makes the task longer and more fraught with issues than you might = suppose.
=A0
Visit 100 random cool websites. Probably 50% of them use JQuery JS
library. Does it mean that each web developer had to build his own JS
library? not at all, they use JQuery.

Now your reply will be "downloading the JS library everytime is not efficient". Ok, visit 100 random cool websites. Probably 50% of them use JQuery JS library. How many times have you downloaded the JQuery
library (assuming that every site has its own copy of the .js)? ... 50
times. Is that a problem? not for the rest of the humans in the world.


It's certainly less efficient and, given the = majority of users now accessing the Internet via mobile devices which are p= ower and bandwidth constrained, that sort of wastefulness should not be tri= vially dismissed.=A0 I
=A0
So please stop making up issues that don't exist. The WWW world does not work as you propose, and anyhow it has succeeded.


You set up a strawman tha= t you attempted to knock down.=A0 He did not propose it, you did.=A0 I also= don't think you scored even a TKO on the strawman.=A0 Again, please fo= cus on your own points,

thanks,

Ted Hardie
=A0


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

--20cf303dd9d0e4a6a304af98251a-- From HKaplan@acmepacket.com Tue Oct 18 13:30: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 7291721F8C17 for ; Tue, 18 Oct 2011 13:30:11 -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 1khnIZseXa6e for ; Tue, 18 Oct 2011 13:30:10 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 8D07B21F8BA0 for ; Tue, 18 Oct 2011 13:30: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; Tue, 18 Oct 2011 16:30:09 -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; Tue, 18 Oct 2011 16:30:09 -0400 From: Hadriel Kaplan To: "rtcweb-chairs@tools.ietf.org" Thread-Topic: [rtcweb] Current state of signaling discussion Thread-Index: AQHMjdS59USwkyocF0KQH5G/+0/FIA== Date: Tue, 18 Oct 2011 20:30:08 +0000 Message-ID: References: <4E9D773A.4010705@ericsson.com> In-Reply-To: <4E9D773A.4010705@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.0.0.30] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Current state of signaling discussion X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 20:30:11 -0000 Dear Chairs, I have a question of clarification on your request for "signaling" proposal= s/drafts. Which *type* of "signaling" do you mean? What purpose/problem-solution are= these candidate drafts meant to address? In the email below, you indicate draft-jennings-rtcweb-signaling is one of = the drafts that provides a solution, but as far as I can tell it is not a s= ession signaling protocol; it is just a protocol for SDP offer/answer. It = is not a sufficient solution for sessions, and it admits that within its ow= n text. It would not, for example, let one write a RTCWeb-based communicat= ion application in "20 lines of code". So are you only talking about how to handle media-plane setup between two B= rowsers? (ie codec negotiation, ICE, etc.) OR do you mean the whole sheban= g? There have been a lot emails floating around the past few days so if I've m= issed the relevant clarification please excuse the question. (but direct me= to the answer :) -hadriel On Oct 18, 2011, at 8:55 AM, Magnus Westerlund wrote: > WG, >=20 > This is an attempt of me as WG chair to try to summarize the state of > the discussion as it was when I wrote this. As usual please speak up > against any miss-characterization of the state from my side. >=20 > The Chairs request for identifying who like to provide input for a > signaling discussion two weeks and to follow up this with a Internet > draft has resulted in that we now have two drafts. >=20 > a) RTCWeb Offer/Answer Protocol (ROAP) > https://datatracker.ietf.org/doc/draft-jennings-rtcweb-signaling/ >=20 > b) RTCWeb standard signaling protocol > https://datatracker.ietf.org/doc/draft-partha-rtcweb-signaling/ >=20 > We also have a third proposal that want to be included in the > considerations: > c) RTCWEB does not define any signaling behavior at all, instead W3C is > tasked to develop an API that allows the application to establish the > media session between peers. >=20 > I have as WG chair requested that the proponents for C to produce a > Internet draft that provides requirements on the API and its capability. > This is to ensure that this proposal can be properly evaluated. So far > no such contribution has occurred. Without a willingness from the > proponents of this style of solution to contribute and evolve their > thinking in such way that the other WG members can gain a better > understanding of the implications of this solution I find it difficult > for us include it in the up coming consensus call. >=20 > We intended to have a phone conference on Friday to enable some direct > discussion on the topic of signaling between the WG members. Details to > follow. This is not an interim, only a possibility for the WG members to > further their understanding in preparation for the decision. >=20 > In addition to signaling proposals the WG have received two other I-Ds. >=20 > 1) Real-Time Web Communication Simplified Interconnection > https://datatracker.ietf.org/doc/draft-beck-rtcweb-alt-ic/ >=20 > Which I interpret as a discussion piece around the federation and > interconnect usages. >=20 > 2) WebSocket Transport for Session Initiation Protocol (SIP) > https://datatracker.ietf.org/doc/draft-ibc-rtcweb-sip-websocket/ >=20 > This is a demonstration that SIP could be implemented in Java script and > be transported over web-socket to enable the cases where SIP want to be > used between a browser instance and a SIP system and its user agents. > This has some requirements on the API to either provide SDP in O/A style > or something that enables the SIP stack to create SIP messages with SDP > O/A messages. >=20 > There has been lively discussion around these documents which I hope > continues but it does need to come to some conclusions. >=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 tasveren@sonusnet.com Tue Oct 18 13:31:01 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79B3F21F8505 for ; Tue, 18 Oct 2011 13:31:01 -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.038, 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 TghqMFwIheN7 for ; Tue, 18 Oct 2011 13:30:59 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id E559821F8512 for ; Tue, 18 Oct 2011 13:30: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 p9IKVPhG018155; Tue, 18 Oct 2011 16:31: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_01CC8DD4.D3AEF782" Date: Tue, 18 Oct 2011 16:30:49 -0400 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E703DBF6D4@sonusmail04.sonusnet.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] Review request for RTCWeb standard signaling protocol Thread-Index: AcyN0FNRa8PK4bssTZKb604uAWGvqgAAmDyQ References: <2E239D6FCD033C4BAF15F386A979BF510F1367@sonusinmail02.sonusnet.com><4E8AC222.4050308@alvestrand.no><2E239D6FCD033C4BAF15F386A979BF510F14CE@sonusinmail02.sonusnet.com><2E239D6FCD033C4BAF15F386A979BF510F14FD@sonusinmail02.sonusnet.com><393F1888-F834-4DAE-B6B1-1C5D35EE3292@phonefromhere.com><2E239D6FCD033C4BAF15F386A979BF510F152B@sonusinmail02.sonusnet.com><2E239D6FCD033C4BAF15F386A979BF510F1532@sonusinmail02.sonusnet.com><2E239D6FCD033C4BAF15F386A979BF511598EE@sonusinmail02.sonusnet.com><665A16AB-AAD8-42B3-AC17-7E629EA2DE35@phonefromhere.com><2E239D6FCD033C4BAF15F386A979BF5115992E@sonusinmail02.sonusnet.com><0950F0E1-6E4B-407F-9563- 654AFE79 F64B@ag-proj ects.com><2E239D6FCD033C4BAF15F386A979BF51159994@sonusinmail02.sonusnet.com><1F2A2C70609D9E41844A2126145FC09804004302@HKGMBOXPRD22.polycom.com><033458F56EC2A64E8D2D7B759FA3E7E703DBF614@sonusmail04.sonusnet.com><8486C8728176924BAF5BDB2F7D7EEDDF3E091D13@ucolhp4d.easf.csd.disa.mil><2E239D6FCD033C4BAF15F386A979BF511599F3@sonusinmail02.sonusnet.com> From: "Asveren, Tolga" To: "Ted Hardie" , =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Review request for RTCWeb standard 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: Tue, 18 Oct 2011 20:31:01 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC8DD4.D3AEF782 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Some opinions about the topics under discussion: =20 i- One difference between JS library and browser support is that service = developer can choose the JS library they want to use (or develop their = own). It is up to them to make sure that it works fine, does not have = malicious behavior etc... If they don't do their homework, their service = will fail. OTOH, service developer has no control over what is/will be = supported in the browser, e.g. browser-X supporting forking only after = release-Y. I also would expect that security requirement is more on the = browser so that it does not let potentially malicious things to be done = and this would be controlled by the enduser by its choice of browser. =20 ii- How big do we expect JS libraries to be? I think we assume that = battery/bandwidth is not a showstopper for realtime communication so I = would think JS library size would be a factor only if its ratio v.s. = media is non-negligible. =20 Thanks, Tolga =20 ________________________________ From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf = Of Ted Hardie Sent: Tuesday, October 18, 2011 3:59 PM To: I=F1aki Baz Castillo Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Review request for RTCWeb standard signaling = protocol =20 On Tue, Oct 18, 2011 at 11:34 AM, I=F1aki Baz Castillo = wrote: =09 When RTCweb becomes a reality there will appear thousands of JavaScript libraries implementing different RTCweb signaling protocols, each one with its own features and capabilities. Do you understand that a website admin will be able to choose the one he prefers? You make this sound like you believe this to be an advantage. Having = seen the bit-rot in quite a few libraries, I'm less included to assume = that every library created will be feature complete and well-maintained. = I'm equally leery of presuming that it is easy to chose among them. = Checking for embedded malware, to take a simple example, makes the task = longer and more fraught with issues than you might suppose. =20 Visit 100 random cool websites. Probably 50% of them use JQuery JS library. Does it mean that each web developer had to build his own JS library? not at all, they use JQuery. =09 Now your reply will be "downloading the JS library everytime is not efficient". Ok, visit 100 random cool websites. Probably 50% of them use JQuery JS library. How many times have you downloaded the JQuery library (assuming that every site has its own copy of the .js)? ... 50 times. Is that a problem? not for the rest of the humans in the world. It's certainly less efficient and, given the majority of users now = accessing the Internet via mobile devices which are power and bandwidth = constrained, that sort of wastefulness should not be trivially = dismissed. I =20 So please stop making up issues that don't exist. The WWW world does not work as you propose, and anyhow it has succeeded. =20 You set up a strawman that you attempted to knock down. He did not = propose it, you did. I also don't think you scored even a TKO on the = strawman. Again, please focus on your own points,=20 thanks, Ted Hardie =20 =09 =09 -- I=F1aki Baz Castillo _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb =20 ------_=_NextPart_001_01CC8DD4.D3AEF782 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Some opinions about the topics = under discussion:

 

i- One difference between JS = library and browser support is that service developer can choose the JS library they = want to use (or develop their own). It is up to them to make sure that it = works fine, does not have malicious behavior etc… If they don’t do = their homework, their service will fail. OTOH, service developer has no = control over what is/will be supported in the browser, e.g. browser-X supporting = forking only after release-Y. I also would expect that security requirement is = more on the browser so that it does not let potentially malicious things to be = done and this would be controlled by the enduser by its choice of = browser.

=A0

ii- How big do we expect JS = libraries to be? I think we assume that battery/bandwidth is not a showstopper for = realtime communication so I would think JS library size would be a factor only if = its ratio v.s. media is non-negligible.

 

Thanks,

=

Tolga

 

From: = rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On = Behalf Of Ted Hardie
Sent: Tuesday, October = 18, 2011 3:59 PM
To: I=F1aki Baz = Castillo
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] = Review request for RTCWeb standard signaling = protocol

 

On Tue, Oct 18, 2011 at 11:34 AM, I=F1aki Baz Castillo <ibc@aliax.net> = wrote:


When RTCweb becomes a reality there will appear thousands of
JavaScript libraries implementing different RTCweb signaling
protocols, each one with its own features and capabilities. Do you
understand that a website admin will be able to choose the one he
prefers?


You make this sound like you believe this to be an advantage.  = Having seen the bit-rot in quite a few libraries,  I'm less included to assume = that every library created will be feature complete and = well-maintained.  I'm equally leery of presuming that it is easy to chose among them.  = Checking for embedded malware, to take a simple example, makes the task longer = and more fraught with issues than you might suppose.
 

Visit 100 = random cool websites. Probably 50% of them use JQuery JS
library. Does it mean that each web developer had to build his own = JS
library? not at all, they use JQuery.

Now your reply will be "downloading the JS library everytime is = not
efficient". Ok, visit 100 random cool websites. Probably 50% of = them
use JQuery JS library. How many times have you downloaded the JQuery
library (assuming that every site has its own copy of the .js)? ... = 50
times. Is that a problem? not for the rest of the humans in the = world.


It's certainly less efficient and, given the majority of users now = accessing the Internet via mobile devices which are power and bandwidth = constrained, that sort of wastefulness should not be trivially dismissed.  I
 

So please stop making up issues that don't exist. The WWW world = does
not work as you propose, and anyhow it has = succeeded.

 


You set up a strawman that you attempted to knock down.  He did not propose it, you did.  I also don't think you scored even a TKO on = the strawman.  Again, please focus on your own points,

thanks,

Ted Hardie
 



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

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

 

------_=_NextPart_001_01CC8DD4.D3AEF782-- From HKaplan@acmepacket.com Tue Oct 18 13:43: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 9204021F8B9C for ; Tue, 18 Oct 2011 13:43:25 -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.088, 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 q-aMs6MNG53X for ; Tue, 18 Oct 2011 13:43:25 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id CDEF521F8B54 for ; Tue, 18 Oct 2011 13:43:24 -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, 18 Oct 2011 16:43:23 -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; Tue, 18 Oct 2011 16:43:23 -0400 From: Hadriel Kaplan To: Ted Hardie Thread-Topic: [rtcweb] Review request for RTCWeb standard signaling protocol Thread-Index: AQHMjdaTfyzFc3/Da0Wwnwst3Qzsew== Date: Tue, 18 Oct 2011 20:43:22 +0000 Message-ID: <37796D08-7A24-478B-8157-052FFB2E3945@acmepacket.com> References: <2E239D6FCD033C4BAF15F386A979BF510F1367@sonusinmail02.sonusnet.com> <4E8AC222.4050308@alvestrand.no> <2E239D6FCD033C4BAF15F386A979BF510F14CE@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF510F14FD@sonusinmail02.sonusnet.com> <393F1888-F834-4DAE-B6B1-1C5D35EE3292@phonefromhere.com> <2E239D6FCD033C4BAF15F386A979BF510F152B@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF510F1532@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF511598EE@sonusinmail02.sonusnet.com> <665A16AB-AAD8-42B3-AC17-7E629EA2DE35@phonefromhere.com> <2E239D6FCD033C4BAF15F386A979BF5115992E@sonusinmail02.sonusnet.com> <0950F0E1-6E4B-407F-9563-654AFE79F64B@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF51159994@sonusinmail02.sonusnet.com> <1F2A2C70609D9E41844A2126145FC09804004302@HKGMBOXPRD22.polycom.com> <033458F56EC2A64E8D2D7B759FA3E7E703DBF614@sonusmail04.sonusnet.com> <8486C8728176924BAF5BDB2F7D7EEDDF3E091D13@ucolhp4d.easf.csd.disa.mil> <2E239D6FCD033C4BAF15F386A979BF511599F3@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: [10.0.0.30] Content-Type: multipart/alternative; boundary="_000_37796D087A24478B8157052FFB2E3945acmepacketcom_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [rtcweb] Review request for RTCWeb standard 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: Tue, 18 Oct 2011 20:43:25 -0000 --_000_37796D087A24478B8157052FFB2E3945acmepacketcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Oct 18, 2011, at 3:58 PM, Ted Hardie wrote: On Tue, Oct 18, 2011 at 11:34 AM, I=F1aki Baz Castillo > wrote: When RTCweb becomes a reality there will appear thousands of JavaScript libraries implementing different RTCweb signaling protocols, each one with its own features and capabilities. Do you understand that a website admin will be able to choose the one he prefers? You make this sound like you believe this to be an advantage. It *is* an advantage. It puts the power in the hands of the app developer,= not the browser developer. Having seen the bit-rot in quite a few libraries, Have you ever used Internet Explorer?? (and I'm not slamming IE because I think their developers are bad - they ha= ve a very tough job of keeping compatibility with numerous Windows OS versi= ons, drivers, etc. - I just think they'll focus on doing that rather dealin= g with signaling protocol changes/bug-fixes for RTCWeb in any timely manner= ) It's certainly less efficient and, given the majority of users now accessin= g the Internet via mobile devices which are power and bandwidth constrained= , that sort of wastefulness should not be trivially dismissed. If a mobile platform is so constrained of power and bandwidth that download= ing a JS library is difficult, it's unlikely it would be able to handle RTP= /RTCP media regardless. -hadriel --_000_37796D087A24478B8157052FFB2E3945acmepacketcom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <27160C18FDF1E34B89CEC9B34771B5D2@acmepacket.com> Content-Transfer-Encoding: quoted-printable
On Oct 18, 2011, at 3:58 PM, Ted Hardie wrote:

On Tue, Oct 18, 2011 at 11:34 AM, I=F1aki Baz Cas= tillo <ibc@aliax.net> wrote:

When RTCweb becomes a reality there will appear thousands of
JavaScript libraries implementing different RTCweb signaling
protocols, each one with its own features and capabilities. Do you
understand that a website admin will be able to choose the one he
prefers?


You make this sound like you believe this to be an advantage. 

It *is* an advantage.  It puts the power in the hands of the app = developer, not the browser developer.


Having seen the bit-rot in quite a few libraries, 

Have you ever used Internet Explorer?? 
 
(and I'm not slamming IE because I think their developers are bad - th= ey have a very tough job of keeping compatibility with numerous Windows OS = versions, drivers, etc. - I just think they'll focus on doing that rather d= ealing with signaling protocol changes/bug-fixes for RTCWeb in any timely manner)

It's certainly less efficient and, given the majority of users now acc= essing the Internet via mobile devices which are power and bandwidth constr= ained, that sort of wastefulness should not be trivially dismissed.  <= /div>

If a mobile platform is so constrained of power and bandwidth that dow= nloading a JS library is difficult, it's unlikely it would be able to handl= e RTP/RTCP media regardless.

-hadriel

--_000_37796D087A24478B8157052FFB2E3945acmepacketcom_-- From ekr@rtfm.com Tue Oct 18 13: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 D6B3D21F8772 for ; Tue, 18 Oct 2011 13:50:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.947 X-Spam-Level: X-Spam-Status: No, score=-102.947 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7QhoN4hGfPkn for ; Tue, 18 Oct 2011 13:50: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 4F4B621F84A5 for ; Tue, 18 Oct 2011 13:50:43 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so1110862vcb.31 for ; Tue, 18 Oct 2011 13:50:41 -0700 (PDT) Received: by 10.52.99.195 with SMTP id es3mr4278072vdb.63.1318971041112; Tue, 18 Oct 2011 13:50:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.161.20 with HTTP; Tue, 18 Oct 2011 13:50:01 -0700 (PDT) In-Reply-To: References: <4E9D773A.4010705@ericsson.com> From: Eric Rescorla Date: Tue, 18 Oct 2011 13:50:01 -0700 Message-ID: To: Hadriel Kaplan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" , "rtcweb-chairs@tools.ietf.org" Subject: Re: [rtcweb] Current state of signaling discussion X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 20:50:44 -0000 On Tue, Oct 18, 2011 at 1:30 PM, Hadriel Kaplan wr= ote: > > Dear Chairs, > I have a question of clarification on your request for "signaling" propos= als/drafts. > Which *type* of "signaling" do you mean? =A0What purpose/problem-solution= are these candidate drafts meant to address? > > In the email below, you indicate draft-jennings-rtcweb-signaling is one o= f the drafts that provides a solution, but as far as I can tell it is not a= session signaling protocol; it is just a protocol for SDP offer/answer. = =A0It is not a sufficient solution for sessions, and it admits that within = its own text. =A0It would not, for example, let one write a RTCWeb-based co= mmunication application in "20 lines of code". Is this actually correct? The introduction of that draft suggests otherwise= : "The protocol is designed to operate between two entities (browsers for example), which exchange messages "directly" - meaning that a message output by one entity is meant to be directly processed by the other entity without further modification. In practice, this means that a web server can treat ROAP messages as opaque and just shuffle them between browser instances. This allows for simple implementations." If we take the PeerConnection API as our point of reference, isn't the idea here that you would instantiate callbacks that take messages coming out of the PeerConnection API and push them to the Web server and messages coming from the Web server and push them to the PeerConnection instance. I don't know if this is 20 li= nes of code (though with JS minimization it might be one line of code :)), but it does seem comparatively trivial... -Ekr -Ekr From fluffy@cisco.com Tue Oct 18 13: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 9335021F8B9E for ; Tue, 18 Oct 2011 13:59:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.535 X-Spam-Level: X-Spam-Status: No, score=-106.535 tagged_above=-999 required=5 tests=[AWL=0.064, 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 xUe31csVi8LH for ; Tue, 18 Oct 2011 13:59:51 -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 1806921F8B9D for ; Tue, 18 Oct 2011 13:59:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=318; q=dns/txt; s=iport; t=1318971591; x=1320181191; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=Hs57VplFF8aiFvUDc1Wk5PBl/EGMFfejpEdFOdspDR0=; b=hM0EjltFwh4qFg/hnxiX3MRh/gt3YzgjSHQSEFXBUrY+SF38mzed5fqo UTDLJPzP3sURXMvSYejEpRpXwLqKsQwYhNI/cpNaXDGXRYbZNB2lrgJ8B y23+SV+eQiXMD1JK37Yx6UA14qRvbNu6yVIXtyn73wVA6pzQEHTJ4TwP0 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAE7onU6rRDoJ/2dsb2JhbABEqG6BBYFuAQEBAwESAWYFCwtGVwY1h16XbwGeSoc6YQSIAot7kXY X-IronPort-AV: E=Sophos;i="4.69,366,1315180800"; d="scan'208";a="8703650" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 18 Oct 2011 20:59:51 +0000 Received: from dhcp-171-70-217-213.cisco.com (dhcp-171-70-217-213.cisco.com [171.70.217.213]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p9IKwkNR016244; Tue, 18 Oct 2011 20:59:50 GMT Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=windows-1252 From: Cullen Jennings In-Reply-To: <9B03E9E2-4376-465E-84F5-EDAC51390408@phonefromhere.com> Date: Tue, 18 Oct 2011 13:59:51 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E9D667A.2040703@alvestrand.no> <9B03E9E2-4376-465E-84F5-EDAC51390408@phonefromhere.com> To: Tim Panton X-Mailer: Apple Mail (2.1251.1) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] My Opinion: Why I think a negotiating protocol is a Good Thing X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 20:59:51 -0000 On Oct 18, 2011, at 5:53 , Tim Panton wrote: > We have an API with blobs only because we chose to stick with the = ugliness that is SDP. One of the most compelling argument to me to stick with SDP is that I = have a hard time imagining anyone creating a replacement for it in less = than a year or two.=20 From HKaplan@acmepacket.com Tue Oct 18 14:05: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 2313B21F8BF4 for ; Tue, 18 Oct 2011 14:05:06 -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 Sc6P51BhQOCO for ; Tue, 18 Oct 2011 14:05:05 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 815A521F8BDC for ; Tue, 18 Oct 2011 14:05:05 -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, 18 Oct 2011 17:05:04 -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; Tue, 18 Oct 2011 17:05:04 -0400 From: Hadriel Kaplan To: Eric Rescorla Thread-Topic: [rtcweb] Current state of signaling discussion Thread-Index: AQHMjdmb9USwkyocF0KQH5G/+0/FIA== Date: Tue, 18 Oct 2011 21:05:03 +0000 Message-ID: References: <4E9D773A.4010705@ericsson.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: <2647DE17A1E2B14ABA66F2C40958B4A8@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "rtcweb@ietf.org" , "rtcweb-chairs@tools.ietf.org" Subject: Re: [rtcweb] Current state of signaling discussion X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 21:05:06 -0000 In the abstract it states: "The protocol focuses solely on media negotiation and does not handle call = control, call processing, or other functions." Ignoring esoteric stuff like session transfer, forwarding, etc. (ie, ignori= ng "phone" stuff) is fine. BUT, for an actual session protocol to work for even a gaming app, you need= to do the following: 1) determine a target for the ROAP message (ie, who's this OFFER going to i= n the end?) 2) define how that target identity is conveyed (ie, how does the web server= know which browser to give this ROAP OFFER to?) 3) define a source identity model, possibly with authentication (ie, who ar= e you?) 4) define how the source identity is conveyed (ie, how does the server/far-= end-browser know who's calling?) 5) define a end-of-session indication 6) define a keep-alive mechanism, for when the far end goes away silently a= nd (5) doesn't apply And I've probably missed some other things. -hadriel On Oct 18, 2011, at 4:50 PM, Eric Rescorla wrote: > Is this actually correct? The introduction of that draft suggests otherwi= se: >=20 > "The protocol is designed to operate between two entities (browsers > for example), which exchange messages "directly" - meaning that a > message output by one entity is meant to be directly processed by the > other entity without further modification. In practice, this means > that a web server can treat ROAP messages as opaque and just shuffle > them between browser instances. This allows for simple > implementations." >=20 > If we take the PeerConnection API as our point of reference, isn't the > idea here that > you would instantiate callbacks that take messages coming out of the > PeerConnection > API and push them to the Web server and messages coming from the Web serv= er > and push them to the PeerConnection instance. I don't know if this is 20 = lines > of code (though with JS minimization it might be one line of code :)), > but it does > seem comparatively trivial... >=20 > -Ekr >=20 >=20 >=20 >=20 > -Ekr From fluffy@cisco.com Tue Oct 18 14:13: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 5694721F8AD3 for ; Tue, 18 Oct 2011 14:13:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.543 X-Spam-Level: X-Spam-Status: No, score=-106.543 tagged_above=-999 required=5 tests=[AWL=0.056, 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 kO3DZzZttW5v for ; Tue, 18 Oct 2011 14:13:43 -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 C7E1321F8AD2 for ; Tue, 18 Oct 2011 14:13:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=301; q=dns/txt; s=iport; t=1318972424; x=1320182024; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=CmgGcI9r3VyeMR1c0QjQVyL2W74gZWypWCVRkwTrG7s=; b=biI3JFwraz6WsGimBFw5Och/U6eDH/4+EVYXuvl8QHwGB2PNRRO/CHGL qJFZ9kNq8C/+eys9xDjhLC0VvpwLCxvXhzgKdK951MA/vifWxrGuZ5kg4 LWT8wVb7tZsrrskrofetg7IMzmO5lb3/2TjtYBR2Ma7GdDu+oxrlj598Z s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAMjrnU6tJV2a/2dsb2JhbABEqG6BBYFuAQEBAwESASc/BQsLRlcGNYdel3YBnkiHOmEEiAKLe5F2 X-IronPort-AV: E=Sophos;i="4.69,366,1315180800"; d="scan'208";a="29341471" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-5.cisco.com with ESMTP; 18 Oct 2011 21:13:43 +0000 Received: from dhcp-171-70-217-213.cisco.com (dhcp-171-70-217-213.cisco.com [171.70.217.213]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p9ILDghw028204; Tue, 18 Oct 2011 21:13:43 GMT Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: Date: Tue, 18 Oct 2011 14:13:42 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1DEFCFF8-4F23-4D84-914D-AB50233C8C06@cisco.com> References: <4E9D667A.2040703@alvestrand.no> <4E9DBECC.6000206@alvestrand.no> To: Wolfgang Beck X-Mailer: Apple Mail (2.1251.1) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] My Opinion: Why I think a negotiating protocol is a Good Thing X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 21:13:44 -0000 On Oct 18, 2011, at 11:29 , Wolfgang Beck wrote: > Depressingly few SIP providers do interconnection, after all those > years. Interesting - most the people I seem to deal with need to send SIP from = one domain to another. Who are you thinking of that does not need to do = interconnect? From ekr@rtfm.com Tue Oct 18 14: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 6081921F8C19 for ; Tue, 18 Oct 2011 14:19:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.952 X-Spam-Level: X-Spam-Status: No, score=-102.952 tagged_above=-999 required=5 tests=[AWL=0.025, 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 tki2-I6-VZeW for ; Tue, 18 Oct 2011 14:19: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 D39D521F8C17 for ; Tue, 18 Oct 2011 14:19:27 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so1137374vcb.31 for ; Tue, 18 Oct 2011 14:19:27 -0700 (PDT) Received: by 10.52.99.195 with SMTP id es3mr4361062vdb.63.1318972767096; Tue, 18 Oct 2011 14:19:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.161.20 with HTTP; Tue, 18 Oct 2011 14:18:47 -0700 (PDT) In-Reply-To: References: <4E9D773A.4010705@ericsson.com> From: Eric Rescorla Date: Tue, 18 Oct 2011 14:18:47 -0700 Message-ID: To: Hadriel Kaplan Content-Type: text/plain; charset=ISO-8859-1 Cc: "rtcweb@ietf.org" , "rtcweb-chairs@tools.ietf.org" Subject: Re: [rtcweb] Current state of signaling discussion X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 21:19:28 -0000 On Tue, Oct 18, 2011 at 2:05 PM, Hadriel Kaplan wrote: > > In the abstract it states: > "The protocol focuses solely on media negotiation and does not handle call control, call processing, or other functions." > > Ignoring esoteric stuff like session transfer, forwarding, etc. (ie, ignoring "phone" stuff) is fine. > > BUT, for an actual session protocol to work for even a gaming app, you need to do the following: > 1) determine a target for the ROAP message (ie, who's this OFFER going to in the end?) > 2) define how that target identity is conveyed (ie, how does the web server know which browser to give this ROAP OFFER to?) > 3) define a source identity model, possibly with authentication (ie, who are you?) > 4) define how the source identity is conveyed (ie, how does the server/far-end-browser know who's calling?) One might already have much of this stuff in your application to support whatever person-to-person communications (E.g., IM) you already have. When I heard "20 lines of code" I always assumed that it excluded that sort of routing-type stuff. > 5) define a end-of-session indication > 6) define a keep-alive mechanism, for when the far end goes away silently and (5) doesn't apply Do these involve a lot of code? -Ekr From ibc@aliax.net Tue Oct 18 14:48: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 0671F21F87FA for ; Tue, 18 Oct 2011 14:48:33 -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 UD-UQBGdU7Ox for ; Tue, 18 Oct 2011 14:48:32 -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 6DD6721F87C5 for ; Tue, 18 Oct 2011 14:48:32 -0700 (PDT) Received: by vws5 with SMTP id 5so984241vws.31 for ; Tue, 18 Oct 2011 14:48:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.35.34 with SMTP id e2mr4343954vdj.52.1318974072653; Tue, 18 Oct 2011 14:41:12 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Tue, 18 Oct 2011 14:41:12 -0700 (PDT) In-Reply-To: References: <4E9D773A.4010705@ericsson.com> Date: Tue, 18 Oct 2011 23:41:12 +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: "rtcweb@ietf.org" , "rtcweb-chairs@tools.ietf.org" Subject: Re: [rtcweb] Current state of signaling discussion X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 21:48:33 -0000 2011/10/18 Hadriel Kaplan : > In the abstract it states: > "The protocol focuses solely on media negotiation and does not handle cal= l control, call processing, or other functions." > > Ignoring esoteric stuff like session transfer, forwarding, etc. (ie, igno= ring "phone" stuff) is fine. > > BUT, for an actual session protocol to work for even a gaming app, you ne= ed to do the following: > 1) determine a target for the ROAP message (ie, who's this OFFER going to= in the end?) > 2) define how that target identity is conveyed (ie, how does the web serv= er know which browser to give this ROAP OFFER to?) > 3) define a source identity model, possibly with authentication (ie, who = are you?) > 4) define how the source identity is conveyed (ie, how does the server/fa= r-end-browser know who's calling?) > 5) define a end-of-session indication > 6) define a keep-alive mechanism, for when the far end goes away silently= and (5) doesn't apply > > And I've probably missed some other things. Hi Hadriel, if ROAP draft specifies all the points above it becomes an entire signaling protocol, and AFAIK we don't want that. If I use SIP over WebSocket I just want (and need) to use SIP for signaling. So the JS client constructs an INVITE which tells the proxy/server who he claims to be. The proxy (speaking SIP over WebSocket) acts as a normal SIP proxy for routing requests and responses, requiring authentication, performing authorization, registration (or routing the REGISTER to a pure registrar server behind it...). So I don't see the need for ROAP to become a on-the-wire signaling protocol. In fact, I don't support that idea. I'm happy if ROAP just covers the communication between the JS and the browser RTCweb stack. How the signaling messages (including the SDP or "like-SDP") are carried on the wire should be out of the scope of ROAP (the draft already is defined for being singaling protocol agnostic). Regards. --=20 I=C3=B1aki Baz Castillo From HKaplan@acmepacket.com Tue Oct 18 14:53:06 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 431ED1F0C76 for ; Tue, 18 Oct 2011 14:53:06 -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 tVEHPwGSlDNl for ; Tue, 18 Oct 2011 14:53:05 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 0209F1F0C7A for ; Tue, 18 Oct 2011 14:53: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, 18 Oct 2011 17:53:00 -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; Tue, 18 Oct 2011 17:53:00 -0400 From: Hadriel Kaplan To: Eric Rescorla Thread-Topic: [rtcweb] Current state of signaling discussion Thread-Index: AQHMjeBN9USwkyocF0KQH5G/+0/FIA== Date: Tue, 18 Oct 2011 21:52:59 +0000 Message-ID: <48FB392E-A65C-44B8-B526-D7DD10C72D7E@acmepacket.com> References: <4E9D773A.4010705@ericsson.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: <5163235E6293C947A9E1D3B14FB7DF74@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "rtcweb@ietf.org" , "rtcweb-chairs@tools.ietf.org" Subject: Re: [rtcweb] Current state of signaling discussion X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 21:53:06 -0000 On Oct 18, 2011, at 5:18 PM, Eric Rescorla wrote: > One might already have much of this stuff in your application to support > whatever person-to-person communications (E.g., IM) you already > have. When I heard "20 lines of code" I always assumed that it excluded t= hat > sort of routing-type stuff. But that's the point exactly - OF COURSE that type of stuff might already b= e in your application, and could be conveyed in a URL or all be implicit or= whatever. Or it might not at all be in your app and need to added for thi= s in some way. =20 And that's the point many of us have been making: don't define a standard s= ignaling protocol, because it's all application-specific to the web-app, wh= ich only the web-app developer would possibly know. Thus, I'm asking the chairs what they mean when they use the word "signalin= g". If they mean session signaling, then ROAP doesn't do it either. If th= ey only mean media-setup+negotiation signaling, that's a different problem = scope. (I think that too is unnecessary, but if you put full SDP offer/answ= er state in the browser, then it's probably a fait accompli) -hadriel From ekr@rtfm.com Tue Oct 18 15: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 0DF8321F8B11 for ; Tue, 18 Oct 2011 15:01:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.956 X-Spam-Level: X-Spam-Status: No, score=-102.956 tagged_above=-999 required=5 tests=[AWL=0.021, 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 mMPgQKVprfno for ; Tue, 18 Oct 2011 15:01: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 83ACD21F8B10 for ; Tue, 18 Oct 2011 15:01:47 -0700 (PDT) Received: by vws5 with SMTP id 5so993588vws.31 for ; Tue, 18 Oct 2011 15:01:47 -0700 (PDT) Received: by 10.52.91.7 with SMTP id ca7mr4459401vdb.29.1318974990474; Tue, 18 Oct 2011 14:56:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.161.20 with HTTP; Tue, 18 Oct 2011 14:55:50 -0700 (PDT) In-Reply-To: <48FB392E-A65C-44B8-B526-D7DD10C72D7E@acmepacket.com> References: <4E9D773A.4010705@ericsson.com> <48FB392E-A65C-44B8-B526-D7DD10C72D7E@acmepacket.com> From: Eric Rescorla Date: Tue, 18 Oct 2011 14:55:50 -0700 Message-ID: To: Hadriel Kaplan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" , "rtcweb-chairs@tools.ietf.org" Subject: Re: [rtcweb] Current state of signaling discussion X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 22:01:48 -0000 On Tue, Oct 18, 2011 at 2:52 PM, Hadriel Kaplan wr= ote: > > On Oct 18, 2011, at 5:18 PM, Eric Rescorla wrote: > >> One might already have much of this stuff in your application to support >> whatever person-to-person communications (E.g., IM) you already >> have. When I heard "20 lines of code" I always assumed that it excluded = that >> sort of routing-type stuff. > > But that's the point exactly - OF COURSE that type of stuff might already= be in your application, and could be conveyed in a URL or all be implicit = or whatever. =A0Or it might not at all be in your app and need to added for= this in some way. > > And that's the point many of us have been making: don't define a standard= signaling protocol, because it's all application-specific to the web-app, = which only the web-app developer would possibly know. I'm not sure why you're arguing with me. Did I say something different? -Ekr From ibc@aliax.net Tue Oct 18 15:04: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 C668E21F8B10 for ; Tue, 18 Oct 2011 15:04:15 -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 YDP6ubUt870Q for ; Tue, 18 Oct 2011 15:04:15 -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 55AD321F8B02 for ; Tue, 18 Oct 2011 15:04:15 -0700 (PDT) Received: by vws5 with SMTP id 5so995170vws.31 for ; Tue, 18 Oct 2011 15:04:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.25.75 with SMTP id a11mr4490703vdg.1.1318975127875; Tue, 18 Oct 2011 14:58:47 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Tue, 18 Oct 2011 14:58:47 -0700 (PDT) In-Reply-To: References: <4E9D773A.4010705@ericsson.com> Date: Tue, 18 Oct 2011 23:58:47 +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: "rtcweb@ietf.org" , "rtcweb-chairs@tools.ietf.org" Subject: Re: [rtcweb] Current state of signaling discussion X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 22:04:15 -0000 2011/10/18 I=C3=B1aki Baz Castillo : > Hi Hadriel, if ROAP draft specifies all the points above it becomes an > entire signaling protocol, and AFAIK we don't want that. I've understood the motivation of your mail after re-reading it. Of course you don't want a default signaling protocol :) --=20 I=C3=B1aki Baz Castillo From pravindran@sonusnet.com Tue Oct 18 16:13: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 1C37A1F0C36 for ; Tue, 18 Oct 2011 16:13:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.924 X-Spam-Level: X-Spam-Status: No, score=-2.924 tagged_above=-999 required=5 tests=[AWL=-0.325, 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 n+W-Ob7F8ItQ for ; Tue, 18 Oct 2011 16:13:07 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 652B921F8B91 for ; Tue, 18 Oct 2011 16:13: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 p9INDYBi025504; Tue, 18 Oct 2011 19:13:34 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail06.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 18 Oct 2011 19:12: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: Wed, 19 Oct 2011 04:42:20 +0530 Message-ID: <2E239D6FCD033C4BAF15F386A979BF511599FA@sonusinmail02.sonusnet.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] Current state of signaling discussion Thread-Index: AQHMjdmb9USwkyocF0KQH5G/+0/FIJWCuRLg References: <4E9D773A.4010705@ericsson.com> From: "Ravindran Parthasarathi" To: "Hadriel Kaplan" , "Eric Rescorla" X-OriginalArrivalTime: 18 Oct 2011 23:12:59.0510 (UTC) FILETIME=[7A456160:01CC8DEB] Cc: rtcweb@ietf.org, rtcweb-chairs@tools.ietf.org Subject: Re: [rtcweb] Current state of signaling discussion X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 23:13:08 -0000 Hi Hadriel, As you know in most of the IP real-time signaling protocol (SIP+SDP, H.323(H.225, H.245), MGCP+SDP), there are two aspects 1) Signaling (SIP, H.225) 2) Media description (SDP offer/answer, H.245) In case of Websocket or long poll HTTP, these protocol act as signaling whereas media description is missing. ROAP will fill this signaling protocol gap for websocket/HTTP. Thanks Partha >-----Original Message----- >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf >Of Hadriel Kaplan >Sent: Wednesday, October 19, 2011 2:35 AM >To: Eric Rescorla >Cc: rtcweb@ietf.org; rtcweb-chairs@tools.ietf.org >Subject: Re: [rtcweb] Current state of signaling discussion > > >In the abstract it states: >"The protocol focuses solely on media negotiation and does not handle >call control, call processing, or other functions." > >Ignoring esoteric stuff like session transfer, forwarding, etc. (ie, >ignoring "phone" stuff) is fine. > >BUT, for an actual session protocol to work for even a gaming app, you >need to do the following: >1) determine a target for the ROAP message (ie, who's this OFFER going >to in the end?) >2) define how that target identity is conveyed (ie, how does the web >server know which browser to give this ROAP OFFER to?) >3) define a source identity model, possibly with authentication (ie, who >are you?) >4) define how the source identity is conveyed (ie, how does the >server/far-end-browser know who's calling?) >5) define a end-of-session indication >6) define a keep-alive mechanism, for when the far end goes away >silently and (5) doesn't apply > >And I've probably missed some other things. > >-hadriel > > >On Oct 18, 2011, at 4:50 PM, Eric Rescorla wrote: > >> Is this actually correct? The introduction of that draft suggests >otherwise: >> >> "The protocol is designed to operate between two entities (browsers >> for example), which exchange messages "directly" - meaning that a >> message output by one entity is meant to be directly processed by the >> other entity without further modification. In practice, this means >> that a web server can treat ROAP messages as opaque and just shuffle >> them between browser instances. This allows for simple >> implementations." >> >> If we take the PeerConnection API as our point of reference, isn't the >> idea here that >> you would instantiate callbacks that take messages coming out of the >> PeerConnection >> API and push them to the Web server and messages coming from the Web >server >> and push them to the PeerConnection instance. I don't know if this is >20 lines >> of code (though with JS minimization it might be one line of code :)), >> but it does >> seem comparatively trivial... >> >> -Ekr >> >> >> >> >> -Ekr > >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb From pravindran@sonusnet.com Tue Oct 18 16:13: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 ACFDC1F0C36 for ; Tue, 18 Oct 2011 16:13:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.908 X-Spam-Level: X-Spam-Status: No, score=-2.908 tagged_above=-999 required=5 tests=[AWL=-0.310, 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 eTH09q2pucUL for ; Tue, 18 Oct 2011 16:13:07 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 6520C21F8AEC for ; Tue, 18 Oct 2011 16:13: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 p9INDZIA025507; Tue, 18 Oct 2011 19:13:35 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail06.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 18 Oct 2011 19:13: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_01CC8DEB.78691B7E" Date: Wed, 19 Oct 2011 04:42:56 +0530 Message-ID: <2E239D6FCD033C4BAF15F386A979BF511599F9@sonusinmail02.sonusnet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comment on draft-ietf-rtcweb-overview-02 (Browser RTC trapezoid) Thread-Index: AcyN6kSGwJVD/poTSuCXs2g3Vz18Sw== From: "Ravindran Parthasarathi" To: "Harald Alvestrand" X-OriginalArrivalTime: 18 Oct 2011 23:13:01.0275 (UTC) FILETIME=[7B52B2B0:01CC8DEB] Cc: rtcweb@ietf.org Subject: [rtcweb] Comment on draft-ietf-rtcweb-overview-02 (Browser RTC trapezoid) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 23:13:08 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC8DEB.78691B7E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Harald, =20 In Fig 2 (Browser RTC Trapezoid), I'm getting the feel that JS/HTML communicates with webserver directly without the involvement of browser. Please clarify whether it is intended not to use browser for JS. =20 IMO, the browser RTC trapezoid shall be=20 =20 +-----------+ +-----------+ | RTCWeb | Federation | RTCWeb | | | Signaling | | | |-------------| | | Server | protocol | Server | | | | | +-----------+ +-----------+ / \ / \ RTCWeb / \ Signaling / \ / RTCWeb \ / Signaling \ / \ +-----------+ +-----------+ | | | | | | | | | Browser | ------------------------- | Browser | | | Media path | | | | | | +-----------+ +-----------+ +-----------+ +-----------+ |JS/HTML/CSS| |JS/HTML/CSS| +-----------+ +-----------+ =20 I explained the same diagram in Fig 1 of draft-partha-rtcweb-signaling-00. RTCWeb signaling shall be proprietary HTTP/websocket. I'm asking this change because I'm seeing folks confuses API vs. on-wire-protocol. Also, Please note that JS + browser is the single system with two different modules and it shall have protocol or API to communicate (without passing any information in the wire). Could you please let me know in case I'm missing something. =20 Thanks Partha =20 ------_=_NextPart_001_01CC8DEB.78691B7E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Harald,

 

In Fig 2 (Browser RTC Trapezoid), I’m getting = the feel that JS/HTML communicates with webserver directly without the = involvement of browser. Please clarify whether it is intended not to use browser  for = JS.

 

IMO, the browser RTC trapezoid shall be =

 

   =             &= nbsp;   +-----------+      &= nbsp;      +-----------+

           &= nbsp;       |   RTCWeb  |  Federation |   RTCWeb  = |

           &= nbsp;       |           |  Signaling  = |           = |

           &= nbsp;       |           |-------------|         &nbs= p; |

           &= nbsp;       |  Server   |   protocol  |  Server   |

           &= nbsp;       |           |            = |           = |

           &= nbsp;       +-----------+          =    +-----------+

           &= nbsp;            /            =             &= nbsp;  \

           &= nbsp;           /            =             &= nbsp;    \   RTCWeb

           &= nbsp;          /            =             &= nbsp;      \  Signaling

           &= nbsp;         /            =             &= nbsp;        \

           &= nbsp;        /  RTCWeb           &= nbsp;           &n= bsp;   \

           &= nbsp;       /   Signaling          &nbs= p;            = ;  \

           &= nbsp;      /        =             &= nbsp;           &n= bsp;      \

            +-----------+          =             &= nbsp;    +-----------+

            |           |            =             &= nbsp;  |           = |

            |           |            =             &= nbsp;  |           = |

            |  Browser  | ------------------------- |  Browser  = |

            |           |          Media path       = |           |

            |           |            =             &= nbsp;  |           = |

            +-----------+          =             &= nbsp;    +-----------+

    =         +-----------+  =             &= nbsp;            +-----------+

            |JS/HTML/CSS|          =             &= nbsp;    |JS/HTML/CSS|

            +-----------+          =             &= nbsp;    +-----------+

 


I explained the same diagram in Fig 1 of = draft-partha-rtcweb-signaling-00. RTCWeb signaling shall be proprietary HTTP/websocket. I’m asking this = change because I’m seeing folks confuses API vs. on-wire-protocol. Also, = Please note that JS + browser is the single system with two different modules = and it shall have protocol or API to communicate (without passing any = information in the wire). Could you please let me know in case I’m missing = something.

 

Thanks

Partha

 

------_=_NextPart_001_01CC8DEB.78691B7E-- From ted.ietf@gmail.com Tue Oct 18 16:22: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 0AE1A21F8AAF for ; Tue, 18 Oct 2011 16:22:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.954 X-Spam-Level: X-Spam-Status: No, score=-1.954 tagged_above=-999 required=5 tests=[AWL=-0.957, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_OBFUSCATE_10_20=2.601, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2a4w7YaFwhP8 for ; Tue, 18 Oct 2011 16:22: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 1940621F8A70 for ; Tue, 18 Oct 2011 16:22:51 -0700 (PDT) Received: by yxj19 with SMTP id 19so1350830yxj.31 for ; Tue, 18 Oct 2011 16:22:50 -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:content-type; bh=oYUtG0+MKa6Y2WNOichbD5SSpZkVw1oeR1+4YBeABfc=; b=KMH3wBMa8KL0RRqWlKImRDkNLLnJz8x6erz3lg6kJvhgdtDMc/ZcyovWycG71HJNhl iN1HOlbDdJmBcQYG/h/CQ3GWjhQsABVLaEiasUayOVXs0gvxqQEi8w98qpapIyqH/RKm 70vNNB7ujtLrqk60GX1zQ09lETDM1LRWfBy8I= MIME-Version: 1.0 Received: by 10.236.73.130 with SMTP id v2mr6608186yhd.57.1318980170588; Tue, 18 Oct 2011 16:22:50 -0700 (PDT) Received: by 10.236.105.169 with HTTP; Tue, 18 Oct 2011 16:22:50 -0700 (PDT) Date: Tue, 18 Oct 2011 16:22:50 -0700 Message-ID: From: Ted Hardie To: rtcweb@ietf.org Content-Type: multipart/alternative; boundary=20cf3005151888a2ae04af9b0058 Subject: [rtcweb] Friday Call details for signaling discussion X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 23:22:52 -0000 --20cf3005151888a2ae04af9b0058 Content-Type: text/plain; charset=ISO-8859-1 Below are the call-in details for Friday's call. This is meant to give any interested working group participants some extra time in high-bandwidth discussions while we hash out the signaling proposals that have circulated on the list. I expect discussion will include ROAP as well as either a proposal from Hadriel and/or Wolfgang Beck's alt-ic draft. This is not an interim meeting, and no decisions will be taken on this call; it has no special status over any other discussions. Thanks to Cullen for arranging the Webex bridge. regards, Ted Topic: RTCWeb Date: Friday, October 21, 2011 Time: 7:00 am, Pacific Daylight Time (San Francisco, GMT-07:00) Meeting Number: 201 918 267 Meeting Password: ietf Host Key: 107934 ------------------------------------------------------- To start the online meeting ------------------------------------------------------- 1. Go to https://cisco.webex.com/ciscosales/j.php?ED=177179667&UID=482186897&PW=NN2U5ZTQxYmE5&RT=MiM0 2. Log in to your account. 3. Click "Start Now". 4. Follow the instructions that appear on your screen. ---------------------------------------------------------------- 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". To update this meeting to your calendar program (for example Microsoft Outlook), click this link: https://cisco.webex.com/ciscosales/j.php?ED=177179667&UID=482186897&ICS=MIU1&LD=1&RD=2&ST=1&SHA2=VSvxj0KwVStvk6aYb0aofqlHI06wOxeTdOeWJrkBJdY= To check whether you have the appropriate players installed for UCF (Universal Communications Format) rich media files, go to https://cisco.webex.com/ciscosales/systemdiagnosis.php http://www.webex.com --20cf3005151888a2ae04af9b0058 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Below are the call-in details for Friday's call.=A0 This is meant to gi= ve any interested working group participants some extra time in high-bandwi= dth discussions while we hash out the signaling proposals that have circula= ted on the list.=A0 I expect discussion will include ROAP as well as either= a proposal from Hadriel and/or Wolfgang Beck's alt-ic draft.=A0

This is not an interim meeting, and no decisions will be taken on this = call; it has no special status over any other discussions.

Thanks t= o Cullen for arranging the Webex bridge.

regards,

Ted

Topi= c: RTCWeb=A0
Date: Friday, = October 21, 2011=A0
Time: 7= :00 am, Pacific Daylight Time (San Francisco, GMT-07:00)=A0
Meeting Number: 201 918 267=A0=
Meeting Password: ietf=A0<= br>Host Key: 107934=A0

= -------------------------------------------------------=A0
To start the online meeting=A0=
-------------------------------------------------------=A0
1. Go to=A0https://ci= sco.webex.com/ciscosales/j.php?ED=3D177179667&UID=3D482186897&PW=3D= NN2U5ZTQxYmE5&RT=3DMiM0=A0
2. Log in to your account.=A0<= br>3. Click "Start Now".=A0=
4. Follow the instructions that appear on your screen.=A0

----------------------------------------------------------------=A0
ALERT:Toll-Free Dial Restricti= ons for (408) and (919) Area Codes=A0=
----------------------------------------------------------------=A0

The affected toll free numbers= are:=A0(866) 432-9903=A0for the San Jose/Milpitas area and=A0(866) 349-3520=A0for the RTP area.=A0

Please dial the local access number for your area from the list below:<= span class=3D"Apple-converted-space">=A0
- San Jose/Milpitas (408= ) area: 525-6800=A0
- RTP (= 919) area: 392-3330=A0

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

San Jose, CA:=A0+1.408.525.6800=A0RTP:=A0+1.91= 9.392.3330=A0

US/Canada:=A0+1.866.432.9903=A0United Kingdom:=A0= +44.20.8824.0117=A0

India:=A0+91.80.4350.1111=A0Germany:=A0+49.61= 9.6773.9002=A0

Japan:=A0+81.3.5763.9394=A0China:=A0= +86.10.8515.5= 666=A0

-------------------------------------------------------=A0
For assistance=A0
------------------------------------------------= -------=A0
1. Go to=A0https://cisco.webex.com/ciscosales/mc=A0
2. On the left navigation bar, click "Support".=A0
To update this meeting to your calendar p= rogram (for example Microsoft Outlook), click this link:=A0
https://cisco.webex.com/ciscosales= /j.php?ED=3D177179667&UID=3D482186897&ICS=3DMIU1&LD=3D1&RD= =3D2&ST=3D1&SHA2=3DVSvxj0KwVStvk6aYb0aofqlHI06wOxeTdOeWJrkBJdY=3D=A0

To check whether you have the appropriate players installed for UCF (Un= iversal Communications Format) rich media files, go tohttps://cisco.webex.com/ciscosale= s/systemdiagnosis.php=A0
http://www.webex.com

--20cf3005151888a2ae04af9b0058-- From fluffy@cisco.com Tue Oct 18 16:35: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 C9D4421F85AE for ; Tue, 18 Oct 2011 16:35:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.549 X-Spam-Level: X-Spam-Status: No, score=-106.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 yvTXPKZOsvqM for ; Tue, 18 Oct 2011 16:35:41 -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 2884B21F841D for ; Tue, 18 Oct 2011 16:35:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=996; q=dns/txt; s=iport; t=1318980941; x=1320190541; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=mW+01sv0LUA+IFUtZ5Ehto0VzkIf/zXwvF7vgiblbO0=; b=I1Fd7Yv+IODAcHHFKMoteBQkOwzXsRyyZrcOSLbIjdr/z+p9Oawu55pZ j3vlsAkmlbwoGmIziMSespFIFXKtgIQAMGg2U1MCZk9FExBMJegdbB3zY ucYPT01PMA/TFD3v8OoMApoXvzD0rSj+P/J3txXAqKS31vS+jYsTLyCsP 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAMYMnk6rRDoJ/2dsb2JhbAA7CahwgQWBbgEBAQMBEgEnPwULCw44VwY1h16XbAGePYRtgk1hBIgCi3uRdg X-IronPort-AV: E=Sophos;i="4.69,368,1315180800"; d="scan'208";a="8447737" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 18 Oct 2011 23:35:40 +0000 Received: from dhcp-171-70-217-213.cisco.com (dhcp-171-70-217-213.cisco.com [171.70.217.213]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p9INZe3m021246; Tue, 18 Oct 2011 23:35:40 GMT Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: Date: Tue, 18 Oct 2011 16:35:39 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3710890A-04D8-4050-A090-FE93DCD073FD@cisco.com> References: <4E9D773A.4010705@ericsson.com> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1251.1) Cc: "rtcweb@ietf.org" , "rtcweb-chairs@tools.ietf.org" Subject: Re: [rtcweb] Current state of signaling discussion X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 23:35:41 -0000 On Oct 18, 2011, at 14:05 , Hadriel Kaplan wrote: > BUT, for an actual session protocol to work for even a gaming app, you = need to do the following: > 1) determine a target for the ROAP message (ie, who's this OFFER going = to in the end?) > 2) define how that target identity is conveyed (ie, how does the web = server know which browser to give this ROAP OFFER to?) > 3) define a source identity model, possibly with authentication (ie, = who are you?) > 4) define how the source identity is conveyed (ie, how does the = server/far-end-browser know who's calling?) > 5) define a end-of-session indication > 6) define a keep-alive mechanism, for when the far end goes away = silently and (5) doesn't apply I've thought a bunch about this - In addition to those, I think we need = a way to cache state, sort of like cookie or something. That gets passed = back at the right time. That type of thing makes it much easier for the = web-service to keep track of things.=20 From ted.ietf@gmail.com Tue Oct 18 16:40: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 DB2D421F8B10 for ; Tue, 18 Oct 2011 16:40:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.159 X-Spam-Level: X-Spam-Status: No, score=-3.159 tagged_above=-999 required=5 tests=[AWL=0.439, 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 z4xmitMr6Kh4 for ; Tue, 18 Oct 2011 16:40:39 -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 07DD921F8B0B for ; Tue, 18 Oct 2011 16:40:38 -0700 (PDT) Received: by ggnv1 with SMTP id v1so1349034ggn.31 for ; Tue, 18 Oct 2011 16:40: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; bh=GMNBz/3SnoodR3rXlpUaHE9VRZ2DjKmJHtmfmH+YoEs=; b=rUgOx15getEgR4Z7W1i5wpD2aeZU5GH3egxpDgsBjEpsTZd6BrPlIQc7FKgHKUEVT3 /ox7wvYJZkgYdcGeQe260FxBgpczRCCpzb9WuD8bU/eBJnERKulyTVWJQK4aSS4ObjUI 0y2POtNLkDxuBB+oxLwwcQSGw5UQT/+8qRsiM= MIME-Version: 1.0 Received: by 10.236.131.40 with SMTP id l28mr6918616yhi.6.1318981238584; Tue, 18 Oct 2011 16:40:38 -0700 (PDT) Received: by 10.236.105.169 with HTTP; Tue, 18 Oct 2011 16:40:38 -0700 (PDT) In-Reply-To: <37796D08-7A24-478B-8157-052FFB2E3945@acmepacket.com> References: <2E239D6FCD033C4BAF15F386A979BF510F1367@sonusinmail02.sonusnet.com> <4E8AC222.4050308@alvestrand.no> <2E239D6FCD033C4BAF15F386A979BF510F14CE@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF510F14FD@sonusinmail02.sonusnet.com> <393F1888-F834-4DAE-B6B1-1C5D35EE3292@phonefromhere.com> <2E239D6FCD033C4BAF15F386A979BF510F152B@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF510F1532@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF511598EE@sonusinmail02.sonusnet.com> <665A16AB-AAD8-42B3-AC17-7E629EA2DE35@phonefromhere.com> <2E239D6FCD033C4BAF15F386A979BF5115992E@sonusinmail02.sonusnet.com> <0950F0E1-6E4B-407F-9563-654AFE79F64B@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF51159994@sonusinmail02.sonusnet.com> <1F2A2C70609D9E41844A2126145FC09804004302@HKGMBOXPRD22.polycom.com> <033458F56EC2A64E8D2D7B759FA3E7E703DBF614@sonusmail04.sonusnet.com> <8486C8728176924BAF5BDB2F7D7EEDDF3E091D13@ucolhp4d.easf.csd.disa.mil> <2E239D6FCD033C4BAF15F386A979BF511599F3@sonusinmail02.sonusnet.com> <37796D08-7A24-478B-8157-052FFB2E3945@acmepacket.com> Date: Tue, 18 Oct 2011 16:40:38 -0700 Message-ID: From: Ted Hardie To: Hadriel Kaplan Content-Type: multipart/alternative; boundary=20cf301afabb30f5dd04af9b400e Cc: "" Subject: Re: [rtcweb] Review request for RTCWeb standard 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: Tue, 18 Oct 2011 23:40:40 -0000 --20cf301afabb30f5dd04af9b400e Content-Type: text/plain; charset=ISO-8859-1 On Tue, Oct 18, 2011 at 1:43 PM, Hadriel Kaplan wrote: > > > You make this sound like you believe this to be an advantage. > > > > It *is* an advantage. It puts the power in the hands of the app > developer, not the browser developer. > > > As Peter Parker's uncle Ben tells, us, with great power comes great responsibility. Yes, it gives them a choice, but it also makes them responsible for something that is, bluntly, infrastructure plumbing that most of them would rather just worked. > Having seen the bit-rot in quite a few libraries, > > > Have you ever used Internet Explorer?? > > Not lately; it doesn't run on any of my current platforms. > (and I'm not slamming IE because I think their developers are bad - they > have a very tough job of keeping compatibility with numerous Windows OS > versions, drivers, etc. - I just think they'll focus on doing that rather > dealing with signaling protocol changes/bug-fixes for RTCWeb in any timely > manner) > > It's certainly less efficient and, given the majority of users now > accessing the Internet via mobile devices which are power and bandwidth > constrained, that sort of wastefulness should not be trivially dismissed. > > > If a mobile platform is so constrained of power and bandwidth that > downloading a JS library is difficult, it's unlikely it would be able to > handle RTP/RTCP media regardless. > > You don't get to be rich by making a lot of money, you get to be rich by keeping it. The same is true with energy in mobile systems. Pay attention to it all the time, and there's a fair chance you will never run out. Pay attention to it only when you're low, and you're likely paying attention to late. regards, Ted > -hadriel > > --20cf301afabb30f5dd04af9b400e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Oct 18, 2011 at 1:43 PM, Hadriel Kaplan <<= a href=3D"mailto:HKaplan@acmepacket.com">HKaplan@acmepacket.com> wrote:


You make this sound like you believe this to be an advantage.=A0


It *is* an advantage. =A0It puts the power in the hands of the a= pp developer, not the browser developer.



As Peter Parker's uncle Ben= tells, us, with great power comes great responsibility.=A0 Yes, it gives t= hem a choice, but it also makes them responsible for something that is, blu= ntly, infrastructure plumbing that most of them would rather just worked. <= br>
Having seen the bit-rot in quite a few libraries,=A0

Have you ever used Internet Explorer??=A0
=A0

Not lately; it doesn&= #39;t run on any of my current platforms.
=A0
(and I'm not slamming IE because I think their developers are bad = - they have a very tough job of keeping compatibility with numerous Windows= OS versions, drivers, etc. - I just think they'll focus on doing that = rather dealing with signaling protocol changes/bug-fixes for RTCWeb in any timely manner)

It's certainly less efficient and, given the majority of users now= accessing the Internet via mobile devices which are power and bandwidth co= nstrained, that sort of wastefulness should not be trivially dismissed. =A0=

If a mobile platform is so constrained of power and bandwidth that dow= nloading a JS library is difficult, it's unlikely it would be able to h= andle RTP/RTCP media regardless.


You don't get to be rich by = making a lot of money, you get to be rich by keeping it.=A0 The same is tru= e with energy in mobile systems.=A0 Pay attention to it all the time, and t= here's a fair chance you will never run out.=A0 Pay attention to it onl= y when you're low, and you're likely paying attention to late.=A0 <= br>
regards,

Ted

=A0
-hadriel


--20cf301afabb30f5dd04af9b400e-- From pravindran@sonusnet.com Tue Oct 18 18:12: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 03A8021F869E for ; Tue, 18 Oct 2011 18:12:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.744 X-Spam-Level: X-Spam-Status: No, score=-2.744 tagged_above=-999 required=5 tests=[AWL=-0.446, 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 ggMwOS-B4F-B for ; Tue, 18 Oct 2011 18:12:21 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id E36E321F84C1 for ; Tue, 18 Oct 2011 18:12:20 -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 p9J1Cpjs005231; Tue, 18 Oct 2011 21:12:51 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail07.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 18 Oct 2011 21:12:14 -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_01CC8DFC.1F79A1C0" Date: Wed, 19 Oct 2011 06:42:07 +0530 Message-ID: <2E239D6FCD033C4BAF15F386A979BF511599FD@sonusinmail02.sonusnet.com> In-Reply-To: <033458F56EC2A64E8D2D7B759FA3E7E703DBF6D4@sonusmail04.sonusnet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] Review request for RTCWeb standard signaling protocol Thread-Index: AcyN0FNRa8PK4bssTZKb604uAWGvqgAAmDyQAAa+WLA= References: <2E239D6FCD033C4BAF15F386A979BF510F1367@sonusinmail02.sonusnet.com><4E8AC222.4050308@alvestrand.no><2E239D6FCD033C4BAF15F386A979BF510F14CE@sonusinmail02.sonusnet.com><2E239D6FCD033C4BAF15F386A979BF510F14FD@sonusinmail02.sonusnet.com><393F1888-F834-4DAE-B6B1-1C5D35EE3292@phonefromhere.com><2E239D6FCD033C4BAF15F386A979BF510F152B@sonusinmail02.sonusnet.com><2E239D6FCD033C4BAF15F386A979BF510F1532@sonusinmail02.sonusnet.com><2E239D6FCD033C4BAF15F386A979BF511598EE@sonusinmail02.sonusnet.com><665A16AB-AAD8-42B3-AC17-7E629EA2DE35@phonefromhere.com><2E239D6FCD033C4BAF15F386A979BF5115992E@sonusinmail02.sonusnet.com><0950F0E1-6E4B-407F-9563- 654AFE79 F64B@ag-pro jects.com><2E239D6FCD033C4BAF15F386A979BF51159994@sonusinmail02.sonusnet.com><1F2A2C70609D9E41844A2126145FC09804004302@HKGMBOXPRD22.polycom.com><033458F56EC2A64E8D2D7B759FA3E7E703DBF614@sonusmail04.sonusnet.com><8486C8728176924BAF5BDB2F7D7EEDDF3E091D13@ucolhp4d.easf.csd.disa.mil><2E239D6FCD033C4BAF15F386A979BF511599F3@sonusinmail02.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E703DBF6D4@sonusmail04.sonusnet.com> From: "Ravindran Parthasarathi" To: "Asveren, Tolga" , "Ted Hardie" , =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= X-OriginalArrivalTime: 19 Oct 2011 01:12:14.0951 (UTC) FILETIME=[233F0770:01CC8DFC] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Review request for RTCWeb standard 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: Wed, 19 Oct 2011 01:12:28 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC8DFC.1F79A1C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Tolga, =20 My basic doubt is how to you ensure jquery library does not have malware = without understanding its detail functionality. AFAIK, Small Web = developer test cycle is very different from exhaustive testing by OEM.=20 =20 In case your concern is related to browser compatibility for the = specific service or RTCWeb compliant, it is unavoidable and it is based = on my end-user browser experience. IETF-81 meetecho conference tool = supports HTML5 which is not working in my browsers (IE8 in windows XP) = and I forced to download Chrome to attend IETF RTCWeb session from = remote. In fact I'm asking for standard because with having HTML5 sort = of standard itself, I'm not getting update with few browsers and without = any standard, none of the browsers (Chrome, Firefox) will support. =20 Based on the above, if you conclude that it is better for everybody to = write signaling protocol and then it may apply to RTCWeb media protocol = as well because it is not guaranteed that browser-x will be RTCWeb = compliant at which release-y. I doubt whether I will get IE update for = HTML5 or RTCWeb anytime soon without OS upgrade ;-). Of course, lot of = Real-time web application is possible without RTCWeb browser using = Jquery and plugins. Your proposal is to avoid plugin only and keep = jquery as such but plugin may be preferred in case of custom build = application wherein compressed RTP/RTCP is the focus. =20 So, IMO standards may not help for the above scenarios. Wherein IETF = standards helps for=20 =20 1) Ensuring interop between RTCWeb client (browser which are = compatible) and RTCWeb server for signaling, RTCWeb client to RTCWeb = client for media 2) Comparatively easy RTCWeb application development in case = framework of the standard signaling protocol exists in the RTCWeb client = and RTCWeb server. 3) I'm worried for the delay because every conference session from = 512 kbps internet connection may take nearly 2 min to join the = conference after I login. The setup time matters because for every = meeting, I have to login before 2 min :-(.=20 4) In case RTCWeb signaling is defined, RTCWeb signaling to legacy = signaling gateway will be available for low cost in terms of $ compare = to the gateway which has to convert custom build. 5) Also ensure that Novice RTCWeb developer does not use = intellectual property of others (jquery library) without knowing in = detail. =20 Also, Some of the usecase which are not well discussed in this forum is = about RTCWeb usage with Enterprise, call center. I'm seeing RTCWeb as a = next generation collaborative mechanism (web + VoIP) rather than just = plugin removal WG. =20 Please note that I'm not talking about API because it is the programming = environment and W3C stuff. =20 Thanks Partha =20 From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf = Of Asveren, Tolga Sent: Wednesday, October 19, 2011 2:01 AM To: Ted Hardie; I=F1aki Baz Castillo Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Review request for RTCWeb standard signaling = protocol =20 Some opinions about the topics under discussion: =20 i- One difference between JS library and browser support is that service = developer can choose the JS library they want to use (or develop their = own). It is up to them to make sure that it works fine, does not have = malicious behavior etc... If they don't do their homework, their service = will fail. OTOH, service developer has no control over what is/will be = supported in the browser, e.g. browser-X supporting forking only after = release-Y. I also would expect that security requirement is more on the = browser so that it does not let potentially malicious things to be done = and this would be controlled by the enduser by its choice of browser. =20 ii- How big do we expect JS libraries to be? I think we assume that = battery/bandwidth is not a showstopper for realtime communication so I = would think JS library size would be a factor only if its ratio v.s. = media is non-negligible. =20 Thanks, Tolga =20 ________________________________ From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf = Of Ted Hardie Sent: Tuesday, October 18, 2011 3:59 PM To: I=F1aki Baz Castillo Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Review request for RTCWeb standard signaling = protocol =20 On Tue, Oct 18, 2011 at 11:34 AM, I=F1aki Baz Castillo = wrote: =09 When RTCweb becomes a reality there will appear thousands of JavaScript libraries implementing different RTCweb signaling protocols, each one with its own features and capabilities. Do you understand that a website admin will be able to choose the one he prefers? You make this sound like you believe this to be an advantage. Having = seen the bit-rot in quite a few libraries, I'm less included to assume = that every library created will be feature complete and well-maintained. = I'm equally leery of presuming that it is easy to chose among them. = Checking for embedded malware, to take a simple example, makes the task = longer and more fraught with issues than you might suppose. =20 Visit 100 random cool websites. Probably 50% of them use JQuery JS library. Does it mean that each web developer had to build his own JS library? not at all, they use JQuery. =09 Now your reply will be "downloading the JS library everytime is not efficient". Ok, visit 100 random cool websites. Probably 50% of them use JQuery JS library. How many times have you downloaded the JQuery library (assuming that every site has its own copy of the .js)? ... 50 times. Is that a problem? not for the rest of the humans in the world. It's certainly less efficient and, given the majority of users now = accessing the Internet via mobile devices which are power and bandwidth = constrained, that sort of wastefulness should not be trivially = dismissed. I =20 So please stop making up issues that don't exist. The WWW world does not work as you propose, and anyhow it has succeeded. =20 You set up a strawman that you attempted to knock down. He did not = propose it, you did. I also don't think you scored even a TKO on the = strawman. Again, please focus on your own points,=20 thanks, Ted Hardie =20 =09 =09 -- I=F1aki Baz Castillo _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb =20 ------_=_NextPart_001_01CC8DFC.1F79A1C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Tolga,

 

My basic doubt is how to you ensure jquery library does = not have malware without understanding its detail functionality. AFAIK, Small Web developer test cycle is very different from exhaustive testing by OEM. =

 

In case your concern is related to browser compatibility = for the specific service or RTCWeb compliant, it is unavoidable and it is based = on my end-user browser experience. IETF-81 meetecho conference tool supports = HTML5 which is not working in my browsers (IE8 in windows XP) and I forced to = download Chrome to attend IETF RTCWeb session from remote. In fact I’m asking for standard because with having HTML5 sort of standard itself, I’m = not getting update with few browsers and without any standard, none of the = browsers (Chrome, Firefox) will support.

 

Based on the above, if you conclude that it is better for everybody to write signaling protocol and then it may apply to RTCWeb = media protocol as well because it is not guaranteed that browser-x will be = RTCWeb compliant at which release-y. I doubt whether I will get IE update for = HTML5 or RTCWeb anytime soon without OS upgrade ;-). Of course, lot of Real-time = web application is possible without RTCWeb browser using Jquery and plugins. = Your proposal is to avoid plugin only and keep jquery as such but plugin may = be preferred in case of custom build application wherein compressed = RTP/RTCP is the focus.

 

=A0So, IMO standards may not help for the above = scenarios. Wherein IETF standards helps for

 

1)      Ensuring interop between RTCWeb client (browser which are compatible) and RTCWeb server for signaling,=A0 RTCWeb client to RTCWeb = client for media

2)      Comparatively easy RTCWeb application development in case framework of the standard signaling protocol exists in the RTCWeb client = and RTCWeb server.

3)      I’m worried for the delay because every conference = session from 512 kbps internet connection may take nearly 2 min to join the = conference after I login. =A0The setup time matters because for every meeting, I = have to login before 2 min :-(.

4)      In case RTCWeb signaling is defined, RTCWeb signaling to = legacy signaling=A0 gateway will be available for low cost in terms of $ = compare to the gateway which has to convert custom build.

5)      Also ensure that Novice RTCWeb developer does not use intellectual property of others (jquery library) without knowing in = detail.

 

Also, Some of the usecase which are not well discussed in = this forum is about RTCWeb usage with Enterprise, call center. I’m = seeing RTCWeb as a next generation collaborative mechanism (web + VoIP) rather than = just plugin removal WG.

 

Please note that I’m not talking about API because = it is the programming environment and W3C stuff.

 

Thanks

Partha

 

From:= rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of = Asveren, Tolga
Sent: Wednesday, October 19, 2011 2:01 AM
To: Ted Hardie; I=F1aki Baz Castillo
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Review request for RTCWeb standard = signaling protocol

 

Some opinions about the topics under = discussion:

 

i- One difference between JS library and browser support is = that service developer can choose the JS library they want to use (or develop = their own). It is up to them to make sure that it works fine, does not have = malicious behavior etc… If they don’t do their homework, their service = will fail. OTOH, service developer has no control over what is/will be = supported in the browser, e.g. browser-X supporting forking only after release-Y. I = also would expect that security requirement is more on the browser so that it does = not let potentially malicious things to be done and this would be controlled by = the enduser by its choice of browser.

 

ii- How big do we expect JS libraries to be? I think we = assume that battery/bandwidth is not a showstopper for realtime communication so I = would think JS library size would be a factor only if its ratio v.s. media is non-negligible.

 

Thanks,

Tolga

 

From:= rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of = Ted Hardie
Sent: Tuesday, October 18, 2011 3:59 PM
To: I=F1aki Baz Castillo
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Review request for RTCWeb standard = signaling protocol

 

On Tue, Oct 18, 2011 at 11:34 AM, I=F1aki Baz = Castillo <ibc@aliax.net> = wrote:

=


When RTCweb becomes a reality there will appear thousands of
JavaScript libraries implementing different RTCweb signaling
protocols, each one with its own features and capabilities. Do you
understand that a website admin will be able to choose the one he
prefers?


You make this sound like you believe this to be an advantage.  = Having seen the bit-rot in quite a few libraries,  I'm less included to assume = that every library created will be feature complete and = well-maintained.  I'm equally leery of presuming that it is easy to chose among them.  = Checking for embedded malware, to take a simple example, makes the task longer = and more fraught with issues than you might suppose.
 

=

Visit 100 random = cool websites. Probably 50% of them use JQuery JS
library. Does it mean that each web developer had to build his own = JS
library? not at all, they use JQuery.

Now your reply will be "downloading the JS library everytime is = not
efficient". Ok, visit 100 random cool websites. Probably 50% of = them
use JQuery JS library. How many times have you downloaded the JQuery
library (assuming that every site has its own copy of the .js)? ... = 50
times. Is that a problem? not for the rest of the humans in the = world.


It's certainly less efficient and, given the majority of users now = accessing the Internet via mobile devices which are power and bandwidth = constrained, that sort of wastefulness should not be trivially dismissed.  I
 

=

So please stop making up issues that don't exist. = The WWW world does
not work as you propose, and anyhow it has succeeded.

 


You set up a strawman that you attempted to knock down.  He did not propose it, you did.  I also don't think you scored even a TKO on = the strawman.  Again, please focus on your own points,

thanks,

Ted Hardie
 

=



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

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

 

------_=_NextPart_001_01CC8DFC.1F79A1C0-- From pravindran@sonusnet.com Tue Oct 18 20: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 134DB1F0C73 for ; Tue, 18 Oct 2011 20:32:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.725 X-Spam-Level: X-Spam-Status: No, score=-2.725 tagged_above=-999 required=5 tests=[AWL=-0.426, 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 b3MTzVgC9SJt for ; Tue, 18 Oct 2011 20:32:14 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 755F41F0C6F for ; Tue, 18 Oct 2011 20:32:14 -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 p9J3WgkT031239; Tue, 18 Oct 2011 23:32:42 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail04.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 18 Oct 2011 23:32:08 -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, 19 Oct 2011 09:02:01 +0530 Message-ID: <2E239D6FCD033C4BAF15F386A979BF51159A00@sonusinmail02.sonusnet.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Gateway need and usecase [was RE: [rtcweb] Review request for RTCWeb standard signaling protocol] Thread-Index: AcyNcsGc1/FirgngTX6nJ9FUa542OQAmqppg References: <2E239D6FCD033C4BAF15F386A979BF510F1367@sonusinmail02.sonusnet.com><4E8AC222.4050308@alvestrand.no><2E239D6FCD033C4BAF15F386A979BF510F14CE@sonusinmail02.sonusnet.com><2E239D6FCD033C4BAF15F386A979BF510F14FD@sonusinmail02.sonusnet.com><393F1888-F834-4DAE-B6B1-1C5D35EE3292@phonefromhere.com><2E239D6FCD033C4BAF15F386A979BF510F152B@sonusinmail02.sonusnet.com><2E239D6FCD033C4BAF15F386A979BF510F1532@sonusinmail02.sonusnet.com><2E239D6FCD033C4BAF15F386A979BF511598EE@sonusinmail02.sonusnet.com><665A16AB-AAD8-42B3-AC17-7E629EA2DE35@phonefromhere.com><2E239D6FCD033C4BAF15F386A979BF5115992E@sonusinmail02.sonusnet.com><0950F0E1-6E4B-407F-9563- 654AFE79 F64B@ag-proj ects.com><2E239D6FCD033C4BAF15F386A979BF51159994@sonusinmail02.sonusnet.com> From: "Ravindran Parthasarathi" To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= X-OriginalArrivalTime: 19 Oct 2011 03:32:08.0288 (UTC) FILETIME=[AE109E00:01CC8E0F] Cc: rtcweb@ietf.org Subject: [rtcweb] Gateway need and usecase [was RE: Review request for RTCWeb standard 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: Wed, 19 Oct 2011 03:32:15 -0000 SW5ha2kvU2F1bCwNCg0KSXQgaXMgbm90IHRoYXQgSSdtIGludGVyZXN0ZWQgaW4gUlRDV2ViIGdh dGV3YXkgYnV0IGl0IGlzIHRoZSBiZXN0IGtub3duIHNvbHV0aW9uIGN1cnJlbnRseS4gUGxlYXNl IGxvb2sgaW50byBteSBlYXJsaWVyIG1haWwgdGhyZWFkIChodHRwOi8vd3d3LmlldGYub3JnL21h aWwtYXJjaGl2ZS93ZWIvcnRjd2ViL2N1cnJlbnQvbXNnMDEwNTguaHRtbCkgZm9yIGFza2luZyBu b3QgdG8gaGF2ZSBnYXRld2F5cyBhbmQgdGhlIGlzc3VlcyBpbnZvbHZlZCBpbiBkZXZlbG9waW5n IGdhdGV3YXlzLiBCdXQgaW4gY2FzZSB0d28gcHJvdG9jb2xzIGxpa2UgU0lQLCB3ZWJzb2NrZXQg YXJlIHN0YXJ0ZWQgdXNpbmcgZm9yIHRoZSBzaWduYWxpbmcgd2l0aGluIHRoZSBzYW1lIHNlc3Np b24sIHRoZSBpbnRlcm9wIGlzIHBvc3NpYmxlIG9ubHkgd2l0aCBnYXRld2F5cyBvciB0dW5uZWxp bmcgd2hlcmVpbiBJIHByZWZlciBnYXRld2F5LiAgDQoNCkkgYWdyZWUgdGhhdCB0aGUgcHJpbWFy eSBmb2N1cyBvZiB0aGlzIFdHIGlzIHRvIGJyb3dzZXItdG8tYnJvd3NlciB3aXRob3V0IGZlZGVy YXRpb24gaW4gbWluZC4gQnV0IHRoZSBwb3dlciBvZiBjb2xsYWJvcmF0aW9uIHVzaW5nIFJUQ1dl YiB3aWxsIGJlIHJlYWxpemVkIGluIGNhc2UgZmVkZXJhdGlvbiBwcm90b2NvbCBhcmUgdXNlZC4g Rm9yIGV4YW1wbGUsIHNlYXJjaCBmb3IgdGhlIGtleXdvcmQgaW4gR29vZ2xlIGZyb20gdGhlIEFu ZHJvaWQgYnJvd3NlciwgZ28gdG8gdGhlIHdlYnNpdGUsIGNsaWNrIGluIHRoZSB3ZWJzaXRlIGxl YWRzIHRvIHRoZSBjYWxsIGluIHRoZSBjYWxsIGNlbnRlciBvZiB0aGUgd2Vic2l0ZSBjb21wYW55 IHdpdGhvdXQgaW52b2x2aW5nIGFueSBQU1ROIG5ldHdvcmsuIEhlcmUsIHdlYnNpdGUgb2YgdGhl IGNvbXBhbnkgYWN0cyBhcyBhIHNlcnZpY2UgcHJvdmlkZXIgZm9yIHRoZSBjb21wYW55IGFuZCBy ZWR1Y2UgdGhlIFBTVE4vU0lQIHRydW5rIGNvc3QgZHJhc3RpY2FsbHkuDQoNClRoYW5rcw0KUGFy dGhhDQoNCg0KPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+RnJvbTogScOxYWtpIEJheiBD YXN0aWxsbyBbbWFpbHRvOmliY0BhbGlheC5uZXRdDQo+U2VudDogVHVlc2RheSwgT2N0b2JlciAx OCwgMjAxMSAyOjE5IFBNDQo+VG86IFJhdmluZHJhbiBQYXJ0aGFzYXJhdGhpDQo+Q2M6IFNhw7ps IEliYXJyYSBDb3JyZXRnw6k7IHJ0Y3dlYkBpZXRmLm9yZw0KPlN1YmplY3Q6IFJlOiBbcnRjd2Vi XSBSZXZpZXcgcmVxdWVzdCBmb3IgUlRDV2ViIHN0YW5kYXJkIHNpZ25hbGluZw0KPnByb3RvY29s DQo+DQo+MjAxMS8xMC8xOCBSYXZpbmRyYW4gUGFydGhhc2FyYXRoaSA8cHJhdmluZHJhbkBzb251 c25ldC5jb20+Og0KPj4gU2F1bCwNCj4+DQo+PiBPbmUgbWlub3IgY29ycmVjdGlvbiBpbiB5b3Vy IG1haWw6IEkgaGF2ZSBtZW50aW9uZWQgIlNJUCBvdmVyDQo+d2Vic29ja2V0IiBpcyBhbiBvdmVy a2lsbCBhbmQgbm90IFNJUC4NCj4NCj5SYXZpbmRyYW4sIHBsZWFzZSBmb3JnZXQgIlNJUCBvdmVy IFdlYlNvY2tldCIuIEkndmUgbmV2ZXIgcHJvcG9zZWQgaXQNCj50byBiZSBhIGRlZmF1bHQgUlRD d2ViIHNpZ25hbGluZyBwcm90b2NvbCwgbm90IGF0IGFsbCwgc28gaWYgeW91IGRvbid0DQo+bGlr ZSBpdCBqdXN0IGRvbid0IHVzZSBpdC4NCj4NCj5CVFcgd2hhdCBJIHVuZGVyc3RhbmQgZ2l2ZW4g eW91ciBpbnNpc3RlbnQgcHJvcG9zYWwgaXMgdGhhdCB5b3UgbmVlZA0KPnRoZSBSVEN3ZWIgc2ln bmFsaW5nIHByb3RvY29sIChtZXNzYWdlcyBpbi10aGUtd2lyZSkgdG8gYmUgYW4gSUVURg0KPnN0 YW5kYXJkIHNvIHlvdSBnZXQgYSBtYXJrZXQgZm9yIGJ1aWxkaW5nIGFuZCBzZWxsaW5nIGdhdGV3 YXkgYm94ZXMNCj5iZXR3ZWVuIHN1Y2ggIklFVEYtUlRDd2ViLVByb3RvY29sIiBhbmQgb3RoZXIg SUVURiBzdGFuZGFyZCBwcm90b2NvbHMNCj4oYXMgU0lQKS4gSXQncyBjbGVhciB0aGF0IHlvdSBs aWtlIGdhdGV3YXlzIGFuZCB5b3Ugd2FudCBnYXRld2F5cy4NCj4NCj4NCj5TYWlkIHRoYXQgSSBh cG9sb2dpemUgdG8gdGhpcyBXRyBmb3Igc29tZSBvZiBteSBtYWlscyB5ZXN0ZXJkYXkuIEl0DQo+ d29uJ3QgaGFwcGVuIGFnYWluLg0KPg0KPg0KPi0tDQo+ScOxYWtpIEJheiBDYXN0aWxsbw0KPjxp YmNAYWxpYXgubmV0Pg0K From harald@alvestrand.no Tue Oct 18 22:00: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 7BA7C11E8083 for ; Tue, 18 Oct 2011 22:00:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.373 X-Spam-Level: X-Spam-Status: No, score=-110.373 tagged_above=-999 required=5 tests=[AWL=-0.226, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, SARE_SUB_ENC_UTF8=0.152, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02aPoftUwFrY for ; Tue, 18 Oct 2011 22:00:25 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id DB99A11E8080 for ; Tue, 18 Oct 2011 22:00:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3627839E0F0 for ; Wed, 19 Oct 2011 07:00: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 vb1V3nnQIA8f for ; Wed, 19 Oct 2011 07:00:21 +0200 (CEST) Received: from [172.16.48.71] (unknown [74.125.121.33]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 7077639E0D2 for ; Wed, 19 Oct 2011 07:00:21 +0200 (CEST) Message-ID: <4E9E5964.4070709@alvestrand.no> Date: Wed, 19 Oct 2011 07:00:20 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: rtcweb@ietf.org References: <15B0E3AD-3086-499A-8E79-7AE58B3376C4@cisco.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [rtcweb] =?utf-8?q?Why_SDP_answer_needs_and_ack_=E2=80=A6_was_Re?= =?utf-8?q?=3A__SDP_Offer/Answer_draft-jennings-rtcweb-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: Wed, 19 Oct 2011 05:00:25 -0000 [Admin note: Please keep discussion of ROAP details on the rtcweb list, not on both lists.] On 10/18/2011 09:44 PM, Iñaki Baz Castillo wrote: > 2011/10/18 Cullen Jennings: >> Hi - glad to hear you see this going the right direction. On the topic of why we have an OK, let me provide a bit of the motivation. >> >> When one side sends and answer that says it wants to receive VP8 instead of H.264, it's probably useful to know when the other side got that information. This might impact the timing of when o send things or user interface that provides feedback about the status of the other side. We are also dealing with a web transaction model where transaction are not guarantee to happen even if they are sent over TCP. So you need to get back a response to request. It also helps with mapping to SIP but even if you were not mapping to another protocol, I suspect you would still need to be able to have an confirmation than and answer was received. > Hi Cullen. Let me put an example: > > - alice: JS client implementing pure SIP over WebSocket. > - A proxy implementing SIP over UDP and WebSocket. > - bob: SIP UDP client. > > The flows: > > - alice sends INVITE to bob with an empty body (no SDP). > - bob replies a 200 with the SDP offer. > - alice receives the 200. Its JS code internally generates a ROAP Offer. > - alice generates a ROAP Answer and inserts its SDP into an ACK to be > sent to bob. > - In SIP we have ended. So how is supposed alice will receive the ROAP > OK message? The entity that knows about the mismatch between ROAP and SIP message sequences will have to generate it. In your hypothetical scenario - alice. > I don't understand yet if such ROAP OK message is mandatory to be sent > to the RTCweb stack. If so, the JS code in alice could auto-generate > it after sending the ACK, so the RTCweb stack becomes happy. But > obviously the advantage of such auto-generated ROAP OK is null. > > > Regards. > > From HKaplan@acmepacket.com Tue Oct 18 22: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 52BD811E8080 for ; Tue, 18 Oct 2011 22:11:32 -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 R5WAcuEbGuKI for ; Tue, 18 Oct 2011 22:11:31 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 9B55011E8073 for ; Tue, 18 Oct 2011 22:11: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; Wed, 19 Oct 2011 01:11:26 -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; Wed, 19 Oct 2011 01:11:26 -0400 From: Hadriel Kaplan To: Ravindran Parthasarathi Thread-Topic: [rtcweb] Gateway need and usecase [was RE: Review request for RTCWeb standard signaling protocol] Thread-Index: AQHMjh2MKAHKdWoRPEeKqc2wy+gDJw== Date: Wed, 19 Oct 2011 05:11:25 +0000 Message-ID: <8EBB58C3-E135-4FB4-80F2-607E82C7BA7A@acmepacket.com> References: <2E239D6FCD033C4BAF15F386A979BF510F1367@sonusinmail02.sonusnet.com><4E8AC222.4050308@alvestrand.no><2E239D6FCD033C4BAF15F386A979BF510F14CE@sonusinmail02.sonusnet.com><2E239D6FCD033C4BAF15F386A979BF510F14FD@sonusinmail02.sonusnet.com><393F1888-F834-4DAE-B6B1-1C5D35EE3292@phonefromhere.com><2E239D6FCD033C4BAF15F386A979BF510F152B@sonusinmail02.sonusnet.com><2E239D6FCD033C4BAF15F386A979BF510F1532@sonusinmail02.sonusnet.com><2E239D6FCD033C4BAF15F386A979BF511598EE@sonusinmail02.sonusnet.com><665A16AB-AAD8-42B3-AC17-7E629EA2DE35@phonefromhere.com><2E239D6FCD033C4BAF15F386A979BF5115992E@sonusinmail02.sonusnet.com><0950F0E1-6E4B-407F-9563- 654AFE79 F64B@ag-proj ects.com><2E239D6FCD033C4BAF15F386A979BF51159994@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF51159A00@sonusinmail02.sonusnet.com> In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF51159A00@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: <728CEA80883FF741A745AF020FB92E67@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [rtcweb] Gateway need and usecase [was RE: Review request for RTCWeb standard 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: Wed, 19 Oct 2011 05:11:32 -0000 Hi Partha, comments inline On Oct 18, 2011, at 11:32 PM, Ravindran Parthasarathi wrote: > It is not that I'm interested in RTCWeb gateway but it is the best known = solution currently. Please look into my earlier mail thread (http://www.iet= f.org/mail-archive/web/rtcweb/current/msg01058.html) for asking not to have= gateways and the issues involved in developing gateways. But in case two p= rotocols like SIP, websocket are started using for the signaling within the= same session, the interop is possible only with gateways or tunneling wher= ein I prefer gateway. =20 I am confused by your statements. In the email thread you cited above, and= in your draft, you imply that websocket is a signaling protocol or browser= -to-browser protocol. It isn't. For all intents and purposes of this WG, = it's a transport. That's all. It's like TCP, UDP or SCTP. And it goes be= tween the browser and a web server, not between browsers. What's put onto = that transport socket is up to the JavaScript and web server code. I also don't understand what you mean by "interop is only possible with gat= eways or tunneling". I don't see how tunneling anything solves interop of = anything. But for gateways, yes if everything spoke a standard protocol, m= aking gateways would be easier - but it doesn't require the RTCWeb<->browse= r path to speak that signaling protocol; it only requires the web-server to= speak it. In fact it might not even require that - it might be possible t= o have a gateway be a JavaScript client too. > I agree that the primary focus of this WG is to browser-to-browser withou= t federation in mind. But the power of collaboration using RTCWeb will be r= ealized in case federation protocol are used. For example, search for the k= eyword in Google from the Android browser, go to the website, click in the = website leads to the call in the call center of the website company without= involving any PSTN network. Here, website of the company acts as a service= provider for the company and reduce the PSTN/SIP trunk cost drastically. So? How does this require a standard signaling protocol on the browser? -hadriel From harald@alvestrand.no Tue Oct 18 22:18: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 75A5611E8080 for ; Tue, 18 Oct 2011 22:18:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.486 X-Spam-Level: X-Spam-Status: No, score=-110.486 tagged_above=-999 required=5 tests=[AWL=0.113, 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 S8uqpuYNhyBv for ; Tue, 18 Oct 2011 22:18:09 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 417B811E8073 for ; Tue, 18 Oct 2011 22:18:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A2D9039E0F0; Wed, 19 Oct 2011 07:18:08 +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 ju5VmWIG15Mx; Wed, 19 Oct 2011 07:18:06 +0200 (CEST) Received: from [172.16.48.71] (unknown [74.125.121.33]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 6A62839E0D2; Wed, 19 Oct 2011 07:18:06 +0200 (CEST) Message-ID: <4E9E5D8D.6030707@alvestrand.no> Date: Wed, 19 Oct 2011 07:18:05 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: Ravindran Parthasarathi References: <2E239D6FCD033C4BAF15F386A979BF511599F9@sonusinmail02.sonusnet.com> In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF511599F9@sonusinmail02.sonusnet.com> Content-Type: multipart/alternative; boundary="------------000606040904020609030809" Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Comment on draft-ietf-rtcweb-overview-02 (Browser RTC trapezoid) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 05:18:11 -0000 This is a multi-part message in MIME format. --------------000606040904020609030809 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 10/19/2011 01:12 AM, Ravindran Parthasarathi wrote: > > Harald, > > In Fig 2 (Browser RTC Trapezoid), I'm getting the feel that JS/HTML > communicates with webserver directly without the involvement of > browser. Please clarify whether it is intended not to use browser for JS. > Sorry, you completely lost me there. The browser is the execution context for Javascript. The words "it is intended not to use browser for JS" look like English to me, but I can't find any interpretation that makes any sense. If you don't have a clear view of the Javascript execution model, I recommend spending a few hours with an introductory Javascript text and playing with writing some Javascript in your own web pages. It will save lots of confused emails to the list. > > IMO, the browser RTC trapezoid shall be > > +-----------+ +-----------+ > > | RTCWeb | Federation | RTCWeb | > > | | Signaling | | > > | |-------------| | > > | Server | protocol | Server | > > | | | | > > +-----------+ +-----------+ > > / \ > > / \ RTCWeb > > / \ Signaling > > / \ > > / RTCWeb \ > > / Signaling \ > > / \ > > +-----------+ +-----------+ > > | | | | > > | | | | > > | Browser | ------------------------- | Browser | > > | | Media path | | > > | | | | > > +-----------+ +-----------+ > > +-----------+ +-----------+ > > |JS/HTML/CSS| |JS/HTML/CSS| > > +-----------+ +-----------+ > Absolutely not. 1) The term "RTCWeb Signaling" has no clear definition, as this discussion has proved again. 2) The conceptual difference between the media path (managed by the browser without being mediated through Javascript) and the signalling path (mediated through Javascript, transmitted through interfaces that this WG has no intention of changing) is lost by the inversion of the "browser stack". The detailed relationships between the browser components are better described in Figure 1 of -overview- than in Figure 2 (the one you've quoted). I've noted the need to mention that the JS uses browser functions to access HTTP and WebSockets too, since it's apparently not completely obvious to all. > > I explained the same diagram in Fig 1 of > draft-partha-rtcweb-signaling-00. RTCWeb signaling shall be > proprietary HTTP/websocket. I'm asking this change because I'm seeing > folks confuses API vs. on-wire-protocol. Also, Please note that JS + > browser is the single system with two different modules and it shall > have protocol or API to communicate (without passing any information > in the wire). Could you please let me know in case I'm missing something. > > Thanks > > Partha > --------------000606040904020609030809 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 10/19/2011 01:12 AM, Ravindran Parthasarathi wrote:

Harald,

 

In Fig 2 (Browser RTC Trapezoid), I’m getting the feel that JS/HTML communicates with webserver directly without the involvement of browser. Please clarify whether it is intended not to use browser  for JS.

Sorry, you completely lost me there.

The browser is the execution context for Javascript. The words "it is intended not to use browser for JS" look like English to me, but I can't find any interpretation that makes any sense.

If you don't have a clear view of the Javascript execution model, I recommend spending a few hours with an introductory Javascript text and playing with writing some Javascript in your own web pages. It will save lots of confused emails to the list.

 

IMO, the browser RTC trapezoid shall be

 

                   +-----------+             +-----------+

                   |   RTCWeb  |  Federation |   RTCWeb  |

                   |           |  Signaling  |           |

                   |           |-------------|           |

                   |  Server   |   protocol  |  Server   |

                   |           |             |           |

                   +-----------+             +-----------+

                        /                           \

                       /                             \   RTCWeb

                      /                               \  Signaling

                     /                                 \

                    /  RTCWeb                           \

                   /   Signaling                         \

                  /                                       \

            +-----------+                           +-----------+

            |           |                           |           |

            |           |                           |           |

            |  Browser  | ------------------------- |  Browser  |

            |           |          Media path       |           |

            |           |                           |           |

            +-----------+                           +-----------+

            +-----------+                           +-----------+

            |JS/HTML/CSS|                           |JS/HTML/CSS|

            +-----------+                           +-----------+


Absolutely not.

1) The term "RTCWeb Signaling" has no clear definition, as this discussion has proved again.
2) The conceptual difference between the media path (managed by the browser without being mediated through Javascript) and the signalling path (mediated through Javascript, transmitted through interfaces that this WG has no intention of changing) is lost by the inversion of the "browser stack".

The detailed relationships between the browser components are better described in Figure 1 of -overview- than in Figure 2 (the one you've quoted). I've noted the need to mention that the JS uses browser functions to access HTTP and WebSockets too, since it's apparently not completely obvious to all.

 


I explained the same diagram in Fig 1 of draft-partha-rtcweb-signaling-00. RTCWeb signaling shall be proprietary HTTP/websocket. I’m asking this change because I’m seeing folks confuses API vs. on-wire-protocol. Also, Please note that JS + browser is the single system with two different modules and it shall have protocol or API to communicate (without passing any information in the wire). Could you please let me know in case I’m missing something.

 

Thanks

Partha

 


--------------000606040904020609030809-- From wolfgang.beck01@googlemail.com Tue Oct 18 22:21: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 591CC11E8080 for ; Tue, 18 Oct 2011 22:21:29 -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 VklqShuYBgHx for ; Tue, 18 Oct 2011 22:21:28 -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 A4C2B11E8073 for ; Tue, 18 Oct 2011 22:21:28 -0700 (PDT) Received: by gyh20 with SMTP id 20so1606347gyh.31 for ; Tue, 18 Oct 2011 22:21:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Sh9oWNbNiEu3ScvqCZAOnJExrVKsRMr3YNHdTJQpE+c=; b=U3fjhaGi+F4y5EwxFFIzQgAailVMT+G2qC77wvA3hP5eBZILrgoUbQEezVFe+j+LVH OqDlmqoxJgDUfztvn3tp3DUyQgzl93jt1+NIXWuhpOcRAz+Vu9LyipGgv3tqrT6x3uCS IzMeXHtjZEVQdLvX7i2oUsWSpo2jAH0XqAHTA= MIME-Version: 1.0 Received: by 10.68.9.2 with SMTP id v2mr10077356pba.101.1319001688018; Tue, 18 Oct 2011 22:21:28 -0700 (PDT) Received: by 10.68.55.230 with HTTP; Tue, 18 Oct 2011 22:21:27 -0700 (PDT) In-Reply-To: <1DEFCFF8-4F23-4D84-914D-AB50233C8C06@cisco.com> References: <4E9D667A.2040703@alvestrand.no> <4E9DBECC.6000206@alvestrand.no> <1DEFCFF8-4F23-4D84-914D-AB50233C8C06@cisco.com> Date: Wed, 19 Oct 2011 07:21:27 +0200 Message-ID: From: Wolfgang Beck To: Cullen Jennings Content-Type: text/plain; charset=ISO-8859-1 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] My Opinion: Why I think a negotiating protocol is a Good Thing X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 05:21:29 -0000 On Tue, Oct 18, 2011 at 11:13 PM, Cullen Jennings wrote: > > On Oct 18, 2011, at 11:29 , Wolfgang Beck wrote: > >> Depressingly few SIP providers do interconnection, after all those >> years. > > Interesting - most the people I seem to deal with need to send SIP from one domain to another. Who are you thinking of that does not need to do > interconnect? There is a need that people with an account at provider A can call people at provider B. I have several SIP accounts with various providers and I don't know for sure which one would be usable for communicating with you. It's not like email. What I see is SIP providers that use the PSTN for interconnection. We might see a lot more SIP interconnection with LTE and VoLTE, which will look very much like the PSTN. RCS ('Rich Communication Suite') standardized presence, chat and file transfer for some years. When it came to interconnection, providers could only agree on the least common denominator, RCS-e. Even in the PSTN you lose many features with interconnection. Wolfgang Beck From HKaplan@acmepacket.com Tue Oct 18 23:05: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 B3CCA11E8097 for ; Tue, 18 Oct 2011 23:05:25 -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 34BgMC7flCB1 for ; Tue, 18 Oct 2011 23:05:25 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 1DB8D11E8090 for ; Tue, 18 Oct 2011 23:05:25 -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, 19 Oct 2011 02:05:22 -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; Wed, 19 Oct 2011 02:05:22 -0400 From: Hadriel Kaplan To: Cullen Jennings Thread-Topic: [rtcweb] My Opinion: Why I think a negotiating protocol is a Good Thing Thread-Index: AQHMjiUV6kdbKMH90Eeuh1H9I7A1XA== Date: Wed, 19 Oct 2011 06:05:21 +0000 Message-ID: <570BDE5E-6EDC-4094-8DC0-094CEC3F12DF@acmepacket.com> References: <4E9D667A.2040703@alvestrand.no> <9B03E9E2-4376-465E-84F5-EDAC51390408@phonefromhere.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [216.41.24.34] Content-Type: text/plain; charset="us-ascii" Content-ID: <507CE665A9BC934EBD28CE360B7CF122@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] My Opinion: Why I think a negotiating protocol is a Good Thing X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 06:05:25 -0000 On Oct 18, 2011, at 4:59 PM, Cullen Jennings wrote: > On Oct 18, 2011, at 5:53 , Tim Panton wrote: >=20 >> We have an API with blobs only because we chose to stick with the ugline= ss that is SDP. >=20 > One of the most compelling argument to me to stick with SDP is that I hav= e a hard time imagining anyone creating a replacement for it in less than a= year or two.=20 Well... there are already replacements for it in other protocols, but that'= s not the issue for me - for me one problem is you're _guaranteeing_ we won= 't see a replacement for it because you're putting it into the browser itse= lf. Instead of treating the browser as a media/RTP library with an API, yo= u're treating it as an active application agent with a protocol.=20 How many RTP libraries do you know of that use SDP offer/answer protocol as= their API? =20 -hadriel From HKaplan@acmepacket.com Tue Oct 18 23:15: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 514081F0C4E for ; Tue, 18 Oct 2011 23:15:28 -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 4dSs3GsEaZfB for ; Tue, 18 Oct 2011 23:15:27 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id B22831F0C49 for ; Tue, 18 Oct 2011 23:15:27 -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, 19 Oct 2011 02:15:26 -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; Wed, 19 Oct 2011 02:15:26 -0400 From: Hadriel Kaplan To: Wolfgang Beck Thread-Topic: [rtcweb] My Opinion: Why I think a negotiating protocol is a Good Thing Thread-Index: AQHMjiZ9U04PtW0ttUmXsgDgKylc8g== Date: Wed, 19 Oct 2011 06:15:25 +0000 Message-ID: References: <4E9D667A.2040703@alvestrand.no> <4E9DBECC.6000206@alvestrand.no> <1DEFCFF8-4F23-4D84-914D-AB50233C8C06@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [216.41.24.34] Content-Type: text/plain; charset="us-ascii" Content-ID: <9AD7AC711A32794EA42EB79C59EFC5BB@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] My Opinion: Why I think a negotiating protocol is a Good Thing X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 06:15:28 -0000 On Oct 19, 2011, at 1:21 AM, Wolfgang Beck wrote: > There is a need that people with an account at provider A can call > people at provider B. I have several SIP accounts with various > providers and I don't know for sure which one would be usable for > communicating with you. It's not like email. >=20 > What I see is SIP providers that use the PSTN for interconnection.=20 I think you need to get out more. :) It's true it's not like email, but provider interconnection with SIP is big= business. Maybe you mean for more than voice calls? IM and video are not nearly as b= ig for SIP interconnection. -hadriel From jmillan@aliax.net Tue Oct 18 23:22: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 6EB081F0C4E for ; Tue, 18 Oct 2011 23:22:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.801 X-Spam-Level: X-Spam-Status: No, score=-1.801 tagged_above=-999 required=5 tests=[AWL=-0.877, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QpVDYE3J5gAb for ; Tue, 18 Oct 2011 23:22:38 -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 C7E831F0C49 for ; Tue, 18 Oct 2011 23:22:38 -0700 (PDT) Received: by iabn5 with SMTP id n5so1872315iab.31 for ; Tue, 18 Oct 2011 23:22:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.67.80 with SMTP id q16mr2231179ibi.86.1319005358358; Tue, 18 Oct 2011 23:22:38 -0700 (PDT) Received: by 10.231.16.75 with HTTP; Tue, 18 Oct 2011 23:22:38 -0700 (PDT) In-Reply-To: <4E9E5D8D.6030707@alvestrand.no> References: <2E239D6FCD033C4BAF15F386A979BF511599F9@sonusinmail02.sonusnet.com> <4E9E5D8D.6030707@alvestrand.no> Date: Wed, 19 Oct 2011 08:22:38 +0200 Message-ID: From: =?ISO-8859-1?Q?Jos=E9_Luis_Mill=E1n?= To: Harald Alvestrand Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: base64 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Comment on draft-ietf-rtcweb-overview-02 (Browser RTC trapezoid) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 06:22:39 -0000 UmF2aW5kcmFuLAoKV2hpY2hldmVyIHlvdXIgbW90aXZhdGlvbiBmb3IgYXJndWluZyBhZ2FpbnN0 IG9yIGluIGZhdm9yLCBhcmd1bWVudHMKbmVlZCB0byBiZSByaWdvcm91cyBhbmQgY2xlYXIuIEkg Z3Vlc3MgbW9zdCBwZW9wbGUgcmVhZGluZyBhbmQKY29udHJpYnV0aW5nIGhhdmUgYSBkZWVwIGtu b3dsZWRnZSBhYm91dCB3aGF0IGlzIGJlaW5nIHNwZWFraW5nIGFib3V0CmhlcmUuCgpBZnRlciBy ZWFkaW5nIHRoaXMgZW1haWwsIGl0J3MgdmVyeSBkaWZpY3VsdCBmb3IgbWUgdW5kZXJzdGFuZGlu ZyBob3cKY2FuIHRoZXJlIGJlIHNvIG1hbnkgbWFpbHMgZnJvbSB5b3UgYXNraW5nIGZvciB0aGUg YWRvcHRpb24gb2YKd2hpY2hldmVyIHBvc2l0aW9uIGluIHRoaXMgbGlzdC4KCj4gSW4gRmlnIDIg KEJyb3dzZXIgUlRDIFRyYXBlem9pZCksIEmSbSBnZXR0aW5nIHRoZSBmZWVsIHRoYXQgSlMvSFRN TAo+IGNvbW11bmljYXRlcyB3aXRoIHdlYnNlcnZlciBkaXJlY3RseSB3aXRob3V0IHRoZSBpbnZv bHZlbWVudCBvZiBicm93c2VyLgo+IFBsZWFzZSBjbGFyaWZ5IHdoZXRoZXIgaXQgaXMgaW50ZW5k ZWQgbm90IHRvIHVzZSBicm93c2VyIKBmb3IgSlMuCgpUaGlzIHF1ZXN0aW9uIChvZiBjb3Vyc2Us IHF1ZXN0aW9ucyBhcmUgYWx3YXlzIGxlZ2l0aW1hdGUpIGNvbWVzIGFmdGVyCnlvdSBleHBvc2Vk IGEgZG9jdW1lbnQKKGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXBhcnRoYS1ydGN3 ZWItc2lnbmFsaW5nLTAwKSBmb2N1c2VkCm9uIHN0YW5kYXJpemluZyBhIHNpZ25hbGluZyBiZXR3 ZWVuIGJyb3dzZXIgYW5kIFJUQ1dlYiBzZXJ2ZXIuCgoiSW4gdGhlIGFib3ZlIG1lbnRpb25lZCBh cmNoaXRlY3R1cmUsIHRoaXMgZG9jdW1lbnQgZm9jdXMgb24KICAgc3RhbmRhcmRpemluZyBSVENX ZWIgc2lnbmFsaW5nIGJldHdlZW4gYnJvd3NlciBhbmQgUlRDV2ViIHNlcnZlciIKCgpUaGlzIGlz IG5vdGhpbmcgcGVyc29uYWwsIGJ1dCB0aGlzIGF0dGl0dWRlIG1ha2VzIHRoZSBtYWlsaW5nIGxp c3QKaGFyZCB0byBmb2xsb3csIGF0IGxlYXN0LgoKCkkgYXBvbG9naXplIGlmIHRoaXMgY29tbWVu dCBpcyBvdXQgb2YgY29udGV4dC4KCgoyMDExLzEwLzE5IEhhcmFsZCBBbHZlc3RyYW5kIDxoYXJh bGRAYWx2ZXN0cmFuZC5ubz46Cj4gT24gMTAvMTkvMjAxMSAwMToxMiBBTSwgUmF2aW5kcmFuIFBh cnRoYXNhcmF0aGkgd3JvdGU6Cj4KPiBIYXJhbGQsCj4KPgo+Cj4gSW4gRmlnIDIgKEJyb3dzZXIg UlRDIFRyYXBlem9pZCksIEmSbSBnZXR0aW5nIHRoZSBmZWVsIHRoYXQgSlMvSFRNTAo+IGNvbW11 bmljYXRlcyB3aXRoIHdlYnNlcnZlciBkaXJlY3RseSB3aXRob3V0IHRoZSBpbnZvbHZlbWVudCBv ZiBicm93c2VyLgo+IFBsZWFzZSBjbGFyaWZ5IHdoZXRoZXIgaXQgaXMgaW50ZW5kZWQgbm90IHRv IHVzZSBicm93c2VyIKBmb3IgSlMuCj4KPiBTb3JyeSwgeW91IGNvbXBsZXRlbHkgbG9zdCBtZSB0 aGVyZS4KPgo+IFRoZSBicm93c2VyIGlzIHRoZSBleGVjdXRpb24gY29udGV4dCBmb3IgSmF2YXNj cmlwdC4gVGhlIHdvcmRzICJpdCBpcwo+IGludGVuZGVkIG5vdCB0byB1c2UgYnJvd3NlciBmb3Ig SlMiIGxvb2sgbGlrZSBFbmdsaXNoIHRvIG1lLCBidXQgSSBjYW4ndAo+IGZpbmQgYW55IGludGVy cHJldGF0aW9uIHRoYXQgbWFrZXMgYW55IHNlbnNlLgo+Cj4gSWYgeW91IGRvbid0IGhhdmUgYSBj bGVhciB2aWV3IG9mIHRoZSBKYXZhc2NyaXB0IGV4ZWN1dGlvbiBtb2RlbCwgSQo+IHJlY29tbWVu ZCBzcGVuZGluZyBhIGZldyBob3VycyB3aXRoIGFuIGludHJvZHVjdG9yeSBKYXZhc2NyaXB0IHRl eHQgYW5kCj4gcGxheWluZyB3aXRoIHdyaXRpbmcgc29tZSBKYXZhc2NyaXB0IGluIHlvdXIgb3du IHdlYiBwYWdlcy4gSXQgd2lsbCBzYXZlCj4gbG90cyBvZiBjb25mdXNlZCBlbWFpbHMgdG8gdGhl IGxpc3QuCj4KPgo+Cj4gSU1PLCB0aGUgYnJvd3NlciBSVEMgdHJhcGV6b2lkIHNoYWxsIGJlCj4K Pgo+Cj4goKAgoKCgoKCgoKCgoKCgoKCgoCstLS0tLS0tLS0tLSugoKCgoKCgoKCgoKAgKy0tLS0t LS0tLS0tKwo+Cj4goKCgoKCgoKCgoKCgoKCgoKCgIHygoCBSVENXZWKgIHygIEZlZGVyYXRpb24g fKCgIFJUQ1dlYqAgfAo+Cj4goKCgoKCgoKCgoKCgoKCgoKCgIHygoKCgoKCgoKCgIHygIFNpZ25h bGluZ6AgfKCgoKCgoKCgoKAgfAo+Cj4goKCgoKCgoKCgoKCgoKCgoKCgIHygoKCgoKCgoKCgIHwt LS0tLS0tLS0tLS0tfKCgoKCgoKCgoKAgfAo+Cj4goKCgoKCgoKCgoKCgoKCgoKCgIHygIFNlcnZl cqCgIHygoCBwcm90b2NvbKAgfKAgU2VydmVyoKAgfAo+Cj4goKCgoKCgoKCgoKCgoKCgoKCgIHyg oKCgoKCgoKCgIHygoKCgoKCgoKCgoKAgfKCgoKCgoKCgoKAgfAo+Cj4goKCgoKCgoKCgoKCgoKCg oKCgICstLS0tLS0tLS0tLSugoKCgoKCgoKCgoKAgKy0tLS0tLS0tLS0tKwo+Cj4goKCgoKCgoKCg oKCgoKCgoKCgoKCgoKAgL6CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgIFwKPgo+IKCgoKCgoKCg oKCgoKCgoKCgoKCgoKAgL6CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKAgXKCgIFJUQ1dlYgo+ Cj4goKCgoKCgoKCgoKCgoKCgoKCgoKCgIC+goKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKAg XKAgU2lnbmFsaW5nCj4KPiCgoKCgoKCgoKCgoKCgoKCgoKCgoCAvoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKAgXAo+Cj4goKCgoKCgoKCgoKCgoKCgoKCgoCAvoCBSVENXZWKgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoCBcCj4KPiCgoKCgoKCgoKCgoKCgoKCgoKAgL6CgIFNpZ25hbGlu Z6CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoCBcCj4KPiCgoKCgoKCgoKCgoKCgIKCgoKAvoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKAgXAo+Cj4goKCgoKCgoKCgoKAgKy0tLS0t LS0tLS0tK6CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgICstLS0tLS0tLS0tLSsKPgo+IKCgoKCg oKCgoKCgIHygoKCgoKCgoKCgIHygoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoCB8oKCgoKCgoKCg oCB8Cj4KPiCgoKCgoKCgoKCgoCB8oKCgoKCgoKCgoCB8oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKAgfKCgoKCgoKCgoKAgfAo+Cj4goKCgoKCgoKCgoKAgfKAgQnJvd3NlcqAgfCAtLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tIHygIEJyb3dzZXKgIHwKPgo+IKCgoKCgoKCgoKCgIHygoKCgoKCgoKCg IHygoKCgoKCgoKAgTWVkaWEgcGF0aKCgoKCgoCB8oKCgoKCgoKCgoCB8Cj4KPiCgoKCgoKCgoKCg oCB8oKCgoKCgoKCgoCB8oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKAgfKCgoKCgoKCgoKAgfAo+ Cj4goKCgoKCgoKCgoKAgKy0tLS0tLS0tLS0tK6CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgICst LS0tLS0tLS0tLSsKPgo+IKCgoCCgoKCgoKCgoCstLS0tLS0tLS0tLSugoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoCArLS0tLS0tLS0tLS0rCj4KPiCgoKCgoKCgoKCgoCB8SlMvSFRNTC9DU1N8oKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKAgfEpTL0hUTUwvQ1NTfAo+Cj4goKCgoKCgoKCgoKAgKy0t LS0tLS0tLS0tK6CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgICstLS0tLS0tLS0tLSsKPgo+IEFi c29sdXRlbHkgbm90Lgo+Cj4gMSkgVGhlIHRlcm0gIlJUQ1dlYiBTaWduYWxpbmciIGhhcyBubyBj bGVhciBkZWZpbml0aW9uLCBhcyB0aGlzIGRpc2N1c3Npb24KPiBoYXMgcHJvdmVkIGFnYWluLgo+ IDIpIFRoZSBjb25jZXB0dWFsIGRpZmZlcmVuY2UgYmV0d2VlbiB0aGUgbWVkaWEgcGF0aCAobWFu YWdlZCBieSB0aGUgYnJvd3Nlcgo+IHdpdGhvdXQgYmVpbmcgbWVkaWF0ZWQgdGhyb3VnaCBKYXZh c2NyaXB0KSBhbmQgdGhlIHNpZ25hbGxpbmcgcGF0aCAobWVkaWF0ZWQKPiB0aHJvdWdoIEphdmFz Y3JpcHQsIHRyYW5zbWl0dGVkIHRocm91Z2ggaW50ZXJmYWNlcyB0aGF0IHRoaXMgV0cgaGFzIG5v Cj4gaW50ZW50aW9uIG9mIGNoYW5naW5nKSBpcyBsb3N0IGJ5IHRoZSBpbnZlcnNpb24gb2YgdGhl ICJicm93c2VyIHN0YWNrIi4KPgo+IFRoZSBkZXRhaWxlZCByZWxhdGlvbnNoaXBzIGJldHdlZW4g dGhlIGJyb3dzZXIgY29tcG9uZW50cyBhcmUgYmV0dGVyCj4gZGVzY3JpYmVkIGluIEZpZ3VyZSAx IG9mIC1vdmVydmlldy0gdGhhbiBpbiBGaWd1cmUgMiAodGhlIG9uZSB5b3UndmUKPiBxdW90ZWQp LiBJJ3ZlIG5vdGVkIHRoZSBuZWVkIHRvIG1lbnRpb24gdGhhdCB0aGUgSlMgdXNlcyBicm93c2Vy IGZ1bmN0aW9ucwo+IHRvIGFjY2VzcyBIVFRQIGFuZCBXZWJTb2NrZXRzIHRvbywgc2luY2UgaXQn cyBhcHBhcmVudGx5IG5vdCBjb21wbGV0ZWx5Cj4gb2J2aW91cyB0byBhbGwuCj4KPgo+Cj4gSSBl eHBsYWluZWQgdGhlIHNhbWUgZGlhZ3JhbSBpbiBGaWcgMSBvZiBkcmFmdC1wYXJ0aGEtcnRjd2Vi LXNpZ25hbGluZy0wMC4KPiBSVENXZWIgc2lnbmFsaW5nIHNoYWxsIGJlIHByb3ByaWV0YXJ5IEhU VFAvd2Vic29ja2V0LiBJkm0gYXNraW5nIHRoaXMgY2hhbmdlCj4gYmVjYXVzZSBJkm0gc2VlaW5n IGZvbGtzIGNvbmZ1c2VzIEFQSSB2cy4gb24td2lyZS1wcm90b2NvbC4gQWxzbywgUGxlYXNlCj4g bm90ZSB0aGF0IEpTICsgYnJvd3NlciBpcyB0aGUgc2luZ2xlIHN5c3RlbSB3aXRoIHR3byBkaWZm ZXJlbnQgbW9kdWxlcyBhbmQKPiBpdCBzaGFsbCBoYXZlIHByb3RvY29sIG9yIEFQSSB0byBjb21t dW5pY2F0ZSAod2l0aG91dCBwYXNzaW5nIGFueQo+IGluZm9ybWF0aW9uIGluIHRoZSB3aXJlKS4g Q291bGQgeW91IHBsZWFzZSBsZXQgbWUga25vdyBpbiBjYXNlIEmSbSBtaXNzaW5nCj4gc29tZXRo aW5nLgo+Cj4KPgo+IFRoYW5rcwo+Cj4gUGFydGhhCj4KPgo+Cj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBydGN3ZWIgbWFpbGluZyBsaXN0Cj4gcnRj d2ViQGlldGYub3JnCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3 ZWIKPgo+Cg== From pravindran@sonusnet.com Tue Oct 18 23:39: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 9810611E8090 for ; Tue, 18 Oct 2011 23:39:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.557 X-Spam-Level: X-Spam-Status: No, score=-2.557 tagged_above=-999 required=5 tests=[AWL=-0.559, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 vUCNHI9+GSNS for ; Tue, 18 Oct 2011 23:39:13 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 2FC8811E8073 for ; Tue, 18 Oct 2011 23:39:13 -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 p9J6dhKJ024009; Wed, 19 Oct 2011 02:39:43 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail07.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 19 Oct 2011 02:38: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_01CC8E28.CC4331CC" Date: Wed, 19 Oct 2011 12:01:55 +0530 Message-ID: <2E239D6FCD033C4BAF15F386A979BF51159A20@sonusinmail02.sonusnet.com> In-Reply-To: <4E9E5D8D.6030707@alvestrand.no> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comment on draft-ietf-rtcweb-overview-02 (Browser RTC trapezoid) Thread-Index: AcyOHoHXAcFfRo72QSKhIaC8Aw8jrAAB0SFQ References: <2E239D6FCD033C4BAF15F386A979BF511599F9@sonusinmail02.sonusnet.com> <4E9E5D8D.6030707@alvestrand.no> From: "Ravindran Parthasarathi" To: "Harald Alvestrand" X-OriginalArrivalTime: 19 Oct 2011 06:38:59.0845 (UTC) FILETIME=[C8AC7350:01CC8E29] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Comment on draft-ietf-rtcweb-overview-02 (Browser RTC trapezoid) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 06:39:15 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC8E28.CC4331CC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Harald, =20 Please read inline. =20 Thanks Partha =20 From: Harald Alvestrand [mailto:harald@alvestrand.no]=20 Sent: Wednesday, October 19, 2011 10:48 AM To: Ravindran Parthasarathi Cc: rtcweb@ietf.org Subject: Re: Comment on draft-ietf-rtcweb-overview-02 (Browser RTC trapezoid) =20 On 10/19/2011 01:12 AM, Ravindran Parthasarathi wrote:=20 Harald, =20 In Fig 2 (Browser RTC Trapezoid), I'm getting the feel that JS/HTML communicates with webserver directly without the involvement of browser. Please clarify whether it is intended not to use browser for JS. Sorry, you completely lost me there. The browser is the execution context for Javascript. The words "it is intended not to use browser for JS" look like English to me, but I can't find any interpretation that makes any sense. Sorry, I messed up with the words here but you clarified it in the below mail thread If you don't have a clear view of the Javascript execution model, I recommend spending a few hours with an introductory Javascript text and playing with writing some Javascript in your own web pages. It will save lots of confused emails to the list. In fact I tried couple of W3Cschools Javascript before starting the mail thread in RTCWeb. I'll learn more terminology in Javascript to clearly present my ideas =20 IMO, the browser RTC trapezoid shall be=20 =20 +-----------+ +-----------+ | RTCWeb | Federation | RTCWeb | | | Signaling | | | |-------------| | | Server | protocol | Server | | | | | +-----------+ +-----------+ / \ / \ RTCWeb / \ Signaling / \ / RTCWeb \ / Signaling \ / \ +-----------+ +-----------+ | | | | | | | | | Browser | ------------------------- | Browser | | | Media path | | | | | | +-----------+ +-----------+ +-----------+ +-----------+ |JS/HTML/CSS| |JS/HTML/CSS| +-----------+ +-----------+ Absolutely not. 1) The term "RTCWeb Signaling" has no clear definition, as this discussion has proved again. May I need to put clear definition by which we will come to common understanding. 2) The conceptual difference between the media path (managed by the browser without being mediated through Javascript) and the signalling path (mediated through Javascript, transmitted through interfaces that this WG has no intention of changing) is lost by the inversion of the "browser stack". =20 Agreed and my intention is not manage media path through Javascript. My figure has to change JS/HTML position to reflect it correctly. The detailed relationships between the browser components are better described in Figure 1 of -overview- than in Figure 2 (the one you've quoted). I've noted the need to mention that the JS uses browser functions to access HTTP and WebSockets too, since it's apparently not completely obvious to all. My intention of the mail is above statement and it is not clear from the figure 1 & 2. =20 I explained the same diagram in Fig 1 of draft-partha-rtcweb-signaling-00. RTCWeb signaling shall be proprietary HTTP/websocket. I'm asking this change because I'm seeing folks confuses API vs. on-wire-protocol. Also, Please note that JS + browser is the single system with two different modules and it shall have protocol or API to communicate (without passing any information in the wire). Could you please let me know in case I'm missing something. =20 Thanks Partha =20 =20 ------_=_NextPart_001_01CC8E28.CC4331CC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Harald,

 

Please read = inline.

 

Thanks

Partha

 

From: Harald Alvestrand [mailto:harald@alvestrand.no]
Sent: Wednesday, October 19, 2011 10:48 AM
To: Ravindran Parthasarathi
Cc: rtcweb@ietf.org
Subject: Re: Comment on draft-ietf-rtcweb-overview-02 (Browser = RTC trapezoid)

 

On 10/19/2011 01:12 AM, Ravindran Parthasarathi = wrote:

Harald,

 

In Fig 2 (Browser RTC Trapezoid), I’m getting = the feel that JS/HTML communicates with webserver directly without the = involvement of browser. Please clarify whether it is intended not to use browser =  for JS.

Sorry, you completely lost me there.

The browser is the execution context for Javascript. The words "it = is intended not to use browser for JS" look like English to me, but I = can't find any interpretation that makes any sense.

<partha> Sorry, = I messed up with the words here but you clarified it in the below mail thread </partha>


If you don't have a clear view of the Javascript execution model, I = recommend spending a few hours with an introductory Javascript text and playing = with writing some Javascript in your own web pages. It will save lots of = confused emails to the list.

<partha> In = fact I tried couple of W3Cschools Javascript before starting the mail thread in RTCWeb. = I’ll learn more terminology in Javascript to clearly present my ideas = </partha>



 

IMO, the browser RTC trapezoid shall be =

 

               &= nbsp;   +-----------+      &= nbsp;      +-----------+

          &= nbsp;        |   RTCWeb  |  Federation |   RTCWeb  = |

          &= nbsp;        |           |  Signaling  = |           = |

          &= nbsp;        |           |-------------|         &nbs= p; |

          &= nbsp;        |  Server   |   protocol  |  Server   |

          &= nbsp;        |           |            = |           = |

          &= nbsp;        +-----------+          =    +-----------+

          &= nbsp;           &n= bsp; /            =             &= nbsp;  \

          &= nbsp;            /            =             &= nbsp;    \   RTCWeb

          &= nbsp;           /            =             &= nbsp;      \  Signaling

          &= nbsp;          /            =             &= nbsp;        \

          &= nbsp;         /  = RTCWeb           &= nbsp;           &n= bsp;   \

          &= nbsp;        /   Signaling          &nbs= p;            = ;  \

          &= nbsp;       /        =             &= nbsp;           &n= bsp;      \

          &= nbsp; +-----------+          =             &= nbsp;    +-----------+

          &= nbsp; |           |            =             &= nbsp;  |           = |

          &= nbsp; |           |            =             &= nbsp;  |           = |

          &= nbsp; |  Browser  | ------------------------- |  Browser  = |

          &= nbsp; |           |          Media path       = |           |

          &= nbsp; |           |            =             &= nbsp;  |           = |

          &= nbsp; +-----------+          =             &= nbsp;    +-----------+

            +-----------+  =             &= nbsp;            +-----------+

          &= nbsp; |JS/HTML/CSS|          =             &= nbsp;    |JS/HTML/CSS|

          &= nbsp; +-----------+          =             &= nbsp;    +-----------+


Absolutely not.

1) The term "RTCWeb Signaling" has no clear definition, as = this discussion has proved again.

<partha> May I = need to put clear definition by which we will come to common understanding. = </partha>


2) The conceptual difference between the media path (managed by the = browser without being mediated through Javascript) and the signalling path = (mediated through Javascript, transmitted through interfaces that this WG has no intention of changing) is lost by the inversion of the "browser stack".

 

<partha> Agreed = and my intention is not manage media path through Javascript. My figure has to change = JS/HTML position to reflect it correctly. </partha>



The detailed relationships between the browser components are better = described in Figure 1 of -overview- than in Figure 2 (the one you've quoted). I've = noted the need to mention that the JS uses browser functions to access HTTP = and WebSockets too, since it's apparently not completely obvious to = all.

<partha> My = intention of the mail is above statement and it is not clear from the figure 1 & = 2.  </partha>




 

I = explained the same diagram in Fig 1 of draft-partha-rtcweb-signaling-00. RTCWeb = signaling shall be proprietary HTTP/websocket. I’m asking this change = because I’m seeing folks confuses API vs. on-wire-protocol. Also, Please = note that JS + browser is the single system with two different modules and it = shall have protocol or API to communicate (without passing any information in = the wire). Could you please let me know in case I’m missing = something.

 

Thanks

Partha

 

 

------_=_NextPart_001_01CC8E28.CC4331CC-- From randell-ietf@jesup.org Wed Oct 19 00:17: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 2204E11E8095 for ; Wed, 19 Oct 2011 00:17:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bN6tdK4sdx0K for ; Wed, 19 Oct 2011 00:17:56 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 69F0811E8096 for ; Wed, 19 Oct 2011 00:17:56 -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 1RGQPP-0001wg-8f for rtcweb@ietf.org; Wed, 19 Oct 2011 02:17:51 -0500 Message-ID: <4E9E7887.4000806@jesup.org> Date: Wed, 19 Oct 2011 03:13:11 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <2E239D6FCD033C4BAF15F386A979BF510F1367@sonusinmail02.sonusnet.com><2E239D6FCD033C4BAF15F386A979BF510F1532@sonusinmail02.sonusnet.com><2E239D6FCD033C4BAF15F386A979BF511598EE@sonusinmail02.sonusnet.com><665A16AB-AAD8-42B3-AC17-7E629EA2DE35@phonefromhere.com><2E239D6FCD033C4BAF15F386A979BF5115992E@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F3 86A979B F51159950@so nusinmail02.sonusnet.com> <0950F0E1-6E4B-407F-9563-654AFE79F64B@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF51159994@sonusinmail02.sonusnet.com> <6398F67A-5E41-44BB-ABB2-831AB7C48DCC@ag-projects.com> <8486C8728176924BAF5BDB2F7D7EEDDF3E091CA3@ucolhp4d.easf.csd.disa.mil> <2E2B1F85-1DED-460D-B17D-0850DB3ACBA9@phonefromhere.com> <8486C8728176924BAF5BDB2F7D7EEDDF3E091D31@ucolhp4d.easf.csd.disa.mil> <7357A569-83A3-43B6-80A7-E2374D78CE28@phonefromhere.com> In-Reply-To: <7357A569-83A3-43B6-80A7-E2374D78CE28@phonefromhere.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] Review request for RTCWeb standard 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: Wed, 19 Oct 2011 07:17:57 -0000 On 10/18/2011 10:19 AM, Tim Panton wrote: > > On 18 Oct 2011, at 14:59, Roy, Radhika R USA CIV (US) wrote: > >> Tim: >> >> The puzzle is this. The other user may not agree completely with the offer of the first user. Even the other user may agree with a given codec type, he/she may not agree other features including bandwidth of the codec. >> >> It simple turns out that a freedom needs to be given for negotiations some-like offer/answer. > > The example I gave had _no_ negotiation, no back and forth, because the application's webserver was > told all the capabilities in advance, (at login in my example), it simply _decided_ based on > it's view of the union of the capabilities of the two ends. It then informed them of the choice > (which may have been asymmetric by the way) and told them to get on with it. > > To the extent that there was a 'negotiation', it took place in a single thread on the web server, > with no propagation delays or locks needed. This example you give raises some security issues based on the current proposals. We require that the user ok access to the camera and microphone; this is a call set up "on the fly" with apparently no individual certification from the user. This use-case would require the JS application get pre-authorization of media access, before any actual access occurs, and have that access persist until , across multiple individual connections. So is this outside of the current security model, since it seems to bring in a number of new requirements? To support this, we would need: 1) pre-authorization of camera/mic access 2) authorization continues until a particular active state with the server ends (leaving the game) This could be handled most simply by considering this to be a single 'call' to the server, which has a default 'forked' instance answered by the server with media 'on-hold'. This 'call' is also forked by the server as needed to other players who happen to be nearby/call/etc. Since these are forks of an existing call, no individual authorization is required (effectively it's the equivalent to a mesh conference where users join and leave over time). The 'call' ends when the user terminates the call to the server. With that sort of setup, I think we can probably handle it within the current security model. The big thing we would need to make sure of is making sure forking is available, and that authorization could occur at the start with the server, even if the server doesn't want to actually receive media. (In a push, it could receive and drop media.) As this is all forking of an initial "call", you can handle it with normal forking negotiation. The server would take the two active "calls" from the users, and generate a forked "answer" to each. It does point out that each side thinks it made an offer and the other side answered. It requires the server handle the answer generation correctly in order to give a proper answer that will match what the device it's masquerading as will be ok with. > Offer - Answer really only crops up because there is a requirement (which I personally put very low on our priorities) to be able > to interop with legacy video phones without needing a media gateway. I do not see that as the reason for offer-answer semantics; and I don't know that we can meet that requirement thus far - and which requirement from the use-case document covers this? What exactly does it require? -- Randell Jesup randell-ietf@jesup.org From stefan.lk.hakansson@ericsson.com Wed Oct 19 00: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 4F09021F8678 for ; Wed, 19 Oct 2011 00:41:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.149 X-Spam-Level: X-Spam-Status: No, score=-6.149 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 1YzLl1UIPQDf for ; Wed, 19 Oct 2011 00:41: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 5FA1A21F8677 for ; Wed, 19 Oct 2011 00:41:27 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-ba-4e9e7f26ce1c Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id F7.6A.20773.62F7E9E4; Wed, 19 Oct 2011 09:41:26 +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, 19 Oct 2011 09:41:25 +0200 Message-ID: <4E9E7F24.8030408@ericsson.com> Date: Wed, 19 Oct 2011 09:41:24 +0200 From: =?ISO-8859-1?Q?Stefan_H=E5kansson?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110922 Lightning/1.0b2 Thunderbird/3.1.15 MIME-Version: 1.0 To: rtcweb@ietf.org References: <15B0E3AD-3086-499A-8E79-7AE58B3376C4@cisco.com> <4E9D8D82.707@ericsson.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [rtcweb] SDP Offer/Answer draft-jennings-rtcweb-signaling: Glare handling X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 07:41:28 -0000 Speaking strictly as an individual (I'm in the same organization as Magnus, so if that means that this input has less weight so be it): I think this discussion got a bit off track. In the ROAP draft glaring is resolved by backing off and waiting in the order of seconds. Magnus proposes another solution that resolves glaring immediately (no need to wait). I think this is a really good idea, especially in the light of that the current API proposal allows each endpoint to asynchronously add streams (for transmission to the other endpoint) at any time. This means that glaring conditions could be quite common. Why should we design something that delays the start of those streams quite some time when it easily can be avoided? Then there could (or not) be situations where the back-off resolution does not work at all, but I think a more efficient glaring resolution mechanism makes sense regardless. (NB: If there are other ways to resolve glaring without delay I'm all for it, I just want to avoid that glaring would delay steam set up unnecessarily) Stefan On 10/18/2011 05:56 PM, BeckW@telekom.de wrote: > > Ekr wrote: >> I'm not sure I agree with this. 2-5 seconds isn't really that long to >> wait for the interval between the caller starting the call and the callee being alerted. > > I consider 2-5 s a quite horrible call setup time, and I can tell that customers really care about it. Of course it's acceptable if such a long setup delay only occurs occasionally. > > Wolfgang Beck > > > Deutsche Telekom Netzproduktion GmbH > Fixed Mobile Engineering Deutschland > Wolfgang Beck > Heinrich-Hertz-Strae 3-7, 64295 Darmstadt > +49 6151 628 2832 (Tel.) > http://www.telekom.de > > Erleben, was verbindet. > > Deutsche Telekom Netzproduktion GmbH > Aufsichtsrat: Dr. Thomas Knoll (Vorsitzender) > Geschftsfhrung: Dr. Bruno Jacobfeuerborn (Vorsitzender), Albert Matheis, Klaus Peren > Handelsregister: Amtsgericht Bonn HRB 14190 > Sitz der Gesellschaft Bonn > USt-IdNr. DE 814645262 > > Groe Vernderungen fangen klein an - Ressourcen schonen und nicht jede E-Mail drucken. > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From randell-ietf@jesup.org Wed Oct 19 00: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 C5A9A21F8B27 for ; Wed, 19 Oct 2011 00:48:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[AWL=0.046, 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 C8F3rdTkbCSr for ; Wed, 19 Oct 2011 00:48:05 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 1E39021F8B24 for ; Wed, 19 Oct 2011 00:48:05 -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 1RGQse-0004aF-Rd for rtcweb@ietf.org; Wed, 19 Oct 2011 02:48:04 -0500 Message-ID: <4E9E7F9F.1020503@jesup.org> Date: Wed, 19 Oct 2011 03:43:27 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <2E239D6FCD033C4BAF15F386A979BF510F1367@sonusinmail02.sonusnet.com> <665A16AB-AAD8-42B3-AC17-7E629EA2DE35@phonefromhere.com> <2E239D6FCD033C4BAF15F386A979BF5115992E@sonusinmail02.sonusnet.com> <0950F0E1-6E4B-407F-9563-654AFE79F64B@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF51159994@sonusinmail02.sonusnet.com> <1F2A2C70609D9E41844A2126145FC09804004302@HKGMBOXPRD22.polycom.com> <033458F56EC2A64E8D2D7B759FA3E7E703DBF614@sonusmail04.sonusnet.com> <8486C8728176924BAF5BDB2F7D7EEDDF3E091D13@ucolhp4d.easf.csd.disa.mil> <2E239D6FCD033C4BAF15F386A979BF511599F3@sonusinmail02.sonusnet.com> <37796D08-7A24-478B-8157-052FFB2E3945@acmepacket.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] Review request for RTCWeb standard 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: Wed, 19 Oct 2011 07:48:05 -0000 On 10/18/2011 7:40 PM, Ted Hardie wrote: > > On Tue, Oct 18, 2011 at 1:43 PM, Hadriel Kaplan > wrote: > It *is* an advantage. It puts the power in the hands of the app > developer, not the browser developer. > > > > As Peter Parker's uncle Ben tells, us, with great power comes great > responsibility. Yes, it gives them a choice, but it also makes them > responsible for something that is, bluntly, infrastructure plumbing that > most of them would rather just worked. I'll come back to where I've been before - Give those who want it access to use their own signaling (on top of ROAP at the browser interface), and provide a "simple" default signaling mechanism that *can* be used on top of ROAP. Responses to arguments against this: 1) Don't lock us in to a existing protocol because it blocks doing X This doesn't lock anyone in; all can use the ROAP interface directly and ignore this protocol offered by the browser. 2) If it's baked into the browsers, it will take years to update/bugfix A specific service (website/app) can replace the "standard" protocol with their updated implementation in JS any time they want - and could even serve it only to people running non-updated browsers. 3) It will take forever to design and agree to a new protocol A valid, good point. That would point one to use an existing protocol, or a subset of one. 4) It bloats the browser with something no one will use I agree it will increase the browser size. I would disagree that no one would use it. I'll note that such a signaling library in the browser doesn't *have* to be required; a browser could offer it, and the service's app could use it if available and download a JS version if not. This (and ROAP, and standard servers for the protocol) would allow the infamous "20-line" JS client, without tying anyone's hands. >> It's certainly less efficient and, given the majority of users now >> accessing the Internet via mobile devices which are power and >> bandwidth constrained, that sort of wastefulness should not be >> trivially dismissed. > > If a mobile platform is so constrained of power and bandwidth that > downloading a JS library is difficult, it's unlikely it would be > able to handle RTP/RTCP media regardless. > > > You don't get to be rich by making a lot of money, you get to be rich by > keeping it. The same is true with energy in mobile systems. Pay > attention to it all the time, and there's a fair chance you will never > run out. Pay attention to it only when you're low, and you're likely > paying attention to late. 150KB signaling libraries can take time (and energy!) to download; if you only have the bandwidth for a narrowband audio call (and rtcweb is not just for video!) it could take up to 45 seconds worth of in-call bandwidth to download the signaling library alone. Now, hopefully this is cached if it's a service you use a lot, but you can't count on it being cached in any particular instance. Even if you have a 128K ISDN-equivalent connection, it's still around 10 seconds just to download the library. Always remember, not everyone has megabit bandwidth, or a good wireless connection - and as Ted mentions, even those who do are often energy-constrained. This is even more the case in developing countries that may be skipping a lot of the wired infrastructure we take for granted. I'll also note that while browsers are very good at running JS code fast, it isn't always the most efficient way to go, and over time is less efficient due to repeated re-parsing and re-JIT-ing the same code. A built-in-but-optional protocol would be more efficient both in usage (faster is also less energy spent) and in not requiring re-download and re-parse/re-JIT. A major issue? probably not, but a valid consideration. -- Randell Jesup randell-ietf@jesup.org From stefan.lk.hakansson@ericsson.com Wed Oct 19 00:52:36 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA16921F8B3B for ; Wed, 19 Oct 2011 00:52:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.179 X-Spam-Level: X-Spam-Status: No, score=-6.179 tagged_above=-999 required=5 tests=[AWL=0.120, 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 J-u1n5mLvdGP for ; Wed, 19 Oct 2011 00:52: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 3073F21F8B6E for ; Wed, 19 Oct 2011 00:52:36 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-de-4e9e81b4cb89 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 50.AC.20773.4B18E9E4; Wed, 19 Oct 2011 09:52:21 +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, 19 Oct 2011 09:52:20 +0200 Message-ID: <4E9E81B3.10404@ericsson.com> Date: Wed, 19 Oct 2011 09:52:19 +0200 From: =?ISO-8859-1?Q?Stefan_H=E5kansson?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110922 Lightning/1.0b2 Thunderbird/3.1.15 MIME-Version: 1.0 To: Roman Shpount References: <15B0E3AD-3086-499A-8E79-7AE58B3376C4@cisco.com> <4E9D43D2.9010804@alvestrand.no> <4E9D5E9A.7090308@alvestrand.no> <4E9D7019.2020303@ericsson.com> <4E9D85CB.6030503@ericsson.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] API options for supporting fork with ROAP (Re: SDP Offer/Answer draft-jennings-rtcweb-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: Wed, 19 Oct 2011 07:52:37 -0000 On 10/18/2011 06:07 PM, Roman Shpount wrote: > On Tue, Oct 18, 2011 at 9:57 AM, Stefan Hkansson LK > > wrote: > > What I mean is: if this web app has already created a > PeerConncection, and is about to open another one (e.g. for a new > fork), the new PeerConnection should use the same local candidates > as the one already created collected. > > > What would happen if new PeerConnection has a different set of > codecs/media streams? Do we just add/remove local candidates based on > how many different streams are needed? Now we're getting into the stuff that is not my home turf :). But as I understand it, the current assumption is that the browser would in fact only open one port which all RTP streams use. In most cases all streams would be multiplexed over the same 5-tuple, but the other end (if it is not a browser) could open separate ports for each RTP stream, if it (read legacy) would like to avoid multiplexing. This means that when the first PeerConnection is set up it would gather candidates (host, srflx, ...) for one port only; my idea is that these candidates would be re-used if a second PeerConnection is created. Codecs and media streams would be negotiated per PeerConnection. I hope this is roughly right, not my home turf as said. > > Overall I do like this idea since it not only addresses the forking > issue, but suggest a good resource usage policy. > _____________ > Roman Shpount > From Markus.Isomaki@nokia.com Wed Oct 19 01:07: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 B785A21F84D8 for ; Wed, 19 Oct 2011 01:07:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pj6gD3e7XYCt for ; Wed, 19 Oct 2011 01:07:40 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id A730521F8B3E for ; Wed, 19 Oct 2011 01:07:40 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p9J8761m025813; Wed, 19 Oct 2011 11:07:36 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 19 Oct 2011 11:07:23 +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; Wed, 19 Oct 2011 10:07:22 +0200 Received: from 008-AM1MPN1-043.mgdnok.nokia.com ([169.254.3.167]) by 008-AM1MMR1-002.mgdnok.nokia.com ([65.54.30.57]) with mapi id 14.01.0339.002; Wed, 19 Oct 2011 10:01:53 +0200 From: To: , Thread-Topic: [rtcweb] My Opinion: Why I think a negotiating protocol is a Good Thing Thread-Index: AQHMjiUvNVhwvx21ak2ubV3jL1roG5WDSS1A Date: Wed, 19 Oct 2011 08:01:52 +0000 Message-ID: References: <4E9D667A.2040703@alvestrand.no> <9B03E9E2-4376-465E-84F5-EDAC51390408@phonefromhere.com> <570BDE5E-6EDC-4094-8DC0-094CEC3F12DF@acmepacket.com> In-Reply-To: <570BDE5E-6EDC-4094-8DC0-094CEC3F12DF@acmepacket.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.21.75.159] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 19 Oct 2011 08:07:23.0311 (UTC) FILETIME=[21C923F0:01CC8E36] X-Nokia-AV: Clean Cc: rtcweb@ietf.org Subject: Re: [rtcweb] My Opinion: Why I think a negotiating protocol is a Good Thing X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 08:07:41 -0000 Hi, Hadriel Kaplan wrote: > >How many RTP libraries do you know of that use SDP offer/answer protocol a= s >their API? > This confuses me too in the direction where the RTC-Web work seems to be he= ading. There are countless SIP user agents and XMPP clients that implement = SDP offer/answer or the Jingle equivalent. But I've not heard SDP used as = an *API* towards the RTP/media libraries. So, when I think about the RTP/me= dia API that the browser should expose to the Javascript app, I'm surprised= to see SDP on that level. I see that it may be useful to have a higher level API that provides ICE an= d SDP offer/answer type of functions to developers who want that. But I'm n= ot sure if that should be a real W3C standard API or could it just be Javas= cript libraries.=20 Having said that, I'm not going to write a "signaling" or API draft. I can = live with any outcome that does not limit app developers too much. So for m= e at this point it would be valuable input to understand what we are *loosi= ng* if the API were based on SDP and we would have something like ROAP. I'v= e heard it "limits innovation" but I haven't seen concrete examples of that= . So if Hadriel is going to produce a draft on these issues, it would be gr= eat if it had something like that. =20 Markus From harald@alvestrand.no Wed Oct 19 01: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 971CF21F848A for ; Wed, 19 Oct 2011 01:21:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.558 X-Spam-Level: X-Spam-Status: No, score=-110.558 tagged_above=-999 required=5 tests=[AWL=0.041, 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 pUNx5QV8MkQ6 for ; Wed, 19 Oct 2011 01:21:01 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id B1FA421F8484 for ; Wed, 19 Oct 2011 01:21:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 68D5939E162 for ; Wed, 19 Oct 2011 10:20: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 QfQAvzzhjrPf for ; Wed, 19 Oct 2011 10:20:42 +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 CFE4E39E0D2 for ; Wed, 19 Oct 2011 10:20:42 +0200 (CEST) Message-ID: <4E9E885A.1030108@alvestrand.no> Date: Wed, 19 Oct 2011 10:20:42 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: rtcweb@ietf.org References: <15B0E3AD-3086-499A-8E79-7AE58B3376C4@cisco.com> <4E9D43D2.9010804@alvestrand.no> <4E9D5E9A.7090308@alvestrand.no> <4E9D7019.2020303@ericsson.com> <4E9D85CB.6030503@ericsson.com> <4E9E81B3.10404@ericsson.com> In-Reply-To: <4E9E81B3.10404@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [rtcweb] API options for supporting fork with ROAP (Re: SDP Offer/Answer draft-jennings-rtcweb-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: Wed, 19 Oct 2011 08:21:01 -0000 On 10/19/11 09:52, Stefan Hkansson wrote: > On 10/18/2011 06:07 PM, Roman Shpount wrote: >> On Tue, Oct 18, 2011 at 9:57 AM, Stefan Hkansson LK >> > > wrote: >> >> What I mean is: if this web app has already created a >> PeerConncection, and is about to open another one (e.g. for a new >> fork), the new PeerConnection should use the same local candidates >> as the one already created collected. >> >> >> What would happen if new PeerConnection has a different set of >> codecs/media streams? Do we just add/remove local candidates based on >> how many different streams are needed? > > Now we're getting into the stuff that is not my home turf :). But as I > understand it, the current assumption is that the browser would in > fact only open one port which all RTP streams use. In most cases all > streams would be multiplexed over the same 5-tuple, but the other end > (if it is not a browser) could open separate ports for each RTP > stream, if it (read legacy) would like to avoid multiplexing. Actually my current understanding is that in all cases, all video components of all MediaStreams would use the same RTP session, and all audio components of all MediaStreams would use the same RTP session. If the TOGETHER extension (draft-alvestrand-one-rtp) or BONDING extension (next version of draft-holmberg-mmusic-sdp-multiplex-negotiation; the name changed) is supported, both media types would be sent across one RTP session. The word "multiplexing" is awfully confusing; at least Holmberg and I have concluded that it's better for communication if we don't use it. > > This means that when the first PeerConnection is set up it would > gather candidates (host, srflx, ...) for one port only; my idea is > that these candidates would be re-used if a second PeerConnection is > created. With a caveat .... note that the parameters passed to the constructor of PeerConnection (STUN/TURN server) will affect the candidate sets, so if those change, the cached candidates cannot be used. > > Codecs and media streams would be negotiated per PeerConnection. > > I hope this is roughly right, not my home turf as said. > >> >> Overall I do like this idea since it not only addresses the forking >> issue, but suggest a good resource usage policy. >> _____________ >> Roman Shpount >> > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From neils@vipadia.com Wed Oct 19 01:33: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 BDA1B21F8B71 for ; Wed, 19 Oct 2011 01:33:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.957 X-Spam-Level: X-Spam-Status: No, score=-2.957 tagged_above=-999 required=5 tests=[AWL=0.019, 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 RHuMXwPAF70T for ; Wed, 19 Oct 2011 01:33: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 493CB21F8B6F for ; Wed, 19 Oct 2011 01:33:43 -0700 (PDT) Received: by iabn5 with SMTP id n5so2017079iab.31 for ; Wed, 19 Oct 2011 01:33:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.82.131 with SMTP id b3mr2441228ibl.74.1319013222788; Wed, 19 Oct 2011 01:33:42 -0700 (PDT) Sender: neils@vipadia.com Received: by 10.231.199.4 with HTTP; Wed, 19 Oct 2011 01:33:42 -0700 (PDT) In-Reply-To: <4E9E7F9F.1020503@jesup.org> References: <2E239D6FCD033C4BAF15F386A979BF510F1367@sonusinmail02.sonusnet.com> <665A16AB-AAD8-42B3-AC17-7E629EA2DE35@phonefromhere.com> <2E239D6FCD033C4BAF15F386A979BF5115992E@sonusinmail02.sonusnet.com> <0950F0E1-6E4B-407F-9563-654AFE79F64B@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF51159994@sonusinmail02.sonusnet.com> <1F2A2C70609D9E41844A2126145FC09804004302@HKGMBOXPRD22.polycom.com> <033458F56EC2A64E8D2D7B759FA3E7E703DBF614@sonusmail04.sonusnet.com> <8486C8728176924BAF5BDB2F7D7EEDDF3E091D13@ucolhp4d.easf.csd.disa.mil> <2E239D6FCD033C4BAF15F386A979BF511599F3@sonusinmail02.sonusnet.com> <37796D08-7A24-478B-8157-052FFB2E3945@acmepacket.com> <4E9E7F9F.1020503@jesup.org> Date: Wed, 19 Oct 2011 09:33:42 +0100 X-Google-Sender-Auth: R477OdPYjIHil-vvlE4q-qzcJVM Message-ID: From: Neil Stratford To: Randell Jesup Content-Type: multipart/alternative; boundary=000e0cd6b306992fff04afa2b20a Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Review request for RTCWeb standard 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: Wed, 19 Oct 2011 08:33:43 -0000 --000e0cd6b306992fff04afa2b20a Content-Type: text/plain; charset=ISO-8859-1 On Wed, Oct 19, 2011 at 8:43 AM, Randell Jesup wrote: > > 1) Don't lock us in to a existing protocol because it blocks doing X > > This doesn't lock anyone in; all can use the ROAP interface directly > and ignore this protocol offered by the browser. > At this point you are already locked in to a protocol that must fit the ROAP model, which I see as a problem if you want to build a solutuion that doesn't look exactly like a traditional RTC system based on SDP o/a. Neil --000e0cd6b306992fff04afa2b20a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Oct 19, 2011 at 8:43 AM, Randell Jesup <randell-ietf@jesup.or= g> wrote:

1) Don't lock us in to a existing protocol because it blocks doing X
=A0 This doesn't lock anyone in; all can use the ROAP interface direct= ly
=A0 and ignore this protocol offered by the browser.
=
At this point you are already locked in to a protocol that m= ust fit the ROAP model, which I see as a problem if you want to build a sol= utuion that doesn't look exactly like a traditional RTC system based on= SDP o/a.

Neil=A0

--000e0cd6b306992fff04afa2b20a-- From harald@alvestrand.no Wed Oct 19 02:25: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 4E4CC21F863E for ; Wed, 19 Oct 2011 02:25:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.561 X-Spam-Level: X-Spam-Status: No, score=-110.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 PYNIzpekAYKs for ; Wed, 19 Oct 2011 02:25:43 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id A6A2421F8634 for ; Wed, 19 Oct 2011 02:25:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 766C239E162; Wed, 19 Oct 2011 11:25: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 FY3F30Z9mWWU; Wed, 19 Oct 2011 11:25:41 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 08AC639E0D2; Wed, 19 Oct 2011 11:25:41 +0200 (CEST) Message-ID: <4E9E9794.8000901@alvestrand.no> Date: Wed, 19 Oct 2011 11:25:40 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: Ted Hardie 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] Friday Call details for signaling discussion X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 09:25:44 -0000 On 10/19/11 01:22, Ted Hardie wrote: > Below are the call-in details for Friday's call. This is meant to > give any interested working group participants some extra time in > high-bandwidth discussions while we hash out the signaling proposals > that have circulated on the list. I expect discussion will include > ROAP as well as either a proposal from Hadriel and/or Wolfgang Beck's > alt-ic draft. Will you be sending out an official reading list before the call? My current list of maybe-relevant material includes: - draft-jennings-rtcweb-signaling-00 (ROAP) - draft-beck-rtcweb-alt-ic-00 (always using a single Web server) - draft-partha-rtcweb-signaling-00 (advocates picking a standard signaling protocol, lists candidates) - draft-ibc-rtcweb-sip-websocket-00 (on use of WebSocket as a SIP subprotocol) - Neil Stratford's "low level JS API" proposal: https://docs.google.com/document/pub?id=1MfrFHKx6O6yWtIv_jqwyH-RAbm8AgRtXQ7dJTZz5J2g I can't find any other docs at the moment. Of these, I would see ROAP and Neil Stratford's document as the ones that come closest to being "concrete solutions" as I understood the intent of that word in the call sent out on October 4. But I may have missed some, or the chairs might want to rule the "low level JS API" out of scope, since it's not an I-D (or referred to by an I-D) at this time. Harald From christer.holmberg@ericsson.com Wed Oct 19 02:35: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 51F1521F8B3E for ; Wed, 19 Oct 2011 02:35:35 -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 j5lN-geENdyd for ; Wed, 19 Oct 2011 02:35:34 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 8A69921F8B7A for ; Wed, 19 Oct 2011 02:35:34 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-0c-4e9e99e5696c Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 11.B4.20773.5E99E9E4; Wed, 19 Oct 2011 11:35:33 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Wed, 19 Oct 2011 11:35:33 +0200 From: Christer Holmberg To: Harald Alvestrand , "rtcweb@ietf.org" Date: Wed, 19 Oct 2011 11:35:32 +0200 Thread-Topic: Draft name change: draft-holmberg-mmusic-sdp-bundle-negotiation-00 [was: API options for supporting fork with ROAP (Re: SDP Offer/Answer draft-jennings-rtcweb-signaling] Thread-Index: AcyOOAvFEQM5Q6/cSBGsE2j1JPlOUgACcZXQ Message-ID: <7F2072F1E0DE894DA4B517B93C6A058522341F4895@ESESSCMS0356.eemea.ericsson.se> References: <15B0E3AD-3086-499A-8E79-7AE58B3376C4@cisco.com> <4E9D43D2.9010804@alvestrand.no> <4E9D5E9A.7090308@alvestrand.no> <4E9D7019.2020303@ericsson.com> <4E9D85CB.6030503@ericsson.com> <4E9E81B3.10404@ericsson.com> <4E9E885A.1030108@alvestrand.no> In-Reply-To: <4E9E885A.1030108@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== Subject: [rtcweb] Draft name change: draft-holmberg-mmusic-sdp-bundle-negotiation-00 [was: API options for supporting fork with ROAP (Re: SDP Offer/Answer draft-jennings-rtcweb-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: Wed, 19 Oct 2011 09:35:35 -0000 Hi, =20 >> Now we're getting into the stuff that is not my home turf :).=20 >> But as I understand it, the current assumption is that the browser would= in=20 >> fact only open one port which all RTP streams use. In most=20 >> cases all streams would be multiplexed over the same 5-tuple, but the=20 >> other end (if it is not a browser) could open separate ports for each RT= P=20 >> stream, if it (read legacy) would like to avoid multiplexing. >> Actually my current understanding is that in all cases, all=20 >> video components of all MediaStreams would use the same RTP=20 >> session, and all audio components of all MediaStreams would=20 >> use the same RTP session. >=20 > If the TOGETHER extension (draft-alvestrand-one-rtp) or=20 > BONDING extension (next version of draft-holmberg-mmusic-sdp-multiplex-ne= gotiation;=20 > the name changed) is supported, both media types would be sent across=20 > one RTP session. Actually, BUNDLE is the name of the new extension :) Due to the name change of the extension, the name of the draft has also cha= nged. The name is now: draft-holmberg-mmusic-sdp-bundle-negotiation-00. http://www.ietf.org/id/draft-holmberg-mmusic-sdp-bundle-negotiation-00.txt Note that Harald is now co-author of the draft. Regards, Christer From stefan.lk.hakansson@ericsson.com Wed Oct 19 03:05: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 A6C0421F8B67 for ; Wed, 19 Oct 2011 03:05:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.199 X-Spam-Level: X-Spam-Status: No, score=-6.199 tagged_above=-999 required=5 tests=[AWL=0.100, 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 3v2-FYKEJwWt for ; Wed, 19 Oct 2011 03:05: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 CDA8121F8B5C for ; Wed, 19 Oct 2011 03:05:03 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-4e-4e9ea0cec499 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id EA.7B.20773.EC0AE9E4; Wed, 19 Oct 2011 12:05:02 +0200 (CEST) Received: from [150.132.142.226] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.137.0; Wed, 19 Oct 2011 12:05:02 +0200 Message-ID: <4E9EA0CE.3020205@ericsson.com> Date: Wed, 19 Oct 2011 12:05:02 +0200 From: =?ISO-8859-1?Q?Stefan_H=E5kansson_LK?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110922 Lightning/1.0b2 Thunderbird/3.1.15 MIME-Version: 1.0 To: rtcweb@ietf.org References: <15B0E3AD-3086-499A-8E79-7AE58B3376C4@cisco.com> <4E9D43D2.9010804@alvestrand.no> <4E9D5E9A.7090308@alvestrand.no> <4E9D7019.2020303@ericsson.com> <4E9D85CB.6030503@ericsson.com> <4E9E81B3.10404@ericsson.com> <4E9E885A.1030108@alvestrand.no> In-Reply-To: <4E9E885A.1030108@alvestrand.no> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [rtcweb] API options for supporting fork with ROAP (Re: SDP Offer/Answer draft-jennings-rtcweb-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: Wed, 19 Oct 2011 10:05:04 -0000 On 10/19/2011 10:20 AM, Harald Alvestrand wrote: > On 10/19/11 09:52, Stefan Hkansson wrote: >> On 10/18/2011 06:07 PM, Roman Shpount wrote: >>> On Tue, Oct 18, 2011 at 9:57 AM, Stefan Hkansson LK >>> >> > wrote: >>> >>> What I mean is: if this web app has already created a >>> PeerConncection, and is about to open another one (e.g. for a new >>> fork), the new PeerConnection should use the same local candidates >>> as the one already created collected. >>> >>> >>> What would happen if new PeerConnection has a different set of >>> codecs/media streams? Do we just add/remove local candidates based on >>> how many different streams are needed? >> >> Now we're getting into the stuff that is not my home turf :). But as I >> understand it, the current assumption is that the browser would in >> fact only open one port which all RTP streams use. In most cases all >> streams would be multiplexed over the same 5-tuple, but the other end >> (if it is not a browser) could open separate ports for each RTP >> stream, if it (read legacy) would like to avoid multiplexing. > Actually my current understanding is that in all cases, all video > components of all MediaStreams would use the same RTP session, and all > audio components of all MediaStreams would use the same RTP session. > > If the TOGETHER extension (draft-alvestrand-one-rtp) or BONDING > extension (next version of > draft-holmberg-mmusic-sdp-multiplex-negotiation; the name changed) is > supported, both media types would be sent across one RTP session. > > The word "multiplexing" is awfully confusing; at least Holmberg and I > have concluded that it's better for communication if we don't use it. >> >> This means that when the first PeerConnection is set up it would >> gather candidates (host, srflx, ...) for one port only; my idea is >> that these candidates would be re-used if a second PeerConnection is >> created. > With a caveat .... > > note that the parameters passed to the constructor of PeerConnection > (STUN/TURN server) will affect the candidate sets, so if those change, > the cached candidates cannot be used. That's right. > >> >> Codecs and media streams would be negotiated per PeerConnection. >> >> I hope this is roughly right, not my home turf as said. >> >>> >>> Overall I do like this idea since it not only addresses the forking >>> issue, but suggest a good resource usage policy. >>> _____________ >>> Roman Shpount >>> >> >> _______________________________________________ >> 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 Wed Oct 19 03:51: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 88F4521F86FF for ; Wed, 19 Oct 2011 03:51:13 -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 RQraddudnO+M for ; Wed, 19 Oct 2011 03:51:12 -0700 (PDT) Received: from zimbra.westhawk.co.uk (zimbra.westhawk.co.uk [192.67.4.167]) by ietfa.amsl.com (Postfix) with ESMTP id 8176121F8753 for ; Wed, 19 Oct 2011 03:51:11 -0700 (PDT) Received: from [192.168.0.14] (unknown [93.89.81.113]) by zimbra.westhawk.co.uk (Postfix) with ESMTP id C20E937A902; Wed, 19 Oct 2011 12:03:51 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Tim Panton In-Reply-To: <4E9E7F9F.1020503@jesup.org> Date: Wed, 19 Oct 2011 11:51:00 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <76E7E93D-E76B-48E0-BE10-B44D286C3F01@phonefromhere.com> References: <2E239D6FCD033C4BAF15F386A979BF510F1367@sonusinmail02.sonusnet.com> <665A16AB-AAD8-42B3-AC17-7E629EA2DE35@phonefromhere.com> <2E239D6FCD033C4BAF15F386A979BF5115992E@sonusinmail02.sonusnet.com> <0950F0E1-6E4B-407F-9563-654AFE79F64B@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF51159994@sonusinmail02.sonusnet.com> <1F2A2C70609D9E41844A2126145FC09804004302@HKGMBOXPRD22.polycom.com> <033458F56EC2A64E8D2D7B759FA3E7E703DBF614@sonusmail04.sonusnet.com> <8486C8728176924BAF5BDB2F7D7EEDDF3E091D13@ucolhp4d.easf.csd.disa.mil> <2E239D6FCD033C4BAF15F386A979BF511599F3@sonusinmail02.sonusnet.com> <37796D08-7A24-478B-8157-052FFB2E3945@acmepacket.com> <4E9E7F9F.1020503@jesup.org> To: Randell Jesup X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Review request for RTCWeb standard 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: Wed, 19 Oct 2011 10:51:13 -0000 On 19 Oct 2011, at 08:43, Randell Jesup wrote: > On 10/18/2011 7:40 PM, Ted Hardie wrote: >>=20 >> On Tue, Oct 18, 2011 at 1:43 PM, Hadriel Kaplan = > > wrote: >> It *is* an advantage. It puts the power in the hands of the app >> developer, not the browser developer. >>=20 >>=20 >>=20 >> As Peter Parker's uncle Ben tells, us, with great power comes great >> responsibility. Yes, it gives them a choice, but it also makes them >> responsible for something that is, bluntly, infrastructure plumbing = that >> most of them would rather just worked. >=20 > I'll come back to where I've been before - Give those who want it = access to use their own signaling (on top of ROAP at the browser = interface), and provide a "simple" default signaling mechanism that = *can* be used on top of ROAP. >=20 > Responses to arguments against this: >=20 > 1) Don't lock us in to a existing protocol because it blocks doing X >=20 > This doesn't lock anyone in; all can use the ROAP interface directly > and ignore this protocol offered by the browser. >=20 > 2) If it's baked into the browsers, it will take years to = update/bugfix >=20 > A specific service (website/app) can replace the "standard" protocol > with their updated implementation in JS any time they want - and > could even serve it only to people running non-updated browsers. >=20 > 3) It will take forever to design and agree to a new protocol >=20 > A valid, good point. That would point one to use an existing > protocol, or a subset of one. >=20 > 4) It bloats the browser with something no one will use >=20 > I agree it will increase the browser size. I would disagree that no > one would use it. >=20 > I'll note that such a signaling library in the browser doesn't *have* = to be required; a browser could offer it, and the service's app could = use it if available and download a JS version if not. >=20 > This (and ROAP, and standard servers for the protocol) would allow the = infamous "20-line" JS client, without tying anyone's hands. >=20 >>> It's certainly less efficient and, given the majority of users = now >>> accessing the Internet via mobile devices which are power and >>> bandwidth constrained, that sort of wastefulness should not be >>> trivially dismissed. >>=20 >> If a mobile platform is so constrained of power and bandwidth that >> downloading a JS library is difficult, it's unlikely it would be >> able to handle RTP/RTCP media regardless. >>=20 >>=20 >> You don't get to be rich by making a lot of money, you get to be rich = by >> keeping it. The same is true with energy in mobile systems. Pay >> attention to it all the time, and there's a fair chance you will = never >> run out. Pay attention to it only when you're low, and you're likely >> paying attention to late. >=20 > 150KB signaling libraries can take time (and energy!) to download; if = you only have the bandwidth for a narrowband audio call (and rtcweb is = not just for video!) it could take up to 45 seconds worth of in-call = bandwidth to download the signaling library alone. Now, hopefully this = is cached if it's a service you use a lot, but you can't count on it = being cached in any particular instance. Even if you have a 128K = ISDN-equivalent connection, it's still around 10 seconds just to = download the library. Always remember, not everyone has megabit = bandwidth, or a good wireless connection - and as Ted mentions, even = those who do are often energy-constrained. This is even more the case = in developing countries that may be skipping a lot of the wired = infrastructure we take for granted. True - but those are _exactly_ the environments which _won't_ need all = the second order requirements of detailed management of video codecs=20 and multiple streams (i.e. the ones that make us 'need' SDP). They will = run a single codec (amr-nb presumably) and not negotiate. The signalling=20= library for that could be _incredibly_ simple, small and efficient, = provided that they don't have to implement a full legacy protocol and = can delegate the hard work to a solar powered webserver elsewhere.=20 =20 (As an aside, why would you use a PSTN-alike-web app on a GSM phone if = you were worried about battery life?=20 GSM's power management is going to trounce anything we can do on the = VoIP side for some years.=20 So this use case requires the _tightest_ possible web integration to = justify it) As a datapoint, phono's xmpp/jingle implementation (including support = for 4 different audio backends) is < 100k , It does IM and audio with = multiple codecs. I doubt that adding video would tip it over the 100k = mark. But that is a full legacy protocol.=20 Setting up a basic audio call should be the proverbial 20 lines of = javascript - if one uses Neil's low-levelAPI proposal. >=20 > I'll also note that while browsers are very good at running JS code = fast, it isn't always the most efficient way to go, and over time is = less efficient due to repeated re-parsing and re-JIT-ing the same code. = A built-in-but-optional protocol would be more efficient both in usage = (faster is also less energy spent) and in not requiring re-download and = re-parse/re-JIT. A major issue? probably not, but a valid = consideration. Sure, but you have to weigh that benefit against the downsides of = picking the _wrong_ protocol. (which I've already ranted about at = length) I take the point that this is an 'built-in-but-optional protocol' -=20 but worry about the slippery slope from 'optional' to 'default' to = 'only-supported-way' to 'standard' . How do you propose to prevent that natural and inevitable progression = taking place=20 (probably before the first browser ships with it in) ? >=20 >=20 > --=20 > Randell Jesup > randell-ietf@jesup.org > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From tim@phonefromhere.com Wed Oct 19 04: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 EC6EA21F85B1 for ; Wed, 19 Oct 2011 04:06:08 -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 lY8mcuYdjxXj for ; Wed, 19 Oct 2011 04:06: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 080DE21F85A8 for ; Wed, 19 Oct 2011 04:06:08 -0700 (PDT) Received: from [192.168.0.14] (unknown [93.89.81.113]) by zimbra.westhawk.co.uk (Postfix) with ESMTP id 2333137A902; Wed, 19 Oct 2011 12:18:56 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Tim Panton In-Reply-To: <4E9E7887.4000806@jesup.org> Date: Wed, 19 Oct 2011 12:06:04 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <898B2A25-BF04-4F48-91FD-CA868FB5A79F@phonefromhere.com> References: <2E239D6FCD033C4BAF15F386A979BF510F1367@sonusinmail02.sonusnet.com><2E239D6FCD033C4BAF15F386A979BF510F1532@sonusinmail02.sonusnet.com><2E239D6FCD033C4BAF15F386A979BF511598EE@sonusinmail02.sonusnet.com><665A16AB-AAD8-42B3-AC17-7E629EA2DE35@phonefromhere.com><2E239D6FCD033C4BAF15F386A979BF5115992E@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F3 86A979B F51159950@so nusinmail02.sonusnet.com> <0950F0E1-6E4B-407F-9563-654AFE79F64B@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF51159994@sonusinmail02.sonusnet.com> <6398F67A-5E41-44BB-ABB2-831AB7C48DCC@ag-projects.com> <8486C8728176924BAF5BDB2F7D7EEDDF3E091CA3@ucolhp4d.easf.csd.disa.mil> <2E2B1F85-1DED-460D-B17D-0850DB3ACBA9@phonefromhere.com> <8486C8728176924BAF5BDB2F7D7EEDDF3E091D31@ucolhp4d.easf.csd.disa.mil> <7357A569-83A3-43B6-80A7-E2374D78CE28@phonefromhere.com> <4E9E7887.400 0806@jesup.org> To: Randell Jesup X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Review request for RTCWeb standard 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: Wed, 19 Oct 2011 11:06:09 -0000 On 19 Oct 2011, at 08:13, Randell Jesup wrote: > On 10/18/2011 10:19 AM, Tim Panton wrote: >>=20 >> On 18 Oct 2011, at 14:59, Roy, Radhika R USA CIV (US) wrote: >>=20 >>> Tim: >>>=20 >>> The puzzle is this. The other user may not agree completely with the = offer of the first user. Even the other user may agree with a given = codec type, he/she may not agree other features including bandwidth of = the codec. >>>=20 >>> It simple turns out that a freedom needs to be given for = negotiations some-like offer/answer. >>=20 >> The example I gave had _no_ negotiation, no back and forth, because = the application's webserver was >> told all the capabilities in advance, (at login in my example), it = simply _decided_ based on >> it's view of the union of the capabilities of the two ends. It then = informed them of the choice >> (which may have been asymmetric by the way) and told them to get on = with it. >>=20 >> To the extent that there was a 'negotiation', it took place in a = single thread on the web server, >> with no propagation delays or locks needed. >=20 > This example you give raises some security issues based on the current = proposals. We require that the user ok access to the camera and = microphone; this is a call set up "on the fly" with apparently no = individual certification from the user. >=20 > This use-case would require the JS application get pre-authorization = of media access, before any actual access occurs, and have that access = persist until , across multiple individual connections. >=20 > So is this outside of the current security model, since it seems to = bring in a number of new requirements? To support this, we would need: >=20 > 1) pre-authorization of camera/mic access > 2) authorization continues until a particular active state with the = server ends (leaving the game) Oh, I thought that there had been some discussion on preserving = authorization for a site - so that I can mark a site as 'trusted' and not have to see the permission request again. Without that = sort of feature, rtcWEB/webRTC will get annoying _really_ fast. Once it is 'trusted' the game can create and tear down calls at will, = with no need to fork anything. (I have to authorize each call separately in the current model ?!?) >=20 > This could be handled most simply by considering this to be a single = 'call' to the server, which has a default 'forked' instance answered by = the server with media 'on-hold'. This 'call' is also forked by the = server as needed to other players who happen to be nearby/call/etc. = Since these are forks of an existing call, no individual authorization = is required (effectively it's the equivalent to a mesh conference where = users join and leave over time). The 'call' ends when the user = terminates the call to the server. >=20 > With that sort of setup, I think we can probably handle it within the = current security model. The big thing we would need to make sure of is = making sure forking is available, and that authorization could occur at = the start with the server, even if the server doesn't want to actually = receive media. (In a push, it could receive and drop media.) >=20 > As this is all forking of an initial "call", you can handle it with = normal forking negotiation. The server would take the two active = "calls" from the users, and generate a forked "answer" to each. It does = point out that each side thinks it made an offer and the other side = answered. It requires the server handle the answer generation correctly = in order to give a proper answer that will match what the device it's = masquerading as will be ok with. >=20 >> Offer - Answer really only crops up because there is a requirement = (which I personally put very low on our priorities) to be able >> to interop with legacy video phones without needing a media gateway. >=20 > I do not see that as the reason for offer-answer semantics; and I = don't know that we can meet that requirement thus far - and which = requirement from the use-case document covers this? What exactly does = it require? (sorry, loose terminology - let's call it a desire or wish rather than a = requirement). As I recall (from somewhere on this list) Cullen's = draft-jennings-rtcweb-api foundered on the difficulty of specifying = video codecs in a way that was SDP compatible. I'm afraid I can't cite where - a quick search didn't = turn it up. If we accepted that video media was always from browser to = browser, or browser to rtcWEB aware proxy that wouldn't be an issue (as far as I can = see). Tim. >=20 >=20 > --=20 > Randell Jesup > randell-ietf@jesup.org > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From neils@vipadia.com Wed Oct 19 04: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 EC7AD21F8B91 for ; Wed, 19 Oct 2011 04:33:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.959 X-Spam-Level: X-Spam-Status: No, score=-2.959 tagged_above=-999 required=5 tests=[AWL=0.017, 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 EnHK6lJIw0QQ for ; Wed, 19 Oct 2011 04:33: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 6C7AF21F8B77 for ; Wed, 19 Oct 2011 04:33:29 -0700 (PDT) Received: by gyh20 with SMTP id 20so1923887gyh.31 for ; Wed, 19 Oct 2011 04:33:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.161.70 with SMTP id s6mr12030098icx.40.1319024009002; Wed, 19 Oct 2011 04:33:29 -0700 (PDT) Sender: neils@vipadia.com Received: by 10.231.199.4 with HTTP; Wed, 19 Oct 2011 04:33:28 -0700 (PDT) In-Reply-To: References: <2E239D6FCD033C4BAF15F386A979BF510F1367@sonusinmail02.sonusnet.com> <4E8AC222.4050308@alvestrand.no> <2E239D6FCD033C4BAF15F386A979BF510F14CE@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF510F14FD@sonusinmail02.sonusnet.com> <393F1888-F834-4DAE-B6B1-1C5D35EE3292@phonefromhere.com> <2E239D6FCD033C4BAF15F386A979BF510F152B@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF510F1532@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF511598EE@sonusinmail02.sonusnet.com> <665A16AB-AAD8-42B3-AC17-7E629EA2DE35@phonefromhere.com> <2E239D6FCD033C4BAF15F386A979BF5115992E@sonusinmail02.sonusnet.com> <0950F0E1-6E4B-407F-9563-654AFE79F64B@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF51159994@sonusinmail02.sonusnet.com> <1F2A2C70609D9E41844A2126145FC09804004302@HKGMBOXPRD22.polycom.com> <033458F56EC2A64E8D2D7B759FA3E7E703DBF614@sonusmail04.sonusnet.com> <8486C8728176924BAF5BDB2F7D7EEDDF3E091D13@ucolhp4d.easf.csd.disa.mil> <2E239D6FCD033C4BAF15F386A979BF511599F3@sonusinmail02.sonusnet.com> <37796D08-7A24-478B-8157-052FFB2E3945@acmepacket.com> Date: Wed, 19 Oct 2011 12:33:28 +0100 X-Google-Sender-Auth: uiNtVa5T5NFmrU96XYZEnkQp7tM Message-ID: From: Neil Stratford To: Ted Hardie Content-Type: multipart/alternative; boundary=90e6ba2123e581c07204afa5359e Cc: "" Subject: Re: [rtcweb] Review request for RTCWeb standard 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: Wed, 19 Oct 2011 11:33:30 -0000 --90e6ba2123e581c07204afa5359e Content-Type: text/plain; charset=ISO-8859-1 On Wed, Oct 19, 2011 at 12:40 AM, Ted Hardie wrote: > > You don't get to be rich by making a lot of money, you get to be rich by > keeping it. The same is true with energy in mobile systems. Pay attention > to it all the time, and there's a fair chance you will never run out. Pay > attention to it only when you're low, and you're likely paying attention to > late. > The low energy example is a great reason why we wouldn't want a single standard protocol. In the low energy case you want to move all the smarts out of the handset and into the server, which requires a different protocol to the one you'd use for a high power desktop application. Forcing a handset to implement a protocol that is expressive enough for all the possible uses on the desktop seems like a bad idea. Neil --90e6ba2123e581c07204afa5359e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Oct 19, 2011 at 12:40 AM, Ted Hardie <ted.ietf@gmail.com> wrote:
=

You don't g= et to be rich by making a lot of money, you get to be rich by keeping it.= =A0 The same is true with energy in mobile systems.=A0 Pay attention to it = all the time, and there's a fair chance you will never run out.=A0 Pay = attention to it only when you're low, and you're likely paying atte= ntion to late.=A0

The low energy example is a gr= eat reason why we wouldn't want a single standard protocol. In the low = energy case you want to move all the smarts out of the handset and into the= server, which requires a different protocol to the one you'd use for a= high power desktop application.

Forcing a handset to implement a protocol that is expre= ssive enough for all the possible uses on the desktop seems like a bad idea= .

Neil
--90e6ba2123e581c07204afa5359e-- From ibc@aliax.net Wed Oct 19 04: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 1A00C21F8B70 for ; Wed, 19 Oct 2011 04:44:40 -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 P1U9OnDZjpzy for ; Wed, 19 Oct 2011 04:44:39 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2AA1A21F87E2 for ; Wed, 19 Oct 2011 04:44:39 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so1711592vcb.31 for ; Wed, 19 Oct 2011 04:44:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.184.11 with SMTP id ci11mr501789vcb.76.1319024678444; Wed, 19 Oct 2011 04:44:38 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Wed, 19 Oct 2011 04:44:38 -0700 (PDT) Date: Wed, 19 Oct 2011 13:44:38 +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] Summary of Signaling Components in RTCweb (clarifications) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 11:44:40 -0000 Hi all, I've tryed to identify all the signaling components of a RTCweb communication ir order to identify each "signaling fragment" in all the path. There are various connotations for the "signaling" keyword in RTCweb and IMHO they are generating confusion. I've exposed it into the following URL: http://public.aliax.net/RTCweb_Signaling_Components.html Hope it helps. Best regards. --=20 I=C3=B1aki Baz Castillo From christer.holmberg@ericsson.com Wed Oct 19 05:21: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 0F63521F8A7B for ; Wed, 19 Oct 2011 05:21:31 -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 stBEPFyRTWz3 for ; Wed, 19 Oct 2011 05:21:30 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 4D1D021F87E2 for ; Wed, 19 Oct 2011 05:21:30 -0700 (PDT) X-AuditID: c1b4fb3d-b7c26ae0000035b9-00-4e9ec0c927f2 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id AD.A1.13753.9C0CE9E4; Wed, 19 Oct 2011 14:21:29 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Wed, 19 Oct 2011 14:21:28 +0200 From: Christer Holmberg To: Cullen Jennings Date: Wed, 19 Oct 2011 14:21:27 +0200 Thread-Topic: [rtcweb] SDP Offer/Answer draft-jennings-rtcweb-signaling - Scope Thread-Index: AcyNyHnKivIjuT9yTbubpRIfsuBwPQAkHnJg Message-ID: <7F2072F1E0DE894DA4B517B93C6A058522341F4A36@ESESSCMS0356.eemea.ericsson.se> References: <15B0E3AD-3086-499A-8E79-7AE58B3376C4@cisco.com> <2E239D6FCD033C4BAF15F386A979BF51159957@sonusinmail02.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A058522341F416A@ESESSCMS0356.eemea.ericsson.se> <10704DBF-9400-42BA-B9C5-209C338F042E@cisco.com> In-Reply-To: <10704DBF-9400-42BA-B9C5-209C338F042E@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: Jonathan Rosenberg , "rtcweb@ietf.org" , "public-webrtc@w3.org" Subject: Re: [rtcweb] SDP Offer/Answer draft-jennings-rtcweb-signaling - Scope X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 12:21:31 -0000 Hi Cullen,=20 >> So, while I support and offer/answer based approach, I=20 >> think we need to get a clearer understanding of the scope. >=20 > My view is this is draft is a set of semantics and syntax=20 > that operates over an abstract transport protocol. In most=20 > cases the transport with be web sockets or HTTP based. If=20 > this looks like a reasonable protocol, it would be likely to=20 > influence the W3C API. As the ROAP state machine is located in the browser, doesn't that already m= ean that ROAP must to be supported by the API? Regards, Christer= From christer.holmberg@ericsson.com Wed Oct 19 05: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 8DCC321F8B3A for ; Wed, 19 Oct 2011 05:30:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.541 X-Spam-Level: X-Spam-Status: No, score=-6.541 tagged_above=-999 required=5 tests=[AWL=0.058, 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 8zMpnJUbL-U9 for ; Wed, 19 Oct 2011 05:30:06 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id D073921F8AFB for ; Wed, 19 Oct 2011 05:30:05 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-51-4e9ec2cc7ea2 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id D9.BB.20773.CC2CE9E4; Wed, 19 Oct 2011 14:30:04 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Wed, 19 Oct 2011 14:30:03 +0200 From: Christer Holmberg To: Cullen Jennings , "rtcweb@ietf.org" Date: Wed, 19 Oct 2011 14:30:01 +0200 Thread-Topic: [rtcweb] SDP Offer/Answer draft-jennings-rtcweb-signaling - Comment on section 5.3.1.2 Thread-Index: AcyK59ZYlpyUDRxNTFOtHnNrwuQvpADcjRuA Message-ID: <7F2072F1E0DE894DA4B517B93C6A058522341F4A4A@ESESSCMS0356.eemea.ericsson.se> References: <15B0E3AD-3086-499A-8E79-7AE58B3376C4@cisco.com> In-Reply-To: <15B0E3AD-3086-499A-8E79-7AE58B3376C4@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: Jonathan Rosenberg Subject: Re: [rtcweb] SDP Offer/Answer draft-jennings-rtcweb-signaling - Comment on section 5.3.1.2 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 12:30:06 -0000 =20 Hi, Section 5.3.1.2 lists cases where an answerer can receive an OFFER. I guess the following case is also valid, and shall not be rejected. - A retransmit of a request to change media parameters (known offererSessoi= nId, known answererSessionId, known seq value). Regards, Christer From christer.holmberg@ericsson.com Wed Oct 19 05:49: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 F29D821F8AA8 for ; Wed, 19 Oct 2011 05:49:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.545 X-Spam-Level: X-Spam-Status: No, score=-6.545 tagged_above=-999 required=5 tests=[AWL=0.054, 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 LhAYbJ0O9LKF for ; Wed, 19 Oct 2011 05:49:50 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 3599521F8C06 for ; Wed, 19 Oct 2011 05:49:50 -0700 (PDT) X-AuditID: c1b4fb3d-b7c26ae0000035b9-4f-4e9ec76b6762 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id A4.E7.13753.B67CE9E4; Wed, 19 Oct 2011 14:49:47 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Wed, 19 Oct 2011 14:49:46 +0200 From: Christer Holmberg To: Cullen Jennings , "rtcweb@ietf.org" , "public-webrtc@w3.org" Date: Wed, 19 Oct 2011 14:49:44 +0200 Thread-Topic: [rtcweb] SDP Offer/Answer draft-jennings-rtcweb-signaling - seq/sessionId vs sess-version/sess-id (Section 5.2.1 and 5.2.2) Thread-Index: AcyK59ZYlpyUDRxNTFOtHnNrwuQvpADcv2WA Message-ID: <7F2072F1E0DE894DA4B517B93C6A058522341F4A8B@ESESSCMS0356.eemea.ericsson.se> References: <15B0E3AD-3086-499A-8E79-7AE58B3376C4@cisco.com> In-Reply-To: <15B0E3AD-3086-499A-8E79-7AE58B3376C4@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: Jonathan Rosenberg Subject: Re: [rtcweb] SDP Offer/Answer draft-jennings-rtcweb-signaling - seq/sessionId vs sess-version/sess-id (Section 5.2.1 and 5.2.2) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 12:49:51 -0000 =20 Hi, What is the relation between the seq/sessionId values and the SDP sess-vers= ion/sess-id values (part of the SDP o=3D line), and why do we need seq/sess= ionId in the first place? AFAIK, the only reason for having the seq/sessionId values is when sending = an OK message, since there will be no SDP (and therefor no SDP sess-version= /sessionId). Or, are there any other reasons? I think the draft should say something about the correlation. And, IF we need seq/sessionId, should we say that the SDP sess-version/sess= -id values must be identical - or, at least saying that they must be set an= d incremented according to the SDP rules? I think that would help in SIP/SD= P interworking cases. Otherwise the interworking gateway will have to check= , keep track of, and possibly modify, the sess-version/sess-id values. Regards, Christer > -----Original Message----- > From: rtcweb-bounces@ietf.org=20 > [mailto:rtcweb-bounces@ietf.org] On Behalf Of Cullen Jennings > Sent: 15. lokakuuta 2011 6:09 > To: rtcweb@ietf.org; public-webrtc@w3.org > Cc: Jonathan Rosenberg > Subject: [rtcweb] SDP Offer/Answer draft-jennings-rtcweb-signaling >=20 >=20 > Jonathan and I submitted a new draft on setting up media=20 > based on the SDP Offer/Answer model. The ASCII flows are a=20 > bit hard to read so until I update them, I recommend reading=20 > the PDF version at=20 >=20 > http://tools.ietf.org/pdf/draft-jennings-rtcweb-signaling-00.pdf >=20 > Clearly the draft is an early stage but we plan to revise it=20 > before the deadline for the IETF 82. Love to get input -=20 > particularly on if this looks like generally the right=20 > direction to go.=20 >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > = From christer.holmberg@ericsson.com Wed Oct 19 06:06: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 D585121F8B9D for ; Wed, 19 Oct 2011 06:06:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 7blQxaCEaTbp for ; Wed, 19 Oct 2011 06:06:24 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 0CDC721F8B22 for ; Wed, 19 Oct 2011 06:06:23 -0700 (PDT) X-AuditID: c1b4fb3d-b7c26ae0000035b9-07-4e9ecb4e1f5f Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 92.FB.13753.E4BCE9E4; Wed, 19 Oct 2011 15:06:23 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Wed, 19 Oct 2011 15:06:22 +0200 From: Christer Holmberg To: Cullen Jennings , "rtcweb@ietf.org" Date: Wed, 19 Oct 2011 15:06:20 +0200 Thread-Topic: [rtcweb] SDP Offer/Answer draft-jennings-rtcweb-signaling - More-coming and final answer (Section 5.2.3) Thread-Index: AcyK59ZYlpyUDRxNTFOtHnNrwuQvpADdhRdw Message-ID: <7F2072F1E0DE894DA4B517B93C6A058522341F4AB9@ESESSCMS0356.eemea.ericsson.se> References: <15B0E3AD-3086-499A-8E79-7AE58B3376C4@cisco.com> In-Reply-To: <15B0E3AD-3086-499A-8E79-7AE58B3376C4@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: Jonathan Rosenberg Subject: Re: [rtcweb] SDP Offer/Answer draft-jennings-rtcweb-signaling - More-coming and final answer (Section 5.2.3) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 13:06:24 -0000 =20 Hi, A couple of questions regarding the usage of the more-coming flag: Q1. If one sends an ANSWER with the more-coming flag set to 'true', is it a= llowed to later send *additional* ANSWER(s) with the flag set to 'true' (be= fore sending the final ANSWER)? Q2. Are there restrictions when it comes to changing information in a non-f= inal answer and a final answer? Or, can the final answer be completely diff= erent from previously sent non-final ANSWERS? In "legacy" O/A there are res= trictions. Q3. Must the answerer wait for OK for a non-final ANSWER before sending a n= ew ANSWER (non-final or final)? Q4. If the answer to Q3 is "no", how does the answerer know to which ANSWER= an OK message applies? AFAIK, the seq/sessionId values are identical for a= ll ANSWERs associated with a specific OFFER. Q5. The text says, that while the OFFER is "open", ie a final ANSWER has no= t been sent, the answerer is not allowed to send an OFFER. I assume that al= so applies to the offerer, ie it is not allowed to send a new OFFER until i= t has received a final ANSWER - even if it has received one or more non-fin= al ANSWERs. Maybe it's obvious, but I think it would be good to explictily = add some text about that (if my assumption is correct, that is :). Regards, Christer > -----Original Message----- > From: rtcweb-bounces@ietf.org=20 > [mailto:rtcweb-bounces@ietf.org] On Behalf Of Cullen Jennings > Sent: 15. lokakuuta 2011 6:09 > To: rtcweb@ietf.org; public-webrtc@w3.org > Cc: Jonathan Rosenberg > Subject: [rtcweb] SDP Offer/Answer draft-jennings-rtcweb-signaling >=20 >=20 > Jonathan and I submitted a new draft on setting up media=20 > based on the SDP Offer/Answer model. The ASCII flows are a=20 > bit hard to read so until I update them, I recommend reading=20 > the PDF version at=20 >=20 > http://tools.ietf.org/pdf/draft-jennings-rtcweb-signaling-00.pdf >=20 > Clearly the draft is an early stage but we plan to revise it=20 > before the deadline for the IETF 82. Love to get input -=20 > particularly on if this looks like generally the right=20 > direction to go.=20 >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > = From dan-ietf@danyork.org Wed Oct 19 06: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 33CE421F8BDE for ; Wed, 19 Oct 2011 06:20:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HQwUO9-YVB6B for ; Wed, 19 Oct 2011 06:20:21 -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 7194621F8AD6 for ; Wed, 19 Oct 2011 06:20:21 -0700 (PDT) Received: by qyk31 with SMTP id 31so1473428qyk.10 for ; Wed, 19 Oct 2011 06:20:20 -0700 (PDT) Received: by 10.229.72.161 with SMTP id m33mr1492661qcj.108.1319030420518; Wed, 19 Oct 2011 06:20:20 -0700 (PDT) Received: from pc-00141.lodestar2.local (cpe-66-65-247-87.mass.res.rr.com. [66.65.247.87]) by mx.google.com with ESMTPS id fa9sm6664746qab.5.2011.10.19.06.20.19 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 19 Oct 2011 06:20:19 -0700 (PDT) From: Dan York Content-Type: multipart/alternative; boundary="Apple-Mail=_E50FB384-C73B-4E41-B7F5-3A9DF18410F6" Date: Wed, 19 Oct 2011 09:20:18 -0400 Message-Id: <9C8CA816-65FB-41A0-999C-4C43128CAAB4@danyork.org> To: rtcweb@ietf.org Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) Subject: [rtcweb] A plea for simplicity, marketability - and... who are we designing RTCWEB for? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 13:20:23 -0000 --Apple-Mail=_E50FB384-C73B-4E41-B7F5-3A9DF18410F6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Folks, I need to rant. I've been lurking on this list from the beginning but = with a new job I haven't been able to really keep up with the volume of = messages... and every time I get ready to reply I find that others like = Hadriel, Tim, Neil, Tolga or others have made the points I was going to = make...=20 But I find myself increasingly frustrated with the ongoing discussions = and want to ask a fundamental question: - WHO ARE WE BUILDING RTCWEB/WEBRTC FOR? Is it for: 1. Telephony developers who are tired of writing code in traditional = languages and want to do things in new web ways; 2. Web developers who want to add real-time comms (as in voice, video = and chat) to their existing or new web applications; 3. Both 1 and 2. If the answer is #1, then I think everything is going along just = wonderfully. We can go ahead and use the SIP/SDP/etc. stuff that we all = in the RAI area are all used to and understand just fine. Heck, let's = just all end the discussions about a signalling protocol and agree on = SIP... get the browser vendors to agree on baking a SIP UA into their = browsers... and call it a day and go have a beer. Simple. Easy. Done. And the only people who will ever use it will be people who work for = RTC/UC/VoIP vendors and random other programmers who actually care about = telephony, etc.=20 But that's okay, because the people who do use it (and their employers) = will be really happy and life will be good. If the answer is #2, then I think we need to step back and ask -=20 HOW DO "WEB DEVELOPERS" REALLY WANT TO WORK? Here's the thing... in my experience... 99% OF WEB DEVELOPERS DON'T GIVE A ______ ABOUT TELEPHONY! Never have. Never will. (In fact, I may be understating that. It may = actually be 99.99999%.) If they are with startups, they want to build nice bright shiny objects = that people will chase and use. They want to make the next Twitter or = FourSquare or (pick your cool service that everyone salivates over). If = they are with more established companies, they want to create = easy-to-use interfaces that expose data or information in new and = interesting ways or allow users to interact with their web apps in new = and useful ways. And they want to do all this using the "languages of the web"... = JavaScript, PHP, Ruby, Python, etc. They want "easily consumable" APIs where they can just look at a web = page of documentation and understand in a few minutes how they can add = functionality to their app using simple REST calls or adding snippets of = code to their web page. Their interaction with telephony is more along = these lines: "Wow, dude, all I have to do is get an authorization token and curl this = URL with my token and a phone number and I can create a phone call!" And the thing is... they can do this **TODAY** with existing proprietary = products and services. You can code it all up in Flex/Flash. You can = write it in Java. You can use Voxeo's Phono. You could probably do it = in Microsoft's Silverlight. I seem to recall Twilio having a web = browser client. A bunch of the carriers/operators are starting to offer = their own ways of doing this. On any given week there are probably a = dozen new startups out there with their own ideas for a new proprietary, = locked-in way of doing RTC via web browsers. Web developers don't *NEED* this RTCWEB/WebRTC work to do real-time = communications between browsers.=20 It can be done today. Now. The drawback is that today you need to have some kind of = applet/plugin/extension downloaded to the browser to allow access to the = mic and speakers and make the RTC actually work. So you have to use = some Flash or Java or something. AND... you are locked into some = particular vendor's way of doing things and are reliant on that vendor = being around. THAT is what RTCWEB can overcome. Make it so that web developers can = easily add RTC to their web apps without requiring any downloads, etc. = Make it do-able in open standards that don't lock developers in to a = specific product or vendor. But if we are targeting "web developers", that is need we need to = satisfy... and we need to understand that they *already* have ways to do = what we are allowing them to do. If we come out with something that is so "different" from what "web = developers" are used to... that requires someone to, for instance, = understand all of what SIP is about... that requires a whole bunch of = lines of code, etc.... well... ... the web developers out there will NOT launch an "Occupy RTCWEB" = movement claiming that they are the "99% who don't care about = telephony"... they will simply... not... use.... RTCWEB! They will continue to use proprietary products and services because = those work in the ways that web developers are used to and they make it = simple for a web developer to go add voice, video and chat to a web app. = Sure... they will still require the dreaded plugin/extension, but so be = it... the "open standard" way is far too complicated for them to look = at. And all the work and the zillions of hours of writing emails and I-Ds = that this group has done will all be for nothing. Well, not nothing... = some of the telephony-centric developers will use them. But the = majority of the web developers out there may not because there are other = simpler, easier ways to do what they need to do. So I go back to the question - who are we building RTCWEB for? Is the goal to enable the zillions of web developers out to be able to = use real-time communications in new and innovative ways? Or is it = solely to make it so that VoIP/UC/RTC vendors can make a softphone in = the browser that calls into their call center software? RTCWEB *can* enable both... but to me it's a question of where the = priority is. The question is - will the RTCWEB/WEBRTC API/protocol/whatever be so = simple and easy that web developers will choose to use it over = Flash/Phono/Twilio/Java/whatever to add RTC functions to their web apps? If the answer is yes, we win. Open standards win. Maybe we upgrade from = having a beer to having champagne. If the answer is no, what are spending all this time for? Dan --=20 Dan York dyork@lodestar2.com http://www.danyork.com/ skype:danyork Phone: +1-802-735-1624 Twitter - http://twitter.com/danyork -------------------------------------------------------- All comments and opinions are entirely my own and have no connection = whatsoever to any employer, past or present. Indeed, by tomorrow even I = might be disavowing these comments. -------------------------------------------------------- --Apple-Mail=_E50FB384-C73B-4E41-B7F5-3A9DF18410F6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

Here's the thing... in my = experience...

    99% OF WEB = DEVELOPERS DON'T GIVE A ______ ABOUT TELEPHONY!

Never have.  Never will.  (In fact, I may be = understating that. It may actually be = 99.99999%.)

If they are with startups, they = want to build nice bright shiny objects that people will chase and use. =  They want to make the next Twitter or FourSquare or (pick your = cool service that everyone salivates over).  If they are with more = established companies, they want to create easy-to-use interfaces that = expose data or information in new and interesting ways or allow users to = interact with their web apps in new and useful = ways.

And they want to do all this using the = "languages of the web"... JavaScript, PHP, Ruby, Python, = etc.

They want "easily consumable" APIs where = they can just look at a web page of documentation and understand in a = few minutes how they can add functionality to their app using simple = REST calls or adding snippets of code to their web page.  Their = interaction with telephony is more along these = lines:

"Wow, dude, all I have to do is get an = authorization token and curl this URL with my token and a phone number = and I can create a phone call!"

And the thing = is... they can do this **TODAY** with existing proprietary products and = services.  You can code it all up in Flex/Flash. You can write it = in Java.  You can use Voxeo's Phono.  You could probably = do it in Microsoft's Silverlight.  I seem to recall Twilio having a = web browser client.  A bunch of the carriers/operators are starting = to offer their own ways of doing this.  On any given week there are = probably a dozen new startups out there with their own ideas for a new = proprietary, locked-in way of doing RTC via web = browsers.

Web developers don't *NEED* this = RTCWEB/WebRTC work to do real-time communications between = browsers. 

It can be done today. =  Now.

The drawback is that today you need = to have some kind of applet/plugin/extension downloaded to the browser = to allow access to the mic and speakers and make the RTC actually work. =  So you have to use some Flash or Java or something. AND... you are = locked into some particular vendor's way of doing things and are reliant = on that vendor being around.

THAT is what = RTCWEB can overcome.  Make it so that web developers can easily add = RTC to their web apps without requiring any downloads, etc.  Make = it do-able in open standards that don't lock developers in to a specific = product or vendor.

But if we are targeting "web = developers", that is need we need to satisfy... and we need to = understand that they *already* have ways to do what we are allowing them = to do.

If we come out with something that is so = "different" from what "web developers" are used to... that requires = someone to, for instance, understand all of what SIP is about... that = requires a whole bunch of lines of code, etc.... = well...

... the web developers out there will = NOT launch an "Occupy RTCWEB" movement claiming that they are the "99% = who don't care about telephony"... they will simply... not... = use.... RTCWEB!

They will continue to use = proprietary products and services because those work in the ways that = web developers are used to and they make it simple for a web developer = to go add voice, video and chat to a web app.  Sure... they will = still require the dreaded plugin/extension, but so be it... the "open = standard" way is far too complicated for them to look = at.

And all the work and the zillions of hours = of writing emails and I-Ds that this group has done will all be for = nothing.  Well, not nothing... some of the telephony-centric = developers will use them.  But the majority of the web developers = out there may not because there are other simpler, easier ways to do = what they need to do.

So I go back to the = question - who are we building RTCWEB for?

Is = the goal to enable the zillions of web developers out to be able to use = real-time communications in new and innovative ways?  Or is it = solely to make it so that VoIP/UC/RTC vendors can make a softphone in = the browser that calls into their call center = software?

RTCWEB *can* enable both... but to me = it's a question of where the priority is.

The = question is - will the RTCWEB/WEBRTC API/protocol/whatever be so simple = and easy that web developers will choose to use it over = Flash/Phono/Twilio/Java/whatever to add RTC functions to their web = apps?

If the answer is yes, we win.  Open = standards win. Maybe we upgrade from having a beer to having = champagne.

If the answer is no, what are = spending all this time = for?

</rant>

Dan

-- 
Dan York  dyork@lodestar2.com
http://www.danyork.com/  &n= bsp;skype:danyork
Phone: = +1-802-735-1624
Twitter - http://twitter.com/danyork
All comments and opinions are = entirely my own and have no connection whatsoever to any employer, past = or present. Indeed, by tomorrow even I might be disavowing these = comments.
So I go back to the question - who are we building RTCWEB for? > > Is the goal to enable the zillions of web developers out to be able to > use real-time communications in new and innovative ways? Or is it > solely to make it so that VoIP/UC/RTC vendors can make a softphone in > the browser that calls into their call center software? > > RTCWEB *can* enable both... but to me it's a question of where the > priority is. > > The question is - will the RTCWEB/WEBRTC API/protocol/whatever be so > simple and easy that web developers will choose to use it over > Flash/Phono/Twilio/Java/whatever to add RTC functions to their web apps? > > If the answer is yes, we win. Open standards win. Maybe we upgrade > from having a beer to having champagne. > > If the answer is no, what are spending all this time for? > While I like beer, I'd like there to be champagne :-) But - in my reading, the "lowlevel API" requires wisdom in both the browser and in Javascript about "all the RTC stuff"; the "ROAP" API requires wisdom in the browser about the same stuff. The "lowlevel API" (once it's fully fleshed out) will (presumably) allow the Phonos of the world to offer an API as compelling as what they have today. The "ROAP API" hides the complexity in a different way; so far, people have argued that everything we have listed as scenarios can be done in a ROAP-like fashion, and this API can be offered without requiring the assistance of additional libraries. Do you see a compelling argument that enables you to say that one path is better than the other? Harald From christer.holmberg@ericsson.com Wed Oct 19 07:04: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 137D821F8C0A for ; Wed, 19 Oct 2011 07:04:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[AWL=0.047, 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 9T+Ycx-ePtjH for ; Wed, 19 Oct 2011 07:04: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 0CE4421F8BDB for ; Wed, 19 Oct 2011 07:04:57 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-9e-4e9ed908750b Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 5B.F0.20773.809DE9E4; Wed, 19 Oct 2011 16:04:57 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Wed, 19 Oct 2011 16:04:56 +0200 From: Christer Holmberg To: Cullen Jennings , Roman Shpount Date: Wed, 19 Oct 2011 16:04:55 +0200 Thread-Topic: [rtcweb] Forking - Re: SDP Offer/Answer draft-jennings-rtcweb-signaling Thread-Index: AcyNxabFlE2H069MTM2qpnNjuIBAmwAnLUPQ Message-ID: <7F2072F1E0DE894DA4B517B93C6A058522341F4B3E@ESESSCMS0356.eemea.ericsson.se> References: <15B0E3AD-3086-499A-8E79-7AE58B3376C4@cisco.com> <5D0FFCB8-8059-4C54-843B-46F1EC720B10@cisco.com> In-Reply-To: <5D0FFCB8-8059-4C54-843B-46F1EC720B10@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: Jonathan Rosenberg , "rtcweb@ietf.org" Subject: Re: [rtcweb] Forking - Re: SDP Offer/Answer draft-jennings-rtcweb-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: Wed, 19 Oct 2011 14:04:59 -0000 Hi,=20 >> Did we decide to explicitly not support forking which=20 >> generates multiple final answers? If this is not the case,=20 >> how is this supposed to be implemented using your model? >=20 > I think that it is critical that we support what is needed to=20 > make a call that goes to 1-800-go-fedex work. So consider the=20 > following use case: A browser calls through a signaling GW to=20 > a sip that forks the call to an SIP to PSTN gateway and also=20 > to a voicemail server. The PSTN gateway generates an 180 with=20 > ringback tone but the SIP call is eventually answered by the=20 > voicemail server that sends a 200.=20 > =20 > So 3264 supports forking by an single offer may result in say=20 > two answers. In the case above, an single offer resulted in=20 > two different answers. Roap would support this type of=20 > transaction by allowing two answers to be received. There are=20 > two ways this can happen - one is with different=20 > answererSessionId in the the answers. Another is the use of=20 > the More-coming flag. We think with these, one can support=20 > the range of what 3264 allows for offer/ answer.=20 - Assume my browser is communicating with a SIP gatway, and I use some non-= SIP signalling protocol to transport ROAP messages between the browser and = the gateway. - The gateway maps ROAP into SIP, and a proxy forks the INVITE to multiple = SIP UAs. - When the gateway receives reliable 18x provisional responses, on differen= t early SIP dialogs, it forwards them as final ANSWERs towards the browser. - When the gateway receives the 200 OK, all other early dialogs are termina= ted. Now, from a pure ROAP perspective, the only way to inform the browser = about that would be for the gateway to send new OFFERs for every terminated= early SIP dialog, and e.g. indicate port=3D0. Correct? Now, instead of mapping the 18x provisional responses to final ANSWERs, the= gateway could of course map them to non-final ANSWERs, and then later send= final ANSWERs with an error code. But, the problem then is that the browse= r is not able to (or, at least that's my assumption - see separate e-mail) = send a new OFFER until it has received a final ANSWER. Regards, Christer From randell-ietf@jesup.org Wed Oct 19 08:04: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 82B8121F8C63 for ; Wed, 19 Oct 2011 08:04:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.256 X-Spam-Level: X-Spam-Status: No, score=-2.256 tagged_above=-999 required=5 tests=[AWL=-0.257, BAYES_00=-2.599, J_CHICKENPOX_23=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 XDyRXWsJMI84 for ; Wed, 19 Oct 2011 08:04: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 B21D921F8C0E for ; Wed, 19 Oct 2011 08:04: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 1RGXgw-0006E5-5q; Wed, 19 Oct 2011 10:04:26 -0500 Message-ID: <4E9EE5E2.2090201@jesup.org> Date: Wed, 19 Oct 2011 10:59:46 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org, "public-webrtc@w3.org" References: <2E239D6FCD033C4BAF15F386A979BF510F1367@sonusinmail02.sonusnet.com><2E239D6FCD033C4BAF15F386A979BF511598EE@sonusinmail02.sonusnet.com><665A16AB-AAD8-42B3-AC17-7E629EA2DE35@phonefromhere.com><2E239D6FCD033C4BAF15F386A979BF5115992E@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F3 86A979B F51159950@so nusinmail02.sonusnet.com> <0950F0E1-6E4B-407F-9563-654AFE79F64B@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF51159994@sonusinmail02.sonusnet.com> <6398F67A-5E41-44BB-ABB2-831AB7C48DCC@ag-projects.com> <8486C8728176924BAF5BDB2F7D7EEDDF3E091CA3@ucolhp4d.easf.csd.disa.mil> <2E2B1F85-1DED-460D-B17D-0850DB3ACBA9@phonefromhere.com> <8486C8728176924BAF5BDB2F7D7EEDDF3E091D31@ucolhp4d.easf.csd.disa.mil> <7357A569-83A3-43B6-80A7-E2374D78CE28@phonefromhere.com> <4E9E7887.400 0806@jesup.org> <898B2A25-BF04-4F48-91FD-CA868FB5A79F@phonefromher e.com> In-Reply-To: <898B2A25-BF04-4F48-91FD-CA868FB5A79F@phonefromhere.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: [rtcweb] UI for getUserMedia() X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 15:04:28 -0000 Changed title; see below for why. On 10/19/2011 7:06 AM, Tim Panton wrote: > > On 19 Oct 2011, at 08:13, Randell Jesup wrote: >> This example you give raises some security issues based on the current proposals. We require that the user ok access to the camera and microphone; this is a call set up "on the fly" with apparently no individual certification from the user. >> >> This use-case would require the JS application get pre-authorization of media access, before any actual access occurs, and have that access persist until, across multiple individual connections. >> >> So is this outside of the current security model, since it seems to bring in a number of new requirements? To support this, we would need: >> >> 1) pre-authorization of camera/mic access >> 2) authorization continues until a particular active state with the server ends (leaving the game) > > Oh, I thought that there had been some discussion on preserving authorization for a site - so that I can mark a site as > 'trusted' and not have to see the permission request again. Without that sort of feature, rtcWEB/webRTC will get annoying _really_ fast. > Once it is 'trusted' the game can create and tear down calls at will, with no need to fork anything. > (I have to authorize each call separately in the current model ?!?) This has not yet been decided; people have certainly talked to wanting to find ways to minimize or avoid user authorizations for certain classes of services, and I have also pushed such efforts, both here and within Mozilla. However, at this point, no clear solution has been proposed; there are several ideas in play (leveraging "installed webapps", etc), but without some decision to modify the threat model it's tough. Without that, the app will probably want to use UI generated by getUserMedia() as part of their UI. That would also mean that the app would want to be able to present some indication as to *why* they're being asked to enable (incoming caller id, name of application since they may have many tabs open, etc), since they don't control the UI for getUserMedia() itself. This is W3C territory, so I'm cc'ing this to that list. -- Randell Jesup randell-ietf@jesup.org From binod.pg@oracle.com Wed Oct 19 08: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 1ED8221F8C7A for ; Wed, 19 Oct 2011 08:07:28 -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 gZcMktkqUKDJ for ; Wed, 19 Oct 2011 08:07:27 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by ietfa.amsl.com (Postfix) with ESMTP id 7CFF821F8C69 for ; Wed, 19 Oct 2011 08:07:27 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p9JF7MF5004731 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 19 Oct 2011 15:07:24 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p9JF7LbZ011301 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Oct 2011 15:07:22 GMT Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p9JF7GEa003303; Wed, 19 Oct 2011 10:07:16 -0500 Received: from [192.168.0.2] (/59.99.99.31) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 19 Oct 2011 08:07:16 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Binod PG In-Reply-To: <4E9D667A.2040703@alvestrand.no> Date: Wed, 19 Oct 2011 20:37:10 +0530 Content-Transfer-Encoding: quoted-printable Message-Id: <36F2FFCB-601B-4C2E-9B60-A2EFF503AC5D@oracle.com> References: <4E9D667A.2040703@alvestrand.no> To: Harald Alvestrand X-Mailer: Apple Mail (2.1084) X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090209.4E9EE7AC.0256:SCFMA922111,ss=1,re=-4.000,fgs=0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] My Opinion: Why I think a negotiating protocol is a Good Thing X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 15:07:28 -0000 >=20 > or even the triangle, where the triangle is formed when the two Web = severs on top are collapsed into one. >=20 > A design criterion for RTCWEB has been that it should be possible to = write applications on top of RTCWEB simply - that is, without deep = knowledge about the world of codecs, RTP sessions and the like. > Another design criterion is that interworking should be possible - = which means that SOMEWHERE in the system, deep knowledge about the world = of codecs, RTP sessions and the like must be embedded; we can=92t just = simplify our options until everything=92s simple. >=20 > There=92s one place in the ecosystem where this knowledge HAS to be - = and that is within the browser, the component that takes care of = implementing the codecs, the RTP sessions and the related features. If = we can avoid requiring embedding it twice, that=92s a feature. >=20 > It used to be that I was a believer in APIs - that we should make the = API the =93king=94, and describe the way you generate an RTP session as = =93you turn this knob, and get this effect=94. > After looking at the problem of Web applications that don=92t have = domain knowledge for a while, I=92ve concluded that this doesn=92t work. = There=92s the need for one browser to communicate with the other = browser, and if the intermediate components are to have the ability to = ignore the details, what=92s communicated has to be treated like a blob = - something passed out of one browser=92s API and into another browser=92s= API, unchanged by the application - because the application must be = able to ignore the details. >=20 > OK, now we have the API with blobs. We also have to make some = assumptions about how those blobs are transported, who=92s responsible = for acting on them, and so on. And we have to make sure different = browsers implement the blob the same way - that is, it has to be = standardized. > What=92s more - we DO want to enable applications that are NOT simple. = Including gateways, which are not browsers. So applications must be free = to look inside the blob - break the blob boundary - when they need to. = So this pulls in the same direction as the need for interoperability - = the format, semantics and handling rules for these blobs has to be = specified. In some detail. >=20 > So we have: > - a data format > - a transmission path > - a set of handling rules, in the form of states, processes and timers >=20 > This doesn=92t look like an API any more. This looks like a protocol. = We=92ve got experience in describing protocols - but it becomes much = easier to apply that experience when we call it a protocol. >=20 > Let=92s do that. I think, it is a move in the right direction. Having some sort of = definition around how the negotiation would look like is far better than leaving everything to interpretation of the web = developer. This is especially good for people who develop gateway libraries, since they will now have something to = actually translate. What exactly you mean by defining "transmission path"? thanks, Binod.= From ibc@aliax.net Wed Oct 19 08:09: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 6907021F8C86 for ; Wed, 19 Oct 2011 08:09:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.638 X-Spam-Level: X-Spam-Status: No, score=-2.638 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xzv+pOBHgXpX for ; Wed, 19 Oct 2011 08:09:35 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id E889521F8C84 for ; Wed, 19 Oct 2011 08:09:33 -0700 (PDT) Received: by vws5 with SMTP id 5so1573260vws.31 for ; Wed, 19 Oct 2011 08:09:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.35.34 with SMTP id e2mr6885188vdj.52.1319035125782; Wed, 19 Oct 2011 07:38:45 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Wed, 19 Oct 2011 07:38:45 -0700 (PDT) In-Reply-To: <9C8CA816-65FB-41A0-999C-4C43128CAAB4@danyork.org> References: <9C8CA816-65FB-41A0-999C-4C43128CAAB4@danyork.org> Date: Wed, 19 Oct 2011 16:38:45 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Dan York Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] A plea for simplicity, marketability - and... who are we designing RTCWEB for? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 15:09:37 -0000 2011/10/19 Dan York : > The question is - will the RTCWEB/WEBRTC API/protocol/whatever be so simp= le > and easy that web developers will choose to use it over > Flash/Phono/Twilio/Java/whatever to add RTC functions to their web apps? You miss the fact that RTCweb is a technology, not a JavaScript library. When RTCweb becomes a reality there will appear thousands of JavaScript libraries implementing a custom signaling protocol. Web developers will choose the best one or the easiest one, in the same way lot of web developers include JQuery library for making JS effects and manage the DOM in their web pages without knowing aout JQuery internals. RTC is about realtime communication. Web is not about communication, so we cannot expect to build "something" that requires no knowledge or RTC protocols. Web developers will choose some existing and successful RTCweb JS library and include it within their web apps. Of course, it also requires some code in the server, but that will be not so hard, and 100% feasible using PHP or whatever language. RTCweb means real integration of VoIP in the WWW world. So VoIP folks must learn something about WWW and WWW folks must learn something about VoIP (not too much when RTCweb JS libraries appear). A web developer has not the right to claim "I want cool new features but I don't want to learn new stuff". Take a look to Google Maps (web version). It contains a really complex JavaScript logic, but the tools are there available for any one (it's JavaScript and AJAX in the client side, no more) and any developer could code something similar (having enough knowledge). And I've not seen a web developer complaining because "doing it is so hard". Regards. --=20 I=C3=B1aki Baz Castillo From wolfgang.beck01@googlemail.com Wed Oct 19 08:12: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 0787221F8C29 for ; Wed, 19 Oct 2011 08:12:19 -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 Fc3coQ9r3tDw for ; Wed, 19 Oct 2011 08:12:18 -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 6BDED21F8C28 for ; Wed, 19 Oct 2011 08:12:18 -0700 (PDT) Received: by pzk34 with SMTP id 34so4742522pzk.9 for ; Wed, 19 Oct 2011 08:12:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=e2QXN7bg9xrh0IrMZCIiHPnGoixwfiMXYd4Q2yySrOk=; b=fsMPQtp1tH6mcDs2GzJINad0igf9pxMpSDahRNSnO2zAp1ZU3wpzp9pgaZHTFtrqkx hWz6778xaLZ1qN9T1ihdmmyFV44htOtnI4f+nQZxVqGuzjRvidwDkaOTP0jZzEIsIF5H 7gx3cmZS5je/FwWGSsoip3NQRnCRAR35Z5ZnU= MIME-Version: 1.0 Received: by 10.68.0.5 with SMTP id 5mr13179248pba.118.1319037138091; Wed, 19 Oct 2011 08:12:18 -0700 (PDT) Received: by 10.68.55.230 with HTTP; Wed, 19 Oct 2011 08:12:18 -0700 (PDT) In-Reply-To: <9C8CA816-65FB-41A0-999C-4C43128CAAB4@danyork.org> References: <9C8CA816-65FB-41A0-999C-4C43128CAAB4@danyork.org> Date: Wed, 19 Oct 2011 17:12:18 +0200 Message-ID: From: Wolfgang Beck To: Dan York Content-Type: text/plain; charset=ISO-8859-1 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] A plea for simplicity, marketability - and... who are we designing RTCWEB for? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 15:12:19 -0000 I agree on all points. My rant in this direction took the form of http://tools.ietf.org/html/draft-beck-rtcweb-alt-ic-00 Wolfgang Beck From saul@ag-projects.com Wed Oct 19 10:43: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 27B0E21F8C4A for ; Wed, 19 Oct 2011 10:43:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.688 X-Spam-Level: X-Spam-Status: No, score=-1.688 tagged_above=-999 required=5 tests=[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 sc-EtggxlyJD for ; Wed, 19 Oct 2011 10:43:30 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 6F0F421F8C49 for ; Wed, 19 Oct 2011 10:43:30 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 3ED4CB01A5; Wed, 19 Oct 2011 19:43:28 +0200 (CEST) Received: from [192.168.99.36] (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id 6917CB019E; Wed, 19 Oct 2011 19:43:27 +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: <9C8CA816-65FB-41A0-999C-4C43128CAAB4@danyork.org> Date: Wed, 19 Oct 2011 19:43:26 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9C8CA816-65FB-41A0-999C-4C43128CAAB4@danyork.org> To: Dan York X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] A plea for simplicity, marketability - and... who are we designing RTCWEB for? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 17:43:31 -0000 Hi Dan, >=20 > If they are with startups, they want to build nice bright shiny = objects that people will chase and use. They want to make the next = Twitter or FourSquare or (pick your cool service that everyone salivates = over). If they are with more established companies, they want to create = easy-to-use interfaces that expose data or information in new and = interesting ways or allow users to interact with their web apps in new = and useful ways. >=20 > And they want to do all this using the "languages of the web"... = JavaScript, PHP, Ruby, Python, etc. >=20 > They want "easily consumable" APIs where they can just look at a web = page of documentation and understand in a few minutes how they can add = functionality to their app using simple REST calls or adding snippets of = code to their web page. Their interaction with telephony is more along = these lines: >=20 > "Wow, dude, all I have to do is get an authorization token and curl = this URL with my token and a phone number and I can create a phone = call!" >=20 > And the thing is... they can do this **TODAY** with existing = proprietary products and services. You can code it all up in = Flex/Flash. You can write it in Java. You can use Voxeo's Phono. You = could probably do it in Microsoft's Silverlight. I seem to recall = Twilio having a web browser client. A bunch of the carriers/operators = are starting to offer their own ways of doing this. On any given week = there are probably a dozen new startups out there with their own ideas = for a new proprietary, locked-in way of doing RTC via web browsers. >=20 > Web developers don't *NEED* this RTCWEB/WebRTC work to do real-time = communications between browsers.=20 >=20 > It can be done today. Now. >=20 [snip] Well, lets take Phono as an example. Why can people build cool things = with it? Because it's a simple library and developers don't need to do = much, right? That's only true because someone (Voxeo in the case of = Phono) provides a server for it. Inaki and Jose could very well build a = jQuery plugin on top of that jsSIP library which would connect you = through *their* OverSIP servers and it would work just as good. A phone = in your browser, 10 lines of JS. Don't get me wrong, I don't want to bring the PSTN dinosaur into web = browsers, but I don't want to build another island o devices to which = we'll need to gateway later either, because we will. Regards, -- Sa=FAl Ibarra Corretg=E9 AG Projects From ibc@aliax.net Wed Oct 19 10:50: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 BC92121F8B62 for ; Wed, 19 Oct 2011 10:50:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.638 X-Spam-Level: X-Spam-Status: No, score=-2.638 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q6M7JVMaNGAZ for ; Wed, 19 Oct 2011 10:50:48 -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 322AE21F8B65 for ; Wed, 19 Oct 2011 10:50:48 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so2151328vcb.31 for ; Wed, 19 Oct 2011 10:50:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.35.34 with SMTP id e2mr7629181vdj.52.1319046647547; Wed, 19 Oct 2011 10:50:47 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Wed, 19 Oct 2011 10:50:47 -0700 (PDT) In-Reply-To: References: <9C8CA816-65FB-41A0-999C-4C43128CAAB4@danyork.org> Date: Wed, 19 Oct 2011 19:50:47 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: =?UTF-8?Q?Sa=C3=BAl_Ibarra_Corretg=C3=A9?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] A plea for simplicity, marketability - and... who are we designing RTCWEB for? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 17:50:48 -0000 2011/10/19 Sa=C3=BAl Ibarra Corretg=C3=A9 : > Well, lets take Phono as an example. Why can people build cool things wit= h it? Because it's a simple library and developers don't need to do much, r= ight? That's only true because someone (Voxeo in the case of Phono) provide= s a server for it. Inaki and Jose could very well build a jQuery plugin on = top of that jsSIP library which would connect you through *their* OverSIP s= ervers and it would work just as good. A phone in your browser, 10 lines of= JS. This is an important note. When a web developer uses Phone it's just using the JS provided by Phono, but it must connect to Phono servers (that is a product, a service, NOT an open technology). --=20 I=C3=B1aki Baz Castillo From saul@ag-projects.com Wed Oct 19 10: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 A49B921F8C53 for ; Wed, 19 Oct 2011 10:57:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.688 X-Spam-Level: X-Spam-Status: No, score=-1.688 tagged_above=-999 required=5 tests=[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 gHWVXuGIKHz8 for ; Wed, 19 Oct 2011 10:57:29 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 3164321F8C5C for ; Wed, 19 Oct 2011 10:57:29 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 8FC6CB01A5; Wed, 19 Oct 2011 19:57:28 +0200 (CEST) Received: from [192.168.99.36] (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id D8E58B019E; Wed, 19 Oct 2011 19:57:25 +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: Wed, 19 Oct 2011 19:57:24 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7DBDE7E0-E6D9-4F3A-8343-4E465E9B817A@ag-projects.com> References: <9C8CA816-65FB-41A0-999C-4C43128CAAB4@danyork.org> To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] A plea for simplicity, marketability - and... who are we designing RTCWEB for? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 17:57:29 -0000 On Oct 19, 2011, at 7:50 PM, I=F1aki Baz Castillo wrote: > 2011/10/19 Sa=FAl Ibarra Corretg=E9 : >> Well, lets take Phono as an example. Why can people build cool things = with it? Because it's a simple library and developers don't need to do = much, right? That's only true because someone (Voxeo in the case of = Phono) provides a server for it. Inaki and Jose could very well build a = jQuery plugin on top of that jsSIP library which would connect you = through *their* OverSIP servers and it would work just as good. A phone = in your browser, 10 lines of JS. >=20 > This is an important note. When a web developer uses Phone it's just > using the JS provided by Phono, but it must connect to Phono servers > (that is a product, a service, NOT an open technology). >=20 That was not my point. My point was that Phono connects to a predefined = server, it doesn't really matter if it's open or close, what matters is = the fact that a server is provided for the cool stuff to happen. -- Sa=FAl Ibarra Corretg=E9 AG Projects From bernard_aboba@hotmail.com Wed Oct 19 11:39: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 D0BDE11E80C1 for ; Wed, 19 Oct 2011 11:39:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.298 X-Spam-Level: X-Spam-Status: No, score=-102.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_57=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w+YtMHki2mq0 for ; Wed, 19 Oct 2011 11:39:14 -0700 (PDT) Received: from blu0-omc4-s20.blu0.hotmail.com (blu0-omc4-s20.blu0.hotmail.com [65.55.111.159]) by ietfa.amsl.com (Postfix) with ESMTP id 24E2811E80BA for ; Wed, 19 Oct 2011 11:39:14 -0700 (PDT) Received: from BLU152-W43 ([65.55.111.137]) by blu0-omc4-s20.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 19 Oct 2011 11:39:13 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_d84f1fe9-52c9-490d-9928-ec8320ab0b3a_" X-Originating-IP: [131.107.0.95] From: Bernard Aboba To: , Date: Wed, 19 Oct 2011 11:39:12 -0700 Importance: Normal In-Reply-To: <9C8CA816-65FB-41A0-999C-4C43128CAAB4@danyork.org> References: <9C8CA816-65FB-41A0-999C-4C43128CAAB4@danyork.org> MIME-Version: 1.0 X-OriginalArrivalTime: 19 Oct 2011 18:39:13.0561 (UTC) FILETIME=[660E3890:01CC8E8E] Subject: Re: [rtcweb] A plea for simplicity, marketability - and... who are we designing RTCWEB for? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 18:39:15 -0000 --_d84f1fe9-52c9-490d-9928-ec8320ab0b3a_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dan -- Great rant. However=2C if I understand you correctly=2C your concerns rela= te to the WEBRTC APIs being developed within W3C=2C not to the work going o= n in IETF RTCWEB. Personally=2C I don't expect the W3C APIs to be used dir= ectly by Web developers in most cases. Rather=2C I expect developers to us= e higher level libraries that will=2C among other things=2C check for the a= vailable browser functionality=2C enabling applications to run both on brow= sers that support RTCWEB=2C as well as ones that do not but support the alt= ernatives you mention. Given that=2C I'm not expecting that developers wil= l find RTCWEB any harder to use than the alternatives=2C because the differ= ences will be abstracted away.=20 However=2C if we are opening the RANT queue=2C I do have a concern that rel= ates to IETF RTCWEB. And that is the number of dependencies that are pilin= g up=2C even for simple scenarios. Fundamentally=2C many of the issues we = have been talking about arise from the need to support peer-to-peer media. = This is what drives the need for ICE (so recipient can authorize sending o= f media)=2C end-to-end security (e.g. to know/authorize where P2P media is= going)=2C and to some extend DoS and congestion control functionality. = While I understand the need for P2P support=2C we do need to avoid imposing= all of these dependencies in simple client/server scenarios. For example= =2C if all a developer wants to do is send media and signalling down a webs= ocket=2C many of the concerns arising from P2P media evaporate. When opera= ting within the "single origin" model=2C it should be possible to maintain = a very high degree of legacy interop=2C with no requirements for ICE=2C e2e= security=2C etc. =20 From: dan-ietf@danyork.org Date: Wed=2C 19 Oct 2011 09:20:18 -0400 To: rtcweb@ietf.org Subject: [rtcweb] A plea for simplicity=2C marketability - and... who are w= e designing RTCWEB for? Folks=2C I need to rant. I've been lurking on this list from the beginning but with = a new job I haven't been able to really keep up with the volume of messages= ... and every time I get ready to reply I find that others like Hadriel=2C = Tim=2C Neil=2C Tolga or others have made the points I was going to make...= =20 But I find myself increasingly frustrated with the ongoing discussions and = want to ask a fundamental question: - WHO ARE WE BUILDING RTCWEB/WEBRTC FOR? Is it for: 1. Telephony developers who are tired of writing code in traditional langua= ges and want to do things in new web ways=3B 2. Web developers who want to add real-time comms (as in voice=2C video and= chat) to their existing or new web applications=3B 3. Both 1 and 2. If the answer is #1=2C then I think everything is going along just wonderfu= lly. We can go ahead and use the SIP/SDP/etc. stuff that we all in the RAI= area are all used to and understand just fine. Heck=2C let's just all end= the discussions about a signalling protocol and agree on SIP... get the br= owser vendors to agree on baking a SIP UA into their browsers... and call i= t a day and go have a beer. Simple. Easy. Done. And the only people who will ever use it will be people who work for RTC/UC= /VoIP vendors and random other programmers who actually care about telephon= y=2C etc.=20 But that's okay=2C because the people who do use it (and their employers) = will be really happy and life will be good. If the answer is #2=2C then I think we need to step back and ask -=20 HOW DO "WEB DEVELOPERS" REALLY WANT TO WORK? Here's the thing... in my experience... 99% OF WEB DEVELOPERS DON'T GIVE A ______ ABOUT TELEPHONY! Never have. Never will. (In fact=2C I may be understating that. It may ac= tually be 99.99999%.) If they are with startups=2C they want to build nice bright shiny objects t= hat people will chase and use. They want to make the next Twitter or FourS= quare or (pick your cool service that everyone salivates over). If they ar= e with more established companies=2C they want to create easy-to-use interf= aces that expose data or information in new and interesting ways or allow u= sers to interact with their web apps in new and useful ways. And they want to do all this using the "languages of the web"... JavaScript= =2C PHP=2C Ruby=2C Python=2C etc. They want "easily consumable" APIs where they can just look at a web page o= f documentation and understand in a few minutes how they can add functional= ity to their app using simple REST calls or adding snippets of code to thei= r web page. Their interaction with telephony is more along these lines: "Wow=2C dude=2C all I have to do is get an authorization token and curl thi= s URL with my token and a phone number and I can create a phone call!" And the thing is... they can do this **TODAY** with existing proprietary pr= oducts and services. You can code it all up in Flex/Flash. You can write i= t in Java. You can use Voxeo's Phono. You could probably do it in Microso= ft's Silverlight. I seem to recall Twilio having a web browser client. A = bunch of the carriers/operators are starting to offer their own ways of doi= ng this. On any given week there are probably a dozen new startups out the= re with their own ideas for a new proprietary=2C locked-in way of doing RTC= via web browsers. Web developers don't *NEED* this RTCWEB/WebRTC work to do real-time communi= cations between browsers.=20 It can be done today. Now. The drawback is that today you need to have some kind of applet/plugin/exte= nsion downloaded to the browser to allow access to the mic and speakers and= make the RTC actually work. So you have to use some Flash or Java or some= thing. AND... you are locked into some particular vendor's way of doing thi= ngs and are reliant on that vendor being around. THAT is what RTCWEB can overcome. Make it so that web developers can easil= y add RTC to their web apps without requiring any downloads=2C etc. Make i= t do-able in open standards that don't lock developers in to a specific pro= duct or vendor. But if we are targeting "web developers"=2C that is need we need to satisfy= ... and we need to understand that they *already* have ways to do what we a= re allowing them to do. If we come out with something that is so "different" from what "web develop= ers" are used to... that requires someone to=2C for instance=2C understand = all of what SIP is about... that requires a whole bunch of lines of code=2C= etc.... well... ... the web developers out there will NOT launch an "Occupy RTCWEB" movemen= t claiming that they are the "99% who don't care about telephony"... they w= ill simply... not... use.... RTCWEB! They will continue to use proprietary products and services because those w= ork in the ways that web developers are used to and they make it simple for= a web developer to go add voice=2C video and chat to a web app. Sure... t= hey will still require the dreaded plugin/extension=2C but so be it... the = "open standard" way is far too complicated for them to look at. And all the work and the zillions of hours of writing emails and I-Ds that = this group has done will all be for nothing. Well=2C not nothing... some o= f the telephony-centric developers will use them. But the majority of the = web developers out there may not because there are other simpler=2C easier = ways to do what they need to do. So I go back to the question - who are we building RTCWEB for? Is the goal to enable the zillions of web developers out to be able to use = real-time communications in new and innovative ways? Or is it solely to ma= ke it so that VoIP/UC/RTC vendors can make a softphone in the browser that = calls into their call center software? RTCWEB *can* enable both... but to me it's a question of where the priority= is. The question is - will the RTCWEB/WEBRTC API/protocol/whatever be so simple= and easy that web developers will choose to use it over Flash/Phono/Twilio= /Java/whatever to add RTC functions to their web apps? If the answer is yes=2C we win. Open standards win. Maybe we upgrade from = having a beer to having champagne. If the answer is no=2C what are spending all this time for? Dan --=20 Dan York dyork@lodestar2.com http://www.danyork.com/ skype:danyork Phone: +1-802-735-1624 Twitter - http://twitter.com/danyork---------------------------------------= -----------------All comments and opinions are entirely my own and have no = connection whatsoever to any employer=2C past or present. Indeed=2C by tomo= rrow even I might be disavowing these comments.----------------------------= ---------------------------- _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb = --_d84f1fe9-52c9-490d-9928-ec8320ab0b3a_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dan --

Great rant. =3B However=2C if I understand you correctly= =2C your concerns relate to the WEBRTC APIs being developed within W3C=2C n= ot to the work going on in IETF RTCWEB. =3B Personally=2C I don't expec= t the W3C APIs to be used directly by Web developers in most cases. =3B= Rather=2C I expect developers to use higher level libraries that will=2C a= mong other things=2C check for the available browser functionality=2C enabl= ing applications to run both on browsers that support RTCWEB=2C as well as = ones that do not but support the alternatives you mention. =3B Given th= at=2C I'm not expecting that developers will find RTCWEB any harder to use = than the alternatives=2C because the differences will be abstracted away. <= br>
However=2C if we are opening the RANT queue=2C I do have a concern t= hat relates to IETF RTCWEB. =3B And that is the number of dependencies = that are piling up=2C even for simple scenarios. =3B Fundamentally=2C m= any of the issues we have been talking about arise from the need to support= peer-to-peer media. =3B This is what drives the need for ICE (so recip= ient can authorize sending of media)=2C =3B end-to-end security (e.g. t= o know/authorize where P2P media is going)=2C =3B and to some extend Do= S and congestion control functionality. =3B =3B While I understand = the need for P2P support=2C we do need to avoid imposing all of these depen= dencies in simple client/server scenarios. =3B For example=2C if all a = developer wants to do is send media and signalling down a websocket=2C many= of the concerns arising from P2P media evaporate. =3B When operating w= ithin the "single origin" model=2C it should be possible to maintain a very= high degree of legacy interop=2C with no requirements for ICE=2C e2e secur= ity=2C etc. =3B

From: dan-ietf@dan= york.org
Date: Wed=2C 19 Oct 2011 09:20:18 -0400
To: rtcweb@ietf.org<= br>Subject: [rtcweb] A plea for simplicity=2C marketability - and... who ar= e we designing RTCWEB for?

Folks=2C

I need to rant. I've been lurking on this list from the beginning = but with a new job I haven't been able to really keep up with the volume of= messages... and every time I get ready to reply I find that others like Ha= driel=2C Tim=2C Neil=2C Tolga or others have made the points I was going to= make... =3B

But I find myself increasingly fr= ustrated with the ongoing discussions and want to ask a fundamental questio= n:

- WHO ARE WE BUILDING RTCWEB/WEBRTC FOR?
<= div>
Is it for:

1. Telephony develop= ers who are tired of writing code in traditional languages and want to do t= hings in new web ways=3B

2. Web developers who wan= t to add real-time comms (as in voice=2C video and chat) to their existing = or new web applications=3B

3. Both 1 and 2.
<= div>
If the answer is #1=2C then I think everything is going = along just wonderfully.  =3BWe can go ahead and use the SIP/SDP/etc. st= uff that we all in the RAI area are all used to and understand just fine. &= nbsp=3BHeck=2C let's just all end the discussions about a signalling protoc= ol and agree on SIP... get the browser vendors to agree on baking a SIP UA = into their browsers... and call it a day and go have a beer.  =3BSimple= . Easy. Done.

And the only people who will ever us= e it will be people who work for RTC/UC/VoIP vendors and random other progr= ammers who actually care about telephony=2C etc. =3B

 =3BBut that's okay=2C because the people who do use it (and the= ir employers) will be really happy and life will be good.


If the answer is #2=2C then I think we need to step = back and ask - =3B

 =3B  =3BHOW DO "WE= B DEVELOPERS" REALLY WANT TO WORK?

Here's the thin= g... in my experience...

 =3B  =3B 99% OF = WEB DEVELOPERS DON'T GIVE A ______ ABOUT TELEPHONY!

Never have.  =3BNever will.  =3B(In fact=2C I may be= understating that. It may actually be 99.99999%.)

If they are with startups=2C they want to build nice bright shiny objects = that people will chase and use.  =3BThey want to make the next Twitter = or FourSquare or (pick your cool service that everyone salivates over). &nb= sp=3BIf they are with more established companies=2C they want to create eas= y-to-use interfaces that expose data or information in new and interesting = ways or allow users to interact with their web apps in new and useful ways.=

And they want to do all this using the "languages= of the web"... JavaScript=2C PHP=2C Ruby=2C Python=2C etc.

<= /div>
They want "easily consumable" APIs where they can just look at a = web page of documentation and understand in a few minutes how they can add = functionality to their app using simple REST calls or adding snippets of co= de to their web page.  =3BTheir interaction with telephony is more alon= g these lines:

"Wow=2C dude=2C all I have to do is= get an authorization token and curl this URL with my token and a phone num= ber and I can create a phone call!"

And the thing = is... they can do this **TODAY** with existing proprietary products and ser= vices.  =3BYou can code it all up in Flex/Flash. You can write it in Ja= va.  =3BYou can use Voxeo's Phono. =3B =3BYou could probably do= it in Microsoft's Silverlight.  =3BI seem to recall Twilio having a we= b browser client.  =3BA bunch of the carriers/operators are starting to= offer their own ways of doing this.  =3BOn any given week there are pr= obably a dozen new startups out there with their own ideas for a new propri= etary=2C locked-in way of doing RTC via web browsers.

<= div>Web developers don't *NEED* this RTCWEB/WebRTC work to do real-time com= munications between browsers. =3B

It can be do= ne today.  =3BNow.

The drawback is that today = you need to have some kind of applet/plugin/extension downloaded to the bro= wser to allow access to the mic and speakers and make the RTC actually work= .  =3BSo you have to use some Flash or Java or something. AND... you ar= e locked into some particular vendor's way of doing things and are reliant = on that vendor being around.

THAT is what RTCWEB c= an overcome.  =3BMake it so that web developers can easily add RTC to t= heir web apps without requiring any downloads=2C etc.  =3BMake it do-ab= le in open standards that don't lock developers in to a specific product or= vendor.

But if we are targeting "web developers"= =2C that is need we need to satisfy... and we need to understand that they = *already* have ways to do what we are allowing them to do.

If we come out with something that is so "different" from what "we= b developers" are used to... that requires someone to=2C for instance=2C un= derstand all of what SIP is about... that requires a whole bunch of lines o= f code=2C etc.... well...

... the web developers o= ut there will NOT launch an "Occupy RTCWEB" movement claiming that they are= the "99% who don't =3Bcare about telephony"... they will simply... not= ... use.... RTCWEB!

They will continue to use prop= rietary products and services because those work in the ways that web devel= opers are used to and they make it simple for a web developer to go add voi= ce=2C video and chat to a web app.  =3BSure... they will still require = the dreaded plugin/extension=2C but so be it... the "open standard" way is = far too complicated for them to look at.

And all t= he work and the zillions of hours of writing emails and I-Ds that this grou= p has done will all be for nothing.  =3BWell=2C not nothing... some of = the telephony-centric developers will use them.  =3BBut the majority of= the web developers out there may not because there are other simpler=2C ea= sier ways to do what they need to do.

So I go back= to the question - who are we building RTCWEB for?

Is the goal to enable the zillions of web developers out to be able to use= real-time communications in new and innovative ways?  =3BOr is it sole= ly to make it so that VoIP/UC/RTC vendors can make a softphone in the brows= er that calls into their call center software?

RTC= WEB *can* enable both... but to me it's a question of where the priority is= .

The question is - will the RTCWEB/WEBRTC API/pro= tocol/whatever be so simple and easy that web developers will choose to use= it over Flash/Phono/Twilio/Java/whatever to add RTC functions to their web= apps?

If the answer is yes=2C we win.  =3BOpe= n standards win. Maybe we upgrade from having a beer to having champagne.

If the answer is no=2C what are spending all this t= ime for?

<=3B/rant>=3B

Dan

-- =3B
Dan York  =3Bd= york@lodestar2.com
http://www.danyork.com/ =3B =3B =3Bskype:danyork
Phone: +1-802-735-1624
Twitter - =3Bhttp://twitter.com/danyor= k
----------------------------= ----------------------------
All comments and opinions are entirely my own and have no connection whats= oever to any employer=2C past or present. Indeed=2C by tomorrow even I migh= t be disavowing these comments.
--= ------------------------------------------------------


_______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
= --_d84f1fe9-52c9-490d-9928-ec8320ab0b3a_-- From ibc@aliax.net Wed Oct 19 12:25: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 94FA211E80C1 for ; Wed, 19 Oct 2011 12:25:11 -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 8184PT7B+5+C for ; Wed, 19 Oct 2011 12:25:10 -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 98EA911E80C2 for ; Wed, 19 Oct 2011 12:25:10 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so2267414vcb.31 for ; Wed, 19 Oct 2011 12:25:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.35.34 with SMTP id e2mr7924166vdj.52.1319052307844; Wed, 19 Oct 2011 12:25:07 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Wed, 19 Oct 2011 12:25:07 -0700 (PDT) In-Reply-To: <4E9E5D8D.6030707@alvestrand.no> References: <2E239D6FCD033C4BAF15F386A979BF511599F9@sonusinmail02.sonusnet.com> <4E9E5D8D.6030707@alvestrand.no> Date: Wed, 19 Oct 2011 21:25:07 +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] Comment on draft-ietf-rtcweb-overview-02 (Browser RTC trapezoid) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 19:25:11 -0000 2011/10/19 Harald Alvestrand : > 1) The term "RTCWeb Signaling" has no clear definition, as this discussio= n > has proved again. Hi Harald, I've tryed to clarify the term(s) "signaling" in RTCweb: http://public.aliax.net/RTCweb_Signaling_Components.html IMHO there is general confusion about such term because we use it in different parts of the whole RTCweb picture. Regards. --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Wed Oct 19 12:45: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 03E901F0C5F for ; Wed, 19 Oct 2011 12:45:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.34 X-Spam-Level: X-Spam-Status: No, score=-2.34 tagged_above=-999 required=5 tests=[AWL=-0.263, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_18=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y7VdHF1nttCZ for ; Wed, 19 Oct 2011 12:45:02 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1526F1F0C5B for ; Wed, 19 Oct 2011 12:45:02 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so2287302vcb.31 for ; Wed, 19 Oct 2011 12:45:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.155.81 with SMTP id r17mr353897vcw.6.1319053500204; Wed, 19 Oct 2011 12:45:00 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Wed, 19 Oct 2011 12:45:00 -0700 (PDT) In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF51159A20@sonusinmail02.sonusnet.com> References: <2E239D6FCD033C4BAF15F386A979BF511599F9@sonusinmail02.sonusnet.com> <4E9E5D8D.6030707@alvestrand.no> <2E239D6FCD033C4BAF15F386A979BF51159A20@sonusinmail02.sonusnet.com> Date: Wed, 19 Oct 2011 21:45:00 +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] Comment on draft-ietf-rtcweb-overview-02 (Browser RTC trapezoid) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 19:45:03 -0000 2011/10/19 Ravindran Parthasarathi : > If you don't have a clear view of the Javascript execution model, I > recommend spending a few hours with an introductory Javascript text and > playing with writing some Javascript in your own web pages. It will save > lots of confused emails to the list. > > In fact I tried couple of W3Cschools Javascript before starting = the > mail thread in RTCWeb. I=E2=80=99ll learn more terminology in Javascript = to clearly > present my ideas Hi Ravindran, please let me understand: You recognize that you have no knowledge of JavaScript (you started reading some tutorials of JavaScript *yesterday*) but your draft clearly states: ------------------------ Abstract [...] There are lots of issues in Javascript based signaling protocol. [...] ------------------------ And in other mail(s) you assert: ------------------------ I=E2=80=99m not favor Inaki solution of SIP over websocket because= it is overkill for signaling protocol. [...] ------------------------ So how should I interpret it? how can you make such assertions without knowledge?. I don't consider that to be very polite, and for me that means that you want to discredit proposals different than yours. Regards. --=20 I=C3=B1aki Baz Castillo From pravindran@sonusnet.com Wed Oct 19 14: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 8A7BE21F8ABE for ; Wed, 19 Oct 2011 14:39:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.385 X-Spam-Level: X-Spam-Status: No, score=-2.385 tagged_above=-999 required=5 tests=[AWL=-0.686, BAYES_00=-2.599, J_CHICKENPOX_18=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ofHL+dYfhCvh for ; Wed, 19 Oct 2011 14:39:25 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 9276321F8AB9 for ; Wed, 19 Oct 2011 14:39:25 -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 p9JLdsZx028212; Wed, 19 Oct 2011 17:39:54 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail05.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 19 Oct 2011 17:39:20 -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, 20 Oct 2011 03:09:13 +0530 Message-ID: <2E239D6FCD033C4BAF15F386A979BF51159AA6@sonusinmail02.sonusnet.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] Comment on draft-ietf-rtcweb-overview-02 (Browser RTC trapezoid) Thread-Index: AcyOl5uqZPyfwxzMRhaOHW1Qi08ZGAAC1XhA References: <2E239D6FCD033C4BAF15F386A979BF511599F9@sonusinmail02.sonusnet.com><4E9E5D8D.6030707@alvestrand.no><2E239D6FCD033C4BAF15F386A979BF51159A20@sonusinmail02.sonusnet.com> From: "Ravindran Parthasarathi" To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= X-OriginalArrivalTime: 19 Oct 2011 21:39:20.0493 (UTC) FILETIME=[8F7D2DD0:01CC8EA7] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Comment on draft-ietf-rtcweb-overview-02 (Browser RTC trapezoid) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 21:39:26 -0000 SW5ha2ksDQoNClRoZXJlIGFyZSBmdW5kYW1lbnRhbGx5IHR3byBhc3BlY3RzIGluIFJUQ1dlYjoN Cg0KMSkgKG9uLXdpcmUpIHByb3RvY29sIG1lY2hhbmlzbSAtIEhvdyBwcm90b2NvbCBpcyBkZXNp Z25lZCBiZXR3ZWVuIFJUQ1dlYiBjbGllbnQgKGJyb3dzZXIpIGFuZCBSVENXZWIgc2VydmVyLCBS VENXZWIgY2xpZW50IGFuZCBSVENXZWIgY2xpZW50LiBUaGUgcHJvdG9jb2wgZGVzaWduIGRvZXMg bm90IGZvY3VzIG9uIFJUQ1dlYiBjbGllbnQgb25seSBidXQgYWxzbyBpbiBSVENXZWIgc2VydmVy IGJlY2F1c2UgdGhlIHByb3RvY29sIGhhcyB0byBiZSBpbXBsZW1lbnRlZCBpbiBib3RoIGVudGl0 aWVzLiBJT1csIGl0IGlzIG5vdCAyMCBsaW5lcyBvZiBKYXZhU2NyaXB0IGJ1dCBpbXBhY3Qgb2Yg UlRDV2ViIHNlcnZlciBkZXNpZ24gaGFzIHRvIGJlIG5vdGVkIGFzIHdlbGwuIEhlcmUgSUVURiBo YXMgc2lnbmlmaWNhbnQgcm9sZSBhbmQgaXQgaGFzIHRvIGNvbWUgdXAgd2l0aCBiZXN0IHByb3Rv Y29sIGRlc2lnbiBiZXR3ZWVuIFJUQ1dlYiBlbnRpdGllcy4NCg0KMikgQVBJIGRlc2lnbiAoSmF2 YVNjcmlwdCBpbiBicm93c2VyKSAtIEJyb3dzZXIgcHJvdmlkZXMgUlRDV2ViIGNsaWVudCBmcmFt ZXdvcmsgYW5kIGV4cG9zZXMgaXRzIEFQSSBhcyBKYXZhU2NyaXB0IGFuZCBKYXZhU2NyaXB0IGlz IHRoZSBsYW5ndWFnZS9zY3JpcHQgb2YgY2hvaWNlIGZvciBicm93c2Vycy4gVGhlIGludGVyYWN0 aW9uIGlzIGJldHdlZW4gYnJvd3NlciBhbmQgSmF2YVNjcmlwdCBvbmx5LiBJTU8sIFczQyBwbGF5 cyB0aGUgdml0YWwgcm9sZSBpbiBjb21pbmcgdXAgd2l0aCBiZXN0IEFQSSBzZXQgYW5kIGFsc28s IHRoZXJlIGlzIG5vIG9uLXdpcmUgc3R1ZmYgaGVyZS4gSGVyZSwgdGhlIGRpc2N1c3Npb24gZm9j dXMgaXMgd2hldGhlciBsb3cgbGV2ZWwgQVBJIG9yIFJPQVAgQVBJIG9yIGFueSBvdGhlciBoaWdo IGxldmVsIEFQSS4gT2YgY291cnNlLCBJIGhhdmUgbGVzcyBleHBlcmllbmNlIGluIEphdmFTY3Jp cHQgYmFzZWQgQVBJIGRlc2lnbi4gUGxlYXNlIG5vdGUgdGhhdCBJIGhhdmUgZGVzaWduZWQgYW5k IHdvcmtlZCBpbiBwcm90b2NvbCBmcmFtZXdvcmsgaW4gb3RoZXIgbGFuZ3VhZ2VzIGxpa2UgQywg VENMLiANCg0KTXkgY29tbWVudCBvbiAiU0lQIG92ZXIgd2Vic29ja2V0IGlzIGFuIG92ZXJraWxs IiBpcyBwdXJlbHkgYmFzZWQgb24gKG9uLXdpcmUpIHByb3RvY29sIG1lY2hhbmlzbSBhbmQgaXQg aXMgbm90aGluZyBkbyB3aXRoIEFQSSBkZXNpZ24uIElycmVzcGVjdGl2ZSBvZiB3aGV0aGVyICJT SVAgb3ZlciB3ZWJzb2NrZXQiIGlzIGltcGxlbWVudGVkIGluIGJyb3dzZXIgb3IgaW4gSmF2YVNj cmlwdCBvciBpbiBvdGhlciBsYW5ndWFnZSwgaXQgaXMgbm90IHRoZSBiZXN0IHByb3RvY29sIGRl c2lnbi4gSG9wZSB0aGlzIGNsYXJpZmllcyBteSBzdGFuY2UuDQoNClRoYW5rcw0KUGFydGhhDQoN Cj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPkZyb206IEnDsWFraSBCYXogQ2FzdGlsbG8g W21haWx0bzppYmNAYWxpYXgubmV0XQ0KPlNlbnQ6IFRodXJzZGF5LCBPY3RvYmVyIDIwLCAyMDEx IDE6MTUgQU0NCj5UbzogUmF2aW5kcmFuIFBhcnRoYXNhcmF0aGkNCj5DYzogSGFyYWxkIEFsdmVz dHJhbmQ7IHJ0Y3dlYkBpZXRmLm9yZw0KPlN1YmplY3Q6IFJlOiBbcnRjd2ViXSBDb21tZW50IG9u IGRyYWZ0LWlldGYtcnRjd2ViLW92ZXJ2aWV3LTAyIChCcm93c2VyDQo+UlRDIHRyYXBlem9pZCkN Cj4NCj4yMDExLzEwLzE5IFJhdmluZHJhbiBQYXJ0aGFzYXJhdGhpIDxwcmF2aW5kcmFuQHNvbnVz bmV0LmNvbT46DQo+PiBJZiB5b3UgZG9uJ3QgaGF2ZSBhIGNsZWFyIHZpZXcgb2YgdGhlIEphdmFz Y3JpcHQgZXhlY3V0aW9uIG1vZGVsLCBJDQo+PiByZWNvbW1lbmQgc3BlbmRpbmcgYSBmZXcgaG91 cnMgd2l0aCBhbiBpbnRyb2R1Y3RvcnkgSmF2YXNjcmlwdCB0ZXh0DQo+YW5kDQo+PiBwbGF5aW5n IHdpdGggd3JpdGluZyBzb21lIEphdmFzY3JpcHQgaW4geW91ciBvd24gd2ViIHBhZ2VzLiBJdCB3 aWxsDQo+c2F2ZQ0KPj4gbG90cyBvZiBjb25mdXNlZCBlbWFpbHMgdG8gdGhlIGxpc3QuDQo+Pg0K Pj4gPHBhcnRoYT4gSW4gZmFjdCBJIHRyaWVkIGNvdXBsZSBvZiBXM0NzY2hvb2xzIEphdmFzY3Jp cHQgYmVmb3JlDQo+c3RhcnRpbmcgdGhlDQo+PiBtYWlsIHRocmVhZCBpbiBSVENXZWIuIEnigJls bCBsZWFybiBtb3JlIHRlcm1pbm9sb2d5IGluIEphdmFzY3JpcHQgdG8NCj5jbGVhcmx5DQo+PiBw cmVzZW50IG15IGlkZWFzIDwvcGFydGhhPg0KPg0KPkhpIFJhdmluZHJhbiwgcGxlYXNlIGxldCBt ZSB1bmRlcnN0YW5kOg0KPg0KPllvdSByZWNvZ25pemUgdGhhdCB5b3UgaGF2ZSBubyBrbm93bGVk Z2Ugb2YgSmF2YVNjcmlwdCAoeW91IHN0YXJ0ZWQNCj5yZWFkaW5nIHNvbWUgdHV0b3JpYWxzIG9m IEphdmFTY3JpcHQgKnllc3RlcmRheSopIGJ1dCB5b3VyIGRyYWZ0DQo+Y2xlYXJseSBzdGF0ZXM6 DQo+DQo+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+QWJzdHJhY3QNCj4NCj4gIFsuLi5dDQo+ ICBUaGVyZSBhcmUgbG90cyBvZiBpc3N1ZXMgaW4gSmF2YXNjcmlwdCBiYXNlZCBzaWduYWxpbmcg cHJvdG9jb2wuDQo+ICBbLi4uXQ0KPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPg0KPkFuZCBp biBvdGhlciBtYWlsKHMpIHlvdSBhc3NlcnQ6DQo+DQo+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQo+PHBhcnRoYT4gSeKAmW0gbm90IGZhdm9yIEluYWtpIHNvbHV0aW9uIG9mIFNJUCBvdmVyIHdl YnNvY2tldCBiZWNhdXNlIGl0DQo+aXMgb3ZlcmtpbGwgZm9yIHNpZ25hbGluZyBwcm90b2NvbC4g Wy4uLl08L3BhcnRoYT4NCj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4NCj4NCj5TbyBob3cg c2hvdWxkIEkgaW50ZXJwcmV0IGl0PyBob3cgY2FuIHlvdSBtYWtlIHN1Y2ggYXNzZXJ0aW9ucyB3 aXRob3V0DQo+a25vd2xlZGdlPy4gSSBkb24ndCBjb25zaWRlciB0aGF0IHRvIGJlIHZlcnkgcG9s aXRlLCBhbmQgZm9yIG1lIHRoYXQNCj5tZWFucyB0aGF0IHlvdSB3YW50IHRvIGRpc2NyZWRpdCBw cm9wb3NhbHMgZGlmZmVyZW50IHRoYW4geW91cnMuDQo+DQo+DQo+UmVnYXJkcy4NCj4NCj4NCj4t LQ0KPknDsWFraSBCYXogQ2FzdGlsbG8NCj48aWJjQGFsaWF4Lm5ldD4NCg== From saul@ag-projects.com Wed Oct 19 14: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 5A8EB21F8B0C for ; Wed, 19 Oct 2011 14:54:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.688 X-Spam-Level: X-Spam-Status: No, score=-1.688 tagged_above=-999 required=5 tests=[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 hW4XipPion2R for ; Wed, 19 Oct 2011 14:54:07 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id A71EA21F84FB for ; Wed, 19 Oct 2011 14:54:06 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 3F8A0B01A2; Wed, 19 Oct 2011 23:54:05 +0200 (CEST) Received: from [192.168.99.36] (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id 5FFC7B017D; Wed, 19 Oct 2011 23:54:04 +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: <2E239D6FCD033C4BAF15F386A979BF51159AA6@sonusinmail02.sonusnet.com> Date: Wed, 19 Oct 2011 23:54:03 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <23CC8E74-8C17-4484-998B-2A7B66358B81@ag-projects.com> References: <2E239D6FCD033C4BAF15F386A979BF511599F9@sonusinmail02.sonusnet.com><4E9E5D8D.6030707@alvestrand.no><2E239D6FCD033C4BAF15F386A979BF51159A20@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF51159AA6@sonusinmail02.sonusnet.com> To: Ravindran Parthasarathi X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Comment on draft-ietf-rtcweb-overview-02 (Browser RTC trapezoid) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 21:54:07 -0000 Hi, On Oct 19, 2011, at 11:39 PM, Ravindran Parthasarathi wrote: > Inaki, >=20 > There are fundamentally two aspects in RTCWeb: >=20 > 1) (on-wire) protocol mechanism - How protocol is designed between = RTCWeb client (browser) and RTCWeb server, RTCWeb client and RTCWeb = client. The protocol design does not focus on RTCWeb client only but = also in RTCWeb server because the protocol has to be implemented in both = entities. IOW, it is not 20 lines of JavaScript but impact of RTCWeb = server design has to be noted as well. Here IETF has significant role = and it has to come up with best protocol design between RTCWeb entities. >=20 > 2) API design (JavaScript in browser) - Browser provides RTCWeb client = framework and exposes its API as JavaScript and JavaScript is the = language/script of choice for browsers. The interaction is between = browser and JavaScript only. IMO, W3C plays the vital role in coming up = with best API set and also, there is no on-wire stuff here. Here, the = discussion focus is whether low level API or ROAP API or any other high = level API. Of course, I have less experience in JavaScript based API = design. Please note that I have designed and worked in protocol = framework in other languages like C, TCL.=20 >=20 If point 2, the JS API is flexible enough there is no need for a new = protocol design, we can reuse an existing one and use the JS API for the = media layer. I've lost count on the number of times this has already = been said, lets move on. > My comment on "SIP over websocket is an overkill" is purely based on = (on-wire) protocol mechanism and it is nothing do with API design. = Irrespective of whether "SIP over websocket" is implemented in browser = or in JavaScript or in other language, it is not the best protocol = design. Hope this clarifies my stance. >=20 Nobody is advocating for SIP over WebSocket nor XMPP over PBTL (pigeon = based transport layer), what some of us want is to let it up to the = developers. -- Sa=FAl Ibarra Corretg=E9 AG Projects From pravindran@sonusnet.com Wed Oct 19 15:04: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 1850411E8096 for ; Wed, 19 Oct 2011 15:04:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.659 X-Spam-Level: X-Spam-Status: No, score=-2.659 tagged_above=-999 required=5 tests=[AWL=-0.360, 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 Cfon3rE5jyTO for ; Wed, 19 Oct 2011 15:04:53 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 8052A11E808A for ; Wed, 19 Oct 2011 15:04: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 p9JM5Oi6012242; Wed, 19 Oct 2011 18:05:24 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail04.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 19 Oct 2011 18:04:49 -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: Thu, 20 Oct 2011 03:34:43 +0530 Message-ID: <2E239D6FCD033C4BAF15F386A979BF51159AA7@sonusinmail02.sonusnet.com> In-Reply-To: <23CC8E74-8C17-4484-998B-2A7B66358B81@ag-projects.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] Comment on draft-ietf-rtcweb-overview-02 (Browser RTC trapezoid) Thread-Index: AcyOqaG5ZImNm9GsQW+sxDvEwl0KqAAALIBw References: <2E239D6FCD033C4BAF15F386A979BF511599F9@sonusinmail02.sonusnet.com><4E9E5D8D.6030707@alvestrand.no><2E239D6FCD033C4BAF15F386A979BF51159A20@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF51159AA6@sonusinmail02.sonusnet.com> <23CC8E74-8C17-4484-998B-2A7B66358B81@ag-projects.com> From: "Ravindran Parthasarathi" To: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= X-OriginalArrivalTime: 19 Oct 2011 22:04:49.0674 (UTC) FILETIME=[1EF3AEA0:01CC8EAB] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Comment on draft-ietf-rtcweb-overview-02 (Browser RTC trapezoid) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 22:04:54 -0000 Saul, I have already mentioned in the mailing alias that *Please don't delete = the existing mail* because we often miss the original intent of the mail = and goes in the circular discussion. My original reply was intended only to answer Inaki query on how I come = to the conclusion that "I'm not favor Inaki solution of SIP over = websocket because it is overkill for signaling protocol".=20 Thanks Partha >-----Original Message----- >From: Sa=FAl Ibarra Corretg=E9 [mailto:saul@ag-projects.com] >Sent: Thursday, October 20, 2011 3:24 AM >To: Ravindran Parthasarathi >Cc: I=F1aki Baz Castillo; rtcweb@ietf.org >Subject: Re: [rtcweb] Comment on draft-ietf-rtcweb-overview-02 (Browser >RTC trapezoid) > >Hi, > >On Oct 19, 2011, at 11:39 PM, Ravindran Parthasarathi wrote: > >> Inaki, >> >> There are fundamentally two aspects in RTCWeb: >> >> 1) (on-wire) protocol mechanism - How protocol is designed between >RTCWeb client (browser) and RTCWeb server, RTCWeb client and RTCWeb >client. The protocol design does not focus on RTCWeb client only but >also in RTCWeb server because the protocol has to be implemented in = both >entities. IOW, it is not 20 lines of JavaScript but impact of RTCWeb >server design has to be noted as well. Here IETF has significant role >and it has to come up with best protocol design between RTCWeb = entities. >> >> 2) API design (JavaScript in browser) - Browser provides RTCWeb = client >framework and exposes its API as JavaScript and JavaScript is the >language/script of choice for browsers. The interaction is between >browser and JavaScript only. IMO, W3C plays the vital role in coming up >with best API set and also, there is no on-wire stuff here. Here, the >discussion focus is whether low level API or ROAP API or any other high >level API. Of course, I have less experience in JavaScript based API >design. Please note that I have designed and worked in protocol >framework in other languages like C, TCL. >> > >If point 2, the JS API is flexible enough there is no need for a new >protocol design, we can reuse an existing one and use the JS API for = the >media layer. I've lost count on the number of times this has already >been said, lets move on. > >> My comment on "SIP over websocket is an overkill" is purely based on >(on-wire) protocol mechanism and it is nothing do with API design. >Irrespective of whether "SIP over websocket" is implemented in browser >or in JavaScript or in other language, it is not the best protocol >design. Hope this clarifies my stance. >> > >Nobody is advocating for SIP over WebSocket nor XMPP over PBTL (pigeon >based transport layer), what some of us want is to let it up to the >developers. > >-- >Sa=FAl Ibarra Corretg=E9 >AG Projects > > From saul@ag-projects.com Wed Oct 19 15:14: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 18A7111E80B0 for ; Wed, 19 Oct 2011 15:14:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.688 X-Spam-Level: X-Spam-Status: No, score=-1.688 tagged_above=-999 required=5 tests=[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 vC+PNEhz+r6J for ; Wed, 19 Oct 2011 15:14:10 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 97A5611E8098 for ; Wed, 19 Oct 2011 15:14:10 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id DC634B01A2; Thu, 20 Oct 2011 00:14:09 +0200 (CEST) Received: from [192.168.99.36] (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id 6DF55B017D; Thu, 20 Oct 2011 00:13:56 +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: <2E239D6FCD033C4BAF15F386A979BF51159AA7@sonusinmail02.sonusnet.com> Date: Thu, 20 Oct 2011 00:13:55 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3C2140FA-B177-4D62-B778-5297DCC30A10@ag-projects.com> References: <2E239D6FCD033C4BAF15F386A979BF511599F9@sonusinmail02.sonusnet.com><4E9E5D8D.6030707@alvestrand.no><2E239D6FCD033C4BAF15F386A979BF51159A20@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF51159AA6@sonusinmail02.sonusnet.com> <23CC8E74-8C17-4484-998B-2A7B66358B81@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF51159AA7@sonusinmail02.sonusnet.com> To: "Ravindran Parthasarathi" X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Comment on draft-ietf-rtcweb-overview-02 (Browser RTC trapezoid) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 22:14:11 -0000 Hi, On Oct 20, 2011, at 12:04 AM, Ravindran Parthasarathi wrote: > Saul, >=20 > I have already mentioned in the mailing alias that *Please don't = delete the existing mail* because we often miss the original intent of = the mail and goes in the circular discussion. >=20 I quoted all your email and *properly* replied inline, instead of = top-posting. The fact that your email client is not good enough it's not = my fault. > My original reply was intended only to answer Inaki query on how I = come to the conclusion that "I'm not favor Inaki solution of SIP over = websocket because it is overkill for signaling protocol".=20 >=20 I know how to read. I'm just saying that no one wants SIP over WebSocket = as a "default protocol". It's up to developers, like Inaki, Jose in this = particular case, to decide what to use. They chose SIP over WS, you may = use something else. -- Sa=FAl Ibarra Corretg=E9 AG Projects From pravindran@sonusnet.com Wed Oct 19 15:33: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 3D28F11E80B0 for ; Wed, 19 Oct 2011 15:33:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.645 X-Spam-Level: X-Spam-Status: No, score=-2.645 tagged_above=-999 required=5 tests=[AWL=-0.346, 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 Nt8dVuTEAxMg for ; Wed, 19 Oct 2011 15:33:30 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id B4BB111E808A for ; Wed, 19 Oct 2011 15:33:30 -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 p9JMY1VR031101; Wed, 19 Oct 2011 18:34:01 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail06.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 19 Oct 2011 18:33:27 -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: Thu, 20 Oct 2011 04:03:20 +0530 Message-ID: <2E239D6FCD033C4BAF15F386A979BF51159AA8@sonusinmail02.sonusnet.com> In-Reply-To: <3C2140FA-B177-4D62-B778-5297DCC30A10@ag-projects.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] Comment on draft-ietf-rtcweb-overview-02 (Browser RTC trapezoid) Thread-Index: AcyOrG9mRI3/s77xQ2ibO9k250+sVQAAcKUA References: <2E239D6FCD033C4BAF15F386A979BF511599F9@sonusinmail02.sonusnet.com><4E9E5D8D.6030707@alvestrand.no><2E239D6FCD033C4BAF15F386A979BF51159A20@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF51159AA6@sonusinmail02.sonusnet.com> <23CC8E74-8C17-4484-998B-2A7B66358B81@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF51159AA7@sonusinmail02.sonusnet.com> <3C2140FA-B177-4D62-B778-5297DCC30A10@ag-projects.com> From: "Ravindran Parthasarathi" To: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= X-OriginalArrivalTime: 19 Oct 2011 22:33:27.0236 (UTC) FILETIME=[1EB2D840:01CC8EAF] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Comment on draft-ietf-rtcweb-overview-02 (Browser RTC trapezoid) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 22:33:31 -0000 Saul, I guess that you didn't get my point. In case you remove the earlier = mail thread and reply inline to my last reply, the context of my reply = is lost, we start discuss something which is not relevant to the = original mail.=20 BTW, Please note that it is nothing to do with my e-mail client or its = settings. Thanks Partha =20 >-----Original Message----- >From: Sa=FAl Ibarra Corretg=E9 [mailto:saul@ag-projects.com] >Sent: Thursday, October 20, 2011 3:44 AM >To: Ravindran Parthasarathi >Cc: I=F1aki Baz Castillo; rtcweb@ietf.org >Subject: Re: [rtcweb] Comment on draft-ietf-rtcweb-overview-02 (Browser >RTC trapezoid) > >Hi, > >On Oct 20, 2011, at 12:04 AM, Ravindran Parthasarathi wrote: > >> Saul, >> >> I have already mentioned in the mailing alias that *Please don't >delete the existing mail* because we often miss the original intent of >the mail and goes in the circular discussion. >> > >I quoted all your email and *properly* replied inline, instead of top- >posting. The fact that your email client is not good enough it's not my >fault. > >> My original reply was intended only to answer Inaki query on how I >come to the conclusion that "I'm not favor Inaki solution of SIP over >websocket because it is overkill for signaling protocol". >> > >I know how to read. I'm just saying that no one wants SIP over = WebSocket >as a "default protocol". It's up to developers, like Inaki, Jose in = this >particular case, to decide what to use. They chose SIP over WS, you may >use something else. > > >-- >Sa=FAl Ibarra Corretg=E9 >AG Projects > > From SRS0=DlSx9b=5C=sipsorcery.com=aaron@eigbox.net Wed Oct 19 15:38: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 5C46521F8A55 for ; Wed, 19 Oct 2011 15:38:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fWParW-xai9l for ; Wed, 19 Oct 2011 15:38:27 -0700 (PDT) Received: from bosmailout07.eigbox.net (bosmailout07.eigbox.net [66.96.188.7]) by ietfa.amsl.com (Postfix) with ESMTP id C961421F8A4E for ; Wed, 19 Oct 2011 15:38:27 -0700 (PDT) Received: from bosmailscan05.eigbox.net ([10.20.15.5]) by bosmailout07.eigbox.net with esmtp (Exim) id 1RGemI-0007p1-Nz for rtcweb@ietf.org; Wed, 19 Oct 2011 18:38:26 -0400 Received: from bosimpout02.eigbox.net ([10.20.55.2]) by bosmailscan05.eigbox.net with esmtp (Exim) id 1RGemI-0002GR-IZ for rtcweb@ietf.org; Wed, 19 Oct 2011 18:38:26 -0400 Received: from bosauthsmtp11.eigbox.net ([10.20.18.11]) by bosimpout02.eigbox.net with NO UCE id mmeS1h0030EKspE01meS3J; Wed, 19 Oct 2011 18:38:26 -0400 X-EN-OrigOutIP: 10.20.18.11 X-EN-IMPSID: mmeS1h0030EKspE01meS3J Received: from cpe-124-179-251-124.lns3.dav.bigpond.net.au ([124.179.251.124] helo=AaronPC) by bosauthsmtp11.eigbox.net with esmtpa (Exim) id 1RGemG-0001ks-MW for rtcweb@ietf.org; Wed, 19 Oct 2011 18:38:26 -0400 From: "Aaron Clauson" To: References: <9C8CA816-65FB-41A0-999C-4C43128CAAB4@danyork.org> In-Reply-To: <9C8CA816-65FB-41A0-999C-4C43128CAAB4@danyork.org> Date: Thu, 20 Oct 2011 09:38:19 +1100 Message-ID: <020001cc8eaf$d08cc850$71a658f0$@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: AcyOYd0kC0dmKnhXQAyGmtiQGZIJWAASxeQQ Content-Language: en-au X-EN-UserInfo: 915df896000ea0661f52ada7de781755:376581c79ab009618cc3d679a775619e X-EN-AuthUser: aaron@sipsorcery.com Sender: "Aaron Clauson" X-EN-OrigIP: 124.179.251.124 X-EN-OrigHost: cpe-124-179-251-124.lns3.dav.bigpond.net.au Subject: Re: [rtcweb] A plea for simplicity, marketability - and... who are we designing RTCWEB for? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 22:40:33 -0000 >-----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Dan York > > > > The question is - will the RTCWEB/WEBRTC API/protocol/whatever be so simple and easy that web developers will choose to use it over > Flash/Phono/Twilio/Java/whatever to add RTC functions to their web apps? > > > > If the answer is no, what are spending all this time for? I thought the point of RTCWeb was so I'd be able to set up a voice call between my browser and my VoIP Phone :). Something I can't do now with Flash/Phono/Twilio/javascript-libraries et al at least not without one or more media and signalling proxies in between. I originally thought RTCWeb was going to be the bridge between the VoIP and the Web Worlds but I must say I'm now a bit lost as to what it's about with all the different ideas flying around at lightspeed. My own very very humble opinion is that RTCWeb should incorporate RTP (over UDP & TCP), a codec plugin mechanism and mircophone/speaker/camera integration and bake it all into the browser. Everything else (signalling, SDP, easy to use APIs etc. etc.) will be sorted out by smart devs coming up with javascript libraries. Aaron From pravindran@sonusnet.com Wed Oct 19 16: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 4736B21F8AB8 for ; Wed, 19 Oct 2011 16:31:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.783 X-Spam-Level: X-Spam-Status: No, score=-2.783 tagged_above=-999 required=5 tests=[AWL=-0.184, 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 xs068Fwd4QYL for ; Wed, 19 Oct 2011 16:31:49 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 85B9C21F8AAC for ; Wed, 19 Oct 2011 16:31:49 -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 p9JNWKYc004325; Wed, 19 Oct 2011 19:32:20 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail06.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 19 Oct 2011 19:31: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: Thu, 20 Oct 2011 05:01:39 +0530 Message-ID: <2E239D6FCD033C4BAF15F386A979BF51159AAA@sonusinmail02.sonusnet.com> In-Reply-To: <8EBB58C3-E135-4FB4-80F2-607E82C7BA7A@acmepacket.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] Gateway need and usecase [was RE: Review request forRTCWeb standard signaling protocol] Thread-Index: AQHMjh2MKAHKdWoRPEeKqc2wy+gDJ5WEQmcg References: <2E239D6FCD033C4BAF15F386A979BF510F1367@sonusinmail02.sonusnet.com><4E8AC222.4050308@alvestrand.no><2E239D6FCD033C4BAF15F386A979BF510F14CE@sonusinmail02.sonusnet.com><2E239D6FCD033C4BAF15F386A979BF510F14FD@sonusinmail02.sonusnet.com><393F1888-F834-4DAE-B6B1-1C5D35EE3292@phonefromhere.com><2E239D6FCD033C4BAF15F386A979BF510F152B@sonusinmail02.sonusnet.com><2E239D6FCD033C4BAF15F386A979BF510F1532@sonusinmail02.sonusnet.com><2E239D6FCD033C4BAF15F386A979BF511598EE@sonusinmail02.sonusnet.com><665A16AB-AAD8-42B3-AC17-7E629EA2DE35@phonefromhere.com><2E239D6FCD033C4BAF15F386A979BF5115992E@sonusinmail02.sonusnet.com><0950F0E1-6E4B-407F-9563- 654AFE7 9 F64B@ag-pr oj ects.com><2E239D6FCD033C4BAF15F386A979BF51159994@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF51159A00@sonusinmail02.sonusnet.com> <8EBB58C3-E135-4FB4-80F2-607E82C7BA7A@acmepacket.com> From: "Ravindran Parthasarathi" To: "Hadriel Kaplan" X-OriginalArrivalTime: 19 Oct 2011 23:31:46.0332 (UTC) FILETIME=[445285C0:01CC8EB7] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Gateway need and usecase [was RE: Review request forRTCWeb standard 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: Wed, 19 Oct 2011 23:31:51 -0000 Hadriel, Please read inline. Thanks Partha >-----Original Message----- >From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] >Sent: Wednesday, October 19, 2011 10:41 AM >To: Ravindran Parthasarathi >Cc: I=F1aki Baz Castillo; >Subject: Re: [rtcweb] Gateway need and usecase [was RE: Review request >forRTCWeb standard signaling protocol] > >Hi Partha, >comments inline > >On Oct 18, 2011, at 11:32 PM, Ravindran Parthasarathi wrote: > >> It is not that I'm interested in RTCWeb gateway but it is the best >known solution currently. Please look into my earlier mail thread >(http://www.ietf.org/mail-archive/web/rtcweb/current/msg01058.html) for >asking not to have gateways and the issues involved in developing >gateways. But in case two protocols like SIP, websocket are started >using for the signaling within the same session, the interop is = possible >only with gateways or tunneling wherein I prefer gateway. > >I am confused by your statements. In the email thread you cited above, >and in your draft, you imply that websocket is a signaling protocol or >browser-to-browser protocol. It isn't. For all intents and purposes = of >this WG, it's a transport. That's all. It's like TCP, UDP or SCTP. I'm not saying websocket as browser-to-browser protocol. In = browser-web server-browser topology, websocket helps to create two-way = communication between browsers through web server. So, SDP shall be = carried between two browsers using two websocket (browser1 to web = server, browser2 to web server) using ROAP sort of protocol.=20 In analogy, SIP protocol acts as a transport mechanism for passing SDP = between two user agents (UAC & UAS) through proxy/B2BUA. Please note = that browser has to no need of maintaining its own identity of the user. = You may debate than the point of discussion is media control protocol = and not signaling protocol. If so, we will discuss in detail to correct = the terminology for common understanding. >And it goes between the browser and a web server, not between browsers. Yes >What's put onto that transport socket is up to the JavaScript and web >server code. > It is the open item discussion between "low level API" vs. = "ROAP API" vs. any other high level API >I also don't understand what you mean by "interop is only possible with >gateways or tunneling". I don't see how tunneling anything solves >interop of anything. =20 Here, the topology is browser--web server & SIP-proxy GW----UA. = Browser shall tunnel SIP messages over websocket by which web server & = SIP-proxy GW entity shall transport the same SIP message to the UA = without any gateway functionality. But for gateways, yes if everything spoke a >standard protocol, making gateways would be easier - but it doesn't >require the RTCWeb<->browser path to speak that signaling protocol; it >only requires the web-server to speak it. In fact it might not even >require that - it might be possible to have a gateway be a JavaScript >client too. > Let us take the topology of browser---web server & SIP UA = GW----UA, browser & web server communication is using some signaling = protocol whereas UA to SIP-UA GW communicates using SIP. Here, I'm = interested in ROAP sort of protocol to be standardized by which gateway = building is easier. For this requirement, browser has to incorporate = ROAP sort of protocol and not custom build signaling. > >> I agree that the primary focus of this WG is to browser-to-browser >without federation in mind. But the power of collaboration using RTCWeb >will be realized in case federation protocol are used. For example, >search for the keyword in Google from the Android browser, go to the >website, click in the website leads to the call in the call center of >the website company without involving any PSTN network. Here, website = of >the company acts as a service provider for the company and reduce the >PSTN/SIP trunk cost drastically. > >So? How does this require a standard signaling protocol on the = browser? > >-hadriel From derhoermi@gmx.net Wed Oct 19 16:53: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 BB4F921F845A for ; Wed, 19 Oct 2011 16:53:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id teK4ZDntae4L for ; Wed, 19 Oct 2011 16:53:58 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id AA0DD21F844D for ; Wed, 19 Oct 2011 16:53:57 -0700 (PDT) Received: (qmail invoked by alias); 19 Oct 2011 23:53:55 -0000 Received: from dslb-094-223-193-217.pools.arcor-ip.net (EHLO HIVE) [94.223.193.217] by mail.gmx.net (mp052) with SMTP; 20 Oct 2011 01:53:55 +0200 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX1++bvNbTii+KjuiNild4gUSgSyQpdgcLt8qbAK32N DHyKnf4gLYct/O From: Bjoern Hoehrmann To: "Ravindran Parthasarathi" Date: Thu, 20 Oct 2011 01:53:56 +0200 Message-ID: <6klu975sd3ufnvcatafpl25ggco7muilac@hive.bjoern.hoehrmann.de> References: <2E239D6FCD033C4BAF15F386A979BF51159A20@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF51159AA6@sonusinmail02.sonusnet.com> <23CC8E74-8C17-4484-998B-2A7B66358B81@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF51159AA7@sonusinmail02.sonusnet.com> <3C2140FA-B177-4D62-B778-5297DCC30A10@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF51159AA8@sonusinmail02.sonusnet.com> In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF51159AA8@sonusinmail02.sonusnet.com> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Comment on draft-ietf-rtcweb-overview-02 (Browser RTC trapezoid) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 23:53:58 -0000 * Ravindran Parthasarathi wrote: >I guess that you didn't get my point. In case you remove the earlier >mail thread and reply inline to my last reply, the context of my reply >is lost, we start discuss something which is not relevant to the >original mail. > >BTW, Please note that it is nothing to do with my e-mail client or its >settings. According to the Netiquette Guidelines in RFC 1855 you should quote just enough of the message to establish context but not the whole message. It also says that follow-up content should exceed what is quoted, and that the quoted text should appear at the top, not bottom, of your response, and it says lines should not exceed a low number of characters. You are violating all these guidelines. The solution to your thread problem is to use a mail client that lets you read the parent of a message easily. A common solution is to let the client render the whole thread as tree that you can navigate. I do not recall ever seeing someone who used the correct posting style for a couple of years to suddenly switch to a very different posting style; I doubt there is a point in asking anybody to. -- Bjrn Hhrmann mailto:bjoern@hoehrmann.de http://bjoern.hoehrmann.de Am Badedeich 7 Telefon: +49(0)160/4415681 http://www.bjoernsworld.de 25899 Dagebll PGP Pub. KeyID: 0xA4357E78 http://www.websitedev.de/ From pravindran@sonusnet.com Wed Oct 19 17:23: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 4FE3A11E80BB for ; Wed, 19 Oct 2011 17:23:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.776 X-Spam-Level: X-Spam-Status: No, score=-2.776 tagged_above=-999 required=5 tests=[AWL=-0.177, 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 E46h74MgJzcl for ; Wed, 19 Oct 2011 17:23:21 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 89DCC11E80AF for ; Wed, 19 Oct 2011 17:23:21 -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 p9K0Nsxr004272; Wed, 19 Oct 2011 20:23:54 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail04.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 19 Oct 2011 20:23:19 -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: Thu, 20 Oct 2011 05:53:12 +0530 Message-ID: <2E239D6FCD033C4BAF15F386A979BF51159AAB@sonusinmail02.sonusnet.com> In-Reply-To: <6klu975sd3ufnvcatafpl25ggco7muilac@hive.bjoern.hoehrmann.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] Comment on draft-ietf-rtcweb-overview-02 (Browser RTC trapezoid) Thread-Index: AcyOumAE9nxZdE0dTkCE0uSNW4qa5QAA+qFg References: <2E239D6FCD033C4BAF15F386A979BF51159A20@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF51159AA6@sonusinmail02.sonusnet.com> <23CC8E74-8C17-4484-998B-2A7B66358B81@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF51159AA7@sonusinmail02.sonusnet.com> <3C2140FA-B177-4D62-B778-5297DCC30A10@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF51159AA8@sonusinmail02.sonusnet.com> <6klu975sd3ufnvcatafpl25ggco7muilac@hive.bjoern.hoehrmann.de> From: "Ravindran Parthasarathi" To: "Bjoern Hoehrmann" X-OriginalArrivalTime: 20 Oct 2011 00:23:19.0511 (UTC) FILETIME=[78002E70:01CC8EBE] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Comment on draft-ietf-rtcweb-overview-02 (Browser RTC trapezoid) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 00:23:22 -0000 The reported issue is that "the message is not complete enough to = establish context" and also, the reply is irrelevant to the original = mail discussion. Please see the following mail thread for details: http://www.ietf.org/mail-archive/web/rtcweb/current/msg02129.html=20 http://www.ietf.org/mail-archive/web/rtcweb/current/msg02130.html http://www.ietf.org/mail-archive/web/rtcweb/current/msg02131.html Thanks Partha >-----Original Message----- >From: Bjoern Hoehrmann [mailto:derhoermi@gmx.net] >Sent: Thursday, October 20, 2011 5:24 AM >To: Ravindran Parthasarathi >Cc: rtcweb@ietf.org >Subject: Re: [rtcweb] Comment on draft-ietf-rtcweb-overview-02 (Browser >RTC trapezoid) > >* Ravindran Parthasarathi wrote: >>I guess that you didn't get my point. In case you remove the earlier >>mail thread and reply inline to my last reply, the context of my reply >>is lost, we start discuss something which is not relevant to the >>original mail. >> >>BTW, Please note that it is nothing to do with my e-mail client or its >>settings. > >According to the Netiquette Guidelines in RFC 1855 you should quote = just >enough of the message to establish context but not the whole message. = It >also says that follow-up content should exceed what is quoted, and that >the quoted text should appear at the top, not bottom, of your response, >and it says lines should not exceed a low number of characters. You are >violating all these guidelines. The solution to your thread problem is >to use a mail client that lets you read the parent of a message easily. >A common solution is to let the client render the whole thread as tree >that you can navigate. I do not recall ever seeing someone who used the >correct posting style for a couple of years to suddenly switch to a = very >different posting style; I doubt there is a point in asking anybody to. >-- >Bj=F6rn H=F6hrmann =B7 mailto:bjoern@hoehrmann.de =B7 = http://bjoern.hoehrmann.de >Am Badedeich 7 =B7 Telefon: +49(0)160/4415681 =B7 = http://www.bjoernsworld.de >25899 Dageb=FCll =B7 PGP Pub. KeyID: 0xA4357E78 =B7 = http://www.websitedev.de/ From fluffy@cisco.com Wed Oct 19 17:38: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 5001911E80C4 for ; Wed, 19 Oct 2011 17:38:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.377 X-Spam-Level: X-Spam-Status: No, score=-105.377 tagged_above=-999 required=5 tests=[AWL=1.178, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, 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 TZfe1LX8gP8d for ; Wed, 19 Oct 2011 17:38:41 -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 6E08911E80C2 for ; Wed, 19 Oct 2011 17:38:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=583; q=dns/txt; s=iport; t=1319071121; x=1320280721; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=T3BNAu3gQCq+SQcWP1/iT9gGmr7HCof+k+z5jaxDcHk=; b=fvbVtwWglckyiWsS34UVRnUx2fsZrrrM4wlOMZYNW5EL0PpkdXTADWB9 sttA7prmvbCfzeH4gVfh6v3G7vtWXZJ/6T9hwQdNNZnZM10XLsVP8LYna dwPR5iAXCoHphUu6me5ENnA/St1bP230Q4cA8yhqK5ZbUZsnUEEer9JSY 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: At0GAHBsn06rRDoG/2dsb2JhbABEJqhcgQWBbgEBAQECARIBJz8QC0ZXBjWHXpgCAZ5OhzphBIgCi3yFKoxM X-IronPort-AV: E=Sophos;i="4.69,375,1315180800"; d="scan'208";a="8616757" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 20 Oct 2011 00:38:41 +0000 Received: from [192.168.4.106] (sjc-fluffy-8914.cisco.com [10.20.249.165]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p9K0c5PB029329; Thu, 20 Oct 2011 00:38:40 GMT Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A058522341F4A4A@ESESSCMS0356.eemea.ericsson.se> Date: Wed, 19 Oct 2011 15:22:57 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <15B0E3AD-3086-499A-8E79-7AE58B3376C4@cisco.com> <7F2072F1E0DE894DA4B517B93C6A058522341F4A4A@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1251.1) Cc: Jonathan Rosenberg , "rtcweb@ietf.org" Subject: Re: [rtcweb] SDP Offer/Answer draft-jennings-rtcweb-signaling - Comment on section 5.3.1.2 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 00:38:42 -0000 On Oct 19, 2011, at 6:30 , Christer Holmberg wrote: >=20 > Hi, >=20 > Section 5.3.1.2 lists cases where an answerer can receive an OFFER. >=20 > I guess the following case is also valid, and shall not be rejected. >=20 > - A retransmit of a request to change media parameters (known = offererSessoinId, known answererSessionId, known seq value). >=20 > Regards, >=20 > Christer yes - we should make it clearer but this is case 2 where we have known = offererSessoinId, known answererSessionId and since we have seen the seq = before, it is a retransmission=20 From fluffy@cisco.com Wed Oct 19 17: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 7B7B911E80BB for ; Wed, 19 Oct 2011 17:40:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.595 X-Spam-Level: X-Spam-Status: No, score=-105.595 tagged_above=-999 required=5 tests=[AWL=1.004, 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 ZD+7IuoWrTsk for ; Wed, 19 Oct 2011 17:40:22 -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 D2FEE11E80AF for ; Wed, 19 Oct 2011 17:40:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=3004; q=dns/txt; s=iport; t=1319071222; x=1320280822; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=Cgihryx7G0BZAUkLMpe0GRbmmP7PXmVqldyZY6mxhpQ=; b=cLi2zoK+eL64mMMzaX3wl/WbSU7kwI+kGkrdIBoUcrpS98PjNMQZTPeD 8hAVws6dphlYZgtOqkdYEATOe7vo3q6J4JpPBhROP3QYjfMzhOX2p4E8b nuTLh54iwR2FS40rIToL/n269wV2SCu2RfSmxNUVRxb8K6XYi4mi11W88 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAE9tn06rRDoJ/2dsb2JhbABEqQKBBYFuAQEBAQIBEgEnPxALRlcGNYdel3sBnk+HOmEEiAKLfIUqjEw X-IronPort-AV: E=Sophos;i="4.69,375,1315180800"; d="scan'208";a="9017815" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 20 Oct 2011 00:40:22 +0000 Received: from [192.168.4.106] (sjc-fluffy-8914.cisco.com [10.20.249.165]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p9K0eM4N030747; Thu, 20 Oct 2011 00:40:22 GMT Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A058522341F4B3E@ESESSCMS0356.eemea.ericsson.se> Date: Wed, 19 Oct 2011 18:40:24 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <15B0E3AD-3086-499A-8E79-7AE58B3376C4@cisco.com> <5D0FFCB8-8059-4C54-843B-46F1EC720B10@cisco.com> <7F2072F1E0DE894DA4B517B93C6A058522341F4B3E@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1251.1) Cc: Jonathan Rosenberg , "rtcweb@ietf.org" Subject: Re: [rtcweb] Forking - Re: SDP Offer/Answer draft-jennings-rtcweb-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: Thu, 20 Oct 2011 00:40:23 -0000 inline but yes, your understanding is what I was thinking=20 On Oct 19, 2011, at 7:04 , Christer Holmberg wrote: >=20 > Hi,=20 >=20 >>> Did we decide to explicitly not support forking which=20 >>> generates multiple final answers? If this is not the case,=20 >>> how is this supposed to be implemented using your model? >>=20 >> I think that it is critical that we support what is needed to=20 >> make a call that goes to 1-800-go-fedex work. So consider the=20 >> following use case: A browser calls through a signaling GW to=20 >> a sip that forks the call to an SIP to PSTN gateway and also=20 >> to a voicemail server. The PSTN gateway generates an 180 with=20 >> ringback tone but the SIP call is eventually answered by the=20 >> voicemail server that sends a 200.=20 >>=20 >> So 3264 supports forking by an single offer may result in say=20 >> two answers. In the case above, an single offer resulted in=20 >> two different answers. Roap would support this type of=20 >> transaction by allowing two answers to be received. There are=20 >> two ways this can happen - one is with different=20 >> answererSessionId in the the answers. Another is the use of=20 >> the More-coming flag. We think with these, one can support=20 >> the range of what 3264 allows for offer/ answer.=20 >=20 > - Assume my browser is communicating with a SIP gatway, and I use some = non-SIP signalling protocol to transport ROAP messages between the = browser and the gateway. >=20 > - The gateway maps ROAP into SIP, and a proxy forks the INVITE to = multiple SIP UAs. >=20 > - When the gateway receives reliable 18x provisional responses, on = different early SIP dialogs, it forwards them as final ANSWERs towards = the browser. >=20 > - When the gateway receives the 200 OK, all other early dialogs are = terminated. Now, from a pure ROAP perspective, the only way to inform = the browser about that would be for the gateway to send new OFFERs for = every terminated early SIP dialog, and e.g. indicate port=3D0. >=20 > Correct? yes - I think that port=3D0 is the wrong way to indicate these have = ended as it is confusing with hold and ending a particular media stream = vs ending an offer/answer session. So this makes the argument for a = better way to clean up state on the ROAP side.=20 >=20 > Now, instead of mapping the 18x provisional responses to final = ANSWERs, the gateway could of course map them to non-final ANSWERs, and = then later send final ANSWERs with an error code. But, the problem then = is that the browser is not able to (or, at least that's my assumption - = see separate e-mail) send a new OFFER until it has received a final = ANSWER. Yes - we have the same understanding of how with would work. I imagine = this would be the path most things takes. I don't see uses case where = needing to send a new OFFER before receiving the final ANSWER would be a = problem.=20 >=20 > Regards, >=20 > Christer >=20 >=20 From fluffy@cisco.com Wed Oct 19 17:41: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 2505911E80BF for ; Wed, 19 Oct 2011 17:41:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.739 X-Spam-Level: X-Spam-Status: No, score=-105.739 tagged_above=-999 required=5 tests=[AWL=0.860, 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 4ZqePq1J07IH for ; Wed, 19 Oct 2011 17:41: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 7256311E80AF for ; Wed, 19 Oct 2011 17:41:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=2880; q=dns/txt; s=iport; t=1319071288; x=1320280888; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=JG6/ZrJkko6rFJ43REpqFyWaPeGuS7Ha4gJUo7oJ9Zs=; b=G9OkppjsnweWXprYiAhflwORzDgL782oufiNp9RKHzPuLrRLj/6t5QnD FTuWggJWqUAOlh2yxgFqS3UsR1ijlEBQaOtELmSStf4TcijKBY6DnQErg QQ5tRvZTtEJ0O+XpqgCz0Cu/TT8bg3rvsrCdgmM5iYbl5Z9UOySosNGwB 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAJxtn06rRDoJ/2dsb2JhbABEqQKBBYFuAQEBAQEBAQEBAQ8BWwYFDAQLEQQBASQEBycfCQgGEyKHXgiXcwGeT4c6YQSIAot8hSqMTA X-IronPort-AV: E=Sophos;i="4.69,375,1315180800"; d="scan'208";a="9004147" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 20 Oct 2011 00:41:28 +0000 Received: from [192.168.4.106] (sjc-fluffy-8914.cisco.com [10.20.249.165]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p9K0fRJt031352; Thu, 20 Oct 2011 00:41:27 GMT Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=windows-1252 From: Cullen Jennings In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A058522341F4AB9@ESESSCMS0356.eemea.ericsson.se> Date: Wed, 19 Oct 2011 18:41:30 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <15B0E3AD-3086-499A-8E79-7AE58B3376C4@cisco.com> <7F2072F1E0DE894DA4B517B93C6A058522341F4AB9@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1251.1) Cc: Jonathan Rosenberg , "rtcweb@ietf.org" Subject: Re: [rtcweb] SDP Offer/Answer draft-jennings-rtcweb-signaling - More-coming and final answer (Section 5.2.3) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 00:41:29 -0000 all good questions and I should clarify in the draft =85 inline On Oct 19, 2011, at 7:06 , Christer Holmberg wrote: >=20 > Hi, >=20 > A couple of questions regarding the usage of the more-coming flag: >=20 > Q1. If one sends an ANSWER with the more-coming flag set to 'true', is = it allowed to later send *additional* ANSWER(s) with the flag set to = 'true' (before sending the final ANSWER)? Yes=20 >=20 > Q2. Are there restrictions when it comes to changing information in a = non-final answer and a final answer? Or, can the final answer be = completely different from previously sent non-final ANSWERS? In "legacy" = O/A there are restrictions. Any answer has to be a valid answer for the offer but other than that, = no restrictions, so the final answer can change everything from an = earlier one.=20 >=20 > Q3. Must the answerer wait for OK for a non-final ANSWER before = sending a new ANSWER (non-final or final)? hmm - not sure :-) I think the answer to needs to be yes but we should = think about this and work through the design choices.=20 >=20 > Q4. If the answer to Q3 is "no", how does the answerer know to which = ANSWER an OK message applies? AFAIK, the seq/sessionId values are = identical for all ANSWERs associated with a specific OFFER. >=20 > Q5. The text says, that while the OFFER is "open", ie a final ANSWER = has not been sent, the answerer is not allowed to send an OFFER. I = assume that also applies to the offerer, ie it is not allowed to send a = new OFFER until it has received a final ANSWER - even if it has received = one or more non-final ANSWERs. Maybe it's obvious, but I think it would = be good to explictily add some text about that (if my assumption is = correct, that is :). yes - agree.=20 =20 >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 >=20 >=20 >> -----Original Message----- >> From: rtcweb-bounces@ietf.org=20 >> [mailto:rtcweb-bounces@ietf.org] On Behalf Of Cullen Jennings >> Sent: 15. lokakuuta 2011 6:09 >> To: rtcweb@ietf.org; public-webrtc@w3.org >> Cc: Jonathan Rosenberg >> Subject: [rtcweb] SDP Offer/Answer draft-jennings-rtcweb-signaling >>=20 >>=20 >> Jonathan and I submitted a new draft on setting up media=20 >> based on the SDP Offer/Answer model. The ASCII flows are a=20 >> bit hard to read so until I update them, I recommend reading=20 >> the PDF version at=20 >>=20 >> http://tools.ietf.org/pdf/draft-jennings-rtcweb-signaling-00.pdf >>=20 >> Clearly the draft is an early stage but we plan to revise it=20 >> before the deadline for the IETF 82. Love to get input -=20 >> particularly on if this looks like generally the right=20 >> direction to go.=20 >>=20 >>=20 >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb From fluffy@cisco.com Wed Oct 19 17:43: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 88D7511E80B3 for ; Wed, 19 Oct 2011 17:43:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.846 X-Spam-Level: X-Spam-Status: No, score=-105.846 tagged_above=-999 required=5 tests=[AWL=0.753, 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 f6YCvra98ZTz for ; Wed, 19 Oct 2011 17:43: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 DE19411E80AF for ; Wed, 19 Oct 2011 17:43:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=1641; q=dns/txt; s=iport; t=1319071420; x=1320281020; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=Xm3KY4vh1REWPhIxTyTinFODFdnxFCB706w9ilqEQ2w=; b=MlBKwqvOb7Ea0JD5bdPeum7DcJgEIH4CrKFvNsKYSFkmNAYLdAmT6mPK FHCpYUPMEIGGz8uGRDKT4fM4Kd/bDBhwsfceocYRsMnd2KFq0Qwy0aZiP tSz/iBijkHaAHJapAPWtMQvxb4XIvyruhlLIRZ6JlemtlCEIwQboaGzyD k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAH9un06rRDoH/2dsb2JhbABEqQKBBYFuAQEBAQIBEgFmEAtGVwY1h16XfAGeT4c6YQSIAot8hSqMTA X-IronPort-AV: E=Sophos;i="4.69,375,1315180800"; d="scan'208";a="9018494" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 20 Oct 2011 00:43:40 +0000 Received: from [192.168.4.106] (sjc-fluffy-8914.cisco.com [10.20.249.165]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p9K0heKP007374; Thu, 20 Oct 2011 00:43:40 GMT Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Cullen Jennings In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A058522341F4A36@ESESSCMS0356.eemea.ericsson.se> Date: Wed, 19 Oct 2011 18:43:39 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <2F4D4B67-7AE0-4C8F-B390-B043FBA82B76@cisco.com> References: <15B0E3AD-3086-499A-8E79-7AE58B3376C4@cisco.com> <2E239D6FCD033C4BAF15F386A979BF51159957@sonusinmail02.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A058522341F416A@ESESSCMS0356.eemea.ericsson.se> <10704DBF-9400-42BA-B9C5-209C338F042E@cisco.com> <7F2072F1E0DE894DA4B517B93C6A058522341F4A36@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1251.1) Cc: Jonathan Rosenberg , "rtcweb@ietf.org" , "public-webrtc@w3.org" Subject: Re: [rtcweb] SDP Offer/Answer draft-jennings-rtcweb-signaling - Scope X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 00:43:42 -0000 On Oct 19, 2011, at 6:21 , Christer Holmberg wrote: >=20 > Hi Cullen,=20 >=20 >>> So, while I support and offer/answer based approach, I=20 >>> think we need to get a clearer understanding of the scope. >>=20 >> My view is this is draft is a set of semantics and syntax=20 >> that operates over an abstract transport protocol. In most=20 >> cases the transport with be web sockets or HTTP based. If=20 >> this looks like a reasonable protocol, it would be likely to=20 >> influence the W3C API. >=20 > As the ROAP state machine is located in the browser, doesn't that = already mean that ROAP must to be supported by the API? This whole "is this an API or Protocol discussion" leaves me sort of = saying "Yes" but I'm not sure it matters much. Any API can be turned = into a protocol using a RPC approach. Most protocol lead to a fairly = obvious API to describe that protocol. =46rom a category theory point of = view, I consider an API the dual of a protocol. I know opinions differ = but in general, I view API's and protocols as surprisingly similar.=20 ROAP is a protocol that could be used to things like a gateway that = converted from ROAP to SIP. However, it is also a protocol that is = designed to work well with an API like one that might be used by W3C for = WebRTC. If we go down this ROAP path, I would expect that the the JSON = object that gets represented by the string in ROAP would be used to pass = in the WebRTC API. The two are closely related - and that is = intentional.=20 I'm trying to make a protocol that closely fits with what the web = browsers want to implement.=20 From fluffy@cisco.com Wed Oct 19 17:43: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 4148B11E80C2 for ; Wed, 19 Oct 2011 17:43:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.78 X-Spam-Level: X-Spam-Status: No, score=-105.78 tagged_above=-999 required=5 tests=[AWL=0.519, 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 rvhJjaEFjd3B for ; Wed, 19 Oct 2011 17:43:52 -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 C5C1C11E80BF for ; Wed, 19 Oct 2011 17:43:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=2319; q=dns/txt; s=iport; t=1319071432; x=1320281032; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=4jd75WBc2FENUSIDZPBz4M+5lCF+mW6wbuelhRK+gWI=; b=H0SATDv5GbjEQvjRwYOY1jPr0fY2mondb8u5MRiCcbFXn21j9NYhSwTz 1VC3nrcdsqWUEhJQdBZexKSkpgWlSaSfwLy+MiO5UMxZ5bA4TCdIdSZkf 7wvLMdM+kOwmwgsIZMSKPgyalAddNK8Xs9JdhYrYa2iXC3oU1yyoXz4wR k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAJxtn06rRDoH/2dsb2JhbABEqQKBBYFuAQEBAQIBEgFmBQsLOwtXBhMih16XewGeT4c6YQSIAot8hSqMTA X-IronPort-AV: E=Sophos;i="4.69,375,1315180800"; d="scan'208";a="9004606" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 20 Oct 2011 00:43:52 +0000 Received: from [192.168.4.106] (sjc-fluffy-8914.cisco.com [10.20.249.165]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p9K0heKQ007374; Thu, 20 Oct 2011 00:43:52 GMT Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Cullen Jennings In-Reply-To: Date: Wed, 19 Oct 2011 18:43:52 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <05C007AF-7462-4A08-894D-9D4DD0569105@cisco.com> References: <15B0E3AD-3086-499A-8E79-7AE58B3376C4@cisco.com> To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= X-Mailer: Apple Mail (2.1251.1) Cc: Jonathan Rosenberg , rtcweb@ietf.org, public-webrtc@w3.org Subject: Re: [rtcweb] =?windows-1252?q?Why_SDP_answer_needs_and_ack_=85_was_Re?= =?windows-1252?q?=3A__SDP_Offer/Answer_draft-jennings-rtcweb-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: Thu, 20 Oct 2011 00:43:53 -0000 I guess the question I am thinking about is how important is this use = case. I'm a bit of the fence on the topic. The primary use of INVITE = with no offer is when doing a gateway to some forms of H.323. It seem = the odds of a gateway from RTCWeb to SIP to H323 is pretty low so I have = not been thinking about how to deal with INVITE with no offer much. I = should think about it more but too few hours in the day :-)=20 On Oct 18, 2011, at 13:44 , I=F1aki Baz Castillo wrote: > 2011/10/18 Cullen Jennings : >> Hi - glad to hear you see this going the right direction. On the = topic of why we have an OK, let me provide a bit of the motivation. >>=20 >> When one side sends and answer that says it wants to receive VP8 = instead of H.264, it's probably useful to know when the other side got = that information. This might impact the timing of when o send things or = user interface that provides feedback about the status of the other = side. We are also dealing with a web transaction model where transaction = are not guarantee to happen even if they are sent over TCP. So you need = to get back a response to request. It also helps with mapping to SIP but = even if you were not mapping to another protocol, I suspect you would = still need to be able to have an confirmation than and answer was = received. >=20 > Hi Cullen. Let me put an example: >=20 > - alice: JS client implementing pure SIP over WebSocket. > - A proxy implementing SIP over UDP and WebSocket. > - bob: SIP UDP client. >=20 > The flows: >=20 > - alice sends INVITE to bob with an empty body (no SDP). > - bob replies a 200 with the SDP offer. > - alice receives the 200. Its JS code internally generates a ROAP = Offer. > - alice generates a ROAP Answer and inserts its SDP into an ACK to be > sent to bob. > - In SIP we have ended. So how is supposed alice will receive the ROAP > OK message? >=20 > I don't understand yet if such ROAP OK message is mandatory to be sent > to the RTCweb stack. If so, the JS code in alice could auto-generate > it after sending the ACK, so the RTCweb stack becomes happy. But > obviously the advantage of such auto-generated ROAP OK is null. >=20 >=20 > Regards. >=20 >=20 > --=20 > I=F1aki Baz Castillo > From fluffy@cisco.com Wed Oct 19 17: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 3F5BC11E80B3 for ; Wed, 19 Oct 2011 17:45:34 -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 fH90FRjoEgwa for ; Wed, 19 Oct 2011 17:45:33 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 6718311E80AF for ; Wed, 19 Oct 2011 17:45:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=3714; q=dns/txt; s=iport; t=1319071533; x=1320281133; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=rkRyDef0zXL5EExBnO12yPCX7cFhpI48dhEW/MJCdQ8=; b=Fj+zaRJf2j8SVHNTSnQ3IHV/s0D87Q4d/N5//DNSzrXeOuHzIHWwciFC jBYfk4iE/waEAWcjvHTvZkDCGvRSNIoXz1FnFRlNo60vdP2/1QPPwMpbk EIiCTIj5zmOKqzc3KYESyIjXPEInVHuWL16jE1SNxHzK/DFGNo39P/Dd2 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAGJun06tJV2Z/2dsb2JhbABEqQKBBYFuAQEBAQIBEgEnPwULCxguVwYTIodel3oBnk+HOmEEiAKLfIUqjEw X-IronPort-AV: E=Sophos;i="4.69,375,1315180800"; d="scan'208";a="29662245" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-7.cisco.com with ESMTP; 20 Oct 2011 00:45:33 +0000 Received: from [192.168.4.106] (sjc-fluffy-8914.cisco.com [10.20.249.165]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p9K0jTC3020510; Thu, 20 Oct 2011 00:45:29 GMT Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: Date: Wed, 19 Oct 2011 18:45:29 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E9D667A.2040703@alvestrand.no> <9B03E9E2-4376-465E-84F5-EDAC51390408@phonefromhere.com> <570BDE5E-6EDC-4094-8DC0-094CEC3F12DF@acmepacket.com> To: "" X-Mailer: Apple Mail (2.1251.1) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] My Opinion: Why I think a negotiating protocol is a Good Thing X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 00:45:34 -0000 I agree SDP is not used as an RTP API. I looked at a few RTP API and = they looked like "here is your compressed media and it's time stamp" and = "send this compressed media with following time stamp to this IP, port. = I don' think any one want that to be the level of API that gets exposed = by the browser. For one thing, the performance issues would likely not = work.=20 One question that comes up is when a browser adds support for a new = CODEC, should the Java script code of a given web sight need to change = to take advantage of it. If your answer to that is at least in some = cases, No, then it means you need an API that allows the browser to do = the negotiation of the codecs. Today SDP (and the mapping of it in = Jingle), are pretty much the only games in town for that sort of = negotiation. You can argue if we should use SDP or invent something new. = I'd love to hear your opinion on that. If we decide we are going to use = SDP, I think you end up with a API at roughly the level of what is the = W3C WEBRTC draft today and something around the level of protocol as = described in ROAP.=20 A third level of api that one could do - and I think Dan York, may have = been arguing for this but I'm not sure - is and API where there is an = DOM object that represent all the communications and in the implies case = you just tell it who to connect to and it is done. Imagine if the HTML5 = Video tag has something like rtc attribute of someone you wanted to = communicate with and the browser set up a video session with them. For = example:
= --_84a87f6f-37b6-4732-80e5-86ca3b5e2a4d_-- From ibc@aliax.net Thu Oct 20 07:39: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 1C6AA21F8BCD for ; Thu, 20 Oct 2011 07:39:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.629 X-Spam-Level: X-Spam-Status: No, score=-2.629 tagged_above=-999 required=5 tests=[AWL=0.048, 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 w9lh4DpN+F-E for ; Thu, 20 Oct 2011 07:39:12 -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 8DD5721F8BBC for ; Thu, 20 Oct 2011 07:39:12 -0700 (PDT) Received: by vws5 with SMTP id 5so2507637vws.31 for ; Thu, 20 Oct 2011 07:39:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.73.166 with SMTP id m6mr10940415vdv.18.1319121550944; Thu, 20 Oct 2011 07:39:10 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Thu, 20 Oct 2011 07:39:10 -0700 (PDT) In-Reply-To: References: <9C8CA816-65FB-41A0-999C-4C43128CAAB4@danyork.org> Date: Thu, 20 Oct 2011 16:39:10 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Bernard Aboba Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] A plea for simplicity, marketability - and... who are we designing RTCWEB for? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 14:39:13 -0000 2011/10/20 Bernard Aboba : > the APIs should also enable media to be sent over a websocket WHAT?? --=20 I=C3=B1aki Baz Castillo From harald@alvestrand.no Thu Oct 20 07:44: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 1D33021F8B75 for ; Thu, 20 Oct 2011 07:44:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.425 X-Spam-Level: X-Spam-Status: No, score=-110.425 tagged_above=-999 required=5 tests=[AWL=-0.126, 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 U9sO1qDOk7t5 for ; Thu, 20 Oct 2011 07:44:46 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 769B421F8A7E for ; Thu, 20 Oct 2011 07:44:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C560B39E0F3; Thu, 20 Oct 2011 16:44: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 7l92CZqOMXfQ; Thu, 20 Oct 2011 16:44: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 26CAF39E072; Thu, 20 Oct 2011 16:44:43 +0200 (CEST) Message-ID: <4EA033DA.5030409@alvestrand.no> Date: Thu, 20 Oct 2011 16:44:42 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= References: <4E9E9794.8000901@alvestrand.no> <4E9FD139.2010406@ericsson.com> <4EA0025E.6080604@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] Friday Agenda: Re: Friday Call details for signaling discussion X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 14:44:47 -0000 On 10/20/11 15:31, Iñaki Baz Castillo wrote: > 2011/10/20 Harald Alvestrand: >> In his category of "info signalling", I would quibble a bit in that I see >> "channel-related signalling" (a term I just invented, describing which media >> is sent on which SSRC on which port) as distinct from "identity-related >> signalling", where the whole question of "who am I talking to" is relevant. >> >> I believe "channel-related signalling" needs to be treated together with >> "media signalling". > Hi Harald, after re-reading this mail from you I've realized that I > don't fully understand it. > > For example, a SIP INVITE has: > > 1) Request URI and headers, which contain the identity information, > the destination of the request, and so. This is what I called > "JS-Server Information Signaling". > > 2) An SDP, which contains media description. This is what I've called > "JS-Server Media Signaling". > > Of course both are carried together (the "JS-Server Information > Signaling" carries the "JS-Server Media Signaling"). > > Initially I understood that your "channel-related signalling" is the > same concept as my "JS-Server Information Signaling" (bullet 1), but > then you said: > >> "channel-related signalling" (a term I just invented, describing which media >> is sent on which SSRC on which port) as distinct from "identity-related >> signalling", where the whole question of "who am I talking to" is relevant. > What do you mean with "channel-related signalling"? "which media is sent on which SSRC on which port". This is usually sent as part of SDP, but some of Neil Stratford's messages have indicated a desire to separate the codec negotiation from the channel negotiation, so I thought it was worth pointing out that I think they both need to be considered in the group that you called "media signaling". Hope this helps! Harald From oej@edvina.net Thu Oct 20 07:45: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 A533D21F8BB6 for ; Thu, 20 Oct 2011 07:45:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[AWL=0.199, 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 nPYaGeEeDpZ2 for ; Thu, 20 Oct 2011 07:45:25 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id 24EAD21F8B75 for ; Thu, 20 Oct 2011 07:45:25 -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 821B0754BCD5; Thu, 20 Oct 2011 14:45:23 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: "Olle E. Johansson" In-Reply-To: Date: Thu, 20 Oct 2011 16:45:25 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6DFC5313-2991-4FB5-811D-FC99D31F9298@edvina.net> References: <9C8CA816-65FB-41A0-999C-4C43128CAAB4@danyork.org> To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= X-Mailer: Apple Mail (2.1251.1) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] A plea for simplicity, marketability - and... who are we designing RTCWEB for? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 14:45:25 -0000 20 okt 2011 kl. 16:39 skrev I=F1aki Baz Castillo: > 2011/10/20 Bernard Aboba : >> the APIs should also enable media to be sent over a websocket >=20 > WHAT?? >=20 A more specific question: What are the use cases? I understand that media over TCP is used in many apps today. While media = over websocket over tcp over IP sounds just a bit too much, I am very = curious on the use case. Thanks. /O= From ibc@aliax.net Thu Oct 20 07:52: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 17D4921F8BA4 for ; Thu, 20 Oct 2011 07:52:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.629 X-Spam-Level: X-Spam-Status: No, score=-2.629 tagged_above=-999 required=5 tests=[AWL=0.048, 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 ca4C-MEVgeNL for ; Thu, 20 Oct 2011 07:52:23 -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 5FAE521F8B87 for ; Thu, 20 Oct 2011 07:52:23 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so3038946vcb.31 for ; Thu, 20 Oct 2011 07:52:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.73.166 with SMTP id m6mr10988608vdv.18.1319122342756; Thu, 20 Oct 2011 07:52:22 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Thu, 20 Oct 2011 07:52:22 -0700 (PDT) In-Reply-To: <6DFC5313-2991-4FB5-811D-FC99D31F9298@edvina.net> References: <9C8CA816-65FB-41A0-999C-4C43128CAAB4@danyork.org> <6DFC5313-2991-4FB5-811D-FC99D31F9298@edvina.net> Date: Thu, 20 Oct 2011 16:52:22 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Bernard Aboba Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] A plea for simplicity, marketability - and... who are we designing RTCWEB for? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 14:52:25 -0000 2011/10/20 Olle E. Johansson : > 20 okt 2011 kl. 16:39 skrev I=C3=B1aki Baz Castillo: > >> 2011/10/20 Bernard Aboba : >>> the APIs should also enable media to be sent over a websocket >> >> WHAT?? >> > A more specific question: What are the use cases? > > I understand that media over TCP is used in many apps today. While media = over websocket over tcp over IP sounds just a bit too much, I am very curio= us on the use case. There is no use case. WebSocket is NOT designed for carrying media. WebSocket is designed for sending and receiving *boundary* messages (with any application content up to the developer) over an existing TCP connection between client and server, in both directions. When a WebSocket message arrives to the browser, a JavaScript callback onmessage(data) is called, so the custom JavaScript code can read it, parse it and react according. This stuff is NOT designed for media ! Please read: http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-17 http://dev.w3.org/html5/websockets/#the-websocket-interface I strongly hope this WG will not waste time in discussions about "RTP over WebSocket", or it will become surrealist. Regards. --=20 I=C3=B1aki Baz Castillo From roman@telurix.com Thu Oct 20 07: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 8662D21F8BCD for ; Thu, 20 Oct 2011 07:52:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.846 X-Spam-Level: X-Spam-Status: No, score=-2.846 tagged_above=-999 required=5 tests=[AWL=0.130, 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 s1UIurcL13B3 for ; Thu, 20 Oct 2011 07:52:53 -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 EA83021F8BBE for ; Thu, 20 Oct 2011 07:52:52 -0700 (PDT) Received: by ggnv1 with SMTP id v1so3443332ggn.31 for ; Thu, 20 Oct 2011 07:52:52 -0700 (PDT) Received: by 10.150.191.20 with SMTP id o20mr8907107ybf.55.1319122372446; Thu, 20 Oct 2011 07:52:52 -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 r9sm15213194anh.8.2011.10.20.07.52.51 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 20 Oct 2011 07:52:51 -0700 (PDT) Received: by ggnv1 with SMTP id v1so3443304ggn.31 for ; Thu, 20 Oct 2011 07:52:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.32.138 with SMTP id j10mr14829290pbi.81.1319122370338; Thu, 20 Oct 2011 07:52:50 -0700 (PDT) Received: by 10.68.47.40 with HTTP; Thu, 20 Oct 2011 07:52:50 -0700 (PDT) In-Reply-To: <6DFC5313-2991-4FB5-811D-FC99D31F9298@edvina.net> References: <9C8CA816-65FB-41A0-999C-4C43128CAAB4@danyork.org> <6DFC5313-2991-4FB5-811D-FC99D31F9298@edvina.net> Date: Thu, 20 Oct 2011 10:52:50 -0400 Message-ID: From: Roman Shpount To: "Olle E. Johansson" Content-Type: multipart/alternative; boundary=bcaec52163d14c9ebd04afbc1c95 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] A plea for simplicity, marketability - and... who are we designing RTCWEB for? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 14:52:53 -0000 --bcaec52163d14c9ebd04afbc1c95 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Oct 20, 2011 at 10:45 AM, Olle E. Johansson wrote: > I understand that media over TCP is used in many apps today. While media > over websocket over tcp over IP sounds just a bit too much, I am very > curious on the use case. > > I am not sure that he actually meant media over websocket, but single origin application and media (RTP media sent to the same IP as web app), might warrant relaxed security requirements. In particular, if RTC client is sending media to the same IP as a web server providing JavaScript, it can probably do so without ICE connectivity check without introducing any security issues. I am not sure how big of the use case this is going to be, but this can be attractive in some cases (use IP load balancer to send HTTP requests to one server and RTP port range to a gateway or SBC). _____________ Roman Shpount --bcaec52163d14c9ebd04afbc1c95 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Oct 20, 2011 at 10:45 AM, Olle E. Johans= son <oej@edvina.net<= /a>> wrote:
I understand that media over TCP is used in many apps today. While media ov= er websocket over tcp over IP sounds just a bit too much, I am very curious= on the use case.


I am not sure that he actually meant media over = websocket, but single origin application and media (RTP media sent to the s= ame IP as web app), might warrant relaxed security requirements. In particu= lar, if RTC client is sending media to the same IP as a web server providin= g JavaScript, it can probably do so without ICE connectivity check without = introducing any security issues. I am not sure how big of the use case this= is going to be, but this can be attractive in some cases (use IP load bala= ncer to send HTTP requests to one server and RTP port range to a gateway or= SBC).
_____________
Roman Shpount


--bcaec52163d14c9ebd04afbc1c95-- From roman@telurix.com Thu Oct 20 07:54: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 EE6FB21F8BAE for ; Thu, 20 Oct 2011 07:54:46 -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.034, 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 2Gb6IUyILdZ2 for ; Thu, 20 Oct 2011 07:54:46 -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 59ADB21F8BA7 for ; Thu, 20 Oct 2011 07:54:46 -0700 (PDT) Received: by qyk34 with SMTP id 34so4070014qyk.10 for ; Thu, 20 Oct 2011 07:54:41 -0700 (PDT) Received: by 10.68.59.10 with SMTP id v10mr21211972pbq.16.1319122481475; Thu, 20 Oct 2011 07:54:41 -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 z3sm19718548pbu.7.2011.10.20.07.54.37 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 20 Oct 2011 07:54:40 -0700 (PDT) Received: by pzk34 with SMTP id 34so7505716pzk.9 for ; Thu, 20 Oct 2011 07:54:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.32.138 with SMTP id j10mr14838767pbi.81.1319122477082; Thu, 20 Oct 2011 07:54:37 -0700 (PDT) Received: by 10.68.47.40 with HTTP; Thu, 20 Oct 2011 07:54:37 -0700 (PDT) In-Reply-To: References: <9C8CA816-65FB-41A0-999C-4C43128CAAB4@danyork.org> <6DFC5313-2991-4FB5-811D-FC99D31F9298@edvina.net> Date: Thu, 20 Oct 2011 10:54:37 -0400 Message-ID: From: Roman Shpount To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=bcaec52163d1a96a1d04afbc2277 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] A plea for simplicity, marketability - and... who are we designing RTCWEB for? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 14:54:47 -0000 --bcaec52163d1a96a1d04afbc2277 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Oct 20, 2011 at 10:52 AM, I=F1aki Baz Castillo wrot= e: > I strongly hope this WG will not waste time in discussions about "RTP > over WebSocket", or it will become surrealist. > > I think it already became surrealist. I now understand why W3C holds private discussions of the standards. _____________ Roman Shpount --bcaec52163d1a96a1d04afbc2277 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Oct 20, 2011 at 10= :52 AM, I=F1aki Baz Castillo <ibc@aliax.net> wrote:
I strongly hope this WG will not waste time in discussions about "RTP<= br> over WebSocket", or it will become surrealist.

I think it already became surrealist. I now understa= nd why W3C holds private discussions of the standards.
_____________
= Roman Shpount

--bcaec52163d1a96a1d04afbc2277-- From ibc@aliax.net Thu Oct 20 07:55:45 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B14221F8B4C for ; Thu, 20 Oct 2011 07:55:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.63 X-Spam-Level: X-Spam-Status: No, score=-2.63 tagged_above=-999 required=5 tests=[AWL=0.047, 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 cREuYqfczQ4L for ; Thu, 20 Oct 2011 07:55: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 0EF4221F8B1A for ; Thu, 20 Oct 2011 07:55:44 -0700 (PDT) Received: by vws5 with SMTP id 5so2526812vws.31 for ; Thu, 20 Oct 2011 07:55:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.73.166 with SMTP id m6mr11000178vdv.18.1319122544526; Thu, 20 Oct 2011 07:55:44 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Thu, 20 Oct 2011 07:55:44 -0700 (PDT) In-Reply-To: References: <9C8CA816-65FB-41A0-999C-4C43128CAAB4@danyork.org> <6DFC5313-2991-4FB5-811D-FC99D31F9298@edvina.net> Date: Thu, 20 Oct 2011 16:55:44 +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] A plea for simplicity, marketability - and... who are we designing RTCWEB for? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 14:55:45 -0000 2011/10/20 Roman Shpount : > I am not sure that he actually meant media over websocket, but single ori= gin > application and media (RTP media sent to the same IP as web app), might > warrant relaxed security requirements. In particular, if RTC client is > sending media to the same IP as a web server providing JavaScript, it can > probably do so without ICE connectivity check without introducing any > security issues. I am not sure how big of the use case this is going to b= e, > but this can be attractive in some cases (use IP load balancer to send HT= TP > requests to one server and RTP port range to a gateway or SBC). Yes, that's the WWW vision for any problem to solve: HTTP/WebSocket protocol for all, port 80 and IP load balancers. There si no more in WWW minds. We can do it much better. --=20 I=C3=B1aki Baz Castillo From oej@edvina.net Thu Oct 20 07:56: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 9955A21F8BA8 for ; Thu, 20 Oct 2011 07:56:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.816 X-Spam-Level: X-Spam-Status: No, score=-1.816 tagged_above=-999 required=5 tests=[AWL=0.133, 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 2HZ-myQFmRhP for ; Thu, 20 Oct 2011 07:56:11 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id 1A70021F8B94 for ; Thu, 20 Oct 2011 07:56:11 -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 76F22754BCD5; Thu, 20 Oct 2011 14:56:09 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: "Olle E. Johansson" In-Reply-To: Date: Thu, 20 Oct 2011 16:56:11 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9DC67F6E-B230-4026-9DE5-A4C11CC96575@edvina.net> References: <9C8CA816-65FB-41A0-999C-4C43128CAAB4@danyork.org> <6DFC5313-2991-4FB5-811D-FC99D31F9298@edvina.net> To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= X-Mailer: Apple Mail (2.1251.1) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] A plea for simplicity, marketability - and... who are we designing RTCWEB for? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 14:56:11 -0000 20 okt 2011 kl. 16:52 skrev I=F1aki Baz Castillo: > 2011/10/20 Olle E. Johansson : >> 20 okt 2011 kl. 16:39 skrev I=F1aki Baz Castillo: >>=20 >>> 2011/10/20 Bernard Aboba : >>>> the APIs should also enable media to be sent over a websocket >>>=20 >>> WHAT?? >>>=20 >> A more specific question: What are the use cases? >>=20 >> I understand that media over TCP is used in many apps today. While = media over websocket over tcp over IP sounds just a bit too much, I am = very curious on the use case. >=20 >=20 > There is no use case. WebSocket is NOT designed for carrying media. Right. But if we want to inject prompts in the call or save media files = recorded, would that work? Not realtime. Bernard - what did you have in mind when you wrote that? /O= From magnus.westerlund@ericsson.com Thu Oct 20 07:58: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 E54ED21F8BBE for ; Thu, 20 Oct 2011 07:58:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.402 X-Spam-Level: X-Spam-Status: No, score=-106.402 tagged_above=-999 required=5 tests=[AWL=-0.103, 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 3bANdJIKOhAC for ; Thu, 20 Oct 2011 07:58: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 E4CA521F8B5D for ; Thu, 20 Oct 2011 07:58:36 -0700 (PDT) X-AuditID: c1b4fb3d-b7c26ae0000035b9-16-4ea0371b0039 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id B6.96.13753.B1730AE4; Thu, 20 Oct 2011 16:58:36 +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, 20 Oct 2011 16:58:35 +0200 Message-ID: <4EA03717.10406@ericsson.com> Date: Thu, 20 Oct 2011 16:58:31 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= References: <4E9E9794.8000901@alvestrand.no> <4E9FD139.2010406@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Friday Agenda: Re: Friday Call details for signaling discussion X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 14:58:38 -0000 On 2011-10-20 12:45, Iñaki Baz Castillo wrote: > 2011/10/20 Magnus Westerlund : >> The proposed agenda for Firday is as follows: >> >> 10 min introduction from each signaling proposal: >> - draft-jennings-rtcweb-signaling-00 (ROAP) Cullen >> - draft-partha-rtcweb-signaling-00 (Standard signaling protocol) Partha >> - ? (No Protocol) ? >> >> In the above only clarifying questions may occur. >> >> 20 min discussion of each proposal >> >> 30 min concluding discussion >> >> From my perspective both draft-beck-rtcweb-alt-ic-00 and >> draft-ibc-rtcweb-sip-websocket-00 are relevant documents to the >> discussion as they provides useful proposals on how interconnect and SIP >> interop respectively can be done. But as they aren't proposals for how >> the actual signaling solution should work. Thus these are homework but >> don't get presentation time. > > Hi Magnus. Honestly I don't consider that discussing about > draft-ibc-rtcweb-sip-websocket-00 should take place. It's just a > suggestion about a signaling protocol in RTCweb (in this case pure SIP > over WebSocket). It's not my aim that the WG considers such spec as a > standard signaling for RTCweb. Well, this is basically the same you > have said :) Sorry if I wasn't clear enough. I don't intended that we would have any discussion either of your draft. Only that it is useful background material for the discussion. The below links seems useful to have read also before yesterdays conference. Cheers Magnus > > In the other said, I'd really would like that, before the meeting, all > the folks could take some time to read: > > http://public.aliax.net/RTCweb_Signaling_Components.html > and > http://www.ietf.org/mail-archive/web/rtcweb/current/msg02158.html > > This means not wasting time if somebody proposes ROAP as a "default > signaling protocol" because ROAP is not that and cannot do that (more > info in the given links). Also, given the general confusion when the > term "signaling" appears in this WG, I've tryied to clarify its > meaning(s) in RTCweb context (first link). > > For those who advocate for a "default signaling protocol", I hope > second link should make them to re-think about what such erroneous > decision would entail in current and *existing* WWW world. > > > Best regards. > > > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From roman@telurix.com Thu Oct 20 08:16: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 893D721F8ACE for ; Thu, 20 Oct 2011 08:16:23 -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 ILZ+DOFfrDhO for ; Thu, 20 Oct 2011 08:16:23 -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 B295321F8A91 for ; Thu, 20 Oct 2011 08:16:22 -0700 (PDT) Received: by ggnv1 with SMTP id v1so3471234ggn.31 for ; Thu, 20 Oct 2011 08:16:22 -0700 (PDT) Received: by 10.68.73.103 with SMTP id k7mr11365285pbv.30.1319123781744; Thu, 20 Oct 2011 08:16:21 -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 w4sm19890311pbf.6.2011.10.20.08.16.20 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 20 Oct 2011 08:16:20 -0700 (PDT) Received: by pzk34 with SMTP id 34so7562776pzk.9 for ; Thu, 20 Oct 2011 08:16:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.17.193 with SMTP id q1mr20615884pbd.98.1319123779713; Thu, 20 Oct 2011 08:16:19 -0700 (PDT) Received: by 10.68.47.40 with HTTP; Thu, 20 Oct 2011 08:16:19 -0700 (PDT) Date: Thu, 20 Oct 2011 11:16:19 -0400 Message-ID: From: Roman Shpount To: rtcweb@ietf.org Content-Type: multipart/alternative; boundary=bcaec520ea434dfc5b04afbc709b Subject: [rtcweb] Why are we asking the wrong questions? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 15:16:23 -0000 --bcaec520ea434dfc5b04afbc709b Content-Type: text/plain; charset=ISO-8859-1 I am sorry for another rant, but it is painful to watch the discussion on this list. We have a chance to create something great, but instead wasting our time discussing irrelevant topics. First irrelevant topic is "We want something that will allow to setup a media call in 20 lines of JavaScript". If we are looking for something that will to do this using the right JavaScript library and web server components, then we will probably achieve this goal. If someone expects to create something that by adding code at the browser level and no web server cooperation will setup a call between two arbitrary browsers, then this is a fool's quest. To setup a call browsers will need a meet point on the public IP. On one hand we have hundred different ways to implement this using current technology using a JavaScript library and one or the other server component. On the other hand we have no standard protocol to implement a meet point (some might argue for SIP or XMPP) but they do too much and do not implement meet point functionality too well. If you want something extremely simple just put a tel (or sip where supported) URL in your HTML. Second irrelevant topic is PSTN vs some future web technology. We should stop arguing about supporting or not supporting PSTN connectivity and tailoring to the needs of some future start up. It is not about PSTN. It is about supporting currently used call negotiation scenarios. RTC will need to support all the scenarios actively used right now. Ideally, it should be able to support future scenarios that we cannot support now due to offer/answer limitations. Deliberately disabling support for current applications is misguided not only from the point of view of interoperability, but from the point of view of disabling future applications. As it was said numerous times on this list, there are quite a few examples of RTC applications currently being used on the web. Their main limitation is that they are using some sort of proprietary plugin to implement real time media connections. The goal of this group is to create a set of recommendations for standard implementation of this functionality. So the right question would be what is the minimal feature set that needs to be added to the browser which will allow web developers to create such applications. Adding convenience APIs or optional functionality can be done later. _____________ Roman Shpount --bcaec520ea434dfc5b04afbc709b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I am sorry for another rant, but it is painful to watch the discussion on t= his list. We have a chance to create something great, but instead wasting o= ur time discussing irrelevant topics.

First irrelevant topic is &quo= t;We want something that will allow to setup a media call in 20 lines of Ja= vaScript". If we are looking for something that will to do this using = the right JavaScript library and web server components, then we will probab= ly achieve this goal. If someone expects to create something that by adding= code at the browser level and no web server cooperation will setup a call = between two arbitrary browsers, then this is a fool's quest. To setup a= call browsers will need a meet point on the public IP. On one hand we have= hundred different ways to implement this using current technology using a = JavaScript library and one or the other server component. On the other hand= we have no standard protocol to implement a meet point (some might argue f= or SIP or XMPP) but they do too much and do not implement meet point functi= onality too well. If you want something extremely simple just put a tel (or= sip where supported) URL in your HTML.

Second irrelevant topic is PSTN vs some future web technology. We shoul= d stop arguing about supporting or not supporting PSTN connectivity and tai= loring to the needs of some future start up. It is not about PSTN. It is ab= out supporting currently used call negotiation scenarios. RTC will need to = support all the scenarios actively used right now. Ideally, it should be ab= le to support future scenarios that we cannot support now due to offer/answ= er limitations. Deliberately disabling support for current applications is = misguided not only from the point of view of interoperability, but from the= point of view of disabling future applications.

As it was said numerous times on this list, there are quite a few examp= les of RTC applications currently being used on the web. Their main limitat= ion is that they are using some sort of proprietary plugin to implement rea= l time media connections. The goal of this group is to create a set of reco= mmendations for standard implementation of this functionality. So the right= question would be what is the minimal feature set that needs to be added t= o the browser which will allow web developers to create such applications. = Adding convenience APIs or optional functionality can be done later.
_____________
Roman Shpount
--bcaec520ea434dfc5b04afbc709b-- From magnus.westerlund@ericsson.com Thu Oct 20 08:25: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 F0B2621F8672 for ; Thu, 20 Oct 2011 08:25:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.546 X-Spam-Level: X-Spam-Status: No, score=-106.546 tagged_above=-999 required=5 tests=[AWL=0.053, 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 Nrcqe6ZWm53g for ; Thu, 20 Oct 2011 08:25: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 24A4D21F8610 for ; Thu, 20 Oct 2011 08:25:51 -0700 (PDT) X-AuditID: c1b4fb3d-b7c26ae0000035b9-eb-4ea03d7f4100 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 41.3B.13753.F7D30AE4; Thu, 20 Oct 2011 17:25:51 +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, 20 Oct 2011 17:25:50 +0200 Message-ID: <4EA03D79.2040804@ericsson.com> Date: Thu, 20 Oct 2011 17:25:45 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4E9E9794.8000901@alvestrand.no> <4E9FD139.2010406@ericsson.com> <4EA03717.10406@ericsson.com> In-Reply-To: <4EA03717.10406@ericsson.com> X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [rtcweb] Friday Agenda: Re: Friday Call details for signaling discussion X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 15:25:53 -0000 On 2011-10-20 16:58, Magnus Westerlund wrote: > The below links seems useful to have read also before yesterdays conference. > Replace yesterday with tomorrow. cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From ekr@rtfm.com Thu Oct 20 08:37: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 4A27021F8C8C for ; Thu, 20 Oct 2011 08:37:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.958 X-Spam-Level: X-Spam-Status: No, score=-102.958 tagged_above=-999 required=5 tests=[AWL=0.019, 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 YRAkl5aABARt for ; Thu, 20 Oct 2011 08:37:34 -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 B4A9C21F8C8A for ; Thu, 20 Oct 2011 08:37:34 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so3093296vcb.31 for ; Thu, 20 Oct 2011 08:37:34 -0700 (PDT) Received: by 10.52.182.39 with SMTP id eb7mr10053697vdc.12.1319125054091; Thu, 20 Oct 2011 08:37:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.161.20 with HTTP; Thu, 20 Oct 2011 08:36:54 -0700 (PDT) In-Reply-To: References: <9C8CA816-65FB-41A0-999C-4C43128CAAB4@danyork.org> From: Eric Rescorla Date: Thu, 20 Oct 2011 08:36:54 -0700 Message-ID: To: Bernard Aboba Content-Type: text/plain; charset=ISO-8859-1 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] A plea for simplicity, marketability - and... who are we designing RTCWEB for? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 15:37:35 -0000 On Thu, Oct 20, 2011 at 7:32 AM, Bernard Aboba wrote: > No, I'm saying that *if* a developer remains within the "single origin" > model, that a number of requirements for peer-to-peer operation do not > apply. > > Also that the APIs should also enable media to be sent over a websocket to > the "single origin" as well as a PeerConnection. > I don't think I'm following you're argument. ISTM that there are two conditions that one might term "single origin": 1. Alice and Bob are on the same site (e.g., PokerStars) and are calling each other via P2P media, 2. Alice and Bob are on the same site and are calling each other via media over WS. In the first case, I don't see why this would allow us to relax any of the security requirements. As long as Alice and Bob are sending media to each other, we still cannot trust the site to adequately verify consent, so we clearly need ICE. As for the need for E2E security, this seems equally important regardless of whether Alice and Bob share the same site. In the second case, I agree that you don't need to verify consent because it's implicit in the WS protocol. (I'm leaving aside the question of whether using WS this way is advisable), but the need for E2E security seems equal if not greater, since in this case the site would have direct access to the media. -Ekr From roman@telurix.com Thu Oct 20 08:45: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 8662021F8B8D for ; Thu, 20 Oct 2011 08:45:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.868 X-Spam-Level: X-Spam-Status: No, score=-2.868 tagged_above=-999 required=5 tests=[AWL=0.108, 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 K050um3CbafD for ; Thu, 20 Oct 2011 08:45:54 -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 0AEB321F8B86 for ; Thu, 20 Oct 2011 08:45:53 -0700 (PDT) Received: by yxj19 with SMTP id 19so3532302yxj.31 for ; Thu, 20 Oct 2011 08:45:53 -0700 (PDT) Received: by 10.43.49.131 with SMTP id va3mr19150505icb.51.1319125553467; Thu, 20 Oct 2011 08:45: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 l28sm24664887ibc.3.2011.10.20.08.45.52 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 20 Oct 2011 08:45:53 -0700 (PDT) Received: by pzk34 with SMTP id 34so7630322pzk.9 for ; Thu, 20 Oct 2011 08:45:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.17.225 with SMTP id r1mr21207888pbd.64.1319125550186; Thu, 20 Oct 2011 08:45:50 -0700 (PDT) Received: by 10.68.47.40 with HTTP; Thu, 20 Oct 2011 08:45:50 -0700 (PDT) In-Reply-To: References: <9C8CA816-65FB-41A0-999C-4C43128CAAB4@danyork.org> Date: Thu, 20 Oct 2011 11:45:50 -0400 Message-ID: From: Roman Shpount To: Eric Rescorla Content-Type: multipart/alternative; boundary=bcaec520ea85d5432104afbcd9f8 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] A plea for simplicity, marketability - and... who are we designing RTCWEB for? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 15:45:54 -0000 --bcaec520ea85d5432104afbcd9f8 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Oct 20, 2011 at 11:36 AM, Eric Rescorla wrote: > I don't think I'm following you're argument. ISTM that there are two > conditions that one might term "single origin": > There is a third condition for the term "single origin": an RTC application calling a server which provided the JavaScript with RTC application. For instance if you have an application from a phone service provider or conferencing app. This application will never setup a P2P call between two browsers, it is always between provider and the browser, so it can ask for relaxed security since it only calls its own IP. _____________ Roman Shpount --bcaec520ea85d5432104afbcd9f8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Oct 20, 2011 at 11:36 AM, Eric Resco= rla <ekr@rtfm.com&= gt; wrote:
I don't think I'm following you're argument. ISTM that there ar= e two
conditions that one might term "single origin":

There is a = third condition for the term "single origin": an RTC application= calling a server which provided the JavaScript with RTC application. For i= nstance if you have an application from a phone service provider or confere= ncing app. This application will never setup a P2P call between two browser= s, it is always between provider and the browser, so it can ask for relaxed= security since it only calls its own IP.
_____________
Roman Shpount

--bcaec520ea85d5432104afbcd9f8-- From ekr@rtfm.com Thu Oct 20 08:55: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 3F8AF21F8C9C for ; Thu, 20 Oct 2011 08:55:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.96 X-Spam-Level: X-Spam-Status: No, score=-102.96 tagged_above=-999 required=5 tests=[AWL=0.017, 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 LUW0qpd+qUyb for ; Thu, 20 Oct 2011 08:55:36 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id B3BE421F8C87 for ; Thu, 20 Oct 2011 08:55:36 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so3115105vcb.31 for ; Thu, 20 Oct 2011 08:55:36 -0700 (PDT) Received: by 10.52.99.195 with SMTP id es3mr11263923vdb.63.1319126136164; Thu, 20 Oct 2011 08:55:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.161.20 with HTTP; Thu, 20 Oct 2011 08:54:55 -0700 (PDT) In-Reply-To: References: <9C8CA816-65FB-41A0-999C-4C43128CAAB4@danyork.org> From: Eric Rescorla Date: Thu, 20 Oct 2011 08:54:55 -0700 Message-ID: To: Roman Shpount Content-Type: text/plain; charset=ISO-8859-1 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] A plea for simplicity, marketability - and... who are we designing RTCWEB for? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 15:55:37 -0000 On Thu, Oct 20, 2011 at 8:45 AM, Roman Shpount wrote: > > On Thu, Oct 20, 2011 at 11:36 AM, Eric Rescorla wrote: >> >> I don't think I'm following you're argument. ISTM that there are two >> conditions that one might term "single origin": > > There is a third condition for the term "single origin": an RTC application > calling a server which provided the JavaScript with RTC application. For > instance if you have an application from a phone service provider or > conferencing app. This application will never setup a P2P call between two > browsers, it is always between provider and the browser, so it can ask for > relaxed security since it only calls its own IP. Unless the browser can directly verify that the target of the media and the source of the JS are one and the same, then at minimum the consent issues apply. -Ekr From ibc@aliax.net Thu Oct 20 08:57: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 A900621F8C92 for ; Thu, 20 Oct 2011 08:57:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[AWL=0.045, 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 Ys7Z9S1oz51I for ; Thu, 20 Oct 2011 08:57:37 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2ABAE21F8C7D for ; Thu, 20 Oct 2011 08:57:37 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so3117304vcb.31 for ; Thu, 20 Oct 2011 08:57:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.155.81 with SMTP id r17mr586040vcw.6.1319126256576; Thu, 20 Oct 2011 08:57:36 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Thu, 20 Oct 2011 08:57:36 -0700 (PDT) In-Reply-To: References: <9C8CA816-65FB-41A0-999C-4C43128CAAB4@danyork.org> Date: Thu, 20 Oct 2011 17:57:36 +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] A plea for simplicity, marketability - and... who are we designing RTCWEB for? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 15:57:37 -0000 2011/10/20 Roman Shpount : > This application will never setup a P2P call between two browsers, it is > always between provider and the browser, so it can ask for relaxed securi= ty > since it only calls its own IP. There is long rationale about this topic in the list. Security cannot (MUST NOT) be relaxed, never, because just the human can determine when to allow "relaxed security" (and we don't want that a malicius site asks the human user "press Accept Relaxed Security and you can win a car". The browser has no way to determine whether the destination of *all* the calls is a "trusted" server or not. Also you are asuming that the media is sent to the same IP of the web server (in case a RTCweb scenario does not include user2user calls). This is a too much simplified scenario, and you miss that a DNS A record can point to N IP's, and you also miss the case in which the webserver has an IP different than the media server (regardless they both are located within the same provider infrastucture). The browser cannot determine it by itself, so security is always a need, and IMHO it's a bad idea to allow a very corner case in which such security could be relaxed. --=20 I=C3=B1aki Baz Castillo From bernard_aboba@hotmail.com Thu Oct 20 09: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 F034621F8C96 for ; Thu, 20 Oct 2011 09:18:52 -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 gfiTJWIei6Q8 for ; Thu, 20 Oct 2011 09:18:51 -0700 (PDT) Received: from blu0-omc2-s33.blu0.hotmail.com (blu0-omc2-s33.blu0.hotmail.com [65.55.111.108]) by ietfa.amsl.com (Postfix) with ESMTP id 84FDA21F8C69 for ; Thu, 20 Oct 2011 09:18:51 -0700 (PDT) Received: from BLU152-W19 ([65.55.111.73]) by blu0-omc2-s33.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 20 Oct 2011 09:18:51 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_7db1a15e-2022-4fd7-bd42-308b78186637_" X-Originating-IP: [24.17.217.162] From: Bernard Aboba To: Date: Thu, 20 Oct 2011 09:18:50 -0700 Importance: Normal In-Reply-To: References: <9C8CA816-65FB-41A0-999C-4C43128CAAB4@danyork.org>, , , MIME-Version: 1.0 X-OriginalArrivalTime: 20 Oct 2011 16:18:51.0215 (UTC) FILETIME=[F45BF5F0:01CC8F43] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] A plea for simplicity, marketability - and... who are we designing RTCWEB for? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 16:18:53 -0000 --_7db1a15e-2022-4fd7-bd42-308b78186637_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > 1. Alice and Bob are on the same site (e.g.=2C PokerStars) and are > calling each other via P2P media=2C > 2. Alice and Bob are on the same site and are calling each other > via media over WS. >=20 > In the first case=2C I don't see why this would allow us to relax any of > the security requirements. As long as Alice and Bob are sending media to = each other=2C we still > cannot trust the site to adequately verify consent=2C so we clearly need > ICE. As for the need for E2E security=2C this seems equally important reg= ardless of whether > Alice and Bob share the same site. [BA] I agree. Where there is P2P media=2C ICE is required. =20 > In the second case=2C I agree that you don't need to verify consent becau= se it's > implicit in the WS protocol. (I'm leaving aside the question of whether u= sing WS > this way is advisable)=2C but the need for E2E security seems equal if > not greater=2C since in this case the site would have direct access to th= e media. [BA] Yes=2C that was my point.=20 = --_7db1a15e-2022-4fd7-bd42-308b78186637_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

>=3B 1. Alice and Bob are on the same site (e.g.=2C PokerStars) = and are
>=3B calling each other via P2P media=2C
>=3B 2. Alice an= d Bob are on the same site and are calling each other
>=3B via media o= ver WS.
>=3B
>=3B In the first case=2C I don't see why this woul= d allow us to relax any of
>=3B the security requirements. As long as = Alice and Bob are sending media to each other=2C we still
>=3B cannot = trust the site to adequately verify consent=2C so we clearly need
>=3B= ICE. As for the need for E2E security=2C this seems equally important rega= rdless of whether
>=3B Alice and Bob share the same site.

[BA] = I agree. =3B Where there is P2P media=2C =3B ICE is required.
&n= bsp=3B
>=3B In the second case=2C I agree that you don't need to verif= y consent because it's
>=3B implicit in the WS protocol. (I'm leaving = aside the question of whether using WS
>=3B this way is advisable)=2C = but the need for E2E security seems equal if
>=3B not greater=2C since= in this case the site would have direct access to the media.

[BA] Y= es=2C that was my point.
= --_7db1a15e-2022-4fd7-bd42-308b78186637_-- From roman@telurix.com Thu Oct 20 09:27: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 C9FF021F8C2D for ; Thu, 20 Oct 2011 09:27:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.727 X-Spam-Level: X-Spam-Status: No, score=-2.727 tagged_above=-999 required=5 tests=[AWL=-0.051, 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 cmC+HJifk-rK for ; Thu, 20 Oct 2011 09:27:34 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 37AF521F8C1C for ; Thu, 20 Oct 2011 09:27:32 -0700 (PDT) Received: by qadc10 with SMTP id c10so638630qad.31 for ; Thu, 20 Oct 2011 09:27:31 -0700 (PDT) Received: by 10.68.4.200 with SMTP id m8mr3667399pbm.50.1319128051462; Thu, 20 Oct 2011 09:27:31 -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 y4sm20449606pbe.4.2011.10.20.09.27.30 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 20 Oct 2011 09:27:30 -0700 (PDT) Received: by pzk34 with SMTP id 34so7729397pzk.9 for ; Thu, 20 Oct 2011 09:27:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.17.225 with SMTP id r1mr21410121pbd.64.1319128049833; Thu, 20 Oct 2011 09:27:29 -0700 (PDT) Received: by 10.68.47.40 with HTTP; Thu, 20 Oct 2011 09:27:29 -0700 (PDT) Date: Thu, 20 Oct 2011 12:27:29 -0400 Message-ID: From: Roman Shpount To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=bcaec520ea85d2d5b404afbd6e72 Cc: rtcweb@ietf.org Subject: [rtcweb] Same location media X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 16:27:35 -0000 --bcaec520ea85d2d5b404afbd6e72 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Changing the topic from "A plea for simplicity, marketability..." On Thu, Oct 20, 2011 at 11:57 AM, I=F1aki Baz Castillo wrot= e: > Also you are asuming that the media is sent to the same IP of the web > server (in case a RTCweb scenario does not include user2user calls). > This is a too much simplified scenario, and you miss that a DNS A > record can point to N IP's, and you also miss the case in which the > webserver has an IP different than the media server (regardless they > both are located within the same provider infrastucture). The browser > cannot determine it by itself, so security is always a need, and IMHO > it's a bad idea to allow a very corner case in which such security > could be relaxed. > > I am not missing the DNS issues. I wanted to bring this up in my previous email, but did not want to confuse the issue. I don't advocate for this cas= e at all, I just wanted to clarify that "same origin media" does not necessarily mean two phones in the same location and means media going to the same location as JavaScript origination. Few additional points related to this: 1. This is what Flash is doing now for streaming media. It does not need consent to send media to the same server that sent the flash app. 2. I am not sure we standardized that only IP addresses are allowed in medi= a description.DNS names might still be allowed then this issue will become th= e issue of doing a literal match. 3. There is still a security issue with ICE: we validate that STUN request can be processed, but not that the media actually should be accepted from this application. In some sense, current Flash cross domain polices are stricter, since they not only validate that media is acceptable at this IP but that it is acceptable from the app served from particular server. In general, I think this is a good thing if I can get readily available hardware components and connect RTC clients to my existing infrastructure (= I do have an JavaScript/HTTP to SIP proxy solution already). If we are not breaking anything by doing this, there might be some benefit for allowing this. But on the other hand, I already got ICE/SRTP to non-ICE/RTP media proxy as well, so if this is not supported I will not suffer much :). _____________ Roman Shpount --bcaec520ea85d2d5b404afbd6e72 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Changing the topic from "A plea for simplic= ity, marketability..."

On Thu, Oct 20, 2011 at 11:57 AM, I=F1ak= i Baz Castillo <ibc@a= liax.net> wrote:
Also you are asuming that the media is sent= to the same IP of the web
server (in case a RTCweb scenario does not include user2user calls).
This is a too much simplified scenario, and you miss that a DNS A
record can point to N IP's, and you also miss the case in which the
webserver has an IP different than the media server (regardless they
both are located within the same provider infrastucture). The browser
cannot determine it by itself, so security is always a need, and IMHO
it's a bad idea to allow a very corner case in which such security
could be relaxed.


I am not missing the DNS issues. I wanted to bri= ng this up in my previous email, but did not want to confuse the issue. I d= on't advocate for this case at all, I just wanted to clarify that "= ;same origin media" does not necessarily mean two phones in the same l= ocation and means media going to the same location as JavaScript originatio= n.

Few additional points related to this:

1. This is what Flash is = doing now for streaming media. It does not need consent to send media to th= e same server that sent the flash app.

2. I am not sure we standardi= zed that only IP addresses are allowed in media description.DNS names might= still be allowed then this issue will become the issue of doing a literal = match.

3. There is still a security issue with ICE: we validate that STUN requ= est can be processed, but not that the media actually should be accepted fr= om this application. In some sense, current Flash cross domain polices are = stricter, since they not only validate that media is acceptable at this IP = but that it is acceptable from the app served from particular server.

In general, I think this is a good thing if I can get readily available= hardware components and connect RTC clients to my existing infrastructure = (I do have an JavaScript/HTTP to SIP proxy solution already). If we are not= breaking anything by doing this, there might be some benefit for allowing = this. But on the other hand, I already got ICE/SRTP to non-ICE/RTP media pr= oxy as well, so if this is not supported I will not suffer much :).
=A0
_____________
Roman Shpount

--bcaec520ea85d2d5b404afbd6e72-- From ekr@rtfm.com Thu Oct 20 09:31: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 06DBB21F8C9B for ; Thu, 20 Oct 2011 09:31:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.962 X-Spam-Level: X-Spam-Status: No, score=-102.962 tagged_above=-999 required=5 tests=[AWL=0.015, 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 JdGg3XphWEoi for ; Thu, 20 Oct 2011 09:31:14 -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 1459621F8C70 for ; Thu, 20 Oct 2011 09:31:07 -0700 (PDT) Received: by gyh20 with SMTP id 20so3592854gyh.31 for ; Thu, 20 Oct 2011 09:31:06 -0700 (PDT) Received: by 10.236.178.3 with SMTP id e3mr7334363yhm.90.1319128266560; Thu, 20 Oct 2011 09:31:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.146.168.5 with HTTP; Thu, 20 Oct 2011 09:30:22 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Thu, 20 Oct 2011 09:30:22 -0700 Message-ID: To: Roman Shpount Content-Type: text/plain; charset=ISO-8859-1 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Same location media X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 16:31:15 -0000 On Thu, Oct 20, 2011 at 9:27 AM, Roman Shpount wrote: > 3. There is still a security issue with ICE: we validate that STUN request > can be processed, but not that the media actually should be accepted from > this application. In some sense, current Flash cross domain polices are > stricter, since they not only validate that media is acceptable at this IP > but that it is acceptable from the app served from particular server. Unless I'm confused, you get a similar check with ICE because the target needs not only to respond to STUN in general but also to STUN with particular credentials, which means that the target can enforce that only specific sites get those credentials. -Ekr From bernard_aboba@hotmail.com Thu Oct 20 09: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 A6EDF21F8C13 for ; Thu, 20 Oct 2011 09:41:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.397 X-Spam-Level: X-Spam-Status: No, score=-102.397 tagged_above=-999 required=5 tests=[AWL=0.201, 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 l20p4S5LrNdx for ; Thu, 20 Oct 2011 09:41:48 -0700 (PDT) Received: from blu0-omc1-s7.blu0.hotmail.com (blu0-omc1-s7.blu0.hotmail.com [65.55.116.18]) by ietfa.amsl.com (Postfix) with ESMTP id 070E921F8BBB for ; Thu, 20 Oct 2011 09:41:47 -0700 (PDT) Received: from BLU152-W27 ([65.55.116.7]) by blu0-omc1-s7.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 20 Oct 2011 09:41:47 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_a99b29c0-3f9e-4b58-8f2d-2e8b78c0ca8c_" X-Originating-IP: [24.17.217.162] From: Bernard Aboba To: Date: Thu, 20 Oct 2011 09:41:47 -0700 Importance: Normal In-Reply-To: References: MIME-Version: 1.0 X-OriginalArrivalTime: 20 Oct 2011 16:41:47.0818 (UTC) FILETIME=[28E0E8A0:01CC8F47] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Same location media X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 16:41:48 -0000 --_a99b29c0-3f9e-4b58-8f2d-2e8b78c0ca8c_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Roman said:=20 "Few additional points related to this: 1. This is what Flash is doing now for streaming media. It does not need co= nsent to send media to the same server that sent the flash app. 2. I am not sure we standardized that only IP addresses are allowed in medi= a description. DNS names might still be allowed then this issue will become= the issue of doing a literal match. 3. There is still a security issue with ICE: we validate that STUN request = can be processed=2C but not that the media actually should be accepted from= this application. In some sense=2C current Flash cross domain polices are = stricter=2C since they not only validate that media is acceptable at this I= P but that it is acceptable from the app served from particular server. In general=2C I think this is a good thing if I can get readily available h= ardware components and connect RTC clients to my existing infrastructure (I= do have an JavaScript/HTTP to SIP proxy solution already). If we are not b= reaking anything by doing this=2C there might be some benefit for allowing = this. But on the other hand=2C I already got ICE/SRTP to non-ICE/RTP media = proxy as well=2C so if this is not supported I will not suffer much :)." [BA] Good points. =20 One of the requirements in the use case document is the ability to work acr= oss firewalls that do not permit UDP. In practice=2C this constraint is en= countered surprisingly often (as much as 15-25% of the time=2C in enterpris= e scenarios). The implication is that ICE will require a fallback=2C such= as sending media over HTTP. In a fallback situation=2C requiring ICE wou= ld be silly=2C since it has typically failed in order for fallback to be co= nsidered. =20 = --_a99b29c0-3f9e-4b58-8f2d-2e8b78c0ca8c_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Roman said:

"Few additional points related to this:

1. This is what Flash is= doing now for streaming media. It does not need consent to send media to t= he same server that sent the flash app.

2. I am not sure we standard= ized that only IP addresses are allowed in media description. DNS names mig= ht still be allowed then this issue will become the issue of doing a litera= l match.

3. There is still a security issue with ICE: we validate that STUN requ= est can be processed=2C but not that the media actually should be accepted = from this application. In some sense=2C current Flash cross domain polices = are stricter=2C since they not only validate that media is acceptable at th= is IP but that it is acceptable from the app served from particular server.=

In general=2C I think this is a good thing if I can get readily availab= le hardware components and connect RTC clients to my existing infrastructur= e (I do have an JavaScript/HTTP to SIP proxy solution already). If we are n= ot breaking anything by doing this=2C there might be some benefit for allow= ing this. But on the other hand=2C I already got ICE/SRTP to non-ICE/RTP me= dia proxy as well=2C so if this is not supported I will not suffer much :).= "

[BA] =3B Good points. =3B

One of the requirements = in the use case document is the ability to work across firewalls that do no= t permit UDP. =3B In practice=2C this constraint is encountered surpris= ingly often (as much as 15-25% of the time=2C in enterprise scenarios).&nbs= p=3B =3B The implication is that ICE will require a fallback=2C such as= sending media over HTTP. =3B =3B In a fallback situation=2C requir= ing ICE would be silly=2C since it has typically failed in order for fallba= ck to be considered. =3B
= --_a99b29c0-3f9e-4b58-8f2d-2e8b78c0ca8c_-- From roman@telurix.com Thu Oct 20 09:45: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 05B6221F8C5B for ; Thu, 20 Oct 2011 09:45:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.873 X-Spam-Level: X-Spam-Status: No, score=-2.873 tagged_above=-999 required=5 tests=[AWL=0.103, 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 Its5ihxqDlU5 for ; Thu, 20 Oct 2011 09:45:28 -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 79B0E21F8BE4 for ; Thu, 20 Oct 2011 09:45:28 -0700 (PDT) Received: by ggnv1 with SMTP id v1so3573971ggn.31 for ; Thu, 20 Oct 2011 09:45:27 -0700 (PDT) Received: by 10.68.73.103 with SMTP id k7mr11809010pbv.30.1319129127547; Thu, 20 Oct 2011 09:45:27 -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 w4sm20573527pbf.6.2011.10.20.09.45.24 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 20 Oct 2011 09:45:26 -0700 (PDT) Received: by pzk34 with SMTP id 34so7767364pzk.9 for ; Thu, 20 Oct 2011 09:45:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.23.6 with SMTP id i6mr21285032pbf.13.1319129123745; Thu, 20 Oct 2011 09:45:23 -0700 (PDT) Received: by 10.68.47.40 with HTTP; Thu, 20 Oct 2011 09:45:23 -0700 (PDT) In-Reply-To: References: Date: Thu, 20 Oct 2011 12:45:23 -0400 Message-ID: From: Roman Shpount To: Bernard Aboba Content-Type: multipart/alternative; boundary=bcaec5216223d56fe004afbdae64 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Same location media X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 16:45:29 -0000 --bcaec5216223d56fe004afbdae64 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Oct 20, 2011 at 12:41 PM, Bernard Aboba wrote: > One of the requirements in the use case document is the ability to work > across firewalls that do not permit UDP. In practice, this constraint is > encountered surprisingly often (as much as 15-25% of the time, in enterprise > scenarios). The implication is that ICE will require a fallback, such as > sending media over HTTP. In a fallback situation, requiring ICE would be > silly, since it has typically failed in order for fallback to be > considered. > Technically speaking, if TURN server relay address is used, connectivity between the RTC client and TURN server can be TCP (or TLS). So, ICE check would be delivered to the RTC client via TCP tunnel. _____________ Roman Shpount --bcaec5216223d56fe004afbdae64 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Oct 20, 2011 at 12= :41 PM, Bernard Aboba <bernard_aboba@hotmail.com> wrote:
One of the requirements in the use case document is the ability to work acr= oss firewalls that do not permit UDP.=A0 In practice, this constraint is en= countered surprisingly often (as much as 15-25% of the time, in enterprise = scenarios).=A0=A0 The implication is that ICE will require a fallback, such= as sending media over HTTP.=A0=A0 In a fallback situation, requiring ICE w= ould be silly, since it has typically failed in order for fallback to be co= nsidered.=A0

Technically speaking, if TURN server relay address i= s used, connectivity between the RTC client and TURN server can be TCP (or = TLS). So, ICE check would be delivered to the RTC client via TCP tunnel. _____________
Roman Shpount

--bcaec5216223d56fe004afbdae64-- From roman@telurix.com Thu Oct 20 09:48: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 4D64F21F8C5E for ; Thu, 20 Oct 2011 09:48:16 -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.096, 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 SkrRpiA9MWoA for ; Thu, 20 Oct 2011 09:48: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 C900C21F8C17 for ; Thu, 20 Oct 2011 09:48:15 -0700 (PDT) Received: by ywa8 with SMTP id 8so3584672ywa.31 for ; Thu, 20 Oct 2011 09:48:15 -0700 (PDT) Received: by 10.236.138.47 with SMTP id z35mr16826732yhi.56.1319129295353; Thu, 20 Oct 2011 09:48:15 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by mx.google.com with ESMTPS id c10sm13706539yhj.2.2011.10.20.09.48.14 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 20 Oct 2011 09:48:14 -0700 (PDT) Received: by qyk34 with SMTP id 34so4197593qyk.10 for ; Thu, 20 Oct 2011 09:48:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.74.4 with SMTP id p4mr21242065pbv.47.1319129293465; Thu, 20 Oct 2011 09:48:13 -0700 (PDT) Received: by 10.68.47.40 with HTTP; Thu, 20 Oct 2011 09:48:13 -0700 (PDT) In-Reply-To: References: Date: Thu, 20 Oct 2011 12:48:13 -0400 Message-ID: From: Roman Shpount To: Eric Rescorla Content-Type: multipart/alternative; boundary=f46d0413911df327f004afbdb895 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Same location media X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 16:48:16 -0000 --f46d0413911df327f004afbdb895 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Oct 20, 2011 at 12:30 PM, Eric Rescorla wrote: > Unless I'm confused, you get a similar check with ICE because the target > needs not only to respond to STUN in general but also to STUN with > particular credentials, which means that the target can enforce that only > specific sites get those credentials. > > You are right. It was me who was confused. With ICE it is even stricter, since the per call credentials are used. What I am concerned about, is there a way to game those credentials (which can be sent by a malicious web server) to allow ICE check to succeed when used against a public STUN server with known credentials? _____________ Roman Shpount --f46d0413911df327f004afbdb895 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Oct 20, 2011 at 12= :30 PM, Eric Rescorla <ekr@rtfm.com> wrote:
Unless I'm confused, you get a similar check with ICE because the targe= t
needs not only to respond to STUN in general but also to STUN with
particular credentials, which means that the target can enforce that only specific sites get those credentials.


You are right. It was me who was confused. With = ICE it is even stricter, since the per call credentials are used. What I am= concerned about, is there a way to game those credentials (which can be se= nt by a malicious web server) to allow ICE check to succeed when used again= st a public STUN server with known credentials?
_____________
Roman Shpount

--f46d0413911df327f004afbdb895-- From bernard_aboba@hotmail.com Thu Oct 20 09:48: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 4364921F8C6D for ; Thu, 20 Oct 2011 09:48:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.426 X-Spam-Level: X-Spam-Status: No, score=-102.426 tagged_above=-999 required=5 tests=[AWL=0.172, 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 OKU3brperr7P for ; Thu, 20 Oct 2011 09:48:22 -0700 (PDT) Received: from blu0-omc1-s28.blu0.hotmail.com (blu0-omc1-s28.blu0.hotmail.com [65.55.116.39]) by ietfa.amsl.com (Postfix) with ESMTP id 57B0021F8C68 for ; Thu, 20 Oct 2011 09:48:22 -0700 (PDT) Received: from BLU152-W65 ([65.55.116.9]) by blu0-omc1-s28.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 20 Oct 2011 09:48:21 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_6cb35439-6428-4cfa-aa48-e312d655682f_" X-Originating-IP: [24.17.217.162] From: Bernard Aboba To: Date: Thu, 20 Oct 2011 09:48:21 -0700 Importance: Normal In-Reply-To: References: , , MIME-Version: 1.0 X-OriginalArrivalTime: 20 Oct 2011 16:48:21.0753 (UTC) FILETIME=[13AE9E90:01CC8F48] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Same location media X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 16:48:23 -0000 --_6cb35439-6428-4cfa-aa48-e312d655682f_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Roman said: "Technically speaking=2C if TURN server relay address is used=2C connectivi= ty between the RTC client and TURN server can be TCP (or TLS). So=2C ICE ch= eck would be delivered to the RTC client via TCP tunnel." [BA] Yes=2C that can be done. But often we find that a firewall that does = not permit UDP traversal also has strict policies about TCP (e.g. only to a= strict set of destination ports). This is why HTTP traversal is impleme= nted by almost all Web conferencing services.=20 = --_6cb35439-6428-4cfa-aa48-e312d655682f_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Roman said:

"Technically speaking=2C if TURN server relay address is= used=2C connectivity between the RTC client and TURN server can be TCP (or= TLS). So=2C ICE check would be delivered to the RTC client via TCP tunnel.= "

[BA] Yes=2C that can be done. =3B But often we find that a fir= ewall that does not permit UDP traversal also has strict policies about TCP= (e.g. only to a strict set of destination ports). =3B =3B =3B = This is why HTTP traversal is implemented by almost all Web conferencing se= rvices.

= --_6cb35439-6428-4cfa-aa48-e312d655682f_-- From matthew.kaufman@skype.net Thu Oct 20 09:48: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 C4D1921F8C68 for ; Thu, 20 Oct 2011 09:48:44 -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 mWCkBN2UVajT for ; Thu, 20 Oct 2011 09:48:44 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id C177F21F8C7B for ; Thu, 20 Oct 2011 09:48:43 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id 961D21711; Thu, 20 Oct 2011 18:48:42 +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=HBSGBSmoc7KYIvRPs6edDdFu8OY=; b=uJx3nDMVf Vv9EVgCnefo3LWeIVAH/QRS9sgCrf5I6NfeNreoWXQMiBSl9M2L4qveG4Cdir4o5 m6B8ih81SC6UAC34+Wq/cFZHhOcS77ueHqkli1EEK08of9J9l+V5kYqf+0xVmq14 eAJjcv4au/2xpJIxS6X25E3MErfrXbKqEg= 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=b68qQxTXURHiqibcOYUE0XLto82BovMpMPWW/O58ws+kMo+U Aqg+Jq2jQAqNxSBZx+oaXq2Bw5Yqo0ZcZE/rPA5G/prUZ3Sy6krKAFkAUJ1DeWWf IUtABlOp2kCBj7jrvFEY83xkuiGjk/q4uEwMs4VxtSJ/HfGWIYoLWXqI1lw= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id 946877F6; Thu, 20 Oct 2011 18:48:42 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id 524281685A01; Thu, 20 Oct 2011 18:48:42 +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 Q+HJmw-Vv603; Thu, 20 Oct 2011 18:48:41 +0200 (CEST) Received: from Matthew-Kaufman-Air.local (unknown [131.107.200.34]) by zimbra.skype.net (Postfix) with ESMTPSA id 217723507015; Thu, 20 Oct 2011 18:48:39 +0200 (CEST) Message-ID: <4EA050E9.6000705@skype.net> Date: Thu, 20 Oct 2011 09:48:41 -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: In-Reply-To: Content-Type: multipart/alternative; boundary="------------060005000801010005000302" Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Same location media X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 16:48:44 -0000 This is a multi-part message in MIME format. --------------060005000801010005000302 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 10/20/11 9:27 AM, Roman Shpount wrote: > Changing the topic from "A plea for simplicity, marketability..." > > On Thu, Oct 20, 2011 at 11:57 AM, I=F1aki Baz Castillo > wrote: > > Also you are asuming that the media is sent to the same IP of the w= eb > server (in case a RTCweb scenario does not include user2user calls)= . > This is a too much simplified scenario, and you miss that a DNS A > record can point to N IP's, and you also miss the case in which the > webserver has an IP different than the media server (regardless the= y > both are located within the same provider infrastucture). The brows= er > cannot determine it by itself, so security is always a need, and IM= HO > it's a bad idea to allow a very corner case in which such security > could be relaxed. > > > I am not missing the DNS issues. I wanted to bring this up in my=20 > previous email, but did not want to confuse the issue. I don't=20 > advocate for this case at all, I just wanted to clarify that "same=20 > origin media" does not necessarily mean two phones in the same=20 > location and means media going to the same location as JavaScript=20 > origination. > > Few additional points related to this: > > 1. This is what Flash is doing now for streaming media. It does not=20 > need consent to send media to the same server that sent the flash app. Flash can send media to ANY server that accepts the RTMP or RTMFP=20 connection. (And obviously it can attempt to open a connection to any=20 address using these protocols.) The server can then examine headers to determine where the SWF file came=20 from, etc. The "consent" model for Flash is that if you speak RTMP or RTMFP, you=20 understand what that is... and neither protocol looks like anything else=20 on the wire. Matthew Kaufman --------------060005000801010005000302 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 10/20/11 9:27 AM, Roman Shpount wrote:
Changing the topic from "A plea for simplicity, marketability..."

On Thu, Oct 20, 2011 at 11:57 AM, Iñaki Baz Castillo <ibc@aliax.net> wrote:
Also you are asuming that the media is sent to the same IP of the web
server (in case a RTCweb scenario does not include user2user calls).
This is a too much simplified scenario, and you miss that a DNS A
record can point to N IP's, and you also miss the case in which the
webserver has an IP different than the media server (regardless they
both are located within the same provider infrastucture). The browser
cannot determine it by itself, so security is always a need, and IMHO
it's a bad idea to allow a very corner case in which such security
could be relaxed.


I am not missing the DNS issues. I wanted to bring this up in my previous email, but did not want to confuse the issue. I don't advocate for this case at all, I just wanted to clarify that "same origin media" does not necessarily mean two phones in the same location and means media going to the same location as JavaScript origination.

Few additional points related to this:

1. This is what Flash is doing now for streaming media. It does not need consent to send media to the same server that sent the flash app.

Flash can send media to ANY server that accepts the RTMP or RTMFP connection. (And obviously it can attempt to open a connection to any address using these protocols.)

The server can then examine headers to determine where the SWF file came from, etc.

The "consent" model for Flash is that if you speak RTMP or RTMFP, you understand what that is... and neither protocol looks like anything else on the wire.

Matthew Kaufman
--------------060005000801010005000302-- From matthew.kaufman@skype.net Thu Oct 20 09:51: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 F07A321F8B86 for ; Thu, 20 Oct 2011 09:51:17 -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=[AWL=0.001, 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 ocPIKTcuOd+K for ; Thu, 20 Oct 2011 09:51:16 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id 2183421F8B76 for ; Thu, 20 Oct 2011 09:51:14 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id 6CC841710; Thu, 20 Oct 2011 18:51: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=P0mGayBXg8kHP0 5rYVTc6mau8So=; b=p8clLVlyseQkjb7gIgnzL4DsQ6l7+RwbLsgRUN4W7A38L8 ++sNX/NZ7LPVqIxTmnmp/L02HHftOYITOw9V9r/a2IQ/ifRjM4DVLIwM7XMtdbfJ +MlavaGvJK/wqgJCd6Bgern1BJH3vEzjc4e6cvnKPb5t/TK/OdnwuC5r1+/Ts= 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=hJt9CJ4BOBfTXDj1/OK4s9 ma/IcTQoJKQfPKstneXm1kPNR+B9spnfrOabpzqs8p/Am7/+BzpYGPU2jc0rg2xS Fd6Xkm0KicezhpTXj0Wr0UNFLz0qGu2jejGq+BsS2LCatw2w/F2KH+J+uWxYwe02 CmteGOn+cLANxBaX2hJco= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id 6B6F87F6; Thu, 20 Oct 2011 18:51:13 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id 2202F3507A01; Thu, 20 Oct 2011 18:51:12 +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 Gkne6e023ChU; Thu, 20 Oct 2011 18:51:12 +0200 (CEST) Received: from Matthew-Kaufman-Air.local (unknown [131.107.200.34]) by zimbra.skype.net (Postfix) with ESMTPSA id AC79E3506F9C; Thu, 20 Oct 2011 18:51:11 +0200 (CEST) Message-ID: <4EA05180.2010405@skype.net> Date: Thu, 20 Oct 2011 09:51:12 -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: Bernard Aboba 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] Same location media X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 16:51:19 -0000 On 10/20/11 9:41 AM, Bernard Aboba wrote: > > One of the requirements in the use case document is the ability to > work across firewalls that do not permit UDP. In practice, this > constraint is encountered surprisingly often (as much as 15-25% of the > time, in enterprise scenarios). The implication is that ICE will > require a fallback, such as sending media over HTTP. The fallback that has been proposed in every document I've ever seen is TURN over TCP/TLS. (Not arguing that this is sufficient... the fact is that sending media over port 80 may be advantageous, and being able to send it through web proxies might be even better.) > In a fallback situation, requiring ICE would be silly, since it has > typically failed in order for fallback to be considered. STUN connectivity checks can proceed with the far end of a TURN-forwarded connection. Matthew Kaufman From roman@telurix.com Thu Oct 20 09:52: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 723FA21F8C48 for ; Thu, 20 Oct 2011 09:52:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.887 X-Spam-Level: X-Spam-Status: No, score=-2.887 tagged_above=-999 required=5 tests=[AWL=0.089, 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 f3l5LkHLuTEM for ; Thu, 20 Oct 2011 09:52:55 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7A90421F8BA7 for ; Thu, 20 Oct 2011 09:52:54 -0700 (PDT) Received: by ggnv1 with SMTP id v1so3581766ggn.31 for ; Thu, 20 Oct 2011 09:52:54 -0700 (PDT) Received: by 10.101.158.4 with SMTP id k4mr2558844ano.94.1319129574060; Thu, 20 Oct 2011 09:52:54 -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 n7sm27335671ano.17.2011.10.20.09.52.53 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 20 Oct 2011 09:52:53 -0700 (PDT) Received: by ywa8 with SMTP id 8so3589483ywa.31 for ; Thu, 20 Oct 2011 09:52:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.74.4 with SMTP id p4mr21262483pbv.47.1319129572884; Thu, 20 Oct 2011 09:52:52 -0700 (PDT) Received: by 10.68.47.40 with HTTP; Thu, 20 Oct 2011 09:52:52 -0700 (PDT) In-Reply-To: References: Date: Thu, 20 Oct 2011 12:52:52 -0400 Message-ID: From: Roman Shpount To: Bernard Aboba Content-Type: multipart/alternative; boundary=f46d0413911d9ac26a04afbdc943 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Same location media X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 16:52:55 -0000 --f46d0413911d9ac26a04afbdc943 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Oct 20, 2011 at 12:48 PM, Bernard Aboba wrote: > Roman said: > > "Technically speaking, if TURN server relay address is used, connectivity > between the RTC client and TURN server can be TCP (or TLS). So, ICE check > would be delivered to the RTC client via TCP tunnel." > > [BA] Yes, that can be done. But often we find that a firewall that does > not permit UDP traversal also has strict policies about TCP (e.g. only to a > strict set of destination ports). This is why HTTP traversal is > implemented by almost all Web conferencing services. > > You can also operate a TURN server on TCP port 80 and TLS port 443. In case of TLS connection firewall will have no way to distinguish TURN TLS traffic from HTTPS traffic. Support for HTTP/SOCKS based connections to TURN servers can be implemented as well. BTW, this is why it is essential to be able to specify TURN server location via JavaScript to the RTC client. _____________ Roman Shpount --f46d0413911d9ac26a04afbdc943 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Oct 20, 2011 at 12:48 = PM, Bernard Aboba <bernard_aboba@hotmail.com> wrote:
Roman said:

"Technically speaking, if TURN server relay address= is used, connectivity between the RTC client and TURN server can be TCP (o= r TLS). So, ICE check would be delivered to the RTC client via TCP tunnel.&= quot;

[BA] Yes, that can be done.=A0 But often we find that a firewall = that does not permit UDP traversal also has strict policies about TCP (e.g.= only to a strict set of destination ports).=A0=A0=A0 This is why HTTP trav= ersal is implemented by almost all Web conferencing services.

=A0
You can also op= erate a TURN server on TCP port 80 and TLS port 443. In case of TLS connec= tion firewall will have no way to distinguish TURN TLS traffic from HTTPS t= raffic. Support for HTTP/SOCKS based connections to TURN servers can be imp= lemented as well. BTW, this is why it is essential to be able to specify TU= RN server location via JavaScript to the RTC client.
_____________
Roman Shpount

--f46d0413911d9ac26a04afbdc943-- From ibc@aliax.net Thu Oct 20 09:56:00 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D69E21F869E for ; Thu, 20 Oct 2011 09:56:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.634 X-Spam-Level: X-Spam-Status: No, score=-2.634 tagged_above=-999 required=5 tests=[AWL=0.043, 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 q7OBosQhW1bu for ; Thu, 20 Oct 2011 09:56: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 E1F6521F8678 for ; Thu, 20 Oct 2011 09:55:59 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so3189176vcb.31 for ; Thu, 20 Oct 2011 09:55:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.124.70 with SMTP id mg6mr283826obb.54.1319129759219; Thu, 20 Oct 2011 09:55:59 -0700 (PDT) Received: by 10.182.144.9 with HTTP; Thu, 20 Oct 2011 09:55:59 -0700 (PDT) In-Reply-To: References: Date: Thu, 20 Oct 2011 18:55:59 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Bernard Aboba Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Same location media X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 16:56:00 -0000 2011/10/20 Bernard Aboba : > "Technically speaking, if TURN server relay address is used, connectivity > between the RTC client and TURN server can be TCP (or TLS). So, ICE check > would be delivered to the RTC client via TCP tunnel." > > [BA] Yes, that can be done.=C2=A0 But often we find that a firewall that = does not > permit UDP traversal also has strict policies about TCP (e.g. only to a > strict set of destination ports).=C2=A0=C2=A0=C2=A0 This is why HTTP trav= ersal is > implemented by almost all Web conferencing services. Well, if the network admin does not want that internet works, then this is the end. But we cannot follow the "WWW vision" of making internet just TCP port 80/443. --=20 I=C3=B1aki Baz Castillo From wolfgang.beck01@googlemail.com Thu Oct 20 09:59: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 85AF121F8BA4 for ; Thu, 20 Oct 2011 09:59:01 -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 AFxH7JvvNUf5 for ; Thu, 20 Oct 2011 09:59:01 -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 0AB6421F86B3 for ; Thu, 20 Oct 2011 09:59:00 -0700 (PDT) Received: by yxj19 with SMTP id 19so3615313yxj.31 for ; Thu, 20 Oct 2011 09:59:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wZObR9Zc6UTSHOYnHQvnimsKwLJTBrEIfe8tjI2Os6E=; b=Hh4dyOkSIU/w3qje7P+jm5tDJgeHMY7VEgySvT0rN11X0w8sSDKdlKyyejqhiLihr2 j9xBKWNU6+9Fb7fus/PeBeSv9uRdaMI+3czsgAzcZnpBVjE6e8pIj9vplnKbOmD9q6l2 n6dAxR6RT7vR0QGKjgEMVO8NIWlaA5BW34inM= MIME-Version: 1.0 Received: by 10.68.4.200 with SMTP id m8mr3815362pbm.50.1319129940324; Thu, 20 Oct 2011 09:59:00 -0700 (PDT) Received: by 10.68.55.230 with HTTP; Thu, 20 Oct 2011 09:59:00 -0700 (PDT) In-Reply-To: <4E9FD139.2010406@ericsson.com> References: <4E9E9794.8000901@alvestrand.no> <4E9FD139.2010406@ericsson.com> Date: Thu, 20 Oct 2011 18:59:00 +0200 Message-ID: From: Wolfgang Beck To: Magnus Westerlund Content-Type: text/plain; charset=ISO-8859-1 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Friday Agenda: Re: Friday Call details for signaling discussion X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 16:59:01 -0000 On Thu, Oct 20, 2011 at 9:43 AM, Magnus Westerlund wrote: > From my perspective both draft-beck-rtcweb-alt-ic-00 and > draft-ibc-rtcweb-sip-websocket-00 are relevant documents to the > discussion as they provides useful proposals on how interconnect and SIP > interop respectively can be done. But as they aren't proposals for how > the actual signaling solution should work. Thus these are homework but > don't get presentation time. It's a bit difficult to present an actual signaling situation if the proposal is not to specify a signaling solution at all.. Wolfgang Beck From matthew.kaufman@skype.net Thu Oct 20 10:00: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 F1B6121F8BBA for ; Thu, 20 Oct 2011 10:00:27 -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 tRGVpjIrKv61 for ; Thu, 20 Oct 2011 10:00:27 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id 545F821F8BA7 for ; Thu, 20 Oct 2011 10:00:27 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id A1ECE16FC; Thu, 20 Oct 2011 19:00: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=lcyTBM+JmXHn3r mjBTbywBf+8TY=; b=keCwRb1PlfyIelWD2d2Ab6KgeoscSjIbf2zWAtBQ5QS76N Y/21vXo4CT2yujlPRLohByBNvNHRFWdWP4xHnSvVke5SHgQPvf8qjq03BmMDUXH8 wPgrxuEBaz4RRdfrU4n3wbMSinzs75dWtbdKOWSvnd3hd/LRVfpQLEB2Hi+qY= 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=PNoL8wUiuOBAf/TyD5/7dH 00mHvsIfdNMjnkyuS7J4drJYADyAOU2RCW7PbQDSHH4OxzHUKBoGNJw1p1XhW30d 8GyTlG1ii2Oi0aa2jB9mRlo08W+MhjLVwkAB62oa9NNzItamsm7x+MDaDAAxlwac zAtJ3/t6id9qqNMB4OTWg= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id A08867F6; Thu, 20 Oct 2011 19:00:26 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id 60A7E35075C9; Thu, 20 Oct 2011 19:00: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 cwrJEgo+HKSa; Thu, 20 Oct 2011 19:00:25 +0200 (CEST) Received: from Matthew-Kaufman-Air.local (unknown [131.107.200.34]) by zimbra.skype.net (Postfix) with ESMTPSA id 13C013506E57; Thu, 20 Oct 2011 19:00:24 +0200 (CEST) Message-ID: <4EA053A9.40107@skype.net> Date: Thu, 20 Oct 2011 10:00:25 -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: Wolfgang Beck References: <4E9E9794.8000901@alvestrand.no> <4E9FD139.2010406@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] Friday Agenda: Re: Friday Call details for signaling discussion X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 17:00:28 -0000 On 10/20/11 9:59 AM, Wolfgang Beck wrote: > > It's a bit difficult to present an actual signaling situation if the > proposal is not to specify a signaling solution at all.. > > +1 Matthew Kaufman From bernard_aboba@hotmail.com Thu Oct 20 10: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 5452B21F8C08 for ; Thu, 20 Oct 2011 10:02:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.447 X-Spam-Level: X-Spam-Status: No, score=-102.447 tagged_above=-999 required=5 tests=[AWL=0.151, 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 mimvSzdI1Pa7 for ; Thu, 20 Oct 2011 10:02:36 -0700 (PDT) Received: from blu0-omc1-s25.blu0.hotmail.com (blu0-omc1-s25.blu0.hotmail.com [65.55.116.36]) by ietfa.amsl.com (Postfix) with ESMTP id BF6F421F8BFE for ; Thu, 20 Oct 2011 10:02:36 -0700 (PDT) Received: from BLU152-W40 ([65.55.116.8]) by blu0-omc1-s25.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 20 Oct 2011 10:02:30 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_077a6252-5e01-4004-b065-786c0196a5fa_" X-Originating-IP: [24.17.217.162] From: Bernard Aboba To: Date: Thu, 20 Oct 2011 10:02:29 -0700 Importance: Normal In-Reply-To: References: , , , , MIME-Version: 1.0 X-OriginalArrivalTime: 20 Oct 2011 17:02:30.0048 (UTC) FILETIME=[0D4E2A00:01CC8F4A] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Same location media X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 17:02:37 -0000 --_077a6252-5e01-4004-b065-786c0196a5fa_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Roman said: "You can also operate a TURN server on TCP port 80 and TLS port 443. In ca= se of TLS connection firewall will have no way to distinguish TURN TLS traf= fic from HTTPS traffic. Support for HTTP/SOCKS based connections to TURN se= rvers can be implemented as well. BTW=2C this is why it is essential to be = able to specify TURN server location via JavaScript to the RTC client." [BA] With respect to TURN with TCP/TLS we have found some firewalls that ac= tually do deep packet inspection. So if you're sending to TCP port 80 and = aren't using HTTP=2C or are sending to port 443 and aren't using TLS (or ar= e using TLS extensions the firewall doesn't understand)=2C the firewall can= block. So yes=2C it is important to support TURN with TCP/TLS=2C but it = should be recognized that even with that=2C there will still be a significa= nt percentage of failures.=20 = --_077a6252-5e01-4004-b065-786c0196a5fa_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Roman said:

"You can also operate a TURN server on TCP port 80 and = TLS port 443. In case of TLS connection firewall will have no way to distin= guish TURN TLS traffic from HTTPS traffic. Support for HTTP/SOCKS based con= nections to TURN servers can be implemented as well. BTW=2C this is why it = is essential to be able to specify TURN server location via JavaScript to t= he RTC client."

[BA] With respect to TURN with TCP/TLS we have found= some firewalls that actually do deep packet inspection. =3B So if you'= re sending to TCP port 80 and aren't using HTTP=2C or are sending to port 4= 43 and aren't using TLS (or are using TLS extensions the firewall doesn't u= nderstand)=2C the firewall can block. =3B =3B So yes=2C it is impor= tant to support TURN with TCP/TLS=2C but it should be recognized that even = with that=2C there will still be a significant percentage of failures.
=
= --_077a6252-5e01-4004-b065-786c0196a5fa_-- From HKaplan@acmepacket.com Thu Oct 20 10:03: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 C869A21F8BFE for ; Thu, 20 Oct 2011 10:03:11 -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.127, 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 f6cUQtm9VhaA for ; Thu, 20 Oct 2011 10:03:11 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 293FA21F8BBA for ; Thu, 20 Oct 2011 10:03:11 -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, 20 Oct 2011 13:03:02 -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, 20 Oct 2011 13:03:02 -0400 From: Hadriel Kaplan To: Roman Shpount Thread-Topic: [rtcweb] Why are we asking the wrong questions? Thread-Index: AQHMj0ogLgat7UQ4sE6A6BZTtTU/lQ== Date: Thu, 20 Oct 2011 17:03:01 +0000 Message-ID: <9794C359-45FC-430D-B2E0-4971441C834A@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: [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: "" Subject: Re: [rtcweb] Why are we asking the wrong questions? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 17:03:11 -0000 +1 Or rather, in memory of Dennis Ritchie: agree++ -hadriel On Oct 20, 2011, at 11:16 AM, Roman Shpount wrote: > I am sorry for another rant, but it is painful to watch the discussion on= this list. We have a chance to create something great, but instead wasting= our time discussing irrelevant topics. >=20 > First irrelevant topic is "We want something that will allow to setup a m= edia call in 20 lines of JavaScript". If we are looking for something that = will to do this using the right JavaScript library and web server component= s, then we will probably achieve this goal. If someone expects to create so= mething that by adding code at the browser level and no web server cooperat= ion will setup a call between two arbitrary browsers, then this is a fool's= quest. To setup a call browsers will need a meet point on the public IP. O= n one hand we have hundred different ways to implement this using current t= echnology using a JavaScript library and one or the other server component.= On the other hand we have no standard protocol to implement a meet point (= some might argue for SIP or XMPP) but they do too much and do not implement= meet point functionality too well. If you want something extremely simple = just put a tel (or sip where supported) URL in your HTML. >=20 > Second irrelevant topic is PSTN vs some future web technology. We should = stop arguing about supporting or not supporting PSTN connectivity and tailo= ring to the needs of some future start up. It is not about PSTN. It is abou= t supporting currently used call negotiation scenarios. RTC will need to su= pport all the scenarios actively used right now. Ideally, it should be able= to support future scenarios that we cannot support now due to offer/answer= limitations. Deliberately disabling support for current applications is mi= sguided not only from the point of view of interoperability, but from the p= oint of view of disabling future applications. >=20 > As it was said numerous times on this list, there are quite a few example= s of RTC applications currently being used on the web. Their main limitatio= n is that they are using some sort of proprietary plugin to implement real = time media connections. The goal of this group is to create a set of recomm= endations for standard implementation of this functionality. So the right q= uestion would be what is the minimal feature set that needs to be added to = the browser which will allow web developers to create such applications. Ad= ding convenience APIs or optional functionality can be done later.=20 > _____________ > Roman Shpount > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From bernard_aboba@hotmail.com Thu Oct 20 10:07: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 67B9D21F8C5F for ; Thu, 20 Oct 2011 10:07:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.464 X-Spam-Level: X-Spam-Status: No, score=-102.464 tagged_above=-999 required=5 tests=[AWL=0.134, 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 uvexNd2xzFer for ; Thu, 20 Oct 2011 10:07:23 -0700 (PDT) Received: from blu0-omc4-s3.blu0.hotmail.com (blu0-omc4-s3.blu0.hotmail.com [65.55.111.142]) by ietfa.amsl.com (Postfix) with ESMTP id DDAE121F8C5D for ; Thu, 20 Oct 2011 10:07:22 -0700 (PDT) Received: from BLU152-W17 ([65.55.111.137]) by blu0-omc4-s3.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 20 Oct 2011 10:07:22 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_5fbdbc83-ec1c-4b45-bede-820832788673_" X-Originating-IP: [24.17.217.162] From: Bernard Aboba To: , Date: Thu, 20 Oct 2011 10:07:21 -0700 Importance: Normal In-Reply-To: <4EA053A9.40107@skype.net> References: , <4E9E9794.8000901@alvestrand.no> <4E9FD139.2010406@ericsson.com>, , <4EA053A9.40107@skype.net> MIME-Version: 1.0 X-OriginalArrivalTime: 20 Oct 2011 17:07:22.0488 (UTC) FILETIME=[BB9CF780:01CC8F4A] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Friday Agenda: Re: Friday Call details for signaling discussion X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 17:07:23 -0000 --_5fbdbc83-ec1c-4b45-bede-820832788673_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable +1 > Date: Thu=2C 20 Oct 2011 10:00:25 -0700 > From: matthew.kaufman@skype.net > To: wolfgang.beck01@googlemail.com > CC: rtcweb@ietf.org > Subject: Re: [rtcweb] Friday Agenda: Re: Friday Call details for signalin= g discussion >=20 > On 10/20/11 9:59 AM=2C Wolfgang Beck wrote: > > > > It's a bit difficult to present an actual signaling situation if the > > proposal is not to specify a signaling solution at all.. > > > > > +1 >=20 > Matthew Kaufman = --_5fbdbc83-ec1c-4b45-bede-820832788673_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
+1

>=3B Date: Thu=2C 20 Oct 2011 10:00:25 -0700
>=3B Fro= m: matthew.kaufman@skype.net
>=3B To: wolfgang.beck01@googlemail.com>=3B CC: rtcweb@ietf.org
>=3B Subject: Re: [rtcweb] Friday Agenda:= Re: Friday Call details for signaling discussion
>=3B
>=3B On 1= 0/20/11 9:59 AM=2C Wolfgang Beck wrote:
>=3B >=3B
>=3B >=3B I= t's a bit difficult to present an actual signaling situation if the
>= =3B >=3B proposal is not to specify a signaling solution at all..
>= =3B >=3B
>=3B >=3B
>=3B +1
>=3B
>=3B Matthew Kaufm= an

= --_5fbdbc83-ec1c-4b45-bede-820832788673_-- From HKaplan@acmepacket.com Thu Oct 20 10: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 CF51D21F8C0D for ; Thu, 20 Oct 2011 10:16:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.476 X-Spam-Level: X-Spam-Status: No, score=-2.476 tagged_above=-999 required=5 tests=[AWL=0.123, 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 uBIQfcpKZyBz for ; Thu, 20 Oct 2011 10:16:55 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id DF95B21F8C0A for ; Thu, 20 Oct 2011 10: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, 20 Oct 2011 13:16: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; Thu, 20 Oct 2011 13:16:53 -0400 From: Hadriel Kaplan To: Matthew Kaufman Thread-Topic: [rtcweb] Same location media Thread-Index: AQHMj0wPU0CJsEVX60m8ZdgWcrqP2w== Date: Thu, 20 Oct 2011 17:16:52 +0000 Message-ID: References: <4EA050E9.6000705@skype.net> In-Reply-To: <4EA050E9.6000705@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: "" Subject: Re: [rtcweb] Same location media X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 17:16:55 -0000 I may be mis-understanding what type of consent you folks are talking about= , but RTMP is over TCP. =20 For any TCP-based mechanism, you get some "consent" from the TCP SYN/ACK yo= u get back from the far end, as opposed to say an ICMP port error. Since t= he TCP layer won't send data until that, it's a natural consent gate. RTMFP uses UDP but I believe there is in fact a handshake required in the b= eginning and that's effectively consent. =20 -hadriel On Oct 20, 2011, at 12:48 PM, Matthew Kaufman wrote: > Flash can send media to ANY server that accepts the RTMP or RTMFP connect= ion. (And obviously it can attempt to open a connection to any address usin= g these protocols.) >=20 > The server can then examine headers to determine where the SWF file came = from, etc. >=20 > The "consent" model for Flash is that if you speak RTMP or RTMFP, you und= erstand what that is... and neither protocol looks like anything else on th= e wire. >=20 > Matthew Kaufman > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From randell-ietf@jesup.org Thu Oct 20 10:44: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 4CF0321F8BB7 for ; Thu, 20 Oct 2011 10:44:45 -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 ZMZzCM4YA0TK for ; Thu, 20 Oct 2011 10:44: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 A1D6C21F8BE8 for ; Thu, 20 Oct 2011 10:44: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 1RGwfb-00086w-F7 for rtcweb@ietf.org; Thu, 20 Oct 2011 12:44:43 -0500 Message-ID: <4EA05CF0.6010904@jesup.org> Date: Thu, 20 Oct 2011 13:40:00 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <9C8CA816-65FB-41A0-999C-4C43128CAAB4@danyork.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: [rtcweb] Single-origin and consent X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 17:44:45 -0000 On 10/20/2011 11:36 AM, Eric Rescorla wrote: > On Thu, Oct 20, 2011 at 7:32 AM, Bernard Aboba > wrote: >> No, I'm saying that *if* a developer remains within the "single origin" >> model, that a number of requirements for peer-to-peer operation do not >> apply. >> >> Also that the APIs should also enable media to be sent over a websocket to >> the "single origin" as well as a PeerConnection. >> > > I don't think I'm following you're argument. ISTM that there are two > conditions that one > might term "single origin": > > 1. Alice and Bob are on the same site (e.g., PokerStars) and are > calling each other via P2P media, > 2. Alice and Bob are on the same site and are calling each other > via media over WS. I'll add a third: Alice and Bob are on the same site, and are participating in a (potentially) multi-person conference run through the site, which is acting as a mixer or at least relay. Media is sent via normal PeerConnection channels, encrypted with DTLS-SRTP. In this limited case, each participant is sending media to the same site (*) as the JS code is loaded from. So, the questions here would be a) can we relax ICE consent checks if the site/app so wishes and b) should we? I think we can (if the app tells us to, since it's "same-origin" and the app should know), but I'm a little less certain of the "should". Is there an attack wherein someone could 'host' some JS content (app) on a site and use it to attack/DoS that site from multiple places? It seems at least plausible. -- Randell Jesup randell-ietf@jesup.org From harald@alvestrand.no Thu Oct 20 10: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 6487A21F8BBB for ; Thu, 20 Oct 2011 10:54:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dLZWIAjR81t1 for ; Thu, 20 Oct 2011 10:54:06 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 371BD21F8BB6 for ; Thu, 20 Oct 2011 10:54:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8457B39E16F for ; Thu, 20 Oct 2011 19:54: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 gIEvf2NnSTQj for ; Thu, 20 Oct 2011 19:54:04 +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 B5DC839E072 for ; Thu, 20 Oct 2011 19:54:04 +0200 (CEST) Message-ID: <4EA0603C.7050304@alvestrand.no> Date: Thu, 20 Oct 2011 19:54:04 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux i686; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4E9E9794.8000901@alvestrand.no> <4E9FD139.2010406@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Friday Agenda: Re: Friday Call details for signaling discussion X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 17:54:07 -0000 On 10/20/2011 06:59 PM, Wolfgang Beck wrote: > On Thu, Oct 20, 2011 at 9:43 AM, Magnus Westerlund > wrote: > >> From my perspective both draft-beck-rtcweb-alt-ic-00 and >> draft-ibc-rtcweb-sip-websocket-00 are relevant documents to the >> discussion as they provides useful proposals on how interconnect and SIP >> interop respectively can be done. But as they aren't proposals for how >> the actual signaling solution should work. Thus these are homework but >> don't get presentation time. > It's a bit difficult to present an actual signaling situation if the > proposal is not to specify a signaling solution at all.. Well, there's always the idea of specifying how the group's goals can be met without specifying a "signaling solution" (noting that, as Inaki has pointed out, this term has multiple meanings). A logical approach would involve showing that it is possible to do all the tasks that need to be done by the functions otherwise described as "signalling" through a reasonably described API, that all the tricky bits (such as deciding to use codec parameters that did not exist when the Javascript was written) can be done using only the information that this API will be willing to expose to the Javascript, and that it's reasonable to assume that the API cannot be used in ways that would negatively impact the safety, security and stability of the browser platform. I believe specifying an API such as is being proposed is a significant chunk of work, but I do not have the competence to even evaluate the size of the effort from the present state of my ignorance, far less the chances of arriving at something that can be used successfully. I'm just somewhat skeptical. Harald From mthornbu@adobe.com Thu Oct 20 10: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 3AF7811E8073 for ; Thu, 20 Oct 2011 10:58:26 -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 PGupEpiBR4+k for ; Thu, 20 Oct 2011 10:58:25 -0700 (PDT) Received: from exprod6og117.obsmtp.com (exprod6og117.obsmtp.com [64.18.1.39]) by ietfa.amsl.com (Postfix) with ESMTP id 1D85921F8BA8 for ; Thu, 20 Oct 2011 10:58:25 -0700 (PDT) Received: from outbound-smtp-2.corp.adobe.com ([193.104.215.16]) by exprod6ob117.postini.com ([64.18.5.12]) with SMTP; Thu, 20 Oct 2011 10:58:25 PDT Received: from inner-relay-1.corp.adobe.com (ms-exchange.macromedia.com [153.32.1.51]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id p9KHwMBb012829 for ; Thu, 20 Oct 2011 10:58:23 -0700 (PDT) Received: from nacas02.corp.adobe.com (nacas02.corp.adobe.com [10.8.189.100]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id p9KHwL5S016652 for ; Thu, 20 Oct 2011 10:58:22 -0700 (PDT) Received: from SJ1SWM219.corp.adobe.com (10.5.77.61) by nacas02.corp.adobe.com (10.8.189.100) with Microsoft SMTP Server (TLS) id 8.3.192.1; Thu, 20 Oct 2011 10:58:21 -0700 Received: from nambx05.corp.adobe.com ([10.8.189.124]) by SJ1SWM219.corp.adobe.com ([fe80::d55c:7209:7a34:fcf7%12]) with mapi; Thu, 20 Oct 2011 10:58:21 -0700 From: Michael Thornburgh To: "" Date: Thu, 20 Oct 2011 10:58:19 -0700 Thread-Topic: [rtcweb] Same location media Thread-Index: AQHMj0wPU0CJsEVX60m8ZdgWcrqP25WFfYHg Message-ID: <02485FF93524F8408ECA9608E47D9F2007CACFEB28@nambx05.corp.adobe.com> References: <4EA050E9.6000705@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [rtcweb] Same location media X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 17:58:26 -0000 correct. RTMP is over TCP to a server, and has the TCP handshake *plus* the= RTMP handshake *plus* any application-level authentication required by the= RTMP server. RTMP can also be tunneled over HTTP. RTMFP is over UDP and has its own 4-way handshake (see Matthew's presentati= on to tsv-area at IETF 77 for what that handshake looks like). when communi= cating with a server, a client must perform the RTMFP handshake plus any ap= plication-level authentication required by the server. to communicate with = a peer (another client), a client must perform the RTMFP handshake with tha= t peer, which requires knowing that peer's unique cryptographic peer ID. th= e handshake won't work if the destination doesn't speak RTMFP or if the des= tination isn't the peer that the initiator is trying to reach. -mike On Oct 20, 2011, at 10:17 AM, Hadriel Kaplan wrote: >=20 > I may be mis-understanding what type of consent you folks are talking abo= ut, but RTMP is over TCP. =20 > For any TCP-based mechanism, you get some "consent" from the TCP SYN/ACK = you get back from the far end, as opposed to say an ICMP port error. Since= the TCP layer won't send data until that, it's a natural consent gate. >=20 > RTMFP uses UDP but I believe there is in fact a handshake required in the= beginning and that's effectively consent. > =20 > -hadriel >=20 >=20 > On Oct 20, 2011, at 12:48 PM, Matthew Kaufman wrote: >=20 > > Flash can send media to ANY server that accepts the RTMP or RTMFP conne= ction. (And obviously it can attempt to open a connection to any address us= ing these protocols.) > >=20 > > The server can then examine headers to determine where the SWF file cam= e from, etc. > >=20 > > The "consent" model for Flash is that if you speak RTMP or RTMFP, you u= nderstand what that is... and neither protocol looks like anything else on = the wire. > >=20 > > Matthew Kaufman From roman@telurix.com Thu Oct 20 10:58: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 88C8121F8BBB for ; Thu, 20 Oct 2011 10:58:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.892 X-Spam-Level: X-Spam-Status: No, score=-2.892 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nq5j5CbqGEFz for ; Thu, 20 Oct 2011 10:58:43 -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 DCD4F21F8B74 for ; Thu, 20 Oct 2011 10:58:42 -0700 (PDT) Received: by ywa8 with SMTP id 8so3660052ywa.31 for ; Thu, 20 Oct 2011 10:58:42 -0700 (PDT) Received: by 10.236.197.99 with SMTP id s63mr17355116yhn.14.1319133522467; Thu, 20 Oct 2011 10:58:42 -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 f24sm15006770yhk.5.2011.10.20.10.58.41 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 20 Oct 2011 10:58:42 -0700 (PDT) Received: by ggnv1 with SMTP id v1so3649948ggn.31 for ; Thu, 20 Oct 2011 10:58:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.23.6 with SMTP id i6mr21639643pbf.13.1319133520948; Thu, 20 Oct 2011 10:58:40 -0700 (PDT) Received: by 10.68.47.40 with HTTP; Thu, 20 Oct 2011 10:58:40 -0700 (PDT) In-Reply-To: References: Date: Thu, 20 Oct 2011 13:58:40 -0400 Message-ID: From: Roman Shpount To: Bernard Aboba Content-Type: multipart/alternative; boundary=bcaec5216223ed6c0104afbeb44d Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Same location media X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 17:58:43 -0000 --bcaec5216223ed6c0104afbeb44d Content-Type: text/plain; charset=ISO-8859-1 On Thu, Oct 20, 2011 at 1:02 PM, Bernard Aboba wrote: > [BA] With respect to TURN with TCP/TLS we have found some firewalls that > actually do deep packet inspection. So if you're sending to TCP port 80 and > aren't using HTTP, or are sending to port 443 and aren't using TLS (or are > using TLS extensions the firewall doesn't understand), the firewall can > block. So yes, it is important to support TURN with TCP/TLS, but it should > be recognized that even with that, there will still be a significant > percentage of failures. > TURN over TLS is non-distinguishable (unless I am missing something) from HTTPS connection. It is using the same TLS transport as HTTPS and firewall cannot inspect the actual data transmitted. Firewall can probably do some sort of heuristics based on packet sizes, but this will not be reliable enough to distinguish TURN over TLS from HTTPS (or real time media over HTTPS). In any case, if people are persistent enough they will find the way to block RTC connections regardless of the protocol used. _____________ Roman Shpount --bcaec5216223ed6c0104afbeb44d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Oct 20, 2011 at 1:= 02 PM, Bernard Aboba <bernard_aboba@hotmail.com> wrote:
[BA] With respect to TURN with TCP/TLS we have found some firewalls that ac= tually do deep packet inspection.=A0 So if you're sending to TCP port 8= 0 and aren't using HTTP, or are sending to port 443 and aren't usin= g TLS (or are using TLS extensions the firewall doesn't understand), th= e firewall can block.=A0=A0 So yes, it is important to support TURN with TC= P/TLS, but it should be recognized that even with that, there will still be= a significant percentage of failures.

TURN over TLS is non-distinguishable (unless I am mi= ssing something) from HTTPS connection. It is using the same TLS transport = as HTTPS and firewall cannot inspect the actual data transmitted. Firewall = can probably do some sort of heuristics based on packet sizes, but this wil= l not be reliable enough to distinguish TURN over TLS from HTTPS (or real t= ime media over HTTPS). In any case, if people are persistent enough they wi= ll find the way to block RTC connections regardless of the protocol used. _____________
Roman Shpount


--bcaec5216223ed6c0104afbeb44d-- From bernard_aboba@hotmail.com Thu Oct 20 11: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 B250721F84F8 for ; Thu, 20 Oct 2011 11:05:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.477 X-Spam-Level: X-Spam-Status: No, score=-102.477 tagged_above=-999 required=5 tests=[AWL=0.121, 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 le-Ic86kaNGx for ; Thu, 20 Oct 2011 11:05:40 -0700 (PDT) Received: from blu0-omc1-s27.blu0.hotmail.com (blu0-omc1-s27.blu0.hotmail.com [65.55.116.38]) by ietfa.amsl.com (Postfix) with ESMTP id 929F121F8BE4 for ; Thu, 20 Oct 2011 11:05:40 -0700 (PDT) Received: from BLU152-W47 ([65.55.116.9]) by blu0-omc1-s27.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 20 Oct 2011 11:05:40 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_95846c9f-2599-47d5-99bc-64d865dfd76f_" X-Originating-IP: [24.17.217.162] From: Bernard Aboba To: Date: Thu, 20 Oct 2011 11:05:39 -0700 Importance: Normal In-Reply-To: References: , , , , , , MIME-Version: 1.0 X-OriginalArrivalTime: 20 Oct 2011 18:05:40.0297 (UTC) FILETIME=[E0784390:01CC8F52] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Same location media X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 18:05:41 -0000 --_95846c9f-2599-47d5-99bc-64d865dfd76f_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yes=2C Turn over TLS is non-distinguishable. However=2C we've found deep i= nspection firewalls that will actually attempt to parse the TLS negotiation= . This creates brittleness to extensions in general. Anything that is not= "vanilla" could potentially fall prey=2C including TLS extensions=2C Webso= ckets=2C etc. Sad=2C but true. Date: Thu=2C 20 Oct 2011 13:58:40 -0400 Subject: Re: [rtcweb] Same location media From: roman@telurix.com To: bernard_aboba@hotmail.com CC: rtcweb@ietf.org On Thu=2C Oct 20=2C 2011 at 1:02 PM=2C Bernard Aboba wrote: [BA] With respect to TURN with TCP/TLS we have found some firewalls that ac= tually do deep packet inspection. So if you're sending to TCP port 80 and = aren't using HTTP=2C or are sending to port 443 and aren't using TLS (or ar= e using TLS extensions the firewall doesn't understand)=2C the firewall can= block. So yes=2C it is important to support TURN with TCP/TLS=2C but it = should be recognized that even with that=2C there will still be a significa= nt percentage of failures.=20 =20 TURN over TLS is non-distinguishable (unless I am missing something) from H= TTPS connection. It is using the same TLS transport as HTTPS and firewall c= annot inspect the actual data transmitted. Firewall can probably do some so= rt of heuristics based on packet sizes=2C but this will not be reliable eno= ugh to distinguish TURN over TLS from HTTPS (or real time media over HTTPS)= . In any case=2C if people are persistent enough they will find the way to = block RTC connections regardless of the protocol used. _____________ Roman Shpount = --_95846c9f-2599-47d5-99bc-64d865dfd76f_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Yes=2C Turn over TLS is non-distinguishable. =3B However=2C we've found= deep inspection firewalls that will actually attempt to parse the TLS nego= tiation. =3B This creates brittleness to extensions in general. =3B= Anything that is not "vanilla" could potentially fall prey=2C including TL= S extensions=2C Websockets=2C etc. =3B Sad=2C but true.

Date: Thu=2C 20 Oct 2011 13:58:40 -0400
Subject: Re= : [rtcweb] Same location media
From: roman@telurix.com
To: bernard_ab= oba@hotmail.com
CC: rtcweb@ietf.org



On Thu=2C Oct 20=2C 2011 at 1:02 PM=2C Bernard Aboba= <=3Bberna= rd_aboba@hotmail.com>=3B wrote:
[BA] With respect to TURN with TCP/TLS we have found some firewalls that ac= tually do deep packet inspection. =3B So if you're sending to TCP port = 80 and aren't using HTTP=2C or are sending to port 443 and aren't using TLS= (or are using TLS extensions the firewall doesn't understand)=2C the firew= all can block. =3B =3B So yes=2C it is important to support TURN wi= th TCP/TLS=2C but it should be recognized that even with that=2C there will= still be a significant percentage of failures.

TURN over TLS is non-distinguishable (unless I am mi= ssing something) from HTTPS connection. It is using the same TLS transport = as HTTPS and firewall cannot inspect the actual data transmitted. Firewall = can probably do some sort of heuristics based on packet sizes=2C but this w= ill not be reliable enough to distinguish TURN over TLS from HTTPS (or real= time media over HTTPS). In any case=2C if people are persistent enough the= y will find the way to block RTC connections regardless of the protocol use= d.
_____________
Roman Shpount


= --_95846c9f-2599-47d5-99bc-64d865dfd76f_-- From ted.ietf@gmail.com Thu Oct 20 11:12: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 075FB21F8B4C for ; Thu, 20 Oct 2011 11:12:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.199 X-Spam-Level: X-Spam-Status: No, score=-3.199 tagged_above=-999 required=5 tests=[AWL=0.399, 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 KGm4ECsRgfil for ; Thu, 20 Oct 2011 11:12:06 -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 8A52B21F8B48 for ; Thu, 20 Oct 2011 11:12:05 -0700 (PDT) Received: by yxj19 with SMTP id 19so3693368yxj.31 for ; Thu, 20 Oct 2011 11:12:05 -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=xweWm2fWlnawaUJbQgEXQRakkYo9Y2/9d+rWoU1mtEU=; b=CQ+LoD+0Rrge5vg8tn/iz+HDfDlSmn0kDJ6Z/HKhOD4NIJEDRXOp5MO+UljiHZIr6j sTf5A4nxKy/S+2FDhVXilukIGYyrQjHnYZ2R+5/Q10drQOQ0bTLxg+R2c7s665fe/b78 F1D8TtPRTR2/ENpwTk4kMN+T2eBETy62AuLbo= MIME-Version: 1.0 Received: by 10.236.186.102 with SMTP id v66mr17272654yhm.108.1319134325197; Thu, 20 Oct 2011 11:12:05 -0700 (PDT) Received: by 10.236.105.169 with HTTP; Thu, 20 Oct 2011 11:12:05 -0700 (PDT) In-Reply-To: References: Date: Thu, 20 Oct 2011 11:12:05 -0700 Message-ID: From: Ted Hardie To: Roman Shpount Content-Type: multipart/alternative; boundary=20cf30563e17dd4b9904afbee4a0 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Why are we asking the wrong questions? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 18:12:07 -0000 --20cf30563e17dd4b9904afbee4a0 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Oct 20, 2011 at 8:16 AM, Roman Shpount wrote: > First irrelevant topic is "We want something that will allow to setup a > media call in 20 lines of JavaScript". Perhaps it is time to review some of the drivers of the work here. One of the primary issues raised during the lead-up to the BoF was that embedded interactive audio/video functions which could be achieved with plugins could not be achieved without them. Since the plugins varied (both among vendors and over versions), that created an interoperability problem and hindered deployment (some people would not download the plugins, others would not upgrade deployed version, not all plugins were available on all platforms--the usual litany). To compete with a plugin, however, it cannot be significantly harder to write an RTCWeb-capable application than the equivalent in the popular plugins. If it is far more difficult or far less clear how to do it, the effort fails. How you achieve that simplicity may still be up for debate, but I don't think the goal is wrong. If you do, I am curious why continuing along the plugin path is not simply the right answer for your goals. regards, Ted PS. In a spirit of openness, I freely admit to having concerns that the "1000s of JS libraries" vision will either fail to emerge, fail to be maintained, or will result in sufficient confusion among app writers that it fails the "far less clear how to do it" test. To avoid that, I think you have to standardize the JS libraries' base capabilities in a way that makes it just as simple to put the base capabilities into the browser--with the resulting advantages in download power and energy already described, not to mention the system simplicity issues Harald raises, and with which I agree. But that issue (standard library functions versus standard browser functions) is less important than the goal: make it dead simple to include interactive audio and video functionality in a web page/app *without a plugin*. --20cf30563e17dd4b9904afbee4a0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Oct 20, 2011 at 8:16 AM, Roman Shpount <roman@telurix.com> wrote:
<= div class=3D"gmail_quote">
First irrelevant topic is "We want something that will allow to setup = a media call in 20 lines of JavaScript".

Perhaps= it is time to review some of the drivers of the work here.=A0 One of the p= rimary issues raised during the lead-up to the BoF was that embedded intera= ctive audio/video functions which could be achieved with plugins could not = be achieved without them.=A0 Since the plugins varied (both among vendors a= nd over versions), that created an interoperability problem and hindered de= ployment (some people would not download the plugins, others would not upgr= ade deployed version, not all plugins were available on all platforms--the = usual litany).

To compete with a plugin, however, it cannot be significantly harder to= write an RTCWeb-capable=A0 application than the equivalent in the popular = plugins.=A0 If it is far more difficult or far less clear how to do it, the= effort fails.

How you achieve that simplicity may still be up for debate, but I don&#= 39;t think the goal is wrong.=A0=A0 If you do, I am curious why continuing = along the plugin path is not simply the right answer for your goals.
regards,

Ted

PS.=A0 In a spirit of openness, I freely admit t= o having concerns that the "1000s of JS libraries" vision will ei= ther fail to emerge, fail to be maintained, or will result in sufficient co= nfusion among app writers that it fails the "far less clear how to do = it" test.=A0 To avoid that, I think you have to standardize the JS lib= raries' base capabilities in a way that makes it just as simple to put = the base capabilities into the browser--with the resulting advantages in do= wnload power and energy already described, not to mention the system simpli= city issues Harald raises, and with which I agree.=A0 But that issue (stand= ard library functions versus standard browser functions) is less important = than the goal: make it dead simple to include interactive audio and video f= unctionality in a web page/app without a plugin.

--20cf30563e17dd4b9904afbee4a0-- From harald@alvestrand.no Thu Oct 20 11:14: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 BBF1021F8BA6 for ; Thu, 20 Oct 2011 11:14:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j+SX+K1TA5oT for ; Thu, 20 Oct 2011 11:14:21 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id E251621F8B89 for ; Thu, 20 Oct 2011 11:14:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3B0A839E16F for ; Thu, 20 Oct 2011 20:14:20 +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 b4BRwUJ2JvuF for ; Thu, 20 Oct 2011 20:14:19 +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 61BA339E072 for ; Thu, 20 Oct 2011 20:14:19 +0200 (CEST) Message-ID: <4EA064FA.1090006@alvestrand.no> Date: Thu, 20 Oct 2011 20:14:18 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux i686; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <9C8CA816-65FB-41A0-999C-4C43128CAAB4@danyork.org> <4EA05CF0.6010904@jesup.org> In-Reply-To: <4EA05CF0.6010904@jesup.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Single-origin and consent X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 18:14:21 -0000 On 10/20/2011 07:40 PM, Randell Jesup wrote: > On 10/20/2011 11:36 AM, Eric Rescorla wrote: >> On Thu, Oct 20, 2011 at 7:32 AM, Bernard Aboba >> wrote: >>> No, I'm saying that *if* a developer remains within the "single origin" >>> model, that a number of requirements for peer-to-peer operation do not >>> apply. >>> >>> Also that the APIs should also enable media to be sent over a >>> websocket to >>> the "single origin" as well as a PeerConnection. >>> >> >> I don't think I'm following you're argument. ISTM that there are two >> conditions that one >> might term "single origin": >> >> 1. Alice and Bob are on the same site (e.g., PokerStars) and are >> calling each other via P2P media, >> 2. Alice and Bob are on the same site and are calling each other >> via media over WS. > > I'll add a third: Alice and Bob are on the same site, and are > participating in a (potentially) multi-person conference run through > the site, which is acting as a mixer or at least relay. Media is sent > via normal PeerConnection channels, encrypted with DTLS-SRTP. In this > limited case, each participant is sending media to the same site (*) > as the JS code is loaded from. > > So, the questions here would be > a) can we relax ICE consent checks if the site/app so wishes and > b) should we? > > I think we can (if the app tells us to, since it's "same-origin" and > the app should know), but I'm a little less certain of the "should". > Is there an attack wherein someone could 'host' some JS content (app) > on a site and use it to attack/DoS that site from multiple places? It > seems at least plausible. My paranoid self comes up with two, and warns me that there may be others.... 1) if the "site" is in fact a NAT box, AND the attacker is able to get a whole TCP port number on that box AND allow incoming connections.... THEN the attacker can "host" a web server at natbox-ip:hisportnumber, and freely use the "same site" criterion to get people to DOS other users of the same NAT box. 2) if the "site" is identified by domain name, and the attacker owns the domain name, and the attacker can dynamically switch between two short-TTL A records for the "site".... THEN the attacker can let the "helper" load up the page and Javascript from the attacking site, switch the A record around to point at his victim, and have the attack go to the victim's IP address. I'm sure people with larger experience in paranoia than I have can come up with other scenarios. Or possibly come up with a defense against these and other threats that is cheaper than ICE. But until then ..... I don't think we should. Harald > > From bernard_aboba@hotmail.com Thu Oct 20 11:33: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 6F98121F8BBA for ; Thu, 20 Oct 2011 11:33:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.488 X-Spam-Level: X-Spam-Status: No, score=-102.488 tagged_above=-999 required=5 tests=[AWL=0.110, 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 qK-dq1Ss7-+F for ; Thu, 20 Oct 2011 11:33:20 -0700 (PDT) Received: from blu0-omc3-s14.blu0.hotmail.com (blu0-omc3-s14.blu0.hotmail.com [65.55.116.89]) by ietfa.amsl.com (Postfix) with ESMTP id E633721F8B75 for ; Thu, 20 Oct 2011 11:33:15 -0700 (PDT) Received: from BLU152-W16 ([65.55.116.73]) by blu0-omc3-s14.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 20 Oct 2011 11:33:15 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_59a92071-1488-4d6a-bdd5-4d4909bca6a3_" X-Originating-IP: [24.17.217.162] From: Bernard Aboba To: Date: Thu, 20 Oct 2011 11:33:14 -0700 Importance: Normal In-Reply-To: <4EA064FA.1090006@alvestrand.no> References: <9C8CA816-65FB-41A0-999C-4C43128CAAB4@danyork.org>, , , , , <4EA05CF0.6010904@jesup.org>, <4EA064FA.1090006@alvestrand.no> MIME-Version: 1.0 X-OriginalArrivalTime: 20 Oct 2011 18:33:15.0521 (UTC) FILETIME=[BB0F6710:01CC8F56] Subject: Re: [rtcweb] Single-origin and consent X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 18:33:21 -0000 --_59a92071-1488-4d6a-bdd5-4d4909bca6a3_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > I think we can (if the app tells us to=2C since it's "same-origin" and=20 > the app should know)=2C but I'm a little less certain of the "should". =20 > Is there an attack wherein someone could 'host' some JS content (app)=20 > on a site and use it to attack/DoS that site from multiple places? It=20 > seems at least plausible. [BA] Taken to its conclusion=2C this is an argument for imposing ICE as a r= equirement for *all* web-based applications.=20 There is no evidence that such a requirement is necessary -- and even if it= were to be done=2C it would be almost certainly be ignored (and rightly so= ) by the developer community.=20 There is a line between safely attempting to add new functionality=2C and a= ttempting to disable existing functionality. =20 The former is in scope=2C the latter is not. =20 = --_59a92071-1488-4d6a-bdd5-4d4909bca6a3_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
>=3B I think we can (if the app tells us to=2C since it's "same-origin" a= nd
>=3B the app should know)=2C but I'm a little less certain of= the "should".
>=3B Is there an attack wherein someone could 'host' = some JS content (app)
>=3B on a site and use it to attack/DoS that si= te from multiple places? It
>=3B seems at least plausible.

[B= A] Taken to its conclusion=2C this is an argument for imposing ICE as a req= uirement for *all* web-based applications.

There is no evidence tha= t such a requirement is necessary -- and even if it were to be done=2C it w= ould be almost certainly be ignored (and rightly so) by the developer commu= nity.

There is a line between safely attempting to add new function= ality=2C and attempting to disable existing functionality. =3B

= The former is in scope=2C the latter is not. =3B



=
= --_59a92071-1488-4d6a-bdd5-4d4909bca6a3_-- From roman@telurix.com Thu Oct 20 11:37: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 311FC21F8BB6 for ; Thu, 20 Oct 2011 11:37:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.897 X-Spam-Level: X-Spam-Status: No, score=-2.897 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g-yhya9p1PeK for ; Thu, 20 Oct 2011 11:37:54 -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 95A1A21F8BB3 for ; Thu, 20 Oct 2011 11:37:54 -0700 (PDT) Received: by gyh20 with SMTP id 20so3728421gyh.31 for ; Thu, 20 Oct 2011 11:37:54 -0700 (PDT) Received: by 10.236.183.52 with SMTP id p40mr4074534yhm.19.1319135874055; Thu, 20 Oct 2011 11:37:54 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by mx.google.com with ESMTPS id d5sm15129469yhl.19.2011.10.20.11.37.53 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 20 Oct 2011 11:37:53 -0700 (PDT) Received: by qadc10 with SMTP id c10so780360qad.31 for ; Thu, 20 Oct 2011 11:37:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.32.138 with SMTP id j10mr15942646pbi.81.1319135872964; Thu, 20 Oct 2011 11:37:52 -0700 (PDT) Received: by 10.68.47.40 with HTTP; Thu, 20 Oct 2011 11:37:52 -0700 (PDT) In-Reply-To: References: Date: Thu, 20 Oct 2011 14:37:52 -0400 Message-ID: From: Roman Shpount To: Ted Hardie Content-Type: multipart/alternative; boundary=bcaec52163d11e57ed04afbf4173 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Why are we asking the wrong questions? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 18:37:55 -0000 --bcaec52163d11e57ed04afbf4173 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Oct 20, 2011 at 2:12 PM, Ted Hardie wrote: > But that issue (standard library functions versus standard browser > functions) is less important than the goal: make it dead simple to include > interactive audio and video functionality in a web page/app *without a > plugin*. > > I think I do not quite agree about "dead simple". "Dead simple" is not the goal, the goal is simple as possible without jeopardizing the functionality. As I mentioned before, adding "tel:" or "skype:" or "sip:" URL to a document is already dead simple, but does not get you much. The good way to develop such APIs is to develop a minimal set of primitives that will allow the desired functionality. If from application building experience a set of operations emerge that are complex to implement, but often used, add them as convenience API functions. Starting from convenience API usually gets you to a point were you get an API with 10 different ways of doing almost the same thing (see sound APIs in Linux or Timers in Windows). Standard signaling protocol is a convenience feature for RTC. It is heavily dependent on the matching server component. It replicates functionality that is already available and requirements for it are unclear. _____________ Roman Shpount --bcaec52163d11e57ed04afbf4173 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Oct 20, 2011 at 2:12 P= M, Ted Hardie <t= ed.ietf@gmail.com> wrote:
But that issue (standard library functions versus standard browser fun= ctions) is less important than the goal: make it dead simple to include int= eractive audio and video functionality in a web page/app without a plugi= n.

=A0
I think I do not quite agree abo= ut "dead simple". "Dead simple" is not the goal, the go= al is simple as possible without jeopardizing the functionality. As I menti= oned before, adding "tel:" or "skype:" or "sip:&qu= ot; URL to a document is already dead simple, but does not get you much.
The good way to develop such APIs is to develop a minimal set of primit= ives that will allow the desired functionality. If from application buildin= g experience a set of operations emerge that are complex to implement, but = often used, add them as convenience API functions. Starting from convenienc= e API usually gets you to a point were you get an API with 10 different way= s of doing almost the same thing (see sound APIs in Linux or Timers in Wind= ows).

Standard signaling protocol is a convenience feature for RTC. It is hea= vily dependent on the matching server component. It replicates functionalit= y that is already available and requirements for it are unclear.
______= _______
Roman Shpount

--bcaec52163d11e57ed04afbf4173-- From ibc@aliax.net Thu Oct 20 13:09: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 20BC71F0C61 for ; Thu, 20 Oct 2011 13:09:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.635 X-Spam-Level: X-Spam-Status: No, score=-2.635 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SwJosVNdKy+Q for ; Thu, 20 Oct 2011 13:09:27 -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 B36731F0C34 for ; Thu, 20 Oct 2011 13:09:27 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so3388853vcb.31 for ; Thu, 20 Oct 2011 13:09:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.25.75 with SMTP id a11mr11993290vdg.1.1319141365891; Thu, 20 Oct 2011 13:09:25 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Thu, 20 Oct 2011 13:09:25 -0700 (PDT) In-Reply-To: References: Date: Thu, 20 Oct 2011 22:09:25 +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] Why are we asking the wrong questions? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 20:09:29 -0000 2011/10/20 Roman Shpount : > Standard signaling protocol is a convenience feature for RTC. It is heavi= ly > dependent on the matching server component. It replicates functionality t= hat > is already available and requirements for it are unclear. Hi Roman, could you please check this short document and specify which "signaling protocol" (of the three appearing in the document) you mean?: http://dev.sipdoc.net/projects/oversip/wiki/RTCweb_Signaling_Components Thanks a lot. PS: I suggest all the WG to avoid the term "TRCweb signaling protocol" because it's confussing given the different fragments of RTCweb in which something related to "signaling" exists. --=20 I=C3=B1aki Baz Castillo From roman@telurix.com Thu Oct 20 13:47: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 A8EAD11E8099 for ; Thu, 20 Oct 2011 13:47:30 -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.075, 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 D8Md0eXweCC6 for ; Thu, 20 Oct 2011 13:47:29 -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 C0FE911E809C for ; Thu, 20 Oct 2011 13:47:29 -0700 (PDT) Received: by yxj19 with SMTP id 19so3846777yxj.31 for ; Thu, 20 Oct 2011 13:47:28 -0700 (PDT) Received: by 10.146.69.10 with SMTP id r10mr2788216yaa.32.1319143648046; Thu, 20 Oct 2011 13:47:28 -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 a16sm14439890ani.14.2011.10.20.13.47.27 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 20 Oct 2011 13:47:27 -0700 (PDT) Received: by ggnv1 with SMTP id v1so3814941ggn.31 for ; Thu, 20 Oct 2011 13:47:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.23.6 with SMTP id i6mr22380076pbf.13.1319143646624; Thu, 20 Oct 2011 13:47:26 -0700 (PDT) Received: by 10.68.47.40 with HTTP; Thu, 20 Oct 2011 13:47:26 -0700 (PDT) In-Reply-To: References: Date: Thu, 20 Oct 2011 16:47:26 -0400 Message-ID: From: Roman Shpount To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=bcaec521622376fae804afc110f1 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Why are we asking the wrong questions? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 20:47:30 -0000 --bcaec521622376fae804afc110f1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Oct 20, 2011 at 4:09 PM, I=F1aki Baz Castillo wrote= : > Hi Roman, could you please check this short document and specify which > "signaling protocol" (of the three appearing in the document) you > mean?: > > http://dev.sipdoc.net/projects/oversip/wiki/RTCweb_Signaling_Components > > This document is under password protection and I cannot access it. P.S. I suggest to stop redefine standard terms for the sake of the working group. Signaling protocol is defined in http://en.wikipedia.org/wiki/Signaling_protocol and is something like SIP -= - definition of data interactions over a wire. A set of JavaScript methods is not a signaling protocol -- it is an API. State machine that describes thes= e JavaScript methods is still part of the API specification. In my personal opinion, there are should be no "signaling protocols" in RTC. Trying to say that JavaScript definitions is some type protocol is just trying to discuss something which out of scope of this group and belongs to W3C. _____________ Roman Shpount --bcaec521622376fae804afc110f1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Oct 20, 2011 at 4:09 P= M, I=F1aki Baz Castillo <ibc@aliax.net> wrote:
Hi Roman, could you please check this short document and specify which
"signaling protocol" (of the three appearing in the document) you=
mean?:

=A0http://dev.sipdoc.net/projects/oversip/wiki/= RTCweb_Signaling_Components

This document is under password protection and I can= not access it.

P.S. I suggest to stop redefine standard terms for th= e sake of the working group. Signaling protocol is defined in http://en.wikipedia.org/wiki= /Signaling_protocol and is something like SIP -- definition of data int= eractions over a wire. A set of JavaScript methods is not a signaling proto= col -- it is an API. State machine that describes these JavaScript methods = is still part of the API specification. In my personal opinion, there are s= hould be no "signaling protocols" in RTC. Trying to say that Java= Script definitions is some type protocol is just trying to discuss somethin= g which out of scope of this group and belongs to W3C.
_____________
Roman Shpount

--bcaec521622376fae804afc110f1-- From ibc@aliax.net Thu Oct 20 13: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 AD50621F8AEA for ; Thu, 20 Oct 2011 13:59:52 -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_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 XcUhrgA5KrzM for ; Thu, 20 Oct 2011 13:59:52 -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 F249821F8557 for ; Thu, 20 Oct 2011 13:59:51 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so3433534vcb.31 for ; Thu, 20 Oct 2011 13:59:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.117.81 with SMTP id p17mr877870vcq.41.1319144390261; Thu, 20 Oct 2011 13:59:50 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Thu, 20 Oct 2011 13:59:50 -0700 (PDT) In-Reply-To: References: Date: Thu, 20 Oct 2011 22:59:50 +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] Why are we asking the wrong questions? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 20:59:52 -0000 2011/10/20 Roman Shpount : > On Thu, Oct 20, 2011 at 4:09 PM, I=C3=B1aki Baz Castillo = wrote: >> >> Hi Roman, could you please check this short document and specify which >> "signaling protocol" (of the three appearing in the document) you >> mean?: >> >> =C2=A0http://dev.sipdoc.net/projects/oversip/wiki/RTCweb_Signaling_Compo= nents >> > This document is under password protection and I cannot access it. Hi Roman, it's not under password protection. But the web has no favicon and the document root has no index permission, so when your browser requests the "standard" favicon icon it finds a 401 response. That's a bug of some web browsers. Please just press "cancel" when user:passwd is requested. > P.S. I suggest to stop redefine standard terms for the sake of the workin= g > group. Signaling protocol is defined in > http://en.wikipedia.org/wiki/Signaling_protocol and is something like SIP= -- > definition of data interactions over a wire. The document I've written is more that just the definition of "signaling protocol". > A set of JavaScript methods is > not a signaling protocol -- it is an API. State machine that describes th= ese > JavaScript methods is still part of the API specification. In my personal > opinion, I can agree with this. The important point here is that all the WG agrees with the term to use in each case. > there are should be no "signaling protocols" in RTC. In your previous comment you said: "Standard signaling protocol is a convenience feature for RTC." Could you please clarify if you are in favour of mandating the in-the-wire signaling protocol or not? Thanks a lot. --=20 I=C3=B1aki Baz Castillo From roman@telurix.com Thu Oct 20 14:07: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 1438311E8097 for ; Thu, 20 Oct 2011 14:07:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.747 X-Spam-Level: X-Spam-Status: No, score=-2.747 tagged_above=-999 required=5 tests=[AWL=-0.071, 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 xL9iDYIlIEaa for ; Thu, 20 Oct 2011 14:07:02 -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 889F711E8085 for ; Thu, 20 Oct 2011 14:07:02 -0700 (PDT) Received: by ggnv1 with SMTP id v1so3833024ggn.31 for ; Thu, 20 Oct 2011 14:07:02 -0700 (PDT) Received: by 10.100.50.23 with SMTP id x23mr2754656anx.141.1319144822117; Thu, 20 Oct 2011 14:07:02 -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 l8sm29308655anb.1.2011.10.20.14.07.01 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 20 Oct 2011 14:07:01 -0700 (PDT) Received: by ggnv1 with SMTP id v1so3833003ggn.31 for ; Thu, 20 Oct 2011 14:07:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.71.234 with SMTP id y10mr22191172pbu.132.1319144820807; Thu, 20 Oct 2011 14:07:00 -0700 (PDT) Received: by 10.68.47.40 with HTTP; Thu, 20 Oct 2011 14:07:00 -0700 (PDT) In-Reply-To: References: Date: Thu, 20 Oct 2011 17:07:00 -0400 Message-ID: From: Roman Shpount To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=bcaec544ebec73961f04afc15654 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Why are we asking the wrong questions? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 21:07:03 -0000 --bcaec544ebec73961f04afc15654 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Oct 20, 2011 at 4:59 PM, I=F1aki Baz Castillo wrote= : > Could you please clarify if you are in favour of mandating the > in-the-wire signaling protocol or not? > > I am saying that it is a convenience feature that provides little useful functionality apart from a few corner cases and is extremly hard to define. because of this I am against it. _____________ Roman Shpount --bcaec544ebec73961f04afc15654 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Oct 20, 2011 at 4:59 PM, I=F1aki Baz= Castillo <ibc@aliax.= net> wrote:
Could you please clarify if you are in favour of mandating the
in-the-wire signaling protocol or not?

I am saying that it is= a convenience feature that provides little useful functionality apart from= a few corner cases and is extremly hard to define. because of this I am ag= ainst it.
_____________
Roman Shpount

=A0
--bcaec544ebec73961f04afc15654-- From ibc@aliax.net Thu Oct 20 14: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 70EB31F0C42 for ; Thu, 20 Oct 2011 14:20:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[AWL=0.045, 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 VQ8HyjpiYxXW for ; Thu, 20 Oct 2011 14:20:48 -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 E199D1F0C3F for ; Thu, 20 Oct 2011 14:20:46 -0700 (PDT) Received: by vws5 with SMTP id 5so2954137vws.31 for ; Thu, 20 Oct 2011 14:20:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.73.166 with SMTP id m6mr12164817vdv.18.1319145645115; Thu, 20 Oct 2011 14:20:45 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Thu, 20 Oct 2011 14:20:45 -0700 (PDT) In-Reply-To: References: Date: Thu, 20 Oct 2011 23:20:45 +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] Why are we asking the wrong questions? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 21:20:49 -0000 2011/10/20 I=C3=B1aki Baz Castillo : > Hi Roman, could you please check this short document and specify which > "signaling protocol" (of the three appearing in the document) you > mean?: > > =C2=A0http://dev.sipdoc.net/projects/oversip/wiki/RTCweb_Signaling_Compon= ents Sorry, the correct link is: http://public.aliax.net/RTCweb_Signaling_Components.html --=20 I=C3=B1aki Baz Castillo From fluffy@cisco.com Thu Oct 20 19:08: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 711A411E8094 for ; Thu, 20 Oct 2011 19:08:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.224 X-Spam-Level: X-Spam-Status: No, score=-105.224 tagged_above=-999 required=5 tests=[AWL=-0.425, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, J_CHICKENPOX_63=0.6, J_CHICKENPOX_64=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 uEc5DU2P-x6S for ; Thu, 20 Oct 2011 19:08:22 -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 E9C2511E808F for ; Thu, 20 Oct 2011 19:08:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=2966; q=dns/txt; s=iport; t=1319162903; x=1320372503; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=vk5dCOOIy3ZbZH0yyStC4pkzJpQLCENBLrIvL0fH//o=; b=ZyQNrNe/CK0PDYftAJtmJqrEjUoViAOXMoS3dhaDLRTzqH9+n8gGc71O XE8JpSVOkfRuSFp9SQVtXWceSluw+Vl8nAI4Ho40hOCJWCL7Aeflv/BkG 5zf6hA4A/Krug2DM1rs8e129WcEXU6INL8riUm55IEaKAMm6QIaCYp4Sg A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmgHAOvToE6rRDoG/2dsb2JhbABDmh+OfYEFggcBJzuBd51qgSYBniWHSGEEiAOLfYUqjEw X-IronPort-AV: E=Sophos;i="4.69,383,1315180800"; d="scan'208";a="9257131" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 21 Oct 2011 02:08: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 p9L28I5T013344 for ; Fri, 21 Oct 2011 02:08:19 GMT From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 20 Oct 2011 20:08:18 -0600 Message-Id: To: rtcweb@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [rtcweb] ROAP Example Application X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 02:08:23 -0000 I liked Dan Yorks rant on what we need and it made me want to show some = simple code using an interface like the current W3C PeerConnection API = along with ROAP. Assuming the ROAP objects got passed in and out of the = Peer Connection object, here is a short little example I copied that = shows how simple it is to write a web application that sets up an audio = / video connection between two browsers. It assumes a simple web server = that that can pass messages from alice to bob and visa versa. Both alice = and bob just short poll the web server to get messages from their = mailbox and post messages to the others mailbox. The web server does not = transform the messages in any way. Clearly this example is wrong in some = ways, lacks authentication, and various error handling but I think it = illustrates the basics of the interfaces.=20 var ui_log =3D function(msg) { var t =3D document.createTextNode(msg); var d =3D document.createElement("div"); $(d).append(t); $("#logwindow").append(d); }; // simple wrapper around XHR. The cool kids use JQuery here, but // we want a self-contained example var ajax =3D function(params) { var xhr =3D new XMLHttpRequest(); xhr.open( params.type || "GET", params.url, true); if(params.contentType){ xhr.setRequestHeader("Content-Type",params.contentType) } if(params.data){ xhr.send(params.data); } else{ xhr.send(); } xhr.onreadystatechange =3D function() { if(xhr.readyState =3D=3D=3D 4) { if(xhr.status =3D=3D=3D 200) { if(params.success){ params.success(xhr.responseText); } } else { if (params.error) { params.error(xhr.responseText); } } } } }; var ROAPClient =3D function(username, peer, start_call) { var poll_timeout =3D 1000; // ms =20 var log =3D function(msg) { console.log("LOG (" + username + "): " + msg); ui_log("LOG (" + username + "): " + msg); }; =20 var signaling =3D function(msg) { msg.dest =3D peer; log("Sending: " + JSON.stringify(msg)); ajax({ url : "/msg/", type:"POST", contentType:"application/json", data: JSON.stringify(msg), }); }; var poll_success =3D function(msg) { var js =3D JSON.parse(msg); log("Received message " + JSON.stringify(js)); =09 pc.processSignalingMessage(js); }; =20 var poll_error =3D function(msg) { setTimeout(poll, poll_timeout); }; var poll =3D function() { ajax({ url: "/msg/" + username + "/", success:poll_success, error:poll_error }); }; var pc =3D new PeerConnection({}, signaling); =20 if (start_call) { pc.addStream(); } // Start polling poll(); }; var ROAPTest =3D function() { var caller =3D new ROAPClient("alice", "bob", true); var callee =3D new ROAPClient("bob", "alice"); }; From fluffy@cisco.com Thu Oct 20 21:35:02 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA05911E8099 for ; Thu, 20 Oct 2011 21:35:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.494 X-Spam-Level: X-Spam-Status: No, score=-105.494 tagged_above=-999 required=5 tests=[AWL=-0.095, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, J_CHICKENPOX_64=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 RzkX-rchF3rg for ; Thu, 20 Oct 2011 21:35:01 -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 C50D121F84DD for ; Thu, 20 Oct 2011 21:35:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=5608; q=dns/txt; s=iport; t=1319171701; x=1320381301; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=R13HG5iMKLu0tm/iTbBnLEFHshAfjXO7RcbvgRM4N1U=; b=Ym1V9v6Or5glmb7kzmKpM8/+FOJmJ3EKe/aMnJSWSJck4srDugfi0jeR CaqQAGever/0y3Ab6+liDaRJF3Hu/46tQcQj3GMeDng3r7wLjRxC59i1z jT8Clgb8Ouy6Y812IE649hNXpsgwOx9uesZ1hG/MlU+cty3kWC1ZL4i2B M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAEn2oE6rRDoG/2dsb2JhbABDqRyBBYFuAQEBAwESASc/EAsOCi5XBi4Hh16XRgGeLYdIYQSIA4t9hSqMTA X-IronPort-AV: E=Sophos;i="4.69,383,1315180800"; d="scan'208";a="9294690" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 21 Oct 2011 04:35: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 p9L4Z0nK009605; Fri, 21 Oct 2011 04:35:01 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: Date: Thu, 20 Oct 2011 22:35:00 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <018D7B69-3A31-480F-BFDD-EA083CF00B13@cisco.com> References: <4E9D667A.2040703@alvestrand.no> <9B03E9E2-4376-465E-84F5-EDAC51390408@phonefromhere.com> <570BDE5E-6EDC-4094-8DC0-094CEC3F12DF@acmepacket.com> <773FB266-721F-4C51-81A6-C01778BB68DF@cisco.com> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1084) Cc: "" Subject: Re: [rtcweb] My Opinion: Why I think a negotiating protocol is a Good Thing X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 04:35:02 -0000 On Oct 19, 2011, at 9:13 PM, Hadriel Kaplan wrote: > [breaking your email up into chunks, 'cause my response is getting = long] >=20 > On Oct 19, 2011, at 8:46 PM, Cullen Jennings wrote: >=20 >> I agree SDP is not used as an RTP API. I looked at a few RTP API and = they looked like "here is your compressed media and it's time stamp" and = "send this compressed media with following time stamp to this IP, port. = I don' think any one want that to be the level of API that gets exposed = by the browser. For one thing, the performance issues would likely not = work.=20 >=20 > Yeah when I said it I was kinda thinking "well not really 'RTP' = library, because many of those are basically pseudo-sockets", but I was = thinking like a media library (libraries that tie the codecs and RTP and = SRTP and ICE layers together and provide an API to an app above). >=20 >=20 >> One question that comes up is when a browser adds support for a new = CODEC, should the Java script code of a given web sight need to change = to take advantage of it. If your answer to that is at least in some = cases, No, then it means you need an API that allows the browser to do = the negotiation of the codecs. >=20 > I don't think you do. At least for most "codecs", all a Browser needs = to give/be-given is all the a=3Drtmp and a=3Dfmtp lines, or maybe even = only the portions after the PT numbers, as a list/table of strings and = their payload-type numbers, per audio/video stream. I know there are = some other codec-specific attributes now and then (T.38 comes to mind, = but it was arguably not your typical "codec" anyway)... but in general = wouldn't rtpmap+fmtp contents do it? I'm happy to ignore T.38 as a "special case" but new codecs, video = codecs in particular, need to define new parameters. Lets say a given = codec defines some new parameters that show up in some normal spot in = SDP, I don't see how the JS app will be able to negotiation without = understanding what the new parameters mean. Lets say some new VP9 video = codec defines a new maxFluffyDepth and the browser reports that it = support 666. The other other side offers a maxFlufflyDepth=3DYes. What = does the Javascript code select? It might be that the based on these you = even use a different parameter, say fluffyDepth=3D-6ft , to specify the = interoperable solution.=20 >=20 > There are a lot of other attributes, of course, but not per new codec. = Right? >=20 >=20 >> Today SDP (and the mapping of it in Jingle), are pretty much the only = games in town for that sort of negotiation. You can argue if we should = use SDP or invent something new. I'd love to hear your opinion on that. = If we decide we are going to use SDP, I think you end up with a API at = roughly the level of what is the W3C WEBRTC draft today and something = around the level of protocol as described in ROAP.=20 >=20 > Let's assume we have to use SDP - I don't actually think we do, but = just for argument's sake. That still doesn't mean we have to embed the = offer/answer model in the Browser, or even use it anywhere at all for = pure web-apps. The offer/answer model has some very specific semantics, = which are actually restrictive. For example, the offer/answer model = assumes a symmetric media-line model: if you send one audio and one = video m-line, the answer can only have one audio and one video m-line. >=20 > As an example of something that cannot be accomplished because of = this: imagine a Web-application which allows the Browser to communicate = with a TelePresence (TP) system. TP systems have multiple cameras, = screen displays, microphones, and speakers. A PC-based Browser = typically only has a single microphone and camera, but can display = multiple video feeds separately and can render-mix the incoming audio = streams. Thus, a Browser to TP system would produce an asymmetric media = stream model: multiple video streams from the TP system to the Browser, = and one video stream from the Browser to the TP system, and the same for = audio. Each TP audio and video stream is an independent m-line RTP = session and has unique attributes to indicate position = (left/center/right), which a Browser could in theory display on the = left/center/right of your browser window. Doing that is currently not = possible with SDP offer/answer; not only because the SDP attributes = aren't yet defined, but because the offer/answer model assumes a = symmetric number of media-lines (m=3D lines). Clearly if and when SDP = is changed to handle TelePresence cases, Browsers could be subsequently = upgraded to handle it as well sometime after; but they wouldn't need to = if the Browser hadn't been involved in SDP and offer/answer to begin = with. Hmm - this example sort leads to the direction I think about this. I = imagine we both agree that eventually mmusic will define an SDP = attribute to help position the video feeds. Clue will slow this down = from happening but once clue figures out it need to specify some = geometry, it will end taking that to mmusic. Having a different = solution defined in something the browsers are using (or in a protocol = like TIP) will just complicate making it work in SDP in a way that = continues to be possible to gateway to shat SDP does. It would be easier = to just add it in one place and call it done.=20 >=20 > The offer/answer model is an ok protocol between VoIP systems, but = it's not a good *API* between an application and its library.=20 >=20 > -hadriel >=20 From stefan.lk.hakansson@ericsson.com Thu Oct 20 23:41:16 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A43D51F0C59 for ; Thu, 20 Oct 2011 23:41:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.213 X-Spam-Level: X-Spam-Status: No, score=-6.213 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 L6lj0lPO6-up for ; Thu, 20 Oct 2011 23:41:15 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 01CF11F0C3B for ; Thu, 20 Oct 2011 23:41:14 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-e6-4ea1140ab18c Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 8C.6F.20773.A0411AE4; Fri, 21 Oct 2011 08:41:14 +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, 21 Oct 2011 08:41:14 +0200 Message-ID: <4EA11409.8050207@ericsson.com> Date: Fri, 21 Oct 2011 08:41:13 +0200 From: =?ISO-8859-1?Q?Stefan_H=E5kansson?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110922 Lightning/1.0b2 Thunderbird/3.1.15 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4E9D667A.2040703@alvestrand.no> <9B03E9E2-4376-465E-84F5-EDAC51390408@phonefromhere.com> <570BDE5E-6EDC-4094-8DC0-094CEC3F12DF@acmepacket.com> <773FB266-721F-4C51-81A6-C01778BB68DF@cisco.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] My Opinion: Why I think a negotiating protocol is a Good Thing X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 06:41:16 -0000 On 10/20/2011 05:13 AM, Hadriel Kaplan wrote: > As an example of something that cannot be accomplished because of > this: imagine a Web-application which allows the Browser to > communicate with a TelePresence (TP) system. TP systems have > multiple cameras, screen displays, microphones, and speakers. A > PC-based Browser typically only has a single microphone and camera, > but can display multiple video feeds separately and can render-mix > the incoming audio streams. Thus, a Browser to TP system would > produce an asymmetric media stream model: multiple video streams from > the TP system to the Browser, and one video stream from the Browser > to the TP system, and the same for audio. Each TP audio and video > stream is an independent m-line RTP session and has unique attributes > to indicate position (left/center/right), which a Browser could in > theory display on the left/center/right of your browser window. > Doing that is currently not possible with SDP offer/answer; not only > because the SDP attributes aren't yet defined, but because the > offer/answer model assumes a symmetric number of media-lines (m= > lines). Clearly if and when SDP is changed to handle TelePresence > cases, Browsers could be subsequently upgraded to handle it as well > sometime after; but they wouldn't need to if the Browser hadn't been > involved in SDP and offer/answer to begin with. I think this is doable with the current toolbox. There is an API that treats outgoing and incoming MediaStreams (over the same PeerConnection) separately, so nothing stops having an asymmetric setup. In addition, you could have several PeerConnections if that would help. Each incoming MediaStream has an unique label, so it is quite simple to associate the received MediaStream with the right display (left/center/rigth). The role of the SDP o/a (or ROAP) is IMO only to enable that those MediaStreams are sent as RTP streams between peers and can be assembled correctly to MediaStreams at the receiving peer (typically a MediaStream consists of several RTP streams, e.g. audio+video). From matthew.kaufman@skype.net Thu Oct 20 23: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 ECE791F0C59 for ; Thu, 20 Oct 2011 23:46:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 jjD1OKMq5AW7 for ; Thu, 20 Oct 2011 23:46:47 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id 2F1B521F84AF for ; Thu, 20 Oct 2011 23:46:47 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id 0E20B1710; Fri, 21 Oct 2011 08:46: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=YS8//dfjfWrehw L89LMe9YXLWZE=; b=taSbuMNCyzcaj4SvqXeN2ESUzAhS/bKv5Ed6alxdE5N2ix g15FbdgC0pi0r+kTsynue8q/P23OXnlK88I4sqerTL2UE3v6uUQIuzqPMtgBawIk CeppxEEQyojSKvWAFPHCC5P74izJjNvv3QvQBOAE+9T3rxGr27o1GX8kRWRZE= 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=mTvblCpK6op969RvBvZd8n p5iqSosAGEvLr7yE0PuXu3piV6YUg9BKejH8nB3IOJu/x68tXU14rK9d7A6+6fsi E9WVepnbPLLi7EObqhE1YbwwWzKVrj+yoGmsRA+cMse4IaO2ZYrCnG0Yoanwu7eQ uJfwfmABuw/QA3yKJHhCc= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id 0BC057F8; Fri, 21 Oct 2011 08:46:46 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id D41903507385; Fri, 21 Oct 2011 08:46: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 yA4-ELXuFDLF; Fri, 21 Oct 2011 08:46:45 +0200 (CEST) Received: from Matthew-Kaufman-Air.local (unknown [12.1.203.209]) by zimbra.skype.net (Postfix) with ESMTPSA id A61A635070B5; Fri, 21 Oct 2011 08:46:44 +0200 (CEST) Message-ID: <4EA11552.3010507@skype.net> Date: Thu, 20 Oct 2011 23:46:42 -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: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] ROAP Example Application X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 06:46:48 -0000 On 10/20/11 7:08 PM, Cullen Jennings wrote: > I liked Dan Yorks rant on what we need and it made me want to show some simple code using an interface like the current W3C PeerConnection API along with ROAP. Assuming the ROAP objects got passed in and out of the Peer Connection object, here is a short little example I copied that shows how simple it is to write a web application that sets up an audio / video connection between two browsers. It assumes a simple web server that that can pass messages from alice to bob and visa versa. Both alice and bob just short poll the web server to get messages from their mailbox and post messages to the others mailbox. The web server does not transform the messages in any way. Clearly this example is wrong in some ways, lacks authentication, and various error handling but I think it illustrates the basics of the interfaces. > > Thanks for the example. However, in addition to illustrating the basics, it also illustrates that ICE parameters and codec SDP parameters are now inextricably intertwined within this proposal, where in fact there is a good argument that not only should they be kept separate but that in fact they are the responsibility of different objects within the JavaScript API. Matthew Kaufman From HKaplan@acmepacket.com Fri Oct 21 00:12: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 C1CE321F858C for ; Fri, 21 Oct 2011 00:12:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.111 X-Spam-Level: X-Spam-Status: No, score=-2.111 tagged_above=-999 required=5 tests=[AWL=-0.112, BAYES_00=-2.599, J_CHICKENPOX_15=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 1nwt19zX80go for ; Fri, 21 Oct 2011 00:12:11 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 0882021F8562 for ; Fri, 21 Oct 2011 00:12: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; Fri, 21 Oct 2011 03:11: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, 21 Oct 2011 03:11:54 -0400 From: Hadriel Kaplan To: Cullen Jennings Thread-Topic: [rtcweb] My Opinion: Why I think a negotiating protocol is a Good Thing Thread-Index: AQHMj8C2DClMf3FX2Eu6JNnlQamw7Q== Date: Fri, 21 Oct 2011 07:11:53 +0000 Message-ID: References: <4E9D667A.2040703@alvestrand.no> <9B03E9E2-4376-465E-84F5-EDAC51390408@phonefromhere.com> <570BDE5E-6EDC-4094-8DC0-094CEC3F12DF@acmepacket.com> <773FB266-721F-4C51-81A6-C01778BB68DF@cisco.com> <018D7B69-3A31-480F-BFDD-EA083CF00B13@cisco.com> In-Reply-To: <018D7B69-3A31-480F-BFDD-EA083CF00B13@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: <08083A11807CB14A8DA36A10E676F98B@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [rtcweb] My Opinion: Why I think a negotiating protocol is a Good Thing X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 07:12:11 -0000 On Oct 21, 2011, at 12:35 AM, Cullen Jennings wrote: >=20 > I'm happy to ignore T.38 as a "special case" but new codecs, video codecs= in particular, need to define new parameters. Lets say a given codec defin= es some new parameters that show up in some normal spot in SDP, I don't see= how the JS app will be able to negotiation without understanding what the = new parameters mean. Lets say some new VP9 video codec defines a new maxFlu= ffyDepth and the browser reports that it support 666. The other other side = offers a maxFlufflyDepth=3DYes. What does the Javascript code select? It mi= ght be that the based on these you even use a different parameter, say fluf= fyDepth=3D-6ft , to specify the interoperable solution.=20 I'm not sure you're following what I meant, or else I'm not following you. = =20 If a new codec VP9 needed to indicate a "maxFluffyDepth" and it supports a = value of "666", then when JS calls a getter on the API for available codec = info, in the array-list of returned codecs it sees something like this: returnedArrayOfLocalVideoCodecs =3D [ { "payload-type": 99, "name": "H263-2000", "clock" : 90000, "fmtp": "CIF= =3D4;QCIF=3D2;F=3D1;K=3D1" }, { "payload-type": 100, "name": "VP9", "clock": 64000, "fmtp": "maxFluffyDe= pth=3D666" }, ... ] (that's not actually exactly what I would do, BTW, but just for sake of sim= plicity) JS could, if it so wished, only use entries in that array it understood. O= R, it could use any/all of them. How it uses them exactly is app-specific.= It could stringify this into JSON, etc. But let's just say it wants to turn this into SDP and use offer/answer. Lu= cky for us there's a sdpForDummies.js library which does that, so this is a= ll in that library. The library knows nothing about codec VP9, but it know= s how to produce attributes and such using the fields defined in the API, s= o it creates this: [some SDP lines missing because I'm lazy] m=3Dvideo 1234 RTP/AVPF 99 100 a=3Drtpmap:99 H263-2000/90000 a=3Dfmtp:99 CIF=3D4;QCIF=3D2;F=3D1;K=3D1 a=3Drtpmap:100 VP9/64000 a=3Dfmtp:100 maxFluffyDepth=3D666 Then let's say it gets an SDP answer back of this: m=3Dvideo 5678 RTP/AVPF 100 a=3Drtpmap:100 VP9/64000 a=3Dfmtp:100 maxFluffyDepth=3DYes So sdpForDummies.js understands the SDP offer/answer model, but not the cod= ec chosen. But it does what it does in every case: it parses it, sees the = fmtp stuff and treats that as a opaque string, and calls a Browser API sett= er function like=20 MediaStream.setRemoteCodec(1, 100, 64000, "maxFluffyDepth=3DYes");=20 // the first arg=3D1 is the array index of codecs for "VP9" You can say "well isn't that like an answer/offer just with SDP parsed out = as Javascript integral data types?" And I would say no it's not - the Brow= ser's maintaining no offer/answer state, it's not handling forking, it's no= t handling reversion in case of failure, it's not parsing protocol messages= (ie, SDP), and it's not making decisions unbeknownst to the JavaScript. I= n short: it's an API rather than a protocol.=20 Will there be some future case that could require the JS to change when the= Browser does something new? Of course. But JS developers are incredibly = fast at changing code and getting it deployed/used compared to timescales o= f Browser changes. If the JS app developer wants to enable some new doohic= ky that really did new things differently in an incompatible way, then the = JS developer will do it. We don't need to tell them how to do their job. = We need to *let* them do their job, and their job is code. -hadriel p.s. as a side benefit, doing this might also keep us honest in MMUSIC abou= t how we encode things and handle SDP offer/answer consistently across code= cs. :) From ibc@aliax.net Fri Oct 21 01:26: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 6DC3021F8B0D for ; Fri, 21 Oct 2011 01:26:50 -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.044, 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 aWbrGmdTIqez for ; Fri, 21 Oct 2011 01:26:49 -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 B448321F8B10 for ; Fri, 21 Oct 2011 01:26:49 -0700 (PDT) Received: by vws5 with SMTP id 5so3267737vws.31 for ; Fri, 21 Oct 2011 01:26:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.73.166 with SMTP id m6mr13550544vdv.18.1319185605712; Fri, 21 Oct 2011 01:26:45 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Fri, 21 Oct 2011 01:26:45 -0700 (PDT) In-Reply-To: References: Date: Fri, 21 Oct 2011 10:26:45 +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] Summary of Signaling Components in RTCweb (clarifications) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 08:26:50 -0000 2011/10/19 I=C3=B1aki Baz Castillo : > Hi all, > I've tryed to identify all the signaling components of a RTCweb > communication ir order to identify each "signaling fragment" in all > the path. There are various connotations for the "signaling" keyword > in RTCweb and IMHO they are generating confusion. > > I've exposed it into the following URL: > > =C2=A0http://public.aliax.net/RTCweb_Signaling_Components.html Hi, I've made some changes to the document: - Renamed "JS-Browser Media Signaling" to "JS-Browser Media API" (it's an API and could also be a "protocol", but let's call it just "API" for better understanding). - Renamed "JS-Server Information Signaling" to "JS-Server Routing Signaling". IMHO this is the correct word. - Added a new section "3. JS Application API" (which is provided by the custom JS retrieved from the webserver, which should hide the internal complexity to the high-user =3D> example: Phono API). http://public.aliax.net/RTCweb_Signaling_Components.html --=20 I=C3=B1aki Baz Castillo From saul@ag-projects.com Fri Oct 21 02:12: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 E423221F84DB for ; Fri, 21 Oct 2011 02:12:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.688 X-Spam-Level: X-Spam-Status: No, score=-1.688 tagged_above=-999 required=5 tests=[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 Ca1WDXFNP+Cn for ; Fri, 21 Oct 2011 02:12:06 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id EF52421F84DA for ; Fri, 21 Oct 2011 02:12:05 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id DB0AFB017D; Fri, 21 Oct 2011 11:11:59 +0200 (CEST) Received: from [192.168.99.36] (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id E3B98B017D; Fri, 21 Oct 2011 11:11:58 +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, 21 Oct 2011 11:11:58 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <837D51A3-BE0D-4BEA-98D4-D86BD460538C@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] Summary of Signaling Components in RTCweb (clarifications) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 09:12:07 -0000 On Oct 21, 2011, at 10:26 AM, I=F1aki Baz Castillo wrote: > 2011/10/19 I=F1aki Baz Castillo : >> Hi all, >> I've tryed to identify all the signaling components of a RTCweb >> communication ir order to identify each "signaling fragment" in all >> the path. There are various connotations for the "signaling" keyword >> in RTCweb and IMHO they are generating confusion. >>=20 >> I've exposed it into the following URL: >>=20 >> http://public.aliax.net/RTCweb_Signaling_Components.html >=20 > Hi, I've made some changes to the document: >=20 > - Renamed "JS-Browser Media Signaling" to "JS-Browser Media API" (it's > an API and could also be a "protocol", but let's call it just "API" > for better understanding). >=20 > - Renamed "JS-Server Information Signaling" to "JS-Server Routing > Signaling". IMHO this is the correct word. >=20 > - Added a new section "3. JS Application API" (which is provided by > the custom JS retrieved from the webserver, which should hide the > internal complexity to the high-user =3D> example: Phono API). >=20 >=20 > http://public.aliax.net/RTCweb_Signaling_Components.html >=20 Sounds better now. Hopefully we can all now be on the same page when we = discuss stuff about "signaling". Thanks, -- Sa=FAl Ibarra Corretg=E9 AG Projects From HKaplan@acmepacket.com Fri Oct 21 02: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 0A4D421F8BB3 for ; Fri, 21 Oct 2011 02:29:49 -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.192, 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 w9x-agQNRDQ4 for ; Fri, 21 Oct 2011 02:29:48 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 41C0321F8B31 for ; Fri, 21 Oct 2011 02:29: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; Fri, 21 Oct 2011 05:29:47 -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, 21 Oct 2011 05:29:47 -0400 From: Hadriel Kaplan To: Magnus Westerlund Thread-Topic: [rtcweb] Friday Agenda: Re: Friday Call details for signaling discussion Thread-Index: AQHMj9P50G3xzaYUXky/jrTbwQZRJg== Date: Fri, 21 Oct 2011 09:29:46 +0000 Message-ID: <1B7DDF56-8919-4A6B-B6F3-86B67D92CF33@acmepacket.com> References: <4E9E9794.8000901@alvestrand.no> <4E9FD139.2010406@ericsson.com> In-Reply-To: <4E9FD139.2010406@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: <59B967E0C23EAC4CBEE153B0B8D29A74@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [rtcweb] Friday Agenda: Re: Friday Call details for signaling discussion X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 09:29:49 -0000 I have seen no details about the call time/number/etc. Is this still happening? -hadriel On Oct 20, 2011, at 3:43 AM, Magnus Westerlund wrote: > WG, >=20 > The proposed agenda for Firday is as follows: >=20 > 10 min introduction from each signaling proposal: > - draft-jennings-rtcweb-signaling-00 (ROAP) Cullen > - draft-partha-rtcweb-signaling-00 (Standard signaling protocol) Partha > - ? (No Protocol) ? >=20 > In the above only clarifying questions may occur. >=20 > 20 min discussion of each proposal >=20 > 30 min concluding discussion >=20 > From my perspective both draft-beck-rtcweb-alt-ic-00 and > draft-ibc-rtcweb-sip-websocket-00 are relevant documents to the > discussion as they provides useful proposals on how interconnect and SIP > interop respectively can be done. But as they aren't proposals for how > the actual signaling solution should work. Thus these are homework but > don't get presentation time. >=20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From christer.holmberg@ericsson.com Fri Oct 21 02:32: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 1754021F8BF3 for ; Fri, 21 Oct 2011 02:32:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.105 X-Spam-Level: X-Spam-Status: No, score=-4.105 tagged_above=-999 required=5 tests=[AWL=-1.706, BAYES_00=-2.599, FM_IS_IT_OUR_ACCOUNT=4.2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vye577buQQ6O for ; Fri, 21 Oct 2011 02:32: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 8D01A21F87D9 for ; Fri, 21 Oct 2011 02:32:55 -0700 (PDT) X-AuditID: c1b4fb3d-b7c26ae0000035b9-6e-4ea13c46dd07 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id DD.BE.13753.64C31AE4; Fri, 21 Oct 2011 11:32:54 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Fri, 21 Oct 2011 11:32:54 +0200 From: Christer Holmberg To: Hadriel Kaplan , Magnus Westerlund Date: Fri, 21 Oct 2011 11:32:53 +0200 Thread-Topic: [rtcweb] Friday Agenda: Re: Friday Call details for signaling discussion Thread-Index: AQHMj9P50G3xzaYUXky/jrTbwQZRJpWGiL8A Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852234235BC4@ESESSCMS0356.eemea.ericsson.se> References: <4E9E9794.8000901@alvestrand.no> <4E9FD139.2010406@ericsson.com> <1B7DDF56-8919-4A6B-B6F3-86B67D92CF33@acmepacket.com> In-Reply-To: <1B7DDF56-8919-4A6B-B6F3-86B67D92CF33@acmepacket.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "" Subject: Re: [rtcweb] Friday Agenda: Re: Friday Call details for signaling discussion X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 09:32:57 -0000 Hi Hadriel, Details were sent out on Wednesday (19.10). See below. Regards, Christer --------------------- Topic: RTCWeb=20 Date: Friday, October 21, 2011=20 Time: 7:00 am, Pacific Daylight Time (San Francisco, GMT-07:00)=20 Meeting Number: 201 918 267=20 Meeting Password: ietf=20 Host Key: 107934=20 -------------------------------------------------------=20 To start the online meeting=20 -------------------------------------------------------=20 1. Go to https://cisco.webex.com/ciscosales/j.php?ED=3D177179667&UID=3D4821= 86897&PW=3DNN2U5ZTQxYmE5&RT=3DMiM0=20 2. Log in to your account.=20 3. Click "Start Now".=20 4. Follow the instructions that appear on your screen.=20 ----------------------------------------------------------------=20 ALERT:Toll-Free Dial Restrictions for (408) and (919) Area Codes=20 ----------------------------------------------------------------=20 The affected toll free numbers are: (866) 432-9903 for the San Jose/Milpita= s area and (866) 349-3520 for the RTP area.=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 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 San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330=20 US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117=20 India: +91.80.4350.1111 Germany: +49.619.6773.9002=20 Japan: +81.3.5763.9394 China: +86.10.8515.5666=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 To update this meeting to your calendar program (for example Microsoft Outl= ook), click this link:=20 https://cisco.webex.com/ciscosales/j.php?ED=3D177179667&UID=3D482186897&ICS= =3DMIU1&LD=3D1&RD=3D2&ST=3D1&SHA2=3DVSvxj0KwVStvk6aYb0aofqlHI06wOxeTdOeWJrk= BJdY=3D=20 To check whether you have the appropriate players installed for UCF (Univer= sal Communications Format) rich media files, go tohttps://cisco.webex.com/c= iscosales/systemdiagnosis.php=20 http://www.webex.com=20 > -----Original Message----- > From: rtcweb-bounces@ietf.org=20 > [mailto:rtcweb-bounces@ietf.org] On Behalf Of Hadriel Kaplan > Sent: 21. lokakuuta 2011 12:30 > To: Magnus Westerlund > Cc: > Subject: Re: [rtcweb] Friday Agenda: Re: Friday Call details=20 > for signaling discussion >=20 >=20 > I have seen no details about the call time/number/etc. > Is this still happening? >=20 > -hadriel >=20 >=20 > On Oct 20, 2011, at 3:43 AM, Magnus Westerlund wrote: >=20 > > WG, > >=20 > > The proposed agenda for Firday is as follows: > >=20 > > 10 min introduction from each signaling proposal: > > - draft-jennings-rtcweb-signaling-00 (ROAP) Cullen > > - draft-partha-rtcweb-signaling-00 (Standard signaling protocol)=20 > > Partha > > - ? (No Protocol) ? > >=20 > > In the above only clarifying questions may occur. > >=20 > > 20 min discussion of each proposal > >=20 > > 30 min concluding discussion > >=20 > > From my perspective both draft-beck-rtcweb-alt-ic-00 and=20 > > draft-ibc-rtcweb-sip-websocket-00 are relevant documents to the=20 > > discussion as they provides useful proposals on how=20 > interconnect and=20 > > SIP interop respectively can be done. But as they aren't=20 > proposals for=20 > > how the actual signaling solution should work. Thus these=20 > are homework=20 > > but don't get presentation time. > >=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 s.choi@computer.or.kr Fri Oct 21 02:37: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 51B5221F8B1D for ; Fri, 21 Oct 2011 02:37:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fbYkFKsZLpQp for ; Fri, 21 Oct 2011 02:37:08 -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 2D62721F8B14 for ; Fri, 21 Oct 2011 02:37:08 -0700 (PDT) Received: by bkas6 with SMTP id s6so5362651bka.31 for ; Fri, 21 Oct 2011 02:37:07 -0700 (PDT) Received: by 10.204.7.155 with SMTP id d27mr10330398bkd.93.1319189827141; Fri, 21 Oct 2011 02:37:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.36.8 with HTTP; Fri, 21 Oct 2011 02:36:47 -0700 (PDT) In-Reply-To: References: From: Soo-Hyun Choi Date: Fri, 21 Oct 2011 18:36:47 +0900 Message-ID: To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Summary of Signaling Components in RTCweb (clarifications) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 09:37:09 -0000 A nice summary. I found a minor typo though. >From the text "This documents tries to summarize all the signaling components of a RTCweb communication ir order to identify each "signaling fragment" in all the path ", ir order to =3D> in order to On Fri, Oct 21, 2011 at 17:26, I=F1aki Baz Castillo wrote: > 2011/10/19 I=F1aki Baz Castillo : >> Hi all, >> I've tryed to identify all the signaling components of a RTCweb >> communication ir order to identify each "signaling fragment" in all >> the path. There are various connotations for the "signaling" keyword >> in RTCweb and IMHO they are generating confusion. >> >> I've exposed it into the following URL: >> >> =A0http://public.aliax.net/RTCweb_Signaling_Components.html > > Hi, I've made some changes to the document: > > - Renamed "JS-Browser Media Signaling" to "JS-Browser Media API" (it's > an API and could also be a "protocol", but let's call it just "API" > for better understanding). > > - Renamed "JS-Server Information Signaling" to "JS-Server Routing > Signaling". IMHO this is the correct word. > > - Added a new section "3. JS Application API" (which is provided by > the custom JS retrieved from the webserver, which should hide the > internal complexity to the high-user =3D> example: Phono API). > > > =A0http://public.aliax.net/RTCweb_Signaling_Components.html > > > -- > I=F1aki Baz Castillo > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From tim@phonefromhere.com Fri Oct 21 02:38: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 3C47521F8BD3 for ; Fri, 21 Oct 2011 02:38:21 -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 bXqaAyM97Rvi for ; Fri, 21 Oct 2011 02:38: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 A825E21F8B5A for ; Fri, 21 Oct 2011 02:38:20 -0700 (PDT) Received: from [192.168.157.49] (unknown [93.89.81.113]) by zimbra.westhawk.co.uk (Postfix) with ESMTP id A76DE37A902; Fri, 21 Oct 2011 10:51:05 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Tim Panton In-Reply-To: Date: Fri, 21 Oct 2011 10:38:25 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <931AFC17-0745-439C-ADB4-6E4581855645@phonefromhere.com> References: To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= X-Mailer: Apple Mail (2.1251.1) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Summary of Signaling Components in RTCweb (clarifications) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 09:38:21 -0000 On 21 Oct 2011, at 09:26, I=F1aki Baz Castillo wrote: > 2011/10/19 I=F1aki Baz Castillo : >> Hi all, >> I've tryed to identify all the signaling components of a RTCweb >> communication ir order to identify each "signaling fragment" in all >> the path. There are various connotations for the "signaling" keyword >> in RTCweb and IMHO they are generating confusion. >>=20 >> I've exposed it into the following URL: >>=20 >> http://public.aliax.net/RTCweb_Signaling_Components.html >=20 > Hi, I've made some changes to the document: >=20 >=20 >=20 >=20 > http://public.aliax.net/RTCweb_Signaling_Components.html >=20 Thanks for putting the time into the document and updates, it is very useful. It does highlight one area that I think is problematic , you say: "JS-Server Media Signaling (in-the-wire): This means carrying SDP (or = like-SDP) bodies. In contrast to the JS-Server Routing Signaling this = information MAY be treated as "blob" by the RTCweb server, by leaving it = to pass verbatim to the destination of the message (which is indicated = in the JS-Server Routing Signaling)." Which is right, the RTCWebserver could treat the the media and network = info as blobs.=20 The local JS Application however can't. It needs to know things that are in that SDP in order to render the = application for the user.=20 Examples include -=20 is it a video or audio stream?=20 is DTMF available (i.e. should it render a keypad) ?=20 What is the screen size of the video?=20 To answer these questions the JS apps will need to parse the SDP-like = blob, so strictly it isn't a Blob anymore. What's more there is are examples where the server should be able to = understand the JS-Server Media Signaling. I'm thinking of the simplest use-case, peer to peer calls within a = single website. As I mentioned in an earlier email, the server can be told what the respective browsers support, and then = make a determination of what the intersection of codecs is and then = inform the browser's JSapp to use that. This has advantages in = simplicity and lack of risk of deadlocks, retries, glare etc. So in short, I think that treating the SDP-like as a blob has = significant disadvantages. Tim. From HKaplan@acmepacket.com Fri Oct 21 02:39: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 50A8F21F8C0A for ; Fri, 21 Oct 2011 02:39:18 -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.073, BAYES_00=-2.599, 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 o3Fr3-NsEjTo for ; Fri, 21 Oct 2011 02:39:17 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id ABD7721F8C04 for ; Fri, 21 Oct 2011 02:39:17 -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, 21 Oct 2011 05:39: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; Fri, 21 Oct 2011 05:39:16 -0400 From: Hadriel Kaplan To: "" Thread-Topic: API draft: draft-kaplan-rtcweb-api-reqs-00 Thread-Index: AQHMj9VMGc5R0uafrUWSeROda/L7iQ== Date: Fri, 21 Oct 2011 09:39:16 +0000 Message-ID: <8E91C7B0-CE22-4CDA-8AC2-707EA5DA7716@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: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Subject: [rtcweb] API draft: draft-kaplan-rtcweb-api-reqs-00 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 09:39:18 -0000 Howdy, we've posted an initial strawman for "API requirements" for "no signaling" = as our chairs have asked for for the con call. I'm still not sure why we need to provide this in an I-D, but given only a = few days notice and having other day jobs, we've tried our best in the shor= t timeframe. Note: given the announced conf call for Friday (today?), I've submitted thi= s version without getting final proof-reading from the other authors. So s= ome new bits I wrote they may not agree with... in fact some bits I wrote *= I* may not agree with, given how late it is at night for me (well I guess e= arly in the morning technically). Caveat emptor. :) Link details below. A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : API Requirements for RTCWEB-enabled Browsers Author(s) : Hadriel Kaplan Dan Burnett Neil Stratford Tim Panton Filename : draft-kaplan-rtcweb-api-reqs-00.txt Pages : 13 Date : 2011-10-21 This document discusses the advantages and disadvantages of several proposed approaches to what type of API and architectural model RTCWeb Browsers should expose and use. The document then defines the requirements for an API that treats the Browser as a library and interface as opposed to a self-contained application agent. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kaplan-rtcweb-api-reqs-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-kaplan-rtcweb-api-reqs-00.txt From saul@ag-projects.com Fri Oct 21 02:50: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 2384D21F8B63 for ; Fri, 21 Oct 2011 02:50:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.688 X-Spam-Level: X-Spam-Status: No, score=-1.688 tagged_above=-999 required=5 tests=[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 jTcOAnRazsj7 for ; Fri, 21 Oct 2011 02:50:16 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 68F9921F8B4F for ; Fri, 21 Oct 2011 02:50:16 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 65606B01B5; Fri, 21 Oct 2011 11:50:15 +0200 (CEST) Received: from [192.168.99.36] (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id 8D6BAB01A0; Fri, 21 Oct 2011 11:50: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: <931AFC17-0745-439C-ADB4-6E4581855645@phonefromhere.com> Date: Fri, 21 Oct 2011 11:50:13 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6236FA56-9D22-4659-939F-16100F4833DB@ag-projects.com> References: <931AFC17-0745-439C-ADB4-6E4581855645@phonefromhere.com> To: Tim Panton X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Summary of Signaling Components in RTCweb (clarifications) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 09:50:17 -0000 Hi Tim, >=20 > Thanks for putting the time into the document and updates, it > is very useful. >=20 > It does highlight one area that I think is problematic , you say: > "JS-Server Media Signaling (in-the-wire): This means carrying SDP (or = like-SDP) bodies. In contrast to the JS-Server Routing Signaling this = information MAY be treated as "blob" by the RTCweb server, by leaving it = to pass verbatim to the destination of the message (which is indicated = in the JS-Server Routing Signaling)." >=20 > Which is right, the RTCWebserver could treat the the media and network = info as blobs.=20 > The local JS Application however can't. > It needs to know things that are in that SDP in order to render the = application for the user.=20 > Examples include -=20 > is it a video or audio stream?=20 > is DTMF available (i.e. should it render a keypad) ?=20 > What is the screen size of the video?=20 > To answer these questions the JS apps will need to parse the SDP-like = blob, so strictly it isn't a Blob anymore. >=20 Assuming this SDP-like thing is ROAP, for example, an API could be = produced for this purpose. If one wants low level access it ma extract = the blob and parse it himself. > What's more there is are examples where the server should be able to = understand the JS-Server Media Signaling. > I'm thinking of the simplest use-case, peer to peer calls within a = single website. As I mentioned in an earlier email, > the server can be told what the respective browsers support, and then = make a determination of what the intersection of codecs is and then = inform the browser's JSapp to use that. This has advantages in = simplicity and > lack of risk of deadlocks, retries, glare etc. >=20 > So in short, I think that treating the SDP-like as a blob has = significant disadvantages. >=20 Notice the MAY ;-)=20 -- Sa=FAl Ibarra Corretg=E9 AG Projects From tim@phonefromhere.com Fri Oct 21 02: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 39F5A21F8BA8 for ; Fri, 21 Oct 2011 02:56:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[AWL=-0.140, 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 cI1DtK3iemGC for ; Fri, 21 Oct 2011 02:56:16 -0700 (PDT) Received: from zimbra.westhawk.co.uk (zimbra.westhawk.co.uk [192.67.4.167]) by ietfa.amsl.com (Postfix) with ESMTP id 8855021F889A for ; Fri, 21 Oct 2011 02:56:16 -0700 (PDT) Received: from [192.168.157.49] (unknown [93.89.81.113]) by zimbra.westhawk.co.uk (Postfix) with ESMTP id AC07937A902; Fri, 21 Oct 2011 11:09:06 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/alternative; boundary="Apple-Mail=_760ADE5D-1000-4E13-B24A-2146784CF7F0" From: Tim Panton In-Reply-To: <6236FA56-9D22-4659-939F-16100F4833DB@ag-projects.com> Date: Fri, 21 Oct 2011 10:56:26 +0100 Message-Id: <41811EE0-D18A-4F3B-9D0C-DC89CA58C682@phonefromhere.com> References: <931AFC17-0745-439C-ADB4-6E4581855645@phonefromhere.com> <6236FA56-9D22-4659-939F-16100F4833DB@ag-projects.com> To: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= X-Mailer: Apple Mail (2.1251.1) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Summary of Signaling Components in RTCweb (clarifications) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 09:56:17 -0000 --Apple-Mail=_760ADE5D-1000-4E13-B24A-2146784CF7F0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 21 Oct 2011, at 10:50, Sa=FAl Ibarra Corretg=E9 wrote: >>=20 >> To answer these questions the JS apps will need to parse the SDP-like = blob, so strictly it isn't a Blob anymore. >>=20 >=20 > Assuming this SDP-like thing is ROAP, for example, an API could be = produced for this purpose. If one wants low level access it ma extract = the blob and parse it himself. My point being that I can't concieve of an app that _didn't_ want to = know how big a screen area to allocate to incoming video (for example). So that = JS-window-on-the-blob-API becomes essential, but we've been told that, it is a) hard b) not necessary to write such a = thing. >>=20 >> So in short, I think that treating the SDP-like as a blob has = significant disadvantages. >>=20 >=20 > Notice the MAY ;-)=20 Sure. I'm pointing out that the MAY-NOT is a significant and useful = case. Tim.= --Apple-Mail=_760ADE5D-1000-4E13-B24A-2146784CF7F0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1

To = answer these questions the JS apps will need to parse the SDP-like blob, = so strictly it isn't a Blob anymore.


Assuming this SDP-like thing is ROAP, = for example, an API could be produced for this purpose. If one wants low = level access it ma extract the blob and parse it = himself.

My point being that I = can't concieve of an app that _didn't_ want to know how big a screen = area to
allocate to incoming video (for example). So that = JS-window-on-the-blob-API becomes essential,
but we've been = told that, it is a) hard b) not necessary to write such a = thing.


So in short, I = think that treating the SDP-like as a blob has significant = disadvantages.


Notice the MAY ;-) =

Sure. I'm pointing out that = the MAY-NOT is a significant and useful = case.

Tim.
= --Apple-Mail=_760ADE5D-1000-4E13-B24A-2146784CF7F0-- From salvatore.loreto@ericsson.com Fri Oct 21 02:58: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 C336821F8C0B for ; Fri, 21 Oct 2011 02:58:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, 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 TI07-rip6PCl for ; Fri, 21 Oct 2011 02:58: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 BDF5021F8BA8 for ; Fri, 21 Oct 2011 02:58:46 -0700 (PDT) X-AuditID: c1b4fb3d-b7c26ae0000035b9-e2-4ea142553886 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 15.24.13753.55241AE4; Fri, 21 Oct 2011 11:58:46 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.137.0; Fri, 21 Oct 2011 11:58:45 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 5BB362321 for ; Fri, 21 Oct 2011 12:58:45 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 2253E517DB for ; Fri, 21 Oct 2011 12:58:45 +0300 (EEST) Received: from n211.nomadiclab.com (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id C328D51236 for ; Fri, 21 Oct 2011 12:58:44 +0300 (EEST) Message-ID: <4EA14254.9030005@ericsson.com> Date: Fri, 21 Oct 2011 12:58:44 +0300 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: , , , , , , In-Reply-To: Content-Type: multipart/alternative; boundary="------------000006060700090508010705" X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Subject: Re: [rtcweb] Same location media X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 09:58:47 -0000 --------------000006060700090508010705 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit On 10/20/11 9:05 PM, Bernard Aboba wrote: > Yes, Turn over TLS is non-distinguishable. However, we've found deep > inspection firewalls that will actually attempt to parse the TLS > negotiation. This creates brittleness to extensions in general. > Anything that is not "vanilla" could potentially fall prey, including > TLS extensions, Websockets, etc. Sad, but true. but then also your fallback proposal to send media on WebSocket can potentially fall, isn't it? or am I missing something? /Sal > > ------------------------------------------------------------------------ > Date: Thu, 20 Oct 2011 13:58:40 -0400 > Subject: Re: [rtcweb] Same location media > From: roman@telurix.com > To: bernard_aboba@hotmail.com > CC: rtcweb@ietf.org > > > > On Thu, Oct 20, 2011 at 1:02 PM, Bernard Aboba > > wrote: > > [BA] With respect to TURN with TCP/TLS we have found some > firewalls that actually do deep packet inspection. So if you're > sending to TCP port 80 and aren't using HTTP, or are sending to > port 443 and aren't using TLS (or are using TLS extensions the > firewall doesn't understand), the firewall can block. So yes, it > is important to support TURN with TCP/TLS, but it should be > recognized that even with that, there will still be a significant > percentage of failures. > > > TURN over TLS is non-distinguishable (unless I am missing something) > from HTTPS connection. It is using the same TLS transport as HTTPS and > firewall cannot inspect the actual data transmitted. Firewall can > probably do some sort of heuristics based on packet sizes, but this > will not be reliable enough to distinguish TURN over TLS from HTTPS > (or real time media over HTTPS). In any case, if people are persistent > enough they will find the way to block RTC connections regardless of > the protocol used. > _____________ > Roman Shpount > > --------------000006060700090508010705 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit
On 10/20/11 9:05 PM, Bernard Aboba wrote:
Yes, Turn over TLS is non-distinguishable.  However, we've found deep inspection firewalls that will actually attempt to parse the TLS negotiation.  This creates brittleness to extensions in general.  Anything that is not "vanilla" could potentially fall prey, including TLS extensions, Websockets, etc.  Sad, but true.
but then also your fallback proposal to send media on WebSocket
can potentially fall, isn't it?
or am I missing something?

/Sal

Date: Thu, 20 Oct 2011 13:58:40 -0400
Subject: Re: [rtcweb] Same location media
From: roman@telurix.com
To: bernard_aboba@hotmail.com
CC: rtcweb@ietf.org



On Thu, Oct 20, 2011 at 1:02 PM, Bernard Aboba <bernard_aboba@hotmail.com> wrote:
[BA] With respect to TURN with TCP/TLS we have found some firewalls that actually do deep packet inspection.  So if you're sending to TCP port 80 and aren't using HTTP, or are sending to port 443 and aren't using TLS (or are using TLS extensions the firewall doesn't understand), the firewall can block.   So yes, it is important to support TURN with TCP/TLS, but it should be recognized that even with that, there will still be a significant percentage of failures.

TURN over TLS is non-distinguishable (unless I am missing something) from HTTPS connection. It is using the same TLS transport as HTTPS and firewall cannot inspect the actual data transmitted. Firewall can probably do some sort of heuristics based on packet sizes, but this will not be reliable enough to distinguish TURN over TLS from HTTPS (or real time media over HTTPS). In any case, if people are persistent enough they will find the way to block RTC connections regardless of the protocol used.
_____________
Roman Shpount




--------------000006060700090508010705-- From ibc@aliax.net Fri Oct 21 03: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 3C18321F8AB0 for ; Fri, 21 Oct 2011 03:23:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.634 X-Spam-Level: X-Spam-Status: No, score=-2.634 tagged_above=-999 required=5 tests=[AWL=0.043, 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 g0exP-rtbbgo for ; Fri, 21 Oct 2011 03:23:30 -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 96ACE21F8A7E for ; Fri, 21 Oct 2011 03:23:30 -0700 (PDT) Received: by vws5 with SMTP id 5so3335515vws.31 for ; Fri, 21 Oct 2011 03:23:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.25.75 with SMTP id a11mr13822288vdg.1.1319192610119; Fri, 21 Oct 2011 03:23:30 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Fri, 21 Oct 2011 03:23:30 -0700 (PDT) In-Reply-To: References: Date: Fri, 21 Oct 2011 12:23:30 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Soo-Hyun Choi Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Summary of Signaling Components in RTCweb (clarifications) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 10:23:31 -0000 2011/10/21 Soo-Hyun Choi : > A nice summary. I found a minor typo though. > > From the text "This documents tries to summarize all the signaling > components of a RTCweb communication ir order to identify each > "signaling fragment" in all the path ", > > ir order to =3D> in order to Thanks, fixed. --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Fri Oct 21 03:30: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 9126121F8B3A for ; Fri, 21 Oct 2011 03:30:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.634 X-Spam-Level: X-Spam-Status: No, score=-2.634 tagged_above=-999 required=5 tests=[AWL=0.043, 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 KrNxUU1zoRLu for ; Fri, 21 Oct 2011 03:30:34 -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 E85B821F8B47 for ; Fri, 21 Oct 2011 03:30:33 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so3832605vcb.31 for ; Fri, 21 Oct 2011 03:30:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.184.103 with SMTP id et7mr13897097vdc.35.1319193033348; Fri, 21 Oct 2011 03:30:33 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Fri, 21 Oct 2011 03:30:33 -0700 (PDT) In-Reply-To: <931AFC17-0745-439C-ADB4-6E4581855645@phonefromhere.com> References: <931AFC17-0745-439C-ADB4-6E4581855645@phonefromhere.com> Date: Fri, 21 Oct 2011 12:30:33 +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] Summary of Signaling Components in RTCweb (clarifications) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 10:30:34 -0000 2011/10/21 Tim Panton : > Thanks for putting the time into the document and updates, it > is very useful. > > It does highlight one area that I think is problematic , you say: > "JS-Server Media Signaling (in-the-wire): This means carrying SDP (or lik= e-SDP) bodies. In contrast to the JS-Server Routing Signaling this informat= ion MAY be treated as "blob" by the RTCweb server, by leaving it to pass ve= rbatim to the destination of the message (which is indicated in the JS-Serv= er Routing Signaling)." > > Which is right, the RTCWebserver could treat the the media and network in= fo as blobs. > The local JS Application however can't. > It needs to know things that are in that SDP in order to render the appli= cation for the user. > Examples include - > =C2=A0 =C2=A0 =C2=A0 =C2=A0is it a video or audio stream? > =C2=A0 =C2=A0 =C2=A0 =C2=A0is DTMF available (i.e. should it render a key= pad) ? > =C2=A0 =C2=A0 =C2=A0 =C2=A0What is the screen size of the video? > To answer these questions the JS apps will need to parse the SDP-like blo= b, so strictly it isn't a Blob anymore. Hi, indeed that is out of the scope of the document, but honestly I imagine that the JS Media API (i.e. ROAP) could include some JS functions/helpers. For example RTCweb.ROAP.parsePlainSDP(sdp), which receives a plain SDP and returns a ROAP object or some standarized JSON object the high-user can insepct in order to determine codecs and so (low leves access). > What's more there is are examples where the server should be able to unde= rstand the JS-Server Media Signaling. > I'm thinking of the simplest use-case, peer to peer calls within a single= website. As I mentioned in an earlier email, > the server can be told what the respective browsers support, and then mak= e a determination of what the intersection of codecs is and then inform the= browser's JSapp to use that. This has advantages in simplicity and > lack of risk of deadlocks, retries, glare etc. That's a possible choice, right. Just don't mandate it please ;) > So in short, I think that treating the SDP-like as a blob has significant= disadvantages. That depends on each scenario. For example, I use SIP over WebSocket. The RTCweb is a pure SIP proxy that speaks SIP over UDP, TCP and WebSocket. It *never* inspects the SDP (the "JS-Server Media Signaling" in my document), and it MUST NOT do it. I prefer the intelligence to be in the UA (the SIP stack in JavaScript, which is the "JS Application API" in my document). Regards. --=20 I=C3=B1aki Baz Castillo From harald@alvestrand.no Fri Oct 21 04:00: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 546A621F8B47 for ; Fri, 21 Oct 2011 04:00:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ba7zAVqps0wV for ; Fri, 21 Oct 2011 04:00:13 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id A138621F8B28 for ; Fri, 21 Oct 2011 04:00:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 09A0F39E08B; Fri, 21 Oct 2011 13:00:11 +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 2X+DRWWw9De5; Fri, 21 Oct 2011 13:00:10 +0200 (CEST) Received: from [192.168.1.58] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 81FF539E088; Fri, 21 Oct 2011 13:00:10 +0200 (CEST) Message-ID: <4EA150BC.9040605@alvestrand.no> Date: Fri, 21 Oct 2011 13:00:12 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: Matthew Kaufman References: <4EA11552.3010507@skype.net> In-Reply-To: <4EA11552.3010507@skype.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] ROAP Example Application X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 11:00:14 -0000 On 10/21/2011 08:46 AM, Matthew Kaufman wrote: > On 10/20/11 7:08 PM, Cullen Jennings wrote: >> I liked Dan Yorks rant on what we need and it made me want to show >> some simple code using an interface like the current W3C >> PeerConnection API along with ROAP. Assuming the ROAP objects got >> passed in and out of the Peer Connection object, here is a short >> little example I copied that shows how simple it is to write a web >> application that sets up an audio / video connection between two >> browsers. It assumes a simple web server that that can pass messages >> from alice to bob and visa versa. Both alice and bob just short poll >> the web server to get messages from their mailbox and post messages >> to the others mailbox. The web server does not transform the messages >> in any way. Clearly this example is wrong in some ways, lacks >> authentication, and various error handling but I think it illustrates >> the basics of the interfaces. >> >> > > Thanks for the example. > > However, in addition to illustrating the basics, it also illustrates > that ICE parameters and codec SDP parameters are now inextricably > intertwined within this proposal, where in fact there is a good > argument that not only should they be kept separate but that in fact > they are the responsibility of different objects within the JavaScript > API. As I've noted before, they are more entangled than one might like them to be; if we don't support the extension to use a single RTP session, we don't know how many ICE sessions we need to set up until we know at least how many top level media types we want to support. If we want to support multiple RTP sessions for other reasons, we need similar control of the number of ICE sessions set up. It illustrates that while a lot of the concerns of codecs and ICE sessions are reasonably separate, the functions that manipulate RTP sessions need access to both. Harald From tim@phonefromhere.com Fri Oct 21 04:13: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 957A621F8AFD for ; Fri, 21 Oct 2011 04:13:27 -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.020, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CN4hfpvKWb9E for ; Fri, 21 Oct 2011 04:13:27 -0700 (PDT) Received: from zimbra.westhawk.co.uk (zimbra.westhawk.co.uk [192.67.4.167]) by ietfa.amsl.com (Postfix) with ESMTP id EC05521F891D for ; Fri, 21 Oct 2011 04:13:26 -0700 (PDT) Received: from [192.168.157.49] (unknown [93.89.81.113]) by zimbra.westhawk.co.uk (Postfix) with ESMTP id 07E4337A902; Fri, 21 Oct 2011 12:26:12 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Tim Panton In-Reply-To: <4EA150BC.9040605@alvestrand.no> Date: Fri, 21 Oct 2011 12:13:20 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <58EF1980-E869-4B0F-8C7D-99029EFB45C3@phonefromhere.com> References: <4EA11552.3010507@skype.net> <4EA150BC.9040605@alvestrand.no> To: Harald Alvestrand X-Mailer: Apple Mail (2.1251.1) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] ROAP Example Application X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 11:13:27 -0000 On 21 Oct 2011, at 12:00, Harald Alvestrand wrote: >=20 > As I've noted before, they are more entangled than one might like them = to be; if we don't support the extension to use a single RTP session, we = don't know how many ICE sessions we need to set up until we know at = least how many top level media types we want to support. If we want to = support multiple RTP sessions for other reasons, we need similar control = of the number of ICE sessions set up. Who is 'we' ? Surely the decision of how many top level media types to = support _must_ be taken at the=20 application layer. The application has to make screen real-estate = available for things like video, keypads etc. >=20 > It illustrates that while a lot of the concerns of codecs and ICE = sessions are reasonably separate, the functions that manipulate RTP = sessions need access to both. And in my view the javascript needs access to _all_ 3 of them. Tim.= From ibc@aliax.net Fri Oct 21 04: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 128F021F8ABE for ; Fri, 21 Oct 2011 04:13:56 -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.071, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, 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 e1Kd0lxMcHfn for ; Fri, 21 Oct 2011 04:13:55 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6DCFA21F8AFD for ; Fri, 21 Oct 2011 04:13:55 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so3864533vcb.31 for ; Fri, 21 Oct 2011 04:13:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.184.103 with SMTP id et7mr14019869vdc.35.1319195634902; Fri, 21 Oct 2011 04:13:54 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Fri, 21 Oct 2011 04:13:54 -0700 (PDT) In-Reply-To: <8E91C7B0-CE22-4CDA-8AC2-707EA5DA7716@acmepacket.com> References: <8E91C7B0-CE22-4CDA-8AC2-707EA5DA7716@acmepacket.com> Date: Fri, 21 Oct 2011 13:13:54 +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] API draft: draft-kaplan-rtcweb-api-reqs-00 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 11:13:56 -0000 2011/10/21 Hadriel Kaplan : > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > > =C2=A0 =C2=A0 =C2=A0 =C2=A0Title =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : API= Requirements for RTCWEB-enabled Browsers > =C2=A0 =C2=A0 =C2=A0 =C2=A0Author(s) =C2=A0 =C2=A0 =C2=A0 : Hadriel Kapla= n > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 Dan Burnett > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 Neil Stratford > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 Tim Panton > =C2=A0 =C2=A0 =C2=A0 =C2=A0Filename =C2=A0 =C2=A0 =C2=A0 =C2=A0: draft-ka= plan-rtcweb-api-reqs-00.txt > =C2=A0 =C2=A0 =C2=A0 =C2=A0Pages =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 13 > =C2=A0 =C2=A0 =C2=A0 =C2=A0Date =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= : 2011-10-21 > > =C2=A0This document discusses the advantages and disadvantages of several > =C2=A0proposed approaches to what type of API and architectural model > =C2=A0RTCWeb Browsers should expose and use. =C2=A0The document then defi= nes > =C2=A0the requirements for an API that treats the Browser as a library an= d > =C2=A0interface as opposed to a self-contained application agent. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-kaplan-rtcweb-api-reqs-00.txt I love this draft. Just a comment. The draft says: --------------------- There has been discussion that RTCWeb should strive to enable media communication session with about "20 lines of code". We assert the only means of achieving that goal in a production-deployment manner is to use Javascript, and in particular Javascript libraries. --------------------- I would like to insist on that. When people says "20 lines of code" I expect that they mean the number of lines that a *high-user* needs to write in order to code a RTC session. But I assume that such *high-user* is using a JS library the browser retrieved from the website, and that JS library deals with all the complexity at low level. So for example, let's take a look to Phono JS library. It does allow implementing a call in 20 lines of code, but the library itself has more than 20 lines :) Anyhow the high-user must only deal with Phono JS API and using such API can code a call in 20 lines. That's the point IMHO. Let's the complexity to the developers of JS libraries, and they will make a simple API for end users. This is how WWW works and IMHO RTCweb should go in the same direction. We cannot and must no change WWW. Best regards. --=20 I=C3=B1aki Baz Castillo From harald@alvestrand.no Fri Oct 21 04:21: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 17E1021F8AEC for ; Fri, 21 Oct 2011 04:21:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2QKaYYuEv3VN for ; Fri, 21 Oct 2011 04:20:59 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id A8F0621F8AE1 for ; Fri, 21 Oct 2011 04:20:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id F323139E08B for ; Fri, 21 Oct 2011 13:20: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 XGC-Z90w7kd9 for ; Fri, 21 Oct 2011 13:20:45 +0200 (CEST) Received: from [192.168.1.58] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 4FBBD39E088 for ; Fri, 21 Oct 2011 13:20:45 +0200 (CEST) Message-ID: <4EA1558F.4030203@alvestrand.no> Date: Fri, 21 Oct 2011 13:20:47 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: rtcweb@ietf.org References: <931AFC17-0745-439C-ADB4-6E4581855645@phonefromhere.com> In-Reply-To: <931AFC17-0745-439C-ADB4-6E4581855645@phonefromhere.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [rtcweb] Summary of Signaling Components in RTCweb (clarifications) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 11:21:00 -0000 On 10/21/2011 11:38 AM, Tim Panton wrote: > On 21 Oct 2011, at 09:26, Iaki Baz Castillo wrote: > >> 2011/10/19 Iaki Baz Castillo: >>> Hi all, >>> I've tryed to identify all the signaling components of a RTCweb >>> communication ir order to identify each "signaling fragment" in all >>> the path. There are various connotations for the "signaling" keyword >>> in RTCweb and IMHO they are generating confusion. >>> >>> I've exposed it into the following URL: >>> >>> http://public.aliax.net/RTCweb_Signaling_Components.html >> Hi, I've made some changes to the document: >> >> >> >> >> http://public.aliax.net/RTCweb_Signaling_Components.html >> > Thanks for putting the time into the document and updates, it > is very useful. > > It does highlight one area that I think is problematic , you say: > "JS-Server Media Signaling (in-the-wire): This means carrying SDP (or like-SDP) bodies. In contrast to the JS-Server Routing Signaling this information MAY be treated as "blob" by the RTCweb server, by leaving it to pass verbatim to the destination of the message (which is indicated in the JS-Server Routing Signaling)." > > Which is right, the RTCWebserver could treat the the media and network info as blobs. > The local JS Application however can't. > It needs to know things that are in that SDP in order to render the application for the user. > Examples include - > is it a video or audio stream? > is DTMF available (i.e. should it render a keypad) ? > What is the screen size of the video? > To answer these questions the JS apps will need to parse the SDP-like blob, so strictly it isn't a Blob anymore. Well..... maybe not. When negotiation is done, there will be onstreamadd() callbacks informing one about the added streams; these will have clear indications on whether they are audio, video or both. When the video is available, I suspect that there will have to be an interface that allows one to tell the resolution of the video; I don't know if this is available from the

-- 
Dan York  dyork@lodestar2.com
http://www.danyork.com/  &n= bsp;skype:danyork
Phone: = +1-802-735-1624
Twitter - http://twitter.com/danyork
All comments and opinions are = entirely my own and have no connection whatsoever to any employer, past = or present. Indeed, by tomorrow even I might be disavowing these = comments.
In-Reply-To: Date: Fri, 21 Oct 2011 08:55:58 -0400 Message-Id: <6918CDB5-1604-4CF1-BFEC-3EA53CD93BFE@danyork.org> References: <8E91C7B0-CE22-4CDA-8AC2-707EA5DA7716@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A05852234235CE0@ESESSCMS0356.eemea.ericsson.se> To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= X-Mailer: Apple Mail (2.1251.1) Cc: "" Subject: Re: [rtcweb] API draft: draft-kaplan-rtcweb-api-reqs-00 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 12:56:06 -0000 --Apple-Mail=_920049A7-BFC7-4FF8-BF54-2ED1C2E1524A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Bingo... I think we want to create the conditions where a hundred = different JavaScript libraries will bloom as developers try out new and = innovative ways to bring real-time communications directly into the web = browsers and weave it into the fabric of the web. Yes, some (many? most?) of those libraries will suck badly ... but over = time I believe the "jQuery of RTCWEB" will emerge from somewhere and = suddenly people all over will be baking RTC directly into web apps using = the proverbial less than 20 lines of code. My 2 cents, Dan On Oct 21, 2011, at 7:24 AM, I=F1aki Baz Castillo wrote: > 2011/10/21 Christer Holmberg : >> We need to specify what is to be used by the JS library developers. = If they then design libraries that allow people to set up calls using 20 = lines of code, fine, but how can WE enforce that to happen? >>=20 >> I don't think we can say that the API WE specify shall allow setting = up a call using 20 lines. We can only hope (and, of course, do whatever = we can do in order to allow that to happen) that the API WE specify = allows someone ELSE to produce a library which then allows users to set = up calls using 20 lines :) >=20 > That's exactly what I meant :) >=20 > --=20 > I=F1aki Baz Castillo > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --=20 Dan York dyork@lodestar2.com http://www.danyork.com/ skype:danyork Phone: +1-802-735-1624 Twitter - http://twitter.com/danyork -------------------------------------------------------- All comments and opinions are entirely my own and have no connection = whatsoever to any employer, past or present. Indeed, by tomorrow even I = might be disavowing these comments. -------------------------------------------------------- --Apple-Mail=_920049A7-BFC7-4FF8-BF54-2ED1C2E1524A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1

My 2 = cents,
Dan

On Oct 21, 2011, at 7:24 = AM, I=F1aki Baz Castillo wrote:

2011/10/21 Christer Holmberg <christer.holmberg@ericsson.= com>:
We need to specify what is to = be used by the JS library developers. If they then design libraries that = allow people to set up calls using 20 lines of code, fine, but how can = WE enforce that to happen?

I don't think = we can say that the API WE specify shall allow setting up a call using = 20 lines. We can only hope (and, of course, do whatever we can do in = order to allow that to happen) that the API WE specify allows someone = ELSE to produce a library which then allows users to set up calls using = 20 lines :)

That's exactly what I meant :)

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

-- 
Dan York  dyork@lodestar2.com
http://www.danyork.com/  &n= bsp;skype:danyork
Phone: = +1-802-735-1624
Twitter - http://twitter.com/danyork
All comments and opinions are = entirely my own and have no connection whatsoever to any employer, past = or present. Indeed, by tomorrow even I might be disavowing these = comments.
Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [rtcweb] API draft: draft-kaplan-rtcweb-api-reqs-00 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 13:00:14 -0000 On Oct 21, 2011, at 7:40 AM, Harald Alvestrand wrote: > It also served very nicely to illustrate the breadth of functionality tha= t a "low level API" needs to expose. Actually I'm 100% sure I've forgotten/missed some things it needs to expose= . BUT, some of the things I listed need to be exposed even for a ROAP mode= l, yet for some reason aren't in the WG use-case-and-requirements draft; an= d some already exist exposed in the current W3C draft I think. > One note (speaking as a W3C WG chair): While it's very nice to imagine th= at one can toss a task like "design an API" over to another organization an= d having it performed, in practice, the W3C functions much like the IETF; i= t's not a place where you throw work in order to get work done, it's a plac= e where people who need the work done go to work on the problem. > But we all knew that, I think=85. Actually I don't know anything about the W3C. What I meant in the draft by= saying "it's really up to W3C" was that I thought it was highly presumptuo= us of us in the IETF to tell the W3C what to do as the API. I figured they= do APIs for a living, while IETF does protocols for a living. (which might= explain why we're now talking in the IETF about defining a protocol as an = API, eh? ;) -hadriel From ibc@aliax.net Fri Oct 21 06:10: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 A190721F8C82 for ; Fri, 21 Oct 2011 06:10:34 -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.070, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, 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 7c30eX3eUOhK for ; Fri, 21 Oct 2011 06:10:34 -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 17BEC21F8C81 for ; Fri, 21 Oct 2011 06:10:34 -0700 (PDT) Received: by vws5 with SMTP id 5so3477719vws.31 for ; Fri, 21 Oct 2011 06:10:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.25.75 with SMTP id a11mr14299213vdg.1.1319202604774; Fri, 21 Oct 2011 06:10:04 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Fri, 21 Oct 2011 06:10:04 -0700 (PDT) In-Reply-To: <6918CDB5-1604-4CF1-BFEC-3EA53CD93BFE@danyork.org> References: <8E91C7B0-CE22-4CDA-8AC2-707EA5DA7716@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A05852234235CE0@ESESSCMS0356.eemea.ericsson.se> <6918CDB5-1604-4CF1-BFEC-3EA53CD93BFE@danyork.org> Date: Fri, 21 Oct 2011 15:10:04 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Dan York Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "" Subject: Re: [rtcweb] API draft: draft-kaplan-rtcweb-api-reqs-00 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 13:10:34 -0000 2011/10/21 Dan York : > Bingo... I think we want to create the conditions where a hundred differe= nt > JavaScript libraries will bloom as developers try out new and innovative > ways to bring real-time communications directly into the web browsers and > weave it into the fabric of the web. > Yes, some (many? most?) of those libraries will suck badly ... but over t= ime > I believe the "jQuery of RTCWEB" will emerge from somewhere and suddenly > people all over will be baking RTC directly into web apps using the > proverbial less than 20 lines of code. Hope we *all* agree on this since this is the ONLY way to go in WWW world (IMHO). It's time to move on and avoid useless discussions about signaling protocols in the wire. In summary: 1) Let the browser vendors to be that: "browser vendors". Don't force them to be SIP/VoIP experts. Well, they must deal with ICE/TURN/RTP, but that's unavoidable in RTC and this is about RTC. 2) Let the complexity and innovation to the developers who build JavaScript libraries implementing all the low level stuff and their own custom singaling protocol in-the-wire (of course with the colaboration of the web/websocket server, which must implement such protocol in some language). 3) Let the end users to make use of the libraries provided in point 2, so they can write a RTC code "in 20 lines". Point 2 means that all the innovation and quality depends on JavaScript (in browser side) and PHP/Ruby/Python/Java/.Net/[...] in server side. This is freedom. Point 3 means success. This is the key in WWW. --=20 I=C3=B1aki Baz Castillo From sebastien.cubaud@orange.com Fri Oct 21 06:24:20 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16F5121F8C77 for ; Fri, 21 Oct 2011 06:24:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[AWL=0.425, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, 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 e6wpzW7PCS1A for ; Fri, 21 Oct 2011 06:24:19 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by ietfa.amsl.com (Postfix) with ESMTP id 2235F21F8C76 for ; Fri, 21 Oct 2011 06:24:19 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id AC0F0958005; Fri, 21 Oct 2011 15:34:06 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id A5556958001; Fri, 21 Oct 2011 15:34:06 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 21 Oct 2011 15:24:18 +0200 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, 21 Oct 2011 15:24:17 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] API draft: draft-kaplan-rtcweb-api-reqs-00 Thread-Index: AQHMj9VMGc5R0uafrUWSeROda/L7iZWGp2mQgAAhdZA= References: <8E91C7B0-CE22-4CDA-8AC2-707EA5DA7716@acmepacket.com> From: To: , X-OriginalArrivalTime: 21 Oct 2011 13:24:18.0504 (UTC) FILETIME=[BC8CD480:01CC8FF4] Subject: Re: [rtcweb] API draft: draft-kaplan-rtcweb-api-reqs-00 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 13:24:20 -0000 Hi Hadriel & al, Thanks for this draft and the effort in having it so quickly released. I = share your views in trying to keep the service logic as much as possible = within the server.=20 Here are below a few comments that hopefully will help: - Regarding the interoperability issues that can be faced when using SDP = O/A model (=A73.7), we can probably explicitly mention the ambiguity and = the potential vendor's implementations variations when the orders of the = same codec are inversed in the offer and in the answer, as well as when = payload types vary for the same codec, or when paquetization differs for = the same codec, .. =20 - Regarding =A75.2, I guess the WEB API, in addition to the codec = capabilities, MUST also provide a means to learn about the limitations = codec use/combinations can put as a constraint to the browser - Regarding =A75.2, it would be suitable to set/get the jitter buffer = characteristics (e.g. for QoS perspectives) - Regarding A2-4, it would be nice to get also the paquetization/bitrate = supported by codecs (e.g. to allow an easy reduction of the required = bandwidth) - Regarding A3-7, if you assume SDES could be used, it is probably TBD = (just like A3-6). Same remark regarding A3-8, it is then probably TBD - Regarding 5.3, in addition to the existing requirements, it would be = nice to get the RTCP stats (packet loss, jitter, ..) as well as = potential RTP notifications (such as when receiving DTMF event or maybe = inband codec modification) but it is very linked to the scoped use = cases. - Regarding 5.3, probably TBD, it could be worth getting the RTP/RTCP = capabilities: for instance, the supported profiles, if multipath-RTP = gets supported, .. - Regarding A5-10, in addition it would be nice to get the browser's = device network attachment capabilities: for instance, whether multiple = NIC exists, if multi-path TCP gets supported, .. These are probably not exhaustive, are made a bit in a hurry and would = certainly benefit from double-crossing them with = draft-rtcweb-requirements.. Kind regards Sebastien -----Message d'origine----- De=A0: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] De la = part de Hadriel Kaplan Envoy=E9=A0: vendredi 21 octobre 2011 11:39 =C0=A0: Objet=A0: [rtcweb] API draft: draft-kaplan-rtcweb-api-reqs-00 Howdy, we've posted an initial strawman for "API requirements" for "no = signaling" as our chairs have asked for for the con call. I'm still not sure why we need to provide this in an I-D, but given only = a few days notice and having other day jobs, we've tried our best in the = short timeframe. Note: given the announced conf call for Friday (today?), I've submitted = this version without getting final proof-reading from the other authors. = So some new bits I wrote they may not agree with... in fact some bits I = wrote *I* may not agree with, given how late it is at night for me (well = I guess early in the morning technically). Caveat emptor. :) Link details below. A New Internet-Draft is available from the on-line Internet-Drafts = directories. Title : API Requirements for RTCWEB-enabled Browsers Author(s) : Hadriel Kaplan Dan Burnett Neil Stratford Tim Panton Filename : draft-kaplan-rtcweb-api-reqs-00.txt Pages : 13 Date : 2011-10-21 This document discusses the advantages and disadvantages of several proposed approaches to what type of API and architectural model RTCWeb Browsers should expose and use. The document then defines the requirements for an API that treats the Browser as a library and interface as opposed to a self-contained application agent. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kaplan-rtcweb-api-reqs-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-kaplan-rtcweb-api-reqs-00.txt _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From harald@alvestrand.no Fri Oct 21 06:39: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 EA43B21F8C3C for ; Fri, 21 Oct 2011 06:39:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.429 X-Spam-Level: X-Spam-Status: No, score=-110.429 tagged_above=-999 required=5 tests=[AWL=-0.057, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MwEIm7-GNdbu for ; Fri, 21 Oct 2011 06:39:33 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 4CAFA21F8C12 for ; Fri, 21 Oct 2011 06:39:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 897A339E08B; Fri, 21 Oct 2011 15:39: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 vaoP03dAMZ9v; Fri, 21 Oct 2011 15:39:32 +0200 (CEST) Received: from [192.168.1.58] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 13E0A39E088; Fri, 21 Oct 2011 15:39:32 +0200 (CEST) Message-ID: <4EA17616.6090904@alvestrand.no> Date: Fri, 21 Oct 2011 15:39:34 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: Hadriel Kaplan References: <8E91C7B0-CE22-4CDA-8AC2-707EA5DA7716@acmepacket.com> <4EA15A31.50902@alvestrand.no> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "" Subject: Re: [rtcweb] API draft: draft-kaplan-rtcweb-api-reqs-00 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 13:39:34 -0000 On 10/21/2011 03:00 PM, Hadriel Kaplan wrote: > On Oct 21, 2011, at 7:40 AM, Harald Alvestrand wrote: > >> It also served very nicely to illustrate the breadth of functionality that a "low level API" needs to expose. > Actually I'm 100% sure I've forgotten/missed some things it needs to expose. BUT, some of the things I listed need to be exposed even for a ROAP model, yet for some reason aren't in the WG use-case-and-requirements draft; and some already exist exposed in the current W3C draft I think. I'm sure. The use cases are relatively high level, much higher level than the APIs and protocols. For those you see missing, it would be a good exercise to follow the object to "how can I describe the use case in which this is essential", and see if it maps to any of the current use cases, or needs to be added. We've done several wrinkles on the use cases in order to expose a specific requirement - for instance, the need to operate when one or both of the participants is behind a NAT box or a 3G mobile connection. >> One note (speaking as a W3C WG chair): While it's very nice to imagine that one can toss a task like "design an API" over to another organization and having it performed, in practice, the W3C functions much like the IETF; it's not a place where you throw work in order to get work done, it's a place where people who need the work done go to work on the problem. >> But we all knew that, I think. > Actually I don't know anything about the W3C. What I meant in the draft by saying "it's really up to W3C" was that I thought it was highly presumptuous of us in the IETF to tell the W3C what to do as the API. I figured they do APIs for a living, while IETF does protocols for a living. (which might explain why we're now talking in the IETF about defining a protocol as an API, eh? ;) I think getting them right requires a huge amount of information exchange .... in the W3C community, I see arguments about the dearth of good API designers too, and designing an API without understanding the underlying technology is just very unlikely to succeed. Luckily, we've got people (usually members of both lists) who are implementing this even as we speak; they might get enough feedback into the loop eventually. Harald From matthew.kaufman@skype.net Fri Oct 21 07:14: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 7E11B21F8C60 for ; Fri, 21 Oct 2011 07:14:04 -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 nE4GC3yWMRWw for ; Fri, 21 Oct 2011 07:14:03 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id D4F8121F8B1A for ; Fri, 21 Oct 2011 07:14:02 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id BDD447F8; Fri, 21 Oct 2011 16:14: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=FEQvue1fDDyIKW 7tGorRZY46tV4=; b=LSzBGLSibEAnaBv088AtMQzLQ/Uom0zzsLVyO16gGDrNb5 ylPeUGFxvBbIH81lciYrF0xdAkr/ITaqHKCU5HE4ueRGdQxfcqUY7QBzJM4pG33t fepQbU0lmdTkCfUIOoNjTV6i8IuuwrD9kDm1Bg2rVAdq3AyYGRs8s/AfoxFs0= 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=Yitgtokaz3g29W+SfCK1JY kaRv8kWE7aw8pns9vUUnDpXixw389f3lrOGjW8ebADiCPu9nbzr88UlniJtqANS5 XpGc7S5ikJ4CRfo4X398nruPysxYQCfJUKqSp6LzAiEOqVFP1HsYgYwViQPGev7y 1GCeKdBUxHeg0/hsZp64o= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id B389E7F6; Fri, 21 Oct 2011 16:14:01 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id 46C04350776A; Fri, 21 Oct 2011 16:14: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 2hTWPtYruL07; Fri, 21 Oct 2011 16:14:00 +0200 (CEST) Received: from Matthew-Kaufman-Air.local (unknown [12.1.203.209]) by zimbra.skype.net (Postfix) with ESMTPSA id 5CD083507343; Fri, 21 Oct 2011 16:13:59 +0200 (CEST) Message-ID: <4EA17E25.9080208@skype.net> Date: Fri, 21 Oct 2011 07:13:57 -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: <4EA11552.3010507@skype.net> <4EA150BC.9040605@alvestrand.no> In-Reply-To: <4EA150BC.9040605@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] ROAP Example Application X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 14:14:04 -0000 On 10/21/11 4:00 AM, Harald Alvestrand wrote: > On 10/21/2011 08:46 AM, Matthew Kaufman wrote: >> On 10/20/11 7:08 PM, Cullen Jennings wrote: >>> I liked Dan Yorks rant on what we need and it made me want to show >>> some simple code using an interface like the current W3C >>> PeerConnection API along with ROAP. Assuming the ROAP objects got >>> passed in and out of the Peer Connection object, here is a short >>> little example I copied that shows how simple it is to write a web >>> application that sets up an audio / video connection between two >>> browsers. It assumes a simple web server that that can pass messages >>> from alice to bob and visa versa. Both alice and bob just short poll >>> the web server to get messages from their mailbox and post messages >>> to the others mailbox. The web server does not transform the >>> messages in any way. Clearly this example is wrong in some ways, >>> lacks authentication, and various error handling but I think it >>> illustrates the basics of the interfaces. >>> >>> >> >> Thanks for the example. >> >> However, in addition to illustrating the basics, it also illustrates >> that ICE parameters and codec SDP parameters are now inextricably >> intertwined within this proposal, where in fact there is a good >> argument that not only should they be kept separate but that in fact >> they are the responsibility of different objects within the >> JavaScript API. > > As I've noted before, they are more entangled than one might like them > to be; This is just an argument that RTP is actually a poor choice as well, but I'm afraid it is too late for that. > if we don't support the extension to use a single RTP session, we > don't know how many ICE sessions we need to set up until we know at > least how many top level media types we want to support. If we want to > support multiple RTP sessions for other reasons, we need similar > control of the number of ICE sessions set up. But none of these examples actually shows that there's a requirement to combine the two into a single blob. An easy solution to these examples, for instance, would be to exchange the codec-choosing blobs *first* and then, based on the results, examine the "encoder" and "decoder" objects to see how many transport streams they need attached. Or, even easier, when you wire the media encoding/decoding objects to the transport object, the transport object can know what it will need to be transporting and, once it receives an internal event that the codec and RTP parameters have been selected, it can fire an event to JavaScript containing the ICE setup blob. > > It illustrates that while a lot of the concerns of codecs and ICE > sessions are reasonably separate, the functions that manipulate RTP > sessions need access to both. Actually this suggests to me that there's *three* blobs. One for codec parameters, one for RTP, and one for ICE. Matthew Kaufman ps. I understand the desire to have the codec selecting and codec parameter parts of this work in such a way that a pair of new browsers that have new codecs can automatically upgrade to the latest and greatest, even if the web site in between doesn't know about it... but that argument doesn't appear to apply to the RTP or ICE, which suggests that the "opaque blob" model isn't even required for 2/3rds of this. From ekr@rtfm.com Fri Oct 21 07: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 673F621F8C80 for ; Fri, 21 Oct 2011 07:22:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.963 X-Spam-Level: X-Spam-Status: No, score=-102.963 tagged_above=-999 required=5 tests=[AWL=0.014, 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 qF5I8w8HLOkl for ; Fri, 21 Oct 2011 07:22: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 3AB3821F8C7D for ; Fri, 21 Oct 2011 07:22:44 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so4056624vcb.31 for ; Fri, 21 Oct 2011 07:22:43 -0700 (PDT) Received: by 10.52.76.199 with SMTP id m7mr2524112vdw.63.1319206963565; Fri, 21 Oct 2011 07:22:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.161.20 with HTTP; Fri, 21 Oct 2011 07:22:03 -0700 (PDT) In-Reply-To: <4EA17E25.9080208@skype.net> References: <4EA11552.3010507@skype.net> <4EA150BC.9040605@alvestrand.no> <4EA17E25.9080208@skype.net> From: Eric Rescorla Date: Fri, 21 Oct 2011 07:22:03 -0700 Message-ID: To: Matthew Kaufman Content-Type: text/plain; charset=ISO-8859-1 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] ROAP Example Application X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 14:22:45 -0000 On Fri, Oct 21, 2011 at 7:13 AM, Matthew Kaufman wrote: > On 10/21/11 4:00 AM, Harald Alvestrand wrote: >> >> On 10/21/2011 08:46 AM, Matthew Kaufman wrote: >>> >>> On 10/20/11 7:08 PM, Cullen Jennings wrote: >>>> >>>> I liked Dan Yorks rant on what we need and it made me want to show some >>>> simple code using an interface like the current W3C PeerConnection API along >>>> with ROAP. Assuming the ROAP objects got passed in and out of the Peer >>>> Connection object, here is a short little example I copied that shows how >>>> simple it is to write a web application that sets up an audio / video >>>> connection between two browsers. It assumes a simple web server that that >>>> can pass messages from alice to bob and visa versa. Both alice and bob just >>>> short poll the web server to get messages from their mailbox and post >>>> messages to the others mailbox. The web server does not transform the >>>> messages in any way. Clearly this example is wrong in some ways, lacks >>>> authentication, and various error handling but I think it illustrates the >>>> basics of the interfaces. >>>> >>>> >>> >>> Thanks for the example. >>> >>> However, in addition to illustrating the basics, it also illustrates that >>> ICE parameters and codec SDP parameters are now inextricably intertwined >>> within this proposal, where in fact there is a good argument that not only >>> should they be kept separate but that in fact they are the responsibility of >>> different objects within the JavaScript API. >> >> As I've noted before, they are more entangled than one might like them to >> be; > > This is just an argument that RTP is actually a poor choice as well, but I'm > afraid it is too late for that. > >> if we don't support the extension to use a single RTP session, we don't >> know how many ICE sessions we need to set up until we know at least how many >> top level media types we want to support. If we want to support multiple RTP >> sessions for other reasons, we need similar control of the number of ICE >> sessions set up. > > But none of these examples actually shows that there's a requirement to > combine the two into a single blob. > > An easy solution to these examples, for instance, would be to exchange the > codec-choosing blobs *first* and then, based on the results, examine the > "encoder" and "decoder" objects to see how many transport streams they need > attached. Or, even easier, when you wire the media encoding/decoding objects > to the transport object, the transport object can know what it will need to > be transporting and, once it receives an internal event that the codec and > RTP parameters have been selected, it can fire an event to JavaScript > containing the ICE setup blob. Note that Jingle in some cases does sort of the opposite of this: The caller offers combined media encoding/decoding objects and transport objects (in a session-initiate) and the callee sends back only transport objects (in a transport-info) and then the combined media encoding objects and transport objects (in a session-accept). XEP-0167 has a good example of this. -Ekr From harald@alvestrand.no Fri Oct 21 08:54:28 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A71E711E80AE for ; Fri, 21 Oct 2011 08:54:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.523 X-Spam-Level: X-Spam-Status: No, score=-110.523 tagged_above=-999 required=5 tests=[AWL=0.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 oul4FOXGgQv6 for ; Fri, 21 Oct 2011 08:54:27 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 9ECEC11E8088 for ; Fri, 21 Oct 2011 08:54:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id ECC2839E08B for ; Fri, 21 Oct 2011 17:54: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 mFCu82CbjpIK for ; Fri, 21 Oct 2011 17:54:26 +0200 (CEST) Received: from [172.16.48.22] (unknown [74.125.121.33]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 38BFF39E088 for ; Fri, 21 Oct 2011 17:54:26 +0200 (CEST) Message-ID: <4EA195B1.4010705@alvestrand.no> Date: Fri, 21 Oct 2011 17:54:25 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: "rtcweb@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [rtcweb] Browser update rates X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 15:54:28 -0000 I found this webpage. No idea of how authoritative it is. http://www.netmagazine.com/features/developers-guide-browser-adoption-rates From ted.ietf@gmail.com Fri Oct 21 09:03: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 4C2F011E80C9 for ; Fri, 21 Oct 2011 09:03:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.232 X-Spam-Level: X-Spam-Status: No, score=-3.232 tagged_above=-999 required=5 tests=[AWL=0.366, 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 aYxKmE+N9YxP for ; Fri, 21 Oct 2011 09:03:09 -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 736971F0C81 for ; Fri, 21 Oct 2011 09:03:09 -0700 (PDT) Received: by gyh20 with SMTP id 20so4819124gyh.31 for ; Fri, 21 Oct 2011 09:03:09 -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:content-type; bh=4JlQnp2hklugr/FmJXmvCbEsiqA/cwjjLjkBdiU2rlU=; b=v2E8fz5NCxh3fQfe0W7aoXOA1o7EbReoR5k4pdyIS1KmzuAR2El32a4N6Umarpf8R5 +EV7BjdZmjLNdQvbydqyvIIyG6RgTI/a+0jSQ69WXjiZAYZ+YDyDJ7CmG/fPXyaRlMFm wnDRXqQKR8IEooMKq51MO2DqgtB+wsrEZd+wM= MIME-Version: 1.0 Received: by 10.236.168.2 with SMTP id j2mr22446576yhl.24.1319212989097; Fri, 21 Oct 2011 09:03:09 -0700 (PDT) Received: by 10.236.105.169 with HTTP; Fri, 21 Oct 2011 09:03:08 -0700 (PDT) Date: Fri, 21 Oct 2011 09:03:08 -0700 Message-ID: From: Ted Hardie To: rtcweb@ietf.org Content-Type: multipart/mixed; boundary=20cf305b121e99271c04afd13503 Subject: [rtcweb] Unedited notes from today's 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: Fri, 21 Oct 2011 16:03:10 -0000 --20cf305b121e99271c04afd13503 Content-Type: multipart/alternative; boundary=20cf305b121e99271a04afd13501 --20cf305b121e99271a04afd13501 Content-Type: text/plain; charset=ISO-8859-1 Here are my completed unedited notes from today's call; I got cut off at 9:00 sharp and have another meeting, so I'm not sure if anything was said after. Ted --20cf305b121e99271a04afd13501 Content-Type: text/html; charset=ISO-8859-1 Here are my completed unedited notes from today's call; I got cut off at 9:00 sharp and have another meeting, so I'm not sure if anything was said after.

Ted
--20cf305b121e99271a04afd13501-- --20cf305b121e99271c04afd13503 Content-Type: application/octet-stream; name=Notes-rtcweb-1021 Content-Disposition: attachment; filename=Notes-rtcweb-1021 Content-Transfer-Encoding: base64 X-Attachment-Id: f_gu1dbv220 Tm90ZXMgZnJvbSBSVENXZWIgQ2FsbCwgT2N0b2JlciAyMSwgMjAxMQpUZWQsIEN1bGxlbiwgTWFn bnVzLCBIYXJhbGQsIFN0ZWZhbiwgQ2hyaXN0aWFuIFNjaG1pZHQsIFBhcnRoYSwgRGFuIEJ1cm5l dHQsIEVuZGEgTWFubmlvbiwgSW5ha2ksIE1hcmt1cyBJc29tYWtpLCBNdXRodSBBcnVsLCBOZWls IFN0cmF0Zm9yZCwgTWFyeSBCYXJuZXMsIFN0ZXBoYW4gV2VuZ2VyLCBTYWx2YXRvcmUsIFRpbSBQ YW50YW4sIFdvbGZnYW5nIEJlY2ssIFhhdmllciBNYXJqb3UsIFJhbmRlbGwgSmVzdXAsIHBtLCBI YWRyaWVsLCBFbnpvLCBKaW0gTWNFYWNoZXJuLCBFbmRhIE1hbm5pb24sIEVyaWMgUmVzY29ybGEK ClBhcnRoYTogIGRyYWZ0LXBhcnRoYS1ydGNld2ViLXNpZ25hbGluZyBwcm90b2NvbC4gIChSZXZp ZXdlZCBzbGlkZSBkZWNrIHByb3ZpZGVkKQpDdWxsZW47ICBObyBzbGlkZXMsIGJ1dCBkaXNjdXNz aW9uIHRoZSBST0FQIHByb3Bvc2FsLCBpbiB0ZXJtcyBvZiBtb3RpdmF0aW9uLiAgSXQncyBjbGVh ciB0aGF0IHdlIGhhdmUgc2VsZWN0ZWQgUlRQLiAgV2UgY291bGQgdXNlIGFuIGFsdGVybmF0aXZl IHRvIFNEUCwgYnV0IEknbSBzdGFydGluZyBmcm9tIHRoZSBwcm9wb3NpdGlvbiB0aGF0IHdlJ3Jl IGdvaW5nIHRvIGVuZCB1cCBhdCBSVFAgb2ZmZXIvYW5zd2VyLiAgQmFzaWNhbGx5LCBjcmVhdGlu ZyBhbHRlcm5hdGl2ZXMgdG8gU0RQIG9mZmVyL2Fuc3dlciBmb3JjZXMgeW91IHRvIGNyZWF0ZSBt YXBwaW5nczsgeW91IGNhbid0IGNyZWF0ZSBtb3JlIG9yIGxlc3Mgd2l0aG91dCBpc3N1ZXMtLWFu ZCBtYWtpbmcgaXQgdGhlIHNhbWUgZnVuY3Rpb25hbGl0eSBqdXN0IGZvcmNlcyB0aGUgbWFwcGlu Zy4gIEdpdmVuIHRoYXQsIHdoYXQgYXJlIHRoZSBhYnNvbHV0ZWx5IG1pbmltYWwgcGllY2VzIHlv dSBoYXZlIHRvIGFkZCB0byBtYWtlIGl0IHdvcmsgaW4gdGhpcyBjb250ZXh0LS0xKSBkaXN0aW5n dWlzaCBiZXR3ZWVuIG9mZmVyIGFuZCBhbnN3ZXIgKGNob3NlIEpTT04sIGJ1dCBjb3VsZCBiZSBh bnl0aGluZy4yKSBUbyByZWFsbHkgbWFrZSB0aGlzIHdvcmsgd2VsbCwgaXQgd291bGQgYmUgZ3Jl YXQgdG8gaGF2ZSBuZXcgZnVuY3Rpb25hbGl0eSAganVzdCBzaG93IHVwIGZvciBwcmV2aW91c2x5 IGJ1aWx0IHdlYiBhcHBsaWNhdGlvbnMsIHdoZW4gbmV3IGNvZGVjcyBzaG93IHVwLCBmb3IgZXhh bXBsZSwgYW5kIHRoYXQgdGVuZHMgdG8gaW1wbHkgdGhhdCBpdCBpcyB0aGUgYnJvd3NlcnMgdGhh dCBoYW5kbGUgdGhlIHJ0cCBuZWdvdGlhdGlvbi4gIDMpIEdsYXJlIGlzIHN0b2xlbiBmcm9tIFNJ UDsgdGhpcyBpcyBqdXN0IGEgZGVtb25zdHJhdGlvbi0tc29tZXRoaW5nIGxpa2UncyBNYWdudXMn cyBwcm9wb3NhbCB3b3VsZCBiZSBiZXR0ZXIgNCkgVG8gZW5hYmxlIHJlLXRyaWVzLCB0aGUgc2Vz c2lvbiBpZCBhbmQgc2VxdWVuY2UgbnVtYmVyIGFyZSBhZGRlZDsgdGhlc2UgYWxsb3cgeW91IHRv IGlkZW50aWZ5IHdoZW4gc29tZXRoaW5nIGhhcyBiZWVuIHNlZW4gKGZ1bmN0aW9uYWxseSBtYWtl cyBpdCBwb3NzaWJsZSB0byBoYXZlIGlkZW1wb3RlbnQgcmV0cmllcykuIDUpIEhvdyBkbyB5b3Ug ZGVhbCB3aXRoIHRoZSBwb3NzaWJpbGl0eSB0aGF0IGFuIG9mZmVyIG1pZ2h0IGdldCBhIGRpZmZl cmVudCBhbnN3ZXIgbGF0ZXI/ICBCeSBtYWtpbmcgYSB0dXBsZSBvZiB0aGUgc2Vzc2lvbiBpZHMg ZnJvbSBib3RoIHNpZGVzIDYpIE1vcmUgY29taW5nLS1uZWVkZWQgZm9yIHNvbWUgb2YgdGhlIHB1 cmUgYnJvd3NlciBhbmQgZm9yIHRoZSBnYXRld2F5IGNhc2VzLi4gIFJlZmVycyBiYWNrIHRvIHdo eSBTRFAtLXRoZSBvdGhlcnMgYXJlIHdvcnNlLCBhbmQgdGhpcyBpcyB0aGUgbWluaW1hbCBuZWVk ZWQgdG8gYWRkOyBoaXMgaW50ZXJuYWwgbGlzdCBhbmQgSGFkcmllbCdzIGxpc3QgYXJlIHNpbWls YXIuIFJvdWdobHkgdGhlIHByb3Bvc2FsLgoKSGFkcmllbCBLYXBsYW4gbmV4dCwgb24gdGhlICJU YW8gb2YgdGhlIFJUQy1XZWIiLiAgUHV0IHRvZ2V0aGVyIGEgc3RyYXdtYW4gZHJhZnQgdG8gY292 ZXIgdGhpcy4gIFdoeSBhcmUgd2ViIGFwcHMgZ29vZD8gIChSZXZpZXdpbmcgZHJhZnQpCgpTdGFy dGluZyB0aGUgZGlzY3Vzc2lvbjogIFdvbGZnYW5nIEJlY2stLVBhcnRoYSdzIGFwcHJvYWNoIGxv b2tzIGxpa2UganVzdCBtb3ZpbmcgYSBTSVAgVUEgaW50byB0aGUgYnJvd3NlcjsgSSBkb24ndCB0 aGluayB3ZSBuZWVkIHRvIGRvIHRoYXQuICBQYXJ0aGEgcmVwbGllcyB0aGF0IGl0IGlzIHNpbXBs aWZ5aW5nIHRvIGRvIHRoaXMgaW4gIGEgd2ViIGNvbnRleHQuICAKQ3VsbGVuIGNvbW1lbnRzIG9u IEhhZHJpZWwgYW5kIFBhcnRoYSdzIHByb3Bvc2FsLCByZWZlcnJpbmcgYmFjayB0byBkcmFmdC1q ZW5uaW5ncy1ydGN3ZWItYXBpLmh0bWwuICBXaGF0IHdvdWxkIGEgcHJvcG9zYWwgYmUgaGVyZT8g IFNob3cgdXMgdGhlIGludGVyZmFjZSBhcGksIHNvIHdlIGNhbiBhY3R1YWxseSBzZWUgdGhlIHBy b3Bvc2FsPyAgSGFkcmllbCB3YXMgc3VycHJpc2VkIHRvIGdldCBhIHJlcXVlc3QgdG8gZG9jdW1l bnQgYW4gQVBJLiBbQXNrZWQgdG8gcmV0dXJuIHRvIFBhcnRoYSdzIHByb3Bvc2FsIGRpc2N1c3Np b25dLiBQYXJ0aGEgcmVwbGllcyB0byBDdWxsZW47IEVyaWMgYXNrcyB3aGF0J3MgdGhlIGRpZmZl cmVuY2UgYmV0d2VlbiBoaXMgcHJvcG9zYWwgYW5kIFJPQVA/ICBQYXJ0aGEgd2FudHMgdG8gY2xh cmlmeSBob3cgaXQgd2lsbCBiZSBjYXJyaWVkIChlLmcuIEpTT04gb3IgWE1MKSBhbmQgbmVlZHMg Y2xhcmlmaWNhdGlvbiBvbiBob3cgeW91IGNsZWFyIGEgc2Vzc2lvbi0taWYgUk9BUCBhZGRlZCB0 aGF0LCBoZSB3b3VsZCBiZSBmaW5lIHdpdGggUk9BUC4gIEp1c3RpbiBVYmVydGktLXRoZSBwYXJ0 IGhlJ3Mgbm90IGdldHRpbmcgaGlzIGhlYWQgYXJvdW5kLS13aGF0IGFyZSB0aGUgZnVuZGFtZW50 YWwgdGhpbmdzIHRoYXQgd291bGQgbWFrZSBoaXMgcHJvcG9zYWwgYmV0dGVyIHRoYW4gUk9BUD8g IFBhcnRoYSBpcyB0cnlpbmcgdGFja2xlIHRoaW5ncyBsaWtlIG9mZmVyIHZhbGlkaXR5IHRpbWUg YW5kIHRlcm1pbmF0aW5nIHNlc3Npb24uIFNwZWFrZXIgc3VnZ2VzdHMgUlRDV0VCIGJ5ZSBtZXNz YWdlIGluc3RlYWQgb2Ygc29tZXRoaW5nIG92ZXIgSFRUUC4gIE1hZ251cyB3aXRoIGEgcGVlckNv bm5lY3Rpb24gQVBJLCBpdCBpcyBlYXN5IGVub3VnaCB0byBjbG9zZSBhIHBlZXIgY29ubmVjdGlv biwgbm90IHRoZXJlIG5vdywgYnV0IGl0IGNvdWxkIGJlIGFkZGVkLiAgUGFydGhhIHRoYXQncyBp dCwgbm90aGluZyBtb3JlLCBqdXN0IG5lZWQgdG8gaWRlbnRpZnkgYSBjYXJyeWluZyBmb3JtYXQu ICBKdXN0aW46ICBpZiB3ZSBhZGRlZCBzb21lIG9mIHRoaXMgZnVuY3Rpb25hbGl0eSwgd291bGQg eW91IHN1cHBvcnQgUk9BUD8gIFllcywgaWYgaXQgaW5jbHVkZXMgYSB3aXJlIGZvcm1hdC4KCkN1 bGxlbjogSSBhZ3JlZSB0aGF0IHdlIG5lZWQgYSB0ZXJtaW5hdGlvbiB0eXBlIG1lc3NhZ2UsIGFu ZCBJIHdvdWxkIGludGVuZCB0byB0aGlzIHRvIGFkZC4gIEkgYWx3YXlzIGludGVuZGVkIHRoaXMg dG8gYmUgYW4gb3Zlci10aGUtd2lyZSBwcm9wb3NhbCAodGhvdWdoIHRoZSB3aXJlIGNvdWxkIGJl IHZlcnkgc2hvcnQgaW4gc29tZSBjYXNlcykuCkp1c3RpbjogIEkgdGhpbmsgdGhhdCdzIGFuIGlt cG9ydGFudCBkaXN0aW5jdGlvbi0td2UgY291bGQgY29uc3VtZSB0aGlzIHdpdGhpbiB0aGUgSmF2 YXNjcmlwdCBpbiBvcmRlciB0byBjb252ZXIgdGhhdCB0byBTSVAgb3IgSmluZ2xlLCB0aGF0IHdv dWxkIGJlIHBvc3NpYmxlLgoKTWFnbnVzOiBhbnltb3JlIHF1ZXN0aW9ucyBvciBjb21tZW50cyBm b3IgUGFydGhhPyAgTm93LCBvbiB0byBST0FQLgoKVGltVDogIGxlc3Mgb2YgYSBxdWVzdGlvbiwg bW9yZSBvZiBhIGNvbW1lbnQsIGJhc2VkIG9uIHByZXZpb3VzIHByb3Bvc2FsLiAgSSB0aGluayB0 aGUgc2VtYW50aWNzIG9mIHBlZXJDb25uZWN0aW9uIGhhcyBub3QgYmVlbiBjbGVhcjsgd2UgbmVl ZCBzb21ldGhpbmcgbGlrZSBST0FQIHRvIGRlZmluZSB3aGF0IHRoZSBzdGF0ZSBtYWNoaW5lIGlz LiAgV2hldGhlciB3ZSBkbyB0aGF0IGhlcmUsIFczQywgd2hlcmV2ZXIsIGl0IGRvZXNuJ3QgbWF0 dGVyLiAgSSB3YXMgaGFwcHkgdG8gc2VlIHNvbWUgb2YgdGhpcyBnZXQgZGV2ZWxvcGVkLgpDdWxs ZW46ICBBdCB0aGUgbGFzdCBJRVRGLCBJIHRvbGQgSkRSIHRoYXQgMzI2NCBkaWRuJ3Qgc3BlY2lm eSB0aGUgc3RhdGUgbWFjaGluZSBhcyB3ZWxsOyBoZSBub3cgYWdyZWVzLCBhbmQgaGUgYmVsaWV2 ZXMgd2UgbmVlZCB0byBtYWtlIHRoZSBzdGF0ZSBtYWNoaW5lIG1vcmUgZXhwbGljaXQgZm9yIGRl dmVsb3BlcnMgaW4gbGF0ZXIgdmVyc2lvbnMgb2YgUk9BUC4KRXJpYzogIFNvLCBST0FQIGRvZXNu J3Qgbm90IGN1cnJlbnRseSB0YWtlIGNhcmUgb2YgZm9ya2luZywgYW5kIHRoZXJlIGlzIGNvbnNp ZGVyYWJsZSBkaXNjdXNzaW9uIG9mIHRoYXQgb24gdGhlIGxpc3QuICBIb3cgZG8gd2UgZGVhbCB3 aXRoIHRoYXQ/CkN1bGxlbjogIEkgdGhpbmsgUk9BUCBkb2VzIGFsbG93IGEgY2VydGFpbiBhbW91 bnQgb2YgZm9ya2luZyBhdCB0aGUgbWVkaWEuICBUaGUgdXNlIGNhc2U6ICBhIGJyb3dzZXIgbWFr ZXMgYSBjYWxsIHRoYXQgZ29lcyB0aHJvdWdoIGEgc2lnbmFsaW5nIGNhbGwgdmlhIGdhdGV3YXkt LWZvcmsgdG8gcGhvbmUgYW5kIHZvaWNlbWFpbC4gIEhlJ3MgYmVlbiBib3VuY2luZyBzb21lIGVt YWlscyB0byBDaHJpc3RlciBvbiB0aGlzIGFzIHdlbGwtLW1vcmUgY29taW5nIGZsYWcgaXMgcGFy dCBvZiB0aGlzOyBpbiBhIGJhc2UgYXBwLCB0aGlzIHdvbid0IGJlIHVzZWQsIGJ1dCBpbiBtb3Jl IGNvbXBsZXggYXBwcyBpdCBjb3VsZCBiZSAoZS5nLiBrbm93aW5nIHRoYXQgdmlkZW8gbWF5IGNv bWUgbGF0ZXIpLiAgVGhlIHNlY29uZCBwaWVjZSBvZiByb2FwCgpUaW0gUGFudG9uOiAgSSBoYXZl IGEgcGhpbG9zb3BoaWNhbCBwcm9ibGVtIHdpdGggUk9BUC4gIEkgaGF2ZSBhIGZlZWxpbmcgaXRz IGFuc3dlcmluZyB0aGUgd3JvbmcgcHJvYmxlbS0taXQncyBhIGdyZWF0IGludGVyb3AgcHJvcG9z YWwuICBCdXQgaXMgaXQgcmlnaHQgZm9yICJuYXRpdmUiIFJUQ1dlYiBpbiB0aGUgZmFjZWJvb2sg d29ybGQ/ICBEb2VzIHRoaXMgbWFrZXMgaXQgdG9vIGhhcmQgZm9yIHRoZSBuYXRpdmUgUlRDV2Vi LiAgQ3VsbGVuOiAgSSB0aGluayB0aGUgbW9zdCBpbXBvcnRhbnQgdGhpbmcgaXMgdG8gbWFrZSB0 aGUgdm9pY2UtdmlkZW8gd2l0aGluIEphdmFzY3JpcHQgYXBwbGljYXRpb25zLCBub3QgaW50ZXJv cC4gIERhbiBZb3JrJ3MgcmFudCBpcyByaWdodC4gIEhlIGJlbGlldmVzIHRoYXQgdGhpcyBkaWQg bm90IG9wdGltaXplIGxlZ2FjeSBpbnRlcm9wLCBpdCBvcHRpbWl6ZXMgZm9yIGVhcmx5IGFkb3B0 aW9uLiAgVGltOiAgSSBndWVzcyB0aGF0J3Mgd2hlcmUgd2UgZGlmZmVyLiAgVGhpcyByZXF1aXJl cyB5b3UgdG8gcGFyc2UgU0RQLCBsaWtlIHlvdXIgZWFybHkgZHJhZnQgYW5kIG91ciBsYXRlciBk cmFmdC4gIEFyZSB0aGV5IGhpZGRlbiBieSBkZWZhdWx0LCBidXQgdmlzaWJsZSBpZiB5b3UgZ3Jv dmVsIHRocm91Z2ggdGhlIFNEUD8gIE9yIGFyZSB0aGV5IGV4cG9zZWQgYnkgZGVmYXVsdCwgYnV0 IGNvdmVyIGl0IHdpdGggYSB0aWR5IGxpYnJhcnk/ICAgSSBmYWxsIGludG8gdGhlIHNlY29uZCBj YW1wLgoKRXJpYzogIFdoYXQgeW91J3JlIHNheWluZyBpcyBhY3R1YWxseSBub3QgdmVyeSB3ZWIt bGlrZS4gIFRoZXkgdGVuZCB0byBiZSBhYm91dCBzZW1hbnRpY3MsIHJhdGhlciB0aGFuIGRpdmlu ZyBpbnRvIHRoZSBjb2RlY3MuCgpUaW06ICBJZiB5b3Ugc2F5IHRoZSBTRFAgaXMgYSBibG9iLCB3 aGljaCBpcyB3aGF0IFJPQVAgZG9lczsKCkVyaWM6ICBJJ20gbm90IHRhbGtpbmcgYWJvdXQgUk9B UCwgSSdtIHNheWluZyB0aGF0IHRoZSBBUEkgbWFkZSBtZSByZXZlcnNlIGVuZ2luZWVyIGZyb20g dGhlIHdpcmUsIGFuZCB0aGUgc3VwcG9ydCBoYXMgdG8gYmUgcmV2ZXJzZSBlbmdpbmVlcmVkLgoK SGFyYWxkOiAgRm9yIGFsbCB0aGUgb25lcyB0aGF0IHlvdSd2ZSBqdXN0IG1lbnRpb25lZCwgdGhl cmUgYXJlIG90aGVyIHdheXMgdG8gZ2V0IHRoZSBpbmZvcm1hdGlvbiBiZXR0ZXIuICBXZSBtaWdo dCBiZSBjb25mdXNpbmcgc2lnbmFsaW5nIGludGVyZmFjZSB3aXRoIHRoZSBvYmplY3RzIHRoYXQg YXJlIHByb2R1Y2VkIGJ5IHRoZSBzaWduYWxpbmcuClRpbTogIEkgYWdyZWUgY29tcGxldGVseSwg YnV0IGl0IHdvdWxkIGJlIG5pY2UgdG8gZXhwcmVzcyBhIHByZWZlcmVuY2UgaW4gYWR2YW5jZS4g IFlvdSB3YW50IHRvIGluZmx1ZW5jZSB0aGUgbmVnb3RpYXRpb24gd2l0aG91dCBncm92ZWxpbmcg dGhyb3VnaCB0aGUgU0RQLgpIYXJhbGQ6ICBJIGFncmVlIHdpdGggZXZlcnkgd29yZCB5b3Ugc2Fp ZCwgYnV0IHlvdSdyZSBiYXJraW5nIHVwIHRoZSB3cm9uZyBpbnRlcmZhY2UuCkVyaWM6ICBJIGFs d2F5cyBhc3N1bWVkIHRoYXQgdGhpcyB3b3VsZCBiZSBwYXJ0IG9mIHRoZSBBUEkKQ3VsbGVuOiAg U2VjdGlvbiA3LjIsIHNheXMgdGhhdCB0aGVyZSBuZWVkcyB0byBiZSBhIHNlcGFyYXRlIEFQSSBm b3IgdGhpcywgYW5kIGl0IGluY2x1ZGVzIGFsbCB0aGUgdGhpbmdzIHlvdSd2ZSBqdXN0IHRhbGtl ZCBhYm91dC4gIEV2ZXJ5dGhpbmcgeW91IHdhbnQgdG8gZG8geW91IHNob3VsZCBkbyB3aXRob3V0 IGdyb3ZlbGluZyB0aHJvZ2ggdGhlIFNEUD8KVGltOiBEb2VzIHRoZSBoaW50cyBhcGkgb3IgbmVn b3RpYXRpb24gdGFrZSBwcmVjZWRlbmNlPwpIYXJhbGQ6ICBJZiB5b3UgY2hhbmdlIGEgaGludCwg aXQgc2lnbmFscyB0byB0aGUgImJsYWNrIGJveCIgdGhhdCBpdCBuZWVkcyB0byByZW5lZ290aWF0 ZWQ7IHdlIGRvIHRoaXMgYWxsIHRoaXMuClRpbTogSXQncyBub3QgYSBoaW50LCBpdCdzIGEgc2V0 dGluZy4KSGFyYWxkOiAgQnV0IGl0IHRlbGxzIHlvdSB3aGljaCBkaXJlY3Rpb24gdG8gZ28sIHNv bWUgc2V0dGluZ3Mgd291bGQgbm90IGJlIHBvc3NpYmxlLgpUaW06ICBIb3cgaXMgdGhhdCBleHBv c2VkPyAgUXVlcnlpbmcgdGhlIHNpZ25hbGxpbmcgYm94IHRvIGZpZ3VyZSB0aGF0IGFiIGluaXRp bz8KCkVyaWM6ICBMZXQgbWUgdW5kZXJzdGFuZCB0aGF0LS1JIGhhdmUgYSB3aW5kb3cgc2l6ZSBh c2lkZSwgYW5kIEkgd2FudCB0byBwdXQgYSB2aWRlbyBpbiBpdC4gIERvIEkgd2FudCB0byBuZWdv dGlhdGUgYXQgdGhlIGxldmVsIG9mIHNheWluZyAiZ2V0IGl0IGJpZ2dlciBhbmQgbGV0IG1lIGN1 dCBpdCBkb3duIj8gIG9yICJleHRyYXBvbGF0ZSI/CgpUaW06ICBJIGJlbGlldmUgaXQgbXVzdCBi ZSBwb3NzaWJsZS4KCkVyaWM6ICBXaGF0IGlzIHRoZSB1c2UgY2FzZT8KClRpbTogIEdldHRpbmcg dGhpbmdzIGluIHRoZWlyICJuYXR1cmFsIHNpemUiIGZvciBzaG93aW5nIHRoZSB2aWRlbyBmcm9t IGEgZG9vciBwaG9uZS4gIFdlYiBhcHAgY2hhbmdlcyB0aGUgbGF5b3V0IHBvc3QtbmVnb3RpYXRp b24gYW5kIHRlbGxzIHRoZSBzeXN0ZW0gd2hhdCBoYXBwZW5lZC4KCkN1bGxlbjogIFRoaXMgaXMg YSBnb29kIHVzZSBjYXNlLCBJIGxpa2UgaXQuICBTZWN0aW9uIDcuMSBvZiB0aGUgZHJhZnQgd2Fz IG9uIGNhcGFiaWxpdGllcywgYW5kIGl0IHdhcyBlbXB0eS4gIEl0IG5lZWRzIHRvIGJlIGZpbGxl ZCBpbiwgYnV0IHdlIGFsc28gaGF2ZSB0byB1bmRlcnN0YW5kIHRoYXQgdGhlcmUgYXJlIGJyb3dz ZXIgYW5kIE9TIG1ldGhvZHMgdGhhdCBjaGFuZ2VzLgoKVGltOiAgSSB1bmRlcnN0YW5kIHRoYXQs IGJ1dCB0aGUgY2FwYWJpbGl0aWVzIG5lZWQgdG8gYmUgc2hvd24gdG8gdGhlIGphdmFzY3JpcHQs IHJhdGhlciB0aGFuIGp1c3QgaGFuZGluZyB0aGUgamF2YXNjcmlwdCB0aGUgcmVzdWx0cyBvZiBh IGJsYWNrLWJveCBuZWdvdGlhdGlvbi4KCkN1bGxlbjogIEJ1dCB0aGVzZSBhcmUgcmVhbGx5IHVs dGltYXRlbHkgdXAgdG8gdGhlIHVuZGVybHlpbmcgc3lzdGVtLgoKVGltOiAgVGhlbiBJIHdhbnQg dG8gc2VlIGFuIGV4Y2VwdGlvbiwgbm90IHRvIGhhdmUgdGhlIG5lZ290aWF0aW9uIHByb2NlZWQg YW5kIGhhZC4KCk1hZ251czogIFlvdSdyZSByZXN0YXRpbmcgdGhlIHNhbWUgdGhpbmdzIG9uIGFu ZCBvbjsgeW91J3ZlIGhhZCBzb21lIHBvaW50cyBhbmQgSSB0aGluayB0aGV5IGFyZSB2YWxpZC4g IEJ1dCB3ZSBuZWVkIHRvIGFzayBmb3Igb3RoZXIgaXNzdWVzIGJlZm9yZSBnb2luZyBvbiB0byBv bmUgbGFzdCB0aGluZz8KCkN1bGxlbjogIENhbiBJIGFkZCBvbmUgbGFzdCB0aGluZz8KCk1hZ251 czogU2hvcnQ/CgpDdWxsZW46ICBJbiB0aGUgd2ViLCBhcyBJIHNlZSBpdCwgeW91IGdldCBtdWNo IG1vcmUgZWZmb3J0IHRvIGhhdmUgdGhpbmdzIGNhcnJ5IG9uLCByYXRoZXIgdGhhbiBleGNlcHRp b24gYW5kIGZhaWx1cmU7IHRoYXQncyB0aGUgbW9kZWwgSSB3YXMgd3JpdGluZyB0bywgcmF0aGVy IHRoYW4gZXhjZXB0aW9uLgoKRGFuIEJ1cm5ldHQ6ICBUaGF0IGlzIHRoZSB3ZWIgaGFzIHdvcmtl ZCwgYnV0IGl0IGlzIG5vdCB0aGUgd2F5IGl0IGlzIGdvaW5nOyBpdCBpcyBnb2luZyB0byBjb250 cm9sLCByYXRoZXIgdGhhbiBkZWNsYXJhdGl2ZSB0aGluZ3M7IG1vZGVybiB3ZWIgYXBwcyBoZWFk aW5nIHRoZSBvdGhlci4KCkp1c3Rpbmc6ICBDdWxsZW4gcHJlc2VudGVkIGEgdmVyeSBsb3dlc3Qg QVBJLS10aGUgdGltZSBpdCB3b3VsZCB0YWtlIHRvIGdldCB0aGVyZSB3b3VsZCB0YWtlIGFuIGVu dGVybml0eS4gIFJPQVAgaXMgc29tZXRoaW5nIHdlIGNhbiBkbyBub3cuICBUbyB0aG9zZSBwcm9w b3NpbmcgdGhlIG51bGwgcHJvcG9zYWwuICBIb3cgZmFyIGRvd24gZG8gd2UgcmVhbGx5IG5lZWQg dG8gZ28gdG8gZ2V0IHRoZSBmcmVlZG9tIHRvIGlubm92YXRlPwoKSGFkcmllbDogIFNvIGhhcmQg dG8gcHJlZGljdCwgc2luY2UgdGhlIGlubm92YXRpb24gY2FuJ3QgYmUgcHJlZGljdGVkLiAgVGhl IGlkZWEgaXMgdG8gcHJvdmlkZSBhIHRvb2xib3gsIGFuZCBsZXQgcGVvcGxlIGRlY2lkZSB3aG8g YXJlIHNtYXJ0ZXIgdGhhbiB0aGF0LiAgVGhlcmUgaXMgbm8gZGViYXRlIHRoYXQgZXhwb3Npbmcg Yml0cyBhbmQgYnl0ZXMgb2YgcGFja2V0IGhlYWRlcnMgaXMgZXhjZXNzaXZlLiAgICBUaGUgdGlt ZSBpdCB0YWtlcyB0byBleHBvc2UgdGhvc2UgaXMgc29tZXRoaW5nIEknbSBub3Qgc3VyZSBJIGNh biBzYXktSSBoYXZlIGl0IGluIHByb2R1Y3QsIGJ1dCBkb24ndCBrbm93IGFib3V0IHlvdSBvciBv dGhlcnMuCgpKdXN0aW46IFNwZWFraW5nIGZvciBHb29nbGUuICBXZSBkbyBoYXZlIGEgdmVyeSBs YXllcmVkIGRlc2lnbi4gIFdlIGNvdWxkIGNvbWUgaW4gYXQgYW55IG9uZSBvZiB0aG9zZSBsYXll cnMsIGJ1dCBhcyB5b3UgZ28gZG93biwgdGhlIEFQSSBleHBhbmRzIGEgKmxvdCouICBJZiBJIGNv dWxkIGRvIGV2ZXJ5dGhpbmcgYXQgamF2YXNjcmlwdCwgc28gSSBjYW4gd29yayBhcm91bmQgYnJv d3NlciBpc3N1ZXMsIHRoYXQgd291bGQgYmUgZ3JlYXQuICBCdXQgdGhlIGVuZXJneSByZXF1aXJl ZCB0byBjcmVhdGUgYSBtaW5pbWFsIGJ1dCBjb21wbGV0ZSBBUEkgd291bGQgYmUgdmVyeSwgdmVy eSBoaWdoLiAgV2UgY2FuIHVzZSBzb21ldGhpbmcgbGlrZSBST0FQIG5vdywgYW5kIHBsdW1iIG90 aGVyIEFQSXMgaW4gdGhlciBmdXR1cmUuCgpUaW1UOiAgSSB3YW50IHRvIHNlY29uZCB0aGF0IHBv aW50LiAgVGhlIHZlcnkgbG93IGxldmVsIEFQSSBzdXBwb3J0ZXJzIHNlZW0gdG8gYmUgc2F5aW5n IHdlIGhhdmUgdG8gaGF2ZSBldmVyeXRoaW5nIHVwIGZyb250LCBidXQgdGhhdCdzIG5vdCB0aGUg d2F5IHRoZSB3ZWIgaGFzIGRvbmUuICBXZSd2ZSBkb25lIHNpbXBsZSB0aGluZ3MgYW5kIGxldCB0 aGVtIGdldCBtb3JlIGNvbXBsZXggYXMgdGhlIG5lZWRzIGFyb3NlLiAgRG9pbmcgYSBmdWxsIGxv dy1sZXZlbCBBUEkgIHdvdWxkIHRha2UgYSBsb25nIHRpbWUgdG8gZ2V0IHJpZ2h0LgoKUmFuZGVs bCBKZXNzdXA6ICBJIGFsc28gYWdyZWUsIGRldmVsb3BpbmcgYW5kIHRlc3RpbmcgdGhhdCBsb3cg bGV2ZWwgQVBJIHdpbGwgYmUgdmVyeSB0aW1lIGNvbnN1bWluZyBhbmQgaW50ZW5zaXZlIHdvcmtp bmcuICBJVCByZXF1aXJlcyBhIGxvbmcgZWZmb3J0IGluIGNyb3NzLWJyb3dzZXIgY29tcGF0aWJp bGl0aWVzLiAgTXkgc3VnZ2VzdGlvbiB3b3VsZCBiZSB0byBzdGFydCBzaW1wbGUuICBXZSBjYW4g Y3JlYXRlIGEgbG93LWxldmVsIEFQSSBmb3IgYSB2ZXJzaW9uIDIuCgpIYXJhbGQ6ICBIYWRyaWVs IG1lbnRpb25lZCB0aGF0IHdlIGhhdmUgdGhlc2UgbG93ZXIgbGF5ZXIgQVBJcyBhbHJlYWR5LCBz byB3ZSBjYW4ganVzdCBleHBvc2UuICBCdXQgeW91IGhhdmUgc29tZSwgYW5kIEkgaGF2ZSBzb21l LCBidXQgdGhleSBhcmUgbm90IHRoZSBzYW1lLiAgV2hhdCB3ZSBhcmUgZG9pbmcgbm93IGlzIGFs bG93aW5nIHRoZSBiYXNlIHVzZSBjYXNlcywgYW5kIHRoZSBsaWJyYXJpZXMgZG8gbm90IGhhdmUg dG8gbWF0Y2ggYmVjYXVzZSB0aGV5IGRvIGFyZSBub3QgZXhwb3NlZC4gIAoKSGFkcmllbDogSSBn cm9rIHRoYXQsIGFuZCBJIHNlZSB0aGUgcHJvYmxlbS4gIEl0IHdpbGwgdGFrZSBhIHdoaWxlIHRv IGdldCB0aGVtIHRvIGJlIHRoZSBzYW1lLiAgV2hhdCBJIHdhcyB0cnlpbmcgdG8gc3VwcG9ydCB3 YXMgYWxyZWFkeSBpbiBTRFAsIHNvIEkgdGhvdWdodCBpdCB3b3VsZCBiZSBzdXBwb3J0LiAgCgpI YXJhbGQ6ICBCdXQgeW91J3JlIGFzc3VtaW5nIHRoYXQgYWxsIHRoZXNlIGNvbnRyb2xzIGhhdmUg dG8gYmUgbWFuaXB1bGF0ZWQgYnkgSmF2YXNjcmlwdCwgc28gdGhleSBoYXZlIHRvIGJlIGV4cG9z ZWQgYnkgdGhlIGJyb3dzZXIuICBUaGF0J3Mgbm90IGEgc2hvcnQgcGF0aC4KCldvbGZnYW5nOiAg SG93IHdvdWxkIHlvdSB0ZXN0IFJPQVAgaW4geW91ciBicm93c2VyPwoKSGFyYWxkOiBUb3NzIHRo ZW0gdG8gb3RoZXIgYnJvd3NlcnMgYW5kIGRvIGludGVyd29ya2luZy4KCkN1bGxlbjogIExldCBt ZSB0YWxrIGFib3V0IHRlc3RpbmcuICBUaGUgc3R1ZmYgaW4gY2hyb21lIGlzIGJhc2VkIG9uIGxp YmppbmdsZS0taXQncyBzZWVuIGJpbGxpb25zIG9mIG1pbnV0ZXMgb2YgdXNlOyB0aGUgc3R1ZmYg d2UncmUgdGVzdGluZyBpbiB0aGUgbW96aWxsYSBwcm9qZWN0IGNvbWVzIGZyb20gY29kZSB0aGF0 IGhhcyAxMCB5ZWFycyBvZiBidWcgZml4ZXMuICBTbyB0ZXN0aW5nIHRoYXQgdGhpcyBwYXJ0IHdh cyB3b3JraW5nIGluIG9mZmVyL2Fuc3dlciBkaWQgbm90IGdvIGludG8gdGhlIGxldmVsIG9mIHRl c3RpbmcgYmVjYXVzZSAgdGhlIGZpZWxkIGV4cG9zdXJlIGhhcyBkb25lIGl0LgoKSGFkcmllbDog IEkgd2FzIG5vdCB3b3JyaWVkIGFib3V0IEdvb2dsZSBhbmQgTW96aWxsYS4KCkN1bGxlbjogIEJ1 dCBTYWZhcmkgaXMgYWxzbyBXZWJraXQgYW5kIElFIGhhcyBhY2Nlc3MgdG8gc29tZSBwcmV0dHkg Z29vZCBvZmZlci9hbnN3ZXIgZW5naW5lcy4KCkhhZHJpZWw6ICBJJ20gd29ycmllZCBhYm91dCB0 aGUgYnJvd3NlcnMgb3V0c2lkZSB0aGUgVS5TL0V1cm9wZWFuIG1hcmtldC4gIEl0J3MgdGhlIG5h dGlvbmFsbHkgc3BlY2lmaWMgdmFyaWFudHMgdGhhdCB3b3JyeSBtZS4KClNwZWFrZXI6ICBzbyB5 b3UncmUgc2F5aW5nIHRoYXQgeW91IG5lZWQgMTAgeWVhcnMgZXhwZXJpZW5jZSB0byBpbXBsZW1l bnQgdGhpcz8KCkhhZHJpZWw7ICBubywgbm8uIE5vdCB3aGF0IEknbSBzYXlpbmcKClJhbmRlbGw6 ICB0aGUgbmF0aW9uYWwgdmFyaWFudHMgdGVuZCB0byBiZSB3cmFwcGVycyBhcm91bmQgd2Via2l0 IG9yIElFIG9yIGJvdGguCgpTdGVmYW46ICBXZSd2ZSBiZWVuIGltcGxlbWVudGluZyB0aGlzIGlu IHdlYmtpdC4gIFVzaW5nIG9mZmVyL2Fuc3dlciwgaXQgd2Fzbid0IHRoYXQgaGFyZCB3b3JrLiAg RnJvbSBhbiBpbXBsZW1lbnRhdGlvbiBhbmQgdGVzdGluZyBhc3BlY3QsIFJPQVAgbG9va3MgZG9h YmxlLgoKSGFyYWxkOiBBbm90aGVyIHRoaW5nIGFib3V0IHRlc3RpbmcsIGlmIHlvdSBoYXZlIGEg MTAwIEFQSSBjYWxscywgdGhlIGNvbWJpbmF0b3JpYWwgc2VxdWVuY2VzIGFyZSB2ZXJ5IGxhcmdl OyB3aXRoIGEgc21hbGxlciBudW1iZXIsIHRoZSBvYmplY3RzIGFyZSBtb3JlIGNvbXBsZXgsIGJ1 dCB0aGUgdGVzdGluZyBpcyBzaW1wbGVyLgoKSGFkcmllbDogIEJlY2F1c2UgbWFueSBvZiB0aG9z ZSBhcmUgaW4gU0RQLCB5b3UgaGF2ZSB0aGlzIHNhbWUgY29tcGxleGl0eSwgYnV0IGl0IGlzIGV2 ZW4gaGFyZGVyLgoKVGltVDogIEFjdHVhbGx5LCBub3QgbmVjZXNzYXJpbHksIGFzIGl0IGdldHMg aGFuZGVkIG9mZiB0byB0aGUgcGFyc2VyIGF0IG9uZSBwbGFjZSBpbiB0aGUgY29kZSBiYXNlLgoK SGFyYWxkOiAgeW91IGhhdmUgdGhlIGNhc2Ugb2Ygc2V0dGluZyB0aGUgY29kZWMgcGFyYW1ldGVy cyB3aGVuIG5lZ290aWF0aW5nIG9yIHJlLW5lZ290aWF0aW5nIHRoZSBzdHJlYW1zLiAgQnV0IHRo ZXJlIGlzIG5vIHJlc3RyaWN0aW9uIG9uIHdoZW4gdGhpcyBpcyBjYWxsZWQgaW4gdGhlIGxvdy1s ZXZlbCBBUEkgcHJvcG9zYWwuICBUaGF0J3MgdmVyeSBoYXJkIHRvIHRlc3QuCgpIYWRyaWVsOiAg SSBkb24ndCBkaXNhZ3JlZSB0aGF0IHRoaXMgaXMgbW9yZSBjb21wbGljYXRlZC4gIEJ1dCBpbiB0 aGUgUk9BUCBwcm9wb3NhbCwgeW91IG1heSBoYXZlIHRvIGtleSB0aGUgaGludHMgdG8gdGhlIFNE UCBvZmZlciBhbnN3ZXIuICBEb2VzIHRoaXMgY2F1c2UgYSByZW5lZ290aWF0aW9uPwoKQ3VsbGVu OiAgU29tZXRpbWVzLiAgSWYgYSBoaW50IGNoYW5nZSBlZmZlY3RzIG9ubHkgdGhlIGxvY2FsIHNp ZGUsIGl0IGRvZXMgbm90IGNyZWF0ZSBhbiBvZmZlci9hbnN3ZXIgZXhjaGFuZ2UuIFNvbWV0aGlu ZyB0aGF0IGRvZXMgcmVxdWlyZSBhbiBvZmZlci9hbnN3ZXIgZXhjaGFuZ2UgZ29lcyB0byB0aGUg b3RoZXIgc2lkZS4gIFlvdSBuZWVkIHNvbWV0aGluZyB0aGF0IHVuZGVyc3RhbmRzIHRoZSBwcm9w ZXJ0aWVzIG9mIHRoZSBjb2RlYyBkZWVwbHkgdG8ga25vdyB3aGljaCBvbmUgeW91J3ZlIGdvdCBp biBhIHBhcnRpY3VsYXIgc2l0dWF0aW9uLgoKSGFkcmllbDogIEluIEphdmFzY3JpcHQsIHdpbGwg eW91IGhhdmUgdG8gY2hhbmdlIG9uZSwgZ2V0IGEgcmV0dXJuLCB0aGVuIGNoYW5nZSBhbm90aGVy LCB0aGVuIGNoYW5nZSBhIHRoaXJkPwoKQ3VsbGVuOiAgSW4gSmF2YXNjcmlwdCBpbiBicm93c2Vy LCB0aGlzIGlzIHF1ZXVlZCB1cCBpbiBhIHJ1bi10by1jb21wbGV0aW9uLCBzbyB0aGlzIGdldHMg c2VudCB0byB0aGUgYnJvd3NlciBvbmx5IHdoZW4gdGhpcyBpcyBhICJzdGFibGUgc3RhdGUiICh3 aGVyZSB0aGUgYnJvd3NlciBzdGFibGUgc3RhdGUgcmVsYXRlcyB0byB0aGUgZG9tLCBub3QgdGhl IHByb3RvY29sIHN0YXRlKS4KCkRzaWN1c3Npb24gb2Ygd2hhdCB0aGUgYnV0dG9uLXByZXNzaW5n IFVJIG1vZGVsIGlzIChpdCBkZXBlbmRzKSwgYnV0IHRoaXMgaXMgbm90IHJlYWxseSBzcGVjaWZp YyB0byBST0FQLCBhcyBpdCBpcyBubyBkaWZmZXJlbnQgaW4gdGhlIGxvdy1sZXZlbCBBUEkuCgpI YWRyaWVsOiByaWdodC4KCkhhZHJpZWw6ICBZb3Uga2VlcCBzYXlpbmcgaXQgaXMgc2ltcGxlLiAg SSBkb24ndCBidXkgdGhhdCBpdCBpcyBzaW1wbGUtdG8taW1wbGVtZW50IGZvciB3ZWIgZGV2ZWxv cGVtZW50LCBidXQgaXQgaXMgbW9yZSBpbnRlcmVzdGluZyB0aGF0IHlvdSBhcmUgc2F5aW5nIGl0 IGlzIHNpbXBsZXIgZm9yIGJyb3dzZXJzLgoKRXJpYzogIEknbSBub3Qgc3VyZSBJIGVudGlyZWx5 IGFncmVlIG9uIHRoZSBsaWJyYXJ5LCBpbiB0aGF0IHRoZSBqYXZhc2NyaXB0cyBzcGVuZCBhIGxv dCBvZiB0aW1lIHBhcGVyaW5nIG92ZXIgZGlmZmVyZW5jZXMgaW4gdGhlIGJyb3dzZXJzLiAgU28g dGhlcmUgYXJlIGEgbG90IG9mIGphdmFzY3JpcHQgZWxlbWVudHMgdGhhdCBhcmUgdGhlcmUgdGhh dCBhcmUgaGFuZGxpbmcgaG93IG90aGVycyBoYW5kbGUgamF2YXNjcmlwdC4KCkRhbjogIEJ1dCBK YXZhc2NyaXB0IGxpYnJhcmllcyBjYW4gYmUgaXRlcmF0ZWQgdmVyeSBxdWlja2x5LgoKQ3VsbGVu OiAgSSBkaWQgc29tZSBzdGF0aXN0aWNzLCBhbmQgdGhlIGV2aWRlbmNlIGFjdHVhbGx5IGRvZXMg bm90IHN1cHBvcnQgdGhhdCBhcmd1bWVudCwgYXMgd2Vic2l0ZXMgZG9uJ3QgdXBncmFkZS4gIFRo ZXkgdXNlIHdoYXRldmVyIHZlcnNpb24gZmlyc3Qgd29ya2VkCgpEYW46ICBCdXQgdGhleSBhcmUg YXZhaWxhYmxlIGlmIG5lZWRlZAoKSGFkcmllbDogIFRoZXkgYXJlIGF2YWlsYWJsZSBpcyBjcml0 aWNhbCBpbmZvcm1hdGlvbiwgYmVjYXVzZSB0aGF0J3Mgd2hlcmUgdGhlIGlubm92YXRpb24gY2Fu IHRha2UgcGxhY2UuCgpEaXNjdXNzaW9uIG9mIHVwZGF0ZSBzdGF0aXN0aWNzIGFuZCB0aGVpciBp bXBhY3RzLiAgU2l0ZXMgY2FuIGZvcmNlIHlvdSBpbnRvIGEgbmV3IHZlcnNpb24gb2YgSnF1ZXJ5 LCBidXQgY2FuJ3QgY2F1c2UgeW91IHRvIHVwZGF0ZSB5b3VyIGJyb3dzZXIsIGJ1dCBicm93c2Vy cyBtYXkgdXBkYXRlIGZhc3Rlci4KClRlZDogIFdvcnN0IGNhc2UgaXMgd2hlbiB5b3UgbXVzdCB1 cGRhdGUgYm90aC4gIFRoaXMgbWF5IGJlIHdvcnNlIGluIHRoZSBsb3ctbGV2ZWwgYXBpLgoKVGlt IFBhdHRvbiAmIEhhZHJpZWw6ICBXZSBkaXNhZ3JlZS4gYnV0IHdlIG5lZWQgdG8gd3JhcCB1cC4K CkN1bGxlbjogIEkgd2lsbCBjbGFyaWZ5IFJPQVAgaXMgb3Zlci10aGUtd2lyZSBwcm90b2NvbCwg YWRkIHRlcm1pbmF0aW9uLCBhbmQgZG8gc29tZSBvdGhlciBjbGFyaWZpY2F0aW9ucywgdGhlbiBy ZS1pc3N1ZS4gIEFyZSB0aGVyZSBvdGhlciB0aGluZ3Mgd2UgaGF2ZSB0byBnbyBkbz8KCkhhZHJp ZWw6ICBJZiB5b3UgZG8gYWxsb3cgc2V0dGluZ3MvaGludHMsIGhvdyBkbyB5b3UgcmVsYXRlIHRo b3NlIHRvIHdoYXQncyBoYXBwZW5pbmcgaW4gdGhlIG5lZ290aWF0aW9uLgoKRXJpYzogIFRoYXQn cyBhIGdlbmVyYWwgaXNzdWU6ICBJIHdhbnQgdG8ga25vdyB3aGV0aGVyIHRoZSBhY3Rpb25zIEkg YXNrZWQgZm9yIGFyZSBjb21wbGV0ZWQuICBTb21lIG9mIHRoZXNlIGFyZSBXM0MgdGhpbmdzLCBi dXQgc2luY2UgQ3VsbGVuIGlzIGVkaXRvciB0aGVyZSB0b28sIGl0J3Mgc3RpbGwgb24gaGlzIHBs YXRlCgpKdXN0aW46ICBJbiBnZW5lcmFsLCBlcnJvciBoYW5kbGluZyBuZWVkcyB0byBiZSB1cGRh dGVkIGFzIHdlbGwuCgpIYXJhbGQ6ICBUaGUgb3RoZXIgdGhpbmcgSSBoZWFyIGlzIHRoYXQgdGhl IHBlb3BsZSB0aGF0IGFyZSBkb2luZyBicm93c2VycyBhcmUgd2lsbGluZyB0byBST0FQLCBidXQg SSBkb24ndCBoZWFyIGEgd2lsbGluZ25lc3MgdG8gaW1wbGVtZW50YSBsb3dlciBsYXllciBBUEkg KmluIHRoaXMgY3ljbGUqLgoKSnVzdGluOiAgQnV0IEkgdGhpbmsgd2UgY2FuIHRoaW5rIGFib3V0 IGRvaW5nIGEgbG93ZXIgbGF5ZXIgQVBJIGluIHRoZSBmdXR1cmUsIGFuZCBwbHVtYmluZyB0aGF0 IGluIHRoZSBmdXR1cmUuCgpNYWdudXM6ICBIYWRyaWVsLCBhbnkgY29uY2x1ZGluZyByZW1hcmtz LgoKSGFkcmllbDogIFdlIGNvdWxkIGtlZXAgd29ya2luZyBvbiB0aGlzIGRyYWZ0LgoKU2NyaWJl IGdvdCBjdXQgb2ZmIHRoZXJlLgoKCgogCg== --20cf305b121e99271c04afd13503-- From wolfgang.beck01@googlemail.com Fri Oct 21 09:04: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 35BF41F0C7A for ; Fri, 21 Oct 2011 09:04:19 -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 1biENk+xbV+W for ; Fri, 21 Oct 2011 09:04:18 -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 33F791F0C76 for ; Fri, 21 Oct 2011 09:04:18 -0700 (PDT) Received: by gyh20 with SMTP id 20so4820392gyh.31 for ; Fri, 21 Oct 2011 09:04:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KP54qKkVMJ/cxQVLrLEX/CWpHiPpnOfUbih26OQJQWM=; b=QK8erkkS4CcM6ZvWHI6JxjQzESBzQ3Tb2TAD4U99d+2ZYTiDbKIf0ADXKW+hTHmGLN b2hFirpBImX5igd72Dt2a7PKHO6JmjMc1XaTqjdkH/MIyRCOo3qodnA9UE/U3x/LtJEM zGxPukZ0/UNmkp+rIzu/+cHl1ZoRlPjXtc4xY= MIME-Version: 1.0 Received: by 10.68.9.2 with SMTP id v2mr28727149pba.101.1319213057599; Fri, 21 Oct 2011 09:04:17 -0700 (PDT) Received: by 10.68.55.230 with HTTP; Fri, 21 Oct 2011 09:04:17 -0700 (PDT) In-Reply-To: <4EA195B1.4010705@alvestrand.no> References: <4EA195B1.4010705@alvestrand.no> Date: Fri, 21 Oct 2011 18:04:17 +0200 Message-ID: From: Wolfgang Beck To: Harald Alvestrand Content-Type: text/plain; charset=ISO-8859-1 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Browser update rates X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 16:04:19 -0000 The differences in adoption rate between IE and Chrome are interesting. On Fri, Oct 21, 2011 at 5:54 PM, Harald Alvestrand wrote: > I found this webpage. No idea of how authoritative it is. > > http://www.netmagazine.com/features/developers-guide-browser-adoption-rates > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From HKaplan@acmepacket.com Fri Oct 21 09:18: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 17C9C21F8B9A for ; Fri, 21 Oct 2011 09:18:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.418 X-Spam-Level: X-Spam-Status: No, score=-2.418 tagged_above=-999 required=5 tests=[AWL=0.181, 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 UhhcbqXHz8HP for ; Fri, 21 Oct 2011 09:18:36 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 4DB8A21F8B90 for ; Fri, 21 Oct 2011 09:18:35 -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, 21 Oct 2011 12:18:34 -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, 21 Oct 2011 12:18:35 -0400 From: Hadriel Kaplan To: Wolfgang Beck Thread-Topic: [rtcweb] Browser update rates Thread-Index: AQHMkAm53veooeqBm06GAI9E6DvMapWHOSaAgAAD+wA= Date: Fri, 21 Oct 2011 16:18:33 +0000 Message-ID: References: <4EA195B1.4010705@alvestrand.no> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [216.41.24.34] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Browser update rates X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 16:18:37 -0000 Yeah it's IE as I said on the call. :( C'est la vie. On Oct 21, 2011, at 12:04 PM, Wolfgang Beck wrote: > The differences in adoption rate between IE and Chrome are interesting. >=20 > On Fri, Oct 21, 2011 at 5:54 PM, Harald Alvestrand = wrote: >> I found this webpage. No idea of how authoritative it is. >>=20 >> http://www.netmagazine.com/features/developers-guide-browser-adoption-ra= tes >>=20 >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >>=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From ibc@aliax.net Fri Oct 21 09:25: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 08A6D21F86DD for ; Fri, 21 Oct 2011 09:25:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[AWL=0.045, 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 LHpRLuiBs6MC for ; Fri, 21 Oct 2011 09:25:45 -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 C61FD21F86C1 for ; Fri, 21 Oct 2011 09:25:43 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so4193764vcb.31 for ; Fri, 21 Oct 2011 09:25:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.115.77 with SMTP id h13mr563185vcq.111.1319214343307; Fri, 21 Oct 2011 09:25:43 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Fri, 21 Oct 2011 09:25:43 -0700 (PDT) Date: Fri, 21 Oct 2011 18:25:43 +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] Does ROAP mandate the on-the-wire format? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 16:25:48 -0000 Hi, I'm a bit afraid after listeing/reading this phrase in the conf: ----------------- Cullen: I will clarify ROAP is over-the-wire protocol, add termination, and do some other clarifications, then re-issue. ----------------- I expect that ROAP does NOT mandate the format of the messages exchanged on-the-wire, but just the communication between the JS custom code and the RTCweb stack in the browser, am I right? say "yes" please. What I understand (or want to understand) is that any custom RTCweb on-the-wire protocol must satisfy ROAP requirements in some way, so when the JavaScript receives some kind of custom message it can interpret it and convert into the appropriate ROAP request, and then make a ROAP call to the browser via the RTCweb API. Am I right? Thanks. --=20 I=C3=B1aki Baz Castillo From giles@thaumas.net Fri Oct 21 09:36: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 914D91F0C6D for ; Fri, 21 Oct 2011 09:36:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bGjwZWM3AcpR for ; Fri, 21 Oct 2011 09:36:04 -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 EAF1F1F0C63 for ; Fri, 21 Oct 2011 09:36:03 -0700 (PDT) Received: by vws5 with SMTP id 5so3709198vws.31 for ; Fri, 21 Oct 2011 09:36:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.173.113 with SMTP id bj17mr14786718vdc.98.1319214962443; Fri, 21 Oct 2011 09:36:02 -0700 (PDT) Received: by 10.220.192.8 with HTTP; Fri, 21 Oct 2011 09:36:02 -0700 (PDT) X-Originating-IP: [66.183.19.247] In-Reply-To: References: Date: Fri, 21 Oct 2011 09:36:02 -0700 Message-ID: From: Ralph Giles To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Does ROAP mandate the on-the-wire format? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 16:36:04 -0000 On 21 October 2011 09:25, I=C3=B1aki Baz Castillo wrote: > I expect that ROAP does NOT mandate the format of the messages > exchanged on-the-wire, but just the communication between the JS > custom code and the RTCweb stack in the browser, am I right? say "yes" > please. I'm not Cullen, but my understanding is that this is the case. The terminology is confusing, and I think we've been talking past each other a lot over the past weeks. I believe the point is that ROAP is the message format, state machine, and 'protocol' which one peerconnection object in one browser uses to talk to another peerconnection object in another browser to set up the direct media connections. Because there's more than one browser implementation this needs to be standardized, and an easy way to think of that requirement is if the roap messages are passed directly between the user agents without modification. Of course, since the format, state machine, etc. are documented, then of course whatever code is conveying the messages between the user agents can translate or edit the data, as long as it's a compatible manipulation. -r > > What I understand (or want to understand) is that any custom RTCweb > on-the-wire protocol must satisfy ROAP requirements in some way, so > when the JavaScript receives some kind of custom message it can > interpret it and convert into the appropriate ROAP request, and then > make a ROAP call to the browser via the RTCweb API. Am I right? > > Thanks. > > -- > I=C3=B1aki Baz Castillo > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From HKaplan@acmepacket.com Fri Oct 21 09:39: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 9ED391F0C6F for ; Fri, 21 Oct 2011 09:39:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.272 X-Spam-Level: X-Spam-Status: No, score=-2.272 tagged_above=-999 required=5 tests=[AWL=0.027, 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 pxbRCavGttis for ; Fri, 21 Oct 2011 09:39:28 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 0194C1F0C6D for ; Fri, 21 Oct 2011 09:39:28 -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, 21 Oct 2011 12:39:26 -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, 21 Oct 2011 12:39:27 -0400 From: Hadriel Kaplan To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= Thread-Topic: [rtcweb] Does ROAP mandate the on-the-wire format? Thread-Index: AQHMkA//9B+N9mef2kyVTdnWzyP1pg== Date: Fri, 21 Oct 2011 16:39:26 +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="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [rtcweb] Does ROAP mandate the on-the-wire format? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 16:39:28 -0000 On Oct 21, 2011, at 12:25 PM, I=F1aki Baz Castillo wrote: > Hi, I'm a bit afraid after listeing/reading this phrase in the conf: >=20 > ----------------- > Cullen: I will clarify ROAP is over-the-wire protocol, add > termination, and do some other clarifications, then re-issue. > ----------------- >=20 > I expect that ROAP does NOT mandate the format of the messages > exchanged on-the-wire, but just the communication between the JS > custom code and the RTCweb stack in the browser, am I right? say "yes" > please. > What I understand (or want to understand) is that any custom RTCweb > on-the-wire protocol must satisfy ROAP requirements in some way, so > when the JavaScript receives some kind of custom message it can > interpret it and convert into the appropriate ROAP request, and then > make a ROAP call to the browser via the RTCweb API. Am I right? Well since the Browser will never know whether ROAP is really to another Br= owser vs. the Javascript, then yes it could be used that way. (it will prob= ably be painful, but possible) -hadriel From ibc@aliax.net Fri Oct 21 09:43: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 0339021F8B07 for ; Fri, 21 Oct 2011 09:43:40 -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.044, 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 HNwCjcXg138J for ; Fri, 21 Oct 2011 09:43:39 -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 014B421F8B04 for ; Fri, 21 Oct 2011 09:43:38 -0700 (PDT) Received: by vws5 with SMTP id 5so3716909vws.31 for ; Fri, 21 Oct 2011 09:43:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.73.166 with SMTP id m6mr15014310vdv.18.1319215413396; Fri, 21 Oct 2011 09:43:33 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Fri, 21 Oct 2011 09:43:33 -0700 (PDT) In-Reply-To: References: Date: Fri, 21 Oct 2011 18:43:33 +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] Does ROAP mandate the on-the-wire format? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 16:43:40 -0000 2011/10/21 Hadriel Kaplan : > Well since the Browser will never know whether ROAP is really to another = Browser vs. the Javascript, then yes it could be used that way. (it will pr= obably be painful, but possible) The question comes because my wire signaling implementation (SIP over WebSocket) is that: SIP. So the JS sends and receives pure SIP messages (with SDP) over the wire. If ROAP includes a real SDP (as the draft currently states) then I'm done as I just need to create a ROAP object (in JavaScript) and pass it the received SDP string (and also set some session status variables, which can be easily mapped from the received SIP request/response). Hope I'm right and I don't have to drop the work of long months. Regards. --=20 I=C3=B1aki Baz Castillo From HKaplan@acmepacket.com Fri Oct 21 10:37: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 469F01F0C91 for ; Fri, 21 Oct 2011 10:37:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.273 X-Spam-Level: X-Spam-Status: No, score=-2.273 tagged_above=-999 required=5 tests=[AWL=0.026, 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 own0V7YkaF9u for ; Fri, 21 Oct 2011 10:37:08 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id AB2131F0C8C for ; Fri, 21 Oct 2011 10:37: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; Fri, 21 Oct 2011 13:37:06 -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, 21 Oct 2011 13:37:07 -0400 From: Hadriel Kaplan To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= Thread-Topic: [rtcweb] Does ROAP mandate the on-the-wire format? Thread-Index: AQHMkBgN2/kP8vYgo0SdE44T6C8DAQ== Date: Fri, 21 Oct 2011 17:37:05 +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="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [rtcweb] Does ROAP mandate the on-the-wire format? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 17:37:09 -0000 You know, doing that would be awesome because then you could test it agains= t real SIP devices, or even at Sipit, to verify we've got the legacy-SIP-co= mpatibility-model right for more esoteric cases. -hadriel On Oct 21, 2011, at 12:43 PM, I=F1aki Baz Castillo wrote: > 2011/10/21 Hadriel Kaplan : >> Well since the Browser will never know whether ROAP is really to another= Browser vs. the Javascript, then yes it could be used that way. (it will p= robably be painful, but possible) >=20 > The question comes because my wire signaling implementation (SIP over > WebSocket) is that: SIP. So the JS sends and receives pure SIP > messages (with SDP) over the wire. >=20 > If ROAP includes a real SDP (as the draft currently states) then I'm > done as I just need to create a ROAP object (in JavaScript) and pass > it the received SDP string (and also set some session status > variables, which can be easily mapped from the received SIP > request/response). >=20 > Hope I'm right and I don't have to drop the work of long months. >=20 > Regards. >=20 > --=20 > I=F1aki Baz Castillo > From matthew.kaufman@skype.net Fri Oct 21 10:37: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 525F41F0C91 for ; Fri, 21 Oct 2011 10:37:16 -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 jqRFGWnZS3ZC for ; Fri, 21 Oct 2011 10:37:15 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id 92F091F0C8C for ; Fri, 21 Oct 2011 10:37:15 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id E3C141707; Fri, 21 Oct 2011 19:37:14 +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=RaaMbs ZSln0U9mKICHke9M8mLpY=; b=ZhER5HT7sEfXhB8b7z3OO0CttHzObeXxxCIOTo N8eyJq4QdFiYrdD8Tx2RmUNNHIb4hcyFkbAHw8reSGDTmULVMdtrCWLJbD2yiqOv ha6ycLJxhyL+UaL3oGEdDCBPS2N/iAjcF401XutO9ILk5xm4rDy7kpwaCQbB4Or8 Q2H1w= 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=UKCBNK9GShPs dYqbil+vu2k+scxm1+AzIee1G+XcWGZWzDbx9hgP4CBTCtZJ8os2650Q+poENDK8 qHzxV2QrKLjBSgJ085bAe6fUpHrMQ1UEFGututTGqYtss+DqFHXqFVduiynfaaWz Slf5WsMH73XoahbYwhQ1NTCEaUs5ezw= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id E22047F8; Fri, 21 Oct 2011 19:37:14 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id ADD4C3506F68; Fri, 21 Oct 2011 19:37: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 hCJ5jf4Pr1Q6; Fri, 21 Oct 2011 19:37:14 +0200 (CEST) Received: from zimbra.skype.net (lu2-zimbra.skype.net [78.141.177.82]) by zimbra.skype.net (Postfix) with ESMTP id 0E7DA3506E8B; Fri, 21 Oct 2011 19:37:14 +0200 (CEST) References: Content-Transfer-Encoding: quoted-printable From: Matthew Kaufman Content-Type: text/plain; charset=us-ascii In-Reply-To: Message-Id: Date: Fri, 21 Oct 2011 19:37:13 +0200 (CEST) To: Cullen Jennings Mime-Version: 1.0 X-Mailer: Zimbra 6.0.9_GA_2686 (MobileSync - Apple-iPad2C2/812.1) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] ROAP Example Application X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 17:37:16 -0000 Thought experiment: If one had a connection object that supported an underlying protocol that c= ould send one or more encrypted flows of both real-time media and reliable = data, what information would you need to exchange between the two browser e= ndpoints in order to ensure that any pair of browsers with any future audio= or video codec could use the best mutually-supported codecs? (And note that if you had this, you could even send that information over t= he peer-to-peer data channel itself, once established.. Or you could send i= t up to a server... Your choice as programmer.) Now, what does it take to swap out the protocol underneath that connection = object with ICE, DTLS-SRTP and TCP-over-UDP (or equivalent) for the data? If we can successfully do this, we will have achieved a much cleaner softwa= re architecture within the browser, separated the connection setup from the= media setup, enabled the substitution of alternative transports, etc. Matthew Kaufman Sent from my iPad, on a plane From matthew.kaufman@skype.net Fri Oct 21 10:41: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 3AE5621F8AAA for ; Fri, 21 Oct 2011 10:41: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=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xLcLKL6sVluL for ; Fri, 21 Oct 2011 10:40:59 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id 7249821F8A7E for ; Fri, 21 Oct 2011 10:40:47 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id C42D61707; Fri, 21 Oct 2011 19:40:46 +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=yiSdhC 3XgMs4hGbNhEOm2oh9j+Y=; b=JHyOwzioEimS4LmCCu8YElnxltbjgUeLNyraLL uYXL/uUIjaIjl6sM7UrA+xHzAZKblcQwd9xOk5Jiv0EqArlHr2ZCySwqgk+/68wc zzaiCzRxHSkYouriA0BhUUoFdJD11i7lRzR3BPwT2KO350uERCvzVTAQL7pn2BIA QlOiM= 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=Q/1OsfiNJ+Wv GXChT6tmKSv6cC42xhMOrA3EJULukT3ZlQwYuDLvqrUYp4KlOt3nb6mnT2gt5GRK KS1f7QtSw2S/+2sP4CMnOGbZnxjNMRn7toVyaaRekLRJ3fGpqkMfTHBqAS1LhF6N Tll9hvu6HTEyveqZhs6/rQDGiS7wkAo= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id C2BD77F8; Fri, 21 Oct 2011 19:40:46 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id 881F41672682; Fri, 21 Oct 2011 19:40: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 gNWSOi0E4a3X; Fri, 21 Oct 2011 19:40:45 +0200 (CEST) Received: from zimbra.skype.net (lu2-zimbra.skype.net [78.141.177.82]) by zimbra.skype.net (Postfix) with ESMTP id B3D4F3507682; Fri, 21 Oct 2011 19:40:45 +0200 (CEST) References: Content-Transfer-Encoding: 7bit From: Matthew Kaufman Content-Type: multipart/alternative; boundary=Apple-Mail-23--538248085 In-Reply-To: Message-Id: Date: Fri, 21 Oct 2011 19:40:45 +0200 (CEST) To: Hadriel Kaplan Mime-Version: 1.0 X-Mailer: Zimbra 6.0.9_GA_2686 (MobileSync - Apple-iPad2C2/812.1) Cc: "" Subject: Re: [rtcweb] Does ROAP mandate the on-the-wire format? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 17:41:00 -0000 --Apple-Mail-23--538248085 Content-Transfer-Encoding: base64 Content-Type: text/plain; charset=utf-8 DQoNCk9uIE9jdCAyMSwgMjAxMSwgYXQgOTozOSBBTSwgSGFkcmllbCBLYXBsYW4gPEhLYXBsYW5A YWNtZXBhY2tldC5jb20+IHdyb3RlOg0KDQo+IA0KPiBPbiBPY3QgMjEsIDIwMTEsIGF0IDEyOjI1 IFBNLCBJw7Fha2kgQmF6IENhc3RpbGxvIHdyb3RlOg0KPiANCj4gDQo+IFdlbGwgc2luY2UgdGhl IEJyb3dzZXIgd2lsbCBuZXZlciBrbm93IHdoZXRoZXIgUk9BUCBpcyByZWFsbHkgdG8gYW5vdGhl ciBCcm93c2VyIHZzLiB0aGUgSmF2YXNjcmlwdCwgdGhlbiB5ZXMgaXQgY291bGQgYmUgdXNlZCB0 aGF0IHdheS4gKGl0IHdpbGwgcHJvYmFibHkgYmUgcGFpbmZ1bCwgYnV0IHBvc3NpYmxlKQ0KPiAN Cg0KSSBhZ3JlZSwgYW5kIGhhdmUgcG9pbnRlZCB0aGlzIG91dCBpbiBwcmV2aW91cyBkaXNjdXNz aW9ucy4NCg0KSSdkIGp1c3QgbGlrZSB0aGUgcGFpbmZ1bCBwYXJ0IHRvIGJlIGFzIGxpdHRsZSBw YWluIGFzIHdlIGNhbiBwb3NzaWJseSBhY2hpZXZlLCBiZWNhdXNlIHRoaXMgaXMgZXhhY3RseSBo b3cgSSBpbnRlbmQgdG8gdXNlIGl0Lg0KDQoNCg0KTWF0dGhldyBLYXVmbWFuDQoNClNlbnQgZnJv bSBteSBpUGFkLCBvbiBhIHBsYW5l --Apple-Mail-23--538248085 Content-Transfer-Encoding: base64 Content-Type: text/html; charset=utf-8 PGh0bWw+PGJvZHkgYmdjb2xvcj0iI0ZGRkZGRiI+PGRpdj48YnI+PC9kaXY+PGRpdj48YnI+T24g T2N0IDIxLCAyMDExLCBhdCA5OjM5IEFNLCBIYWRyaWVsIEthcGxhbiAmbHQ7PGEgaHJlZj0ibWFp bHRvOkhLYXBsYW5AYWNtZXBhY2tldC5jb20iPkhLYXBsYW5AYWNtZXBhY2tldC5jb208L2E+Jmd0 OyB3cm90ZTo8YnI+PGJyPjwvZGl2PjxkaXY+PC9kaXY+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+ PGRpdj48c3Bhbj48L3NwYW4+PGJyPjxzcGFuPk9uIE9jdCAyMSwgMjAxMSwgYXQgMTI6MjUgUE0s IEnDsWFraSBCYXogQ2FzdGlsbG8gd3JvdGU6PC9zcGFuPjxicj48Zm9udCBjbGFzcz0iQXBwbGUt c3R5bGUtc3BhbiIgY29sb3I9IiMwMDUwMDEiPjxmb250IGNsYXNzPSJBcHBsZS1zdHlsZS1zcGFu IiBjb2xvcj0iIzAwMjNBMyI+PGJyPjwvZm9udD48L2ZvbnQ+PHNwYW4+PC9zcGFuPjxicj48c3Bh bj5XZWxsIHNpbmNlIHRoZSBCcm93c2VyIHdpbGwgbmV2ZXIga25vdyB3aGV0aGVyIFJPQVAgaXMg cmVhbGx5IHRvIGFub3RoZXIgQnJvd3NlciB2cy4gdGhlIEphdmFzY3JpcHQsIHRoZW4geWVzIGl0 IGNvdWxkIGJlIHVzZWQgdGhhdCB3YXkuIChpdCB3aWxsIHByb2JhYmx5IGJlIHBhaW5mdWwsIGJ1 dCBwb3NzaWJsZSk8L3NwYW4+PGJyPjxzcGFuPjwvc3Bhbj48YnI+PC9kaXY+PC9ibG9ja3F1b3Rl PjxkaXY+PGJyPjwvZGl2PkkgYWdyZWUsIGFuZCBoYXZlIHBvaW50ZWQgdGhpcyBvdXQgaW4gcHJl dmlvdXMgZGlzY3Vzc2lvbnMuPGRpdj48YnI+PC9kaXY+PGRpdj5JJ2QganVzdCBsaWtlIHRoZSBw YWluZnVsIHBhcnQgdG8gYmUgYXMgbGl0dGxlIHBhaW4gYXMgd2UgY2FuIHBvc3NpYmx5IGFjaGll dmUsIGJlY2F1c2UgdGhpcyBpcyBleGFjdGx5IGhvdyBJIGludGVuZCB0byB1c2UgaXQuPGJyPjxi cj48c3BhbiBjbGFzcz0iQXBwbGUtc3R5bGUtc3BhbiIgc3R5bGU9Ii13ZWJraXQtdGFwLWhpZ2hs aWdodC1jb2xvcjogcmdiYSgyNiwgMjYsIDI2LCAwLjI5Njg3NSk7IC13ZWJraXQtY29tcG9zaXRp b24tZmlsbC1jb2xvcjogcmdiYSgxNzUsIDE5MiwgMjI3LCAwLjIzMDQ2OSk7IC13ZWJraXQtY29t cG9zaXRpb24tZnJhbWUtY29sb3I6IHJnYmEoNzcsIDEyOCwgMTgwLCAwLjIzMDQ2OSk7ICI+PGJy Pjxicj5NYXR0aGV3IEthdWZtYW48ZGl2Pjxicj48L2Rpdj48ZGl2PlNlbnQgZnJvbSBteSBpUGFk LCBvbiBhIHBsYW5lPC9kaXY+PC9zcGFuPjwvZGl2PjwvYm9keT48L2h0bWw+ --Apple-Mail-23--538248085-- From HKaplan@acmepacket.com Fri Oct 21 10:45: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 F38E621F8ABB for ; Fri, 21 Oct 2011 10:45:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.423 X-Spam-Level: X-Spam-Status: No, score=-2.423 tagged_above=-999 required=5 tests=[AWL=0.176, 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 rC9WDxFeIVZI for ; Fri, 21 Oct 2011 10:45:01 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 5F5BB21F8A97 for ; Fri, 21 Oct 2011 10:45: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; Fri, 21 Oct 2011 13:44:59 -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, 21 Oct 2011 13:45:00 -0400 From: Hadriel Kaplan To: Ted Hardie Thread-Topic: [rtcweb] Unedited notes from today's call Thread-Index: AQHMkBknlgwAq/jOfE2PWWOL93nqiQ== Date: Fri, 21 Oct 2011 17:44:58 +0000 Message-ID: <5E960741-093D-4093-96AD-3765278712C7@acmepacket.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [216.41.24.34] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <7E715B427F4FC040848C7B5B72905E73@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [rtcweb] Unedited notes from today's 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: Fri, 21 Oct 2011 17:45:02 -0000 Thanks for writing the minutes up! Maybe someday my Browser will have a speech-to-text engine, so I could join= it to the conf call and have it do the work for you. :) With regards to my ending comments, what I basically said was: if Browser v= endors won't do low-level then it's a fait accompli, because we need them o= bviously. (I don't mean that in a negative way - I mean it in a practical w= ay) With regards to next-steps, I plan to: 1) Assuming my co-authors agree, up-rev the low-level draft adding some of = the reasons given on the call for not doing a low-layer, namely:=20 a) Exposing a low layer API is a much longer development cycle due to test= ing the permutations impacting code paths. b) Since the low-layers are more implementation specific, there's a very l= arge chance of cross-browser differences/incompatibility. Those had never been expressed on the mailing list, and I think both of tho= se arguments are very compelling and should be recorded for the Google sear= ch archive via a new draft. :) 2) Go through the low-level draft for requirements that weren't in the WG r= equirements doc but should be even for ROAP, and post those on the mailing = list (and the use-cases that make them requirements). 3) Buy Cullen a beer in Taipei. -hadriel On Oct 21, 2011, at 12:03 PM, Ted Hardie wrote: > Here are my completed unedited notes from today's call; I got cut off at = 9:00 sharp and have another meeting, so I'm not sure if anything was said a= fter. >=20 > Ted > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From matthew.kaufman@skype.net Fri Oct 21 10:47: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 0CBAA1F0C91 for ; Fri, 21 Oct 2011 10:47:16 -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 0AowdWBSMU2Q for ; Fri, 21 Oct 2011 10:47:15 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id 7B8BC1F0C8C for ; Fri, 21 Oct 2011 10:47:15 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id CC1DE1707; Fri, 21 Oct 2011 19:47:14 +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=dCTkk2 odWSA5Ph6Ro7fa0+BmUT8=; b=iXqOuY1poClG10VdwRPTGU7tG9MYx8hhKGFcnJ czcs2n1Clu/beaRbhezdNNOSwPnSurg3r3V2AUu/Ru4sApJ5/+OxJeD5G8BTc2kP yejcohTsP14T4l3RCznky3S627Cjy65Mbp5pRxlMNaS1KWUobFfjCHrlEueQSTnC wxhKg= 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=vBbF6pTbyIwa ZHHsog9R3JMma7WQiyc4eceRjVPvwtv0kajBCTjop+Bvf8jY1iD1QmehuTAgovbo qGga3ye75ueQQqquIRfoY0fibyhBUixK8Nt1nAxud0gnP3bYl1gX/cWzzTR2USq/ cQAlgkcQBQYBFVW8EbjOMlqwcwpiCLw= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id C973E7F8; Fri, 21 Oct 2011 19:47:14 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id A35A31672682; Fri, 21 Oct 2011 19:47: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 TnPEB85v2WJs; Fri, 21 Oct 2011 19:47:13 +0200 (CEST) Received: from zimbra.skype.net (lu2-zimbra.skype.net [78.141.177.82]) by zimbra.skype.net (Postfix) with ESMTP id C810C1672681; Fri, 21 Oct 2011 19:47:13 +0200 (CEST) References: Content-Transfer-Encoding: base64 From: Matthew Kaufman Content-Type: text/plain; charset=utf-8 In-Reply-To: Message-Id: <5E920713-0B41-493D-9457-7FE48DB6A98D@skype.net> Date: Fri, 21 Oct 2011 19:47:13 +0200 (CEST) To: =?utf-8?Q?I=C3=B1aki_Baz_Castillo?= Mime-Version: 1.0 X-Mailer: Zimbra 6.0.9_GA_2686 (MobileSync - Apple-iPad2C2/812.1) Cc: "" Subject: Re: [rtcweb] Does ROAP mandate the on-the-wire format? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 17:47:16 -0000 DQoNCk9uIE9jdCAyMSwgMjAxMSwgYXQgOTo0MyBBTSwgScOxYWtpIEJheiBDYXN0aWxsbyA8aWJj QGFsaWF4Lm5ldD4gd3JvdGU6DQoNCj4gDQo+IA0KPiBJZiBST0FQIGluY2x1ZGVzIGEgcmVhbCBT RFAgKGFzIHRoZSBkcmFmdCBjdXJyZW50bHkgc3RhdGVzKSB0aGVuIEknbQ0KPiBkb25lIGFzIEkg anVzdCBuZWVkIHRvIGNyZWF0ZSBhIFJPQVAgb2JqZWN0IChpbiBKYXZhU2NyaXB0KSBhbmQgcGFz cw0KPiBpdCB0aGUgcmVjZWl2ZWQgU0RQIHN0cmluZyAoYW5kIGFsc28gc2V0IHNvbWUgc2Vzc2lv biBzdGF0dXMNCj4gdmFyaWFibGVzLCB3aGljaCBjYW4gYmUgZWFzaWx5IG1hcHBlZCBmcm9tIHRo ZSByZWNlaXZlZCBTSVANCj4gcmVxdWVzdC9yZXNwb25zZSkuDQo+IA0KPiANCg0KSWYgeW91IGNh biBkbyB0aGlzIGFzIGVhc2lseSBhcyBpdCBzb3VuZHMgYWJvdmUsIGFuZCBpdCBzdXBwb3J0cyBi b3RoIGVhcmx5IG1lZGlhIGFuZCBmb3JraW5nLCB0aGVuIEkgdGhpbmsgd2UndmUgcHV0IGZhciB0 b28gbXVjaCBpbnRvIHRoZSBicm93c2VyIGxvZ2ljLiBTbyB0aGlzIGlzIGFjdHVhbGx5IGEgZ29v ZCB0ZXN0IG9mIHRoZSBkZXNpZ24uDQoNCkZvciBhIGJyb3dzZXIsIHRoZXJlIHNob3VsZCBiZSBu byBzdWNoIHRoaW5nIGFzIGVhcmx5IG1lZGlhLi4uIEp1c3QgbWVkaWEuDQoNCkFuZCBmb3IgYSBi cm93c2VyLCB0aGVyZSBzaG91bGQgYmUgbm8gc3VjaCB0aGluZyBhcyBmb3JraW5nLCBqdXN0IHR3 byAob3IgbW9yZSkgY29ubmVjdGlvbiBvYmplY3RzIHRoYXQgcmVwcmVzZW50IHRoZSB0d28gKG9y IG1vcmUpIHBvc3NpYmxlIGNhbGwgbGVncy4NCg0KQW5kIGl0IHNob3VsZCBiZSBwb3NzaWJsZSwg d2l0aCB0aGUgcmlnaHQgSmF2YVNjcmlwdCBhbmQgdGhlIHJpZ2h0IEFQSXMgdG8gYWNoaWV2ZSBl eGFjdGx5IHdoYXQgeW91IGRlc2NyaWJlIGFib3ZlLiBCdXQgcGVyaGFwcyBub3QgYXMgZWFzaWx5 IGFzIHlvdSBkZXNjcmliZS4NCg0KTWF0dGhldyBLYXVmbWFuDQoNClNlbnQgZnJvbSBteSBpUGFk LCBvbiBhIHBsYW5l From ibc@aliax.net Fri Oct 21 11: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 5C6551F0C91 for ; Fri, 21 Oct 2011 11:04:56 -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.044, 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 cMiwAjjLOSfB for ; Fri, 21 Oct 2011 11:04:55 -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 B23301F0C8C for ; Fri, 21 Oct 2011 11:04:55 -0700 (PDT) Received: by vws5 with SMTP id 5so3806144vws.31 for ; Fri, 21 Oct 2011 11:04:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.25.75 with SMTP id a11mr15269628vdg.1.1319220294919; Fri, 21 Oct 2011 11:04:54 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Fri, 21 Oct 2011 11:04:54 -0700 (PDT) In-Reply-To: References: Date: Fri, 21 Oct 2011 20:04:54 +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] Does ROAP mandate the on-the-wire format? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 18:04:56 -0000 2011/10/21 Hadriel Kaplan : > You know, doing that would be awesome because then you could test it agai= nst real SIP devices, or even at Sipit, to verify we've got the legacy-SIP-= compatibility-model right for more esoteric cases. Oh, I already test it against real SIP devices. Even better, I can test SIP devices against my (our) much better SIP implementation :) http://www.youtube.com/watch?v=3DqfFlK1KyF6Q --=20 I=C3=B1aki Baz Castillo From HKaplan@acmepacket.com Fri Oct 21 11:05: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 10F4721F8783 for ; Fri, 21 Oct 2011 11:05:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.127 X-Spam-Level: X-Spam-Status: No, score=-2.127 tagged_above=-999 required=5 tests=[AWL=-0.128, BAYES_00=-2.599, J_CHICKENPOX_27=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 xO+3DQMei8j0 for ; Fri, 21 Oct 2011 11:05:52 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 79DBA21F85C7 for ; Fri, 21 Oct 2011 11:05: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; Fri, 21 Oct 2011 14:05:50 -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, 21 Oct 2011 14:05:51 -0400 From: Hadriel Kaplan To: Matthew Kaufman Thread-Topic: [rtcweb] Does ROAP mandate the on-the-wire format? Thread-Index: AQHMkBwQmEXXTEsSfEaLWlSDmayJ4w== Date: Fri, 21 Oct 2011 18:05:49 +0000 Message-ID: References: <5E920713-0B41-493D-9457-7FE48DB6A98D@skype.net> In-Reply-To: <5E920713-0B41-493D-9457-7FE48DB6A98D@skype.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="iso-8859-1" Content-ID: <2674A7316C3DD24C82EC774542A8D204@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [rtcweb] Does ROAP mandate the on-the-wire format? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 18:05:53 -0000 On Oct 21, 2011, at 1:47 PM, Matthew Kaufman wrote: > For a browser, there should be no such thing as early media... Just media= . Not disagreeing with your high-level point... but I don't think early media= is possible in RTCweb no matter how we dice it, if by "early media" you me= an your JS+browser being able to render media before getting some high-path= info back from the Server. Because you can't do ICE until you know the ot= her side's ICE user/pass, so media won't flow till then. Right? -hadriel From ibc@aliax.net Fri Oct 21 11:12: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 4B69A11E8095 for ; Fri, 21 Oct 2011 11:12:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.634 X-Spam-Level: X-Spam-Status: No, score=-2.634 tagged_above=-999 required=5 tests=[AWL=0.043, 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 9s-XufVlsJtZ for ; Fri, 21 Oct 2011 11:12:09 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id B82C511E8082 for ; Fri, 21 Oct 2011 11:12:09 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so4300461vcb.31 for ; Fri, 21 Oct 2011 11:12:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.117.81 with SMTP id p17mr1109243vcq.41.1319220729248; Fri, 21 Oct 2011 11:12:09 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Fri, 21 Oct 2011 11:12:09 -0700 (PDT) In-Reply-To: <5E920713-0B41-493D-9457-7FE48DB6A98D@skype.net> References: <5E920713-0B41-493D-9457-7FE48DB6A98D@skype.net> Date: Fri, 21 Oct 2011 20:12:09 +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: "" Subject: Re: [rtcweb] Does ROAP mandate the on-the-wire format? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 18:12:10 -0000 2011/10/21 Matthew Kaufman : > If you can do this as easily as it sounds above, and it supports both ear= ly media and forking, then I think we've put far too much into the browser = logic. So this is actually a good test of the design. > > For a browser, there should be no such thing as early media... Just media= . As Hadriel has pointed out, in SIP early media is just a *normal* media session but without a confirmed INVITE transaction (not a final response yet, but just 180/183 with SDP). So there is no problem in implementing early media in the browser. > And for a browser, there should be no such thing as forking, Why not? my current implementation can receive different SIP 180/183 with different To-tags, which means "forking". Regards. --=20 I=C3=B1aki Baz Castillo From randell-ietf@jesup.org Fri Oct 21 11:33: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 9A4F721F8AFE for ; Fri, 21 Oct 2011 11:33:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.537 X-Spam-Level: X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[AWL=0.062, 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 KpQ0dD-6RfxF for ; Fri, 21 Oct 2011 11:33:38 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 26AD421F8AFC for ; Fri, 21 Oct 2011 11:33:37 -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 1RHJuT-0000w0-3C for rtcweb@ietf.org; Fri, 21 Oct 2011 13:33:37 -0500 Message-ID: <4EA1B9E5.8030507@jesup.org> Date: Fri, 21 Oct 2011 14:28:53 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <9C8CA816-65FB-41A0-999C-4C43128CAAB4@danyork.org> <2E239D6FCD033C4BAF15F386A979BF51159B91@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] A plea for simplicity, marketability - and... who are we designing RTCWEB for? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 18:33:38 -0000 On 10/21/2011 8:25 AM, Wolfgang Beck wrote: > At the layer of call signaling messages are ultimately exchanged > between two JS clients running on browsers. If we have different JS > clients here, we need a standardized protocol between them. With > trapezoid interconnection, we can hide this to some extent by doing > protocol translations between JS client A / RTCWEB Server A and Server > B / JS client B. Some > information will get lost in translation. > > But as browsers can load JS on the fly, user A could simply point her > browser to Server B and use the same client as user B. Now all > components at the signaling layer are provided by a single vendor and > no standardized protocol is required. There is no loss of information > as there are no protocol translators. This is the rough equivalent to saying "instead of exchanging email in a standard format, and letting people use whatever client/webmail-client they want to read it; if you want to read an email from a gmail user you should log into gmail using their interface; from an aol user log into AOL and their interface, etc. Oh, and history, phonebooks, etc would all be separate." Yes, it avoids standard 'federation' formats and conversions, but... -- Randell Jesup randell-ietf@jesup.org From ted.ietf@gmail.com Fri Oct 21 12: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 78C5D21F8B10 for ; Fri, 21 Oct 2011 12:02:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.26 X-Spam-Level: X-Spam-Status: No, score=-3.26 tagged_above=-999 required=5 tests=[AWL=0.338, 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 sbX3eYv7gmqd for ; Fri, 21 Oct 2011 12:02:00 -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 DD4E321F8B0C for ; Fri, 21 Oct 2011 12:01:59 -0700 (PDT) Received: by yxj19 with SMTP id 19so4989536yxj.31 for ; Fri, 21 Oct 2011 12:01:59 -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=+PI5+F8J8Dco6gqvc7YlYY8MY3LD/FItpmeVqJCtI8E=; b=IbTfaFbsgU3c5Az+K3XPR1bnipj/s0emE8zz6K1lVKVdcJh+G7127Ky4v96poPZEAd oVPbCMY6Z1AkG9yBWMxEBN8e1PGiMMXtdOrXUbdk5BOYB7QhHLW+3Xeqs3ZC9lzLO32z QpGyg8OSnAFcdpRoM2jGeHzw2cz8UHEk56uVg= MIME-Version: 1.0 Received: by 10.236.168.2 with SMTP id j2mr23406533yhl.24.1319223719301; Fri, 21 Oct 2011 12:01:59 -0700 (PDT) Received: by 10.236.105.169 with HTTP; Fri, 21 Oct 2011 12:01:58 -0700 (PDT) In-Reply-To: References: Date: Fri, 21 Oct 2011 12:01:58 -0700 Message-ID: From: Ted Hardie To: Matthew Kaufman Content-Type: multipart/alternative; boundary=20cf305b121e2b120304afd3b5e1 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] ROAP Example Application X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 19:02:00 -0000 --20cf305b121e2b120304afd3b5e1 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Oct 21, 2011 at 10:37 AM, Matthew Kaufman wrote: > Thought experiment: > > If one had a connection object that supported an underlying protocol that > could send one or more encrypted flows of both real-time media and reliable > data, what information would you need to exchange between the two browser > endpoints in order to ensure that any pair of browsers with any future audio > or video codec could use the best mutually-supported codecs? > > I think I am missing your point slightly. Do you mean the connection object talks to an abstraction layer that manages how the flows are sent, and the swapping occurs in what it manages, or do you mean the connection object should be able to swap out whether it is talking to ICE, DTLS-SRTP, or TCP-over-UDP transparently? or something else? regards, Ted --20cf305b121e2b120304afd3b5e1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Oct 21, 2011 at 10:37 AM, Matthew Kaufman <matthew.kaufman@skype.net>= wrote:
Oh, and history, phonebooks, etc would all be separate. RTCweb is not a generic and personal phone in the browser, so there is no "phonebook" concept here. Don't you realize that you are clearly thinking as a telco now? :) More stuf: - When you press the "I like" button of Facebook in an external page, such link points to Facebook servers. - When you want to write something in Twitter (regardless you use the Twitter website or any Twitter desktop/mobile client) you are connecting to Twitter servers. - When a website includes an embedded Youtube video, such video is loaded from Youtube servers, not from the website in which it's embedded. This is the History of WWW and the reason of its success: - NO standards (others than HTTP, HTML and JavaScript). - Do whatever you want without reading IETF specs. - Innovate without deep knowledge. Said that, mandating the format in the wire is the key of no-success. Even more: mandating anything apart from the RTCweb JS API and the RTP/ICE design is the key of no-success. I'm pretty sure of that. Cheers. --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Fri Oct 21 12:17: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 1FE751F0C40 for ; Fri, 21 Oct 2011 12:17:52 -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 klkgni7Lkmjz for ; Fri, 21 Oct 2011 12:17:51 -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 65F171F0C3E for ; Fri, 21 Oct 2011 12:17:46 -0700 (PDT) Received: by vws5 with SMTP id 5so3871982vws.31 for ; Fri, 21 Oct 2011 12:17:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.184.103 with SMTP id et7mr15541935vdc.35.1319224665719; Fri, 21 Oct 2011 12:17:45 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Fri, 21 Oct 2011 12:17:45 -0700 (PDT) In-Reply-To: References: <9C8CA816-65FB-41A0-999C-4C43128CAAB4@danyork.org> <2E239D6FCD033C4BAF15F386A979BF51159B91@sonusinmail02.sonusnet.com> <4EA1B9E5.8030507@jesup.org> Date: Fri, 21 Oct 2011 21:17:45 +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] A plea for simplicity, marketability - and... who are we designing RTCWEB for? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 19:17:52 -0000 2011/10/21 I=C3=B1aki Baz Castillo : > At this point, I think we should have some folks from WWW world in > this WG (not too many, or we would end sending RTP on top of HTTP and having to map the ~400 SIP response codes into "Answered", "No Answered" and "I like"). --=20 I=C3=B1aki Baz Castillo From jovass@adobe.com Fri Oct 21 13:29: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 5D53F1F0C4B for ; Fri, 21 Oct 2011 13:29:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.298 X-Spam-Level: X-Spam-Status: No, score=-106.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 euoes8pu4pBY for ; Fri, 21 Oct 2011 13:28:59 -0700 (PDT) Received: from exprod6og102.obsmtp.com (exprod6og102.obsmtp.com [64.18.1.183]) by ietfa.amsl.com (Postfix) with ESMTP id 9EBF11F0C35 for ; Fri, 21 Oct 2011 13:28:57 -0700 (PDT) Received: from outbound-smtp-1.corp.adobe.com ([192.150.11.134]) by exprod6ob102.postini.com ([64.18.5.12]) with SMTP; Fri, 21 Oct 2011 13:28:57 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 p9LKRIYE005594; Fri, 21 Oct 2011 13:27:18 -0700 (PDT) Received: from nacas02.corp.adobe.com (nacas02.corp.adobe.com [10.8.189.100]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id p9LKSr5R024814; Fri, 21 Oct 2011 13:28:53 -0700 (PDT) Received: from nambx03.corp.adobe.com ([10.8.189.93]) by nacas02.corp.adobe.com ([10.8.189.100]) with mapi; Fri, 21 Oct 2011 13:28:53 -0700 From: Jozsef Vass To: Roman Shpount , =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= Date: Fri, 21 Oct 2011 13:28:47 -0700 Thread-Topic: [rtcweb] Same location media Thread-Index: AcyPRS9+XFqEQCpJQ6OzyQUdEjlLIQA6c05Q Message-ID: <0FEA137C08A9DF4781EEF745038C969430A558E884@nambx03.corp.adobe.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: multipart/alternative; boundary="_000_0FEA137C08A9DF4781EEF745038C969430A558E884nambx03corpad_" MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Same location media X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 20:29:00 -0000 --_000_0FEA137C08A9DF4781EEF745038C969430A558E884nambx03corpad_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable As for Flash, I think your are referring to the same origin policy and not = media, which is true for all browsers. That means, that http://www.a.com/a.= swf cannot load http://www.b.com/data.txt without an explicit permission by= a cross-domain policy file. Jozsef From: Roman Shpount [mailto:roman@telurix.com] Sent: Thursday, October 20, 2011 9:27 AM To: I=F1aki Baz Castillo Cc: rtcweb@ietf.org Subject: [rtcweb] Same location media Changing the topic from "A plea for simplicity, marketability..." On Thu, Oct 20, 2011 at 11:57 AM, I=F1aki Baz Castillo > wrote: Also you are asuming that the media is sent to the same IP of the web server (in case a RTCweb scenario does not include user2user calls). This is a too much simplified scenario, and you miss that a DNS A record can point to N IP's, and you also miss the case in which the webserver has an IP different than the media server (regardless they both are located within the same provider infrastucture). The browser cannot determine it by itself, so security is always a need, and IMHO it's a bad idea to allow a very corner case in which such security could be relaxed. I am not missing the DNS issues. I wanted to bring this up in my previous e= mail, but did not want to confuse the issue. I don't advocate for this case= at all, I just wanted to clarify that "same origin media" does not necessa= rily mean two phones in the same location and means media going to the same= location as JavaScript origination. Few additional points related to this: 1. This is what Flash is doing now for streaming media. It does not need co= nsent to send media to the same server that sent the flash app. 2. I am not sure we standardized that only IP addresses are allowed in medi= a description.DNS names might still be allowed then this issue will become = the issue of doing a literal match. 3. There is still a security issue with ICE: we validate that STUN request = can be processed, but not that the media actually should be accepted from t= his application. In some sense, current Flash cross domain polices are stri= cter, since they not only validate that media is acceptable at this IP but = that it is acceptable from the app served from particular server. In general, I think this is a good thing if I can get readily available har= dware components and connect RTC clients to my existing infrastructure (I d= o have an JavaScript/HTTP to SIP proxy solution already). If we are not bre= aking anything by doing this, there might be some benefit for allowing this= . But on the other hand, I already got ICE/SRTP to non-ICE/RTP media proxy = as well, so if this is not supported I will not suffer much :). _____________ Roman Shpount --_000_0FEA137C08A9DF4781EEF745038C969430A558E884nambx03corpad_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

As for Fl= ash, I think your are referring to the same origin policy and not media, wh= ich is true for all browsers. That means, that http://www.a.com/a.swf cannot load http://www.b.com/data.txt without an explicit permission by a = cross-domain policy file.

=  

Jozsef

 

From: Roman Shpount [mailto:roman@telurix.com]
Sent: = Thursday, October 20, 2011 9:27 AM
To: I=F1aki Baz Castillo
Cc: rtcweb@ietf.org
Subject: [rtcweb] Same location media

 

Changing the topic from "A plea for simplicity, marketabi= lity..."

On Thu, Oct 20, 2011 at 11:57 AM, I=F1aki Baz Castillo= <ibc@aliax.net> wrote:

Also you are asum= ing that the media is sent to the same IP of the web
server (in case a R= TCweb scenario does not include user2user calls).
This is a too much sim= plified scenario, and you miss that a DNS A
record can point to N IP's, = and you also miss the case in which the
webserver has an IP different th= an the media server (regardless they
both are located within the same pr= ovider infrastucture). The browser
cannot determine it by itself, so sec= urity is always a need, and IMHO
it's a bad idea to allow a very corner = case in which such security
could be relaxed.


I am not missing the DNS = issues. I wanted to bring this up in my previous email, but did not want to= confuse the issue. I don't advocate for this case at all, I just wanted to= clarify that "same origin media" does not necessarily mean two p= hones in the same location and means media going to the same location as Ja= vaScript origination.

Few additional points related to this:

= 1. This is what Flash is doing now for streaming media. It does not need co= nsent to send media to the same server that sent the flash app.

2. I= am not sure we standardized that only IP addresses are allowed in media de= scription.DNS names might still be allowed then this issue will become the = issue of doing a literal match.

3. There is still a security issue w= ith ICE: we validate that STUN request can be processed, but not that the m= edia actually should be accepted from this application. In some sense, curr= ent Flash cross domain polices are stricter, since they not only validate t= hat media is acceptable at this IP but that it is acceptable from the app s= erved from particular server.

In general, I think this is a good thi= ng if I can get readily available hardware components and connect RTC clien= ts to my existing infrastructure (I do have an JavaScript/HTTP to SIP proxy= solution already). If we are not breaking anything by doing this, there mi= ght be some benefit for allowing this. But on the other hand, I already got= ICE/SRTP to non-ICE/RTP media proxy as well, so if this is not supported I= will not suffer much :).
 
_____________
Roman Shpount<= /o:p>

= --_000_0FEA137C08A9DF4781EEF745038C969430A558E884nambx03corpad_-- From rocallahan@gmail.com Fri Oct 21 13:53: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 3B54911E8083 for ; Fri, 21 Oct 2011 13:53:34 -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 hw-gAUcw7x5Z for ; Fri, 21 Oct 2011 13:53:33 -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 9498611E8082 for ; Fri, 21 Oct 2011 13:53:33 -0700 (PDT) Received: by iabn5 with SMTP id n5so5696650iab.31 for ; Fri, 21 Oct 2011 13:53:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:reply-to:sender:date:x-google-sender-auth:message-id :subject:from:to:content-type; bh=vos/dJG5+1OCTPpvpL1HP7fqs0PydL3PB9+C4GJUlgc=; b=D3YQiiLb+V9yaFoL6udY8ahcPKNBrUr4CXnmvzydGti2ObIqc0J1Wz8LT7VmcKAzzj Omg0Np6rVtx0yE15gKd4Hu897rMEiucmXfDD/q+v1NlldIHXiQgeKBlm1q681GCHjJmt 636hEZLOsExrxzDlf4eoK6+vwztZIU7C3Dv1M= MIME-Version: 1.0 Received: by 10.231.84.8 with SMTP id h8mr6462246ibl.47.1319230412393; Fri, 21 Oct 2011 13:53:32 -0700 (PDT) Sender: rocallahan@gmail.com Received: by 10.231.211.74 with HTTP; Fri, 21 Oct 2011 13:53:32 -0700 (PDT) Date: Sat, 22 Oct 2011 09:53:32 +1300 X-Google-Sender-Auth: erBuxZf8blMOEqyF5-6CSU7UBU0 Message-ID: From: "Robert O'Callahan" To: rtcweb@ietf.org Content-Type: multipart/alternative; boundary=00151774156e1b8e2804afd5441a Subject: [rtcweb] a couple of comments on the latest API draft X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@ocallahan.org List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 20:53:34 -0000 --00151774156e1b8e2804afd5441a Content-Type: text/plain; charset=UTF-8 http://dev.w3.org/2011/webrtc/editor/webrtc-20111017.html I'm not sure that "blackness" is the appropriate output for a finished MediaStream. HTML media elements that aren't playing anything are transparent. For consistency, it's probably better for MediaStreams that aren't playing anything to also be transparent. When a MediaStreamobject ends for any reason (e.g. because the user rescinds the permission > for the page to use the local camera, or because the data comes from a > finite file and the file's end has been reached and the user has not > requested that it be looped, or because the stream comes from a remote peer > and the remote peer has permanently stopped sending data, it is said to be finished > . > What if the user reinstates permission for the page to use a camera, or the author modifies the source to add looping or otherwise replenish the data (e.g. by restarting the source via some API)? In general, especially as we add more sources, it's going to be hard to ensure that the ended/finished state (I think probably you should remove all mentions of "finished" in favour of "ended") is truly permanent. Certainly if we allow arbitrary media elements to be used as sources (as I think we will want to), the author can cause the media element to play again after it's finished. I'm not sure what to do about this, but if we could allow MediaStreams to exit the "ended" state, that would be good. Rob -- "If we claim to be without sin, we deceive ourselves and the truth is not in us. If we confess our sins, he is faithful and just and will forgive us our sins and purify us from all unrighteousness. If we claim we have not sinned, we make him out to be a liar and his word is not in us." [1 John 1:8-10] --00151774156e1b8e2804afd5441a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable http:= //dev.w3.org/2011/webrtc/editor/webrtc-20111017.html
<= br>I'm not sure that "blackness" is the appropriate output fo= r a finished MediaStream. HTML media elements that aren't playing anyth= ing are transparent. For consistency, it's probably better for MediaStr= eams that aren't playing anything to also be transparent.

When a = MediaStream object ends for any reason (e.g. because the user rescinds the permission for the page to use= the local camera, or because the data comes from a finite file and the file's e= nd has been reached and the user has not requested that it be looped, or because the = stream comes from a remote peer and the remote peer has permanently stopped sending da= ta, it is said to be finished .

What if the user reinstates permission f= or the page to use a camera, or the author modifies the source to add loopi= ng or otherwise replenish the data (e.g. by restarting the source via some = API)? In general, especially as we add more sources, it's going to be h= ard to ensure that the ended/finished state (I think probably you should re= move all mentions of "finished" in favour of "ended") i= s truly permanent. Certainly if we allow arbitrary media elements to be use= d as sources (as I think we will want to), the author can cause the media e= lement to play again after it's finished.

I'm not sure what to do about this, but if we could allow MediaStre= ams to exit the "ended" state, that would be good.

R= ob
--
"If we claim to be without sin, we deceive ourselves and = the truth is not in us. If we confess our sins, he is faithful and just and= will forgive us our sins and purify us from all unrighteousness. If we cla= im we have not sinned, we make him out to be a liar and his word is not in = us." [1 John 1:8-10]
--00151774156e1b8e2804afd5441a-- From randell-ietf@jesup.org Fri Oct 21 15:10: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 92EF011E8081 for ; Fri, 21 Oct 2011 15:10:25 -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 mdAekpkBs9U0 for ; Fri, 21 Oct 2011 15:10:25 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 0236021F8AD2 for ; Fri, 21 Oct 2011 15:10: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 1RHNI7-0005H6-4k for rtcweb@ietf.org; Fri, 21 Oct 2011 17:10:15 -0500 Message-ID: <4EA1ECA9.7030509@jesup.org> Date: Fri, 21 Oct 2011 18:05:29 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <5E920713-0B41-493D-9457-7FE48DB6A98D@skype.net> 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] Does ROAP mandate the on-the-wire format? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 22:10:25 -0000 On 10/21/2011 2:12 PM, Iñaki Baz Castillo wrote: > 2011/10/21 Matthew Kaufman: >> If you can do this as easily as it sounds above, and it supports both early media and forking, then I think we've put far too much into the browser logic. So this is actually a good test of the design. >> >> For a browser, there should be no such thing as early media... Just media. > > As Hadriel has pointed out, in SIP early media is just a *normal* > media session but without a confirmed INVITE transaction (not a final > response yet, but just 180/183 with SDP). So there is no problem in > implementing early media in the browser. In ROAP, this would be a TENTATIVE ANSWER, which can set up ICE and media channels for one-way media (if desired). >> And for a browser, there should be no such thing as forking, > > Why not? my current implementation can receive different SIP 180/183 > with different To-tags, which means "forking". I believe it's very important to be able to receive multiple answers to an offer, which allows for all sorts of interesting uses by the app writer. For example, the case I gave yesterday, where each participant in a game OFFERed to the game server at the start, and if during the game it wanted them connected to another player, it would forward (fork) the OFFER to the other player as an ANSWER to *their* OFFER, and vice versa. This 'tricky' server-side manipulation might require the server to manually perform O/A resolution to transform the OFFERs into ANSWERs; though that shouldn't be that hard for this case. This also means it can leverage the existing authority granted for access to camera and mic. Also, this "transformation" isn't needed if the existing authority can be leveraged in some other manner This is roughly equivalent to the use-case of a "mesh" conference, where the server isn't serving as a media hub/mixer, and in that case we wouldn't want a new user joining to force everyone to individually authorize talking to them. So if we can solve that problem security-wise, then the game scenario above just becomes "fork the original offer to the other player, and route the answer back" - very easy. -- Randell Jesup randell-ietf@jesup.org From matthew.kaufman@skype.net Fri Oct 21 16:29: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 ACFFC21F8B28 for ; Fri, 21 Oct 2011 16:29:39 -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 RIObdiHCJ902 for ; Fri, 21 Oct 2011 16:29:39 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id E9B9321F8B26 for ; Fri, 21 Oct 2011 16:29:38 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id 93E8C1707; Sat, 22 Oct 2011 01:29: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=L4t2VYefiibWKQ 3DQkBJst5n6T0=; b=kSUdqAVjbbnWJkN3SVbaXSXbZ5DyZRfp22i6JRXGcNFWi9 Er/48zPYi7HE4QVldP128fA7wY7c6iN6yCaZmzFLiNCdqpbVs1DoQaXDHGiNRA3J u+t8jzt3WBii15eX7lgJ1KXZoU6qjevIu4aYmr3PPFDSM6p9EHNvbCeqDbVoo= 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=E06BJupIfyZZQMPHeWeYil zzh46wI27n1dn8lguLnLWBqWwG0wCQsy7CEjGvRCT9zFIYi7AZee3hlIRC9rEms6 qAhtGEmBZA/rQ6neQkXojxzP6Vb8CaNFJ2g1rNYUcMxXxEEao89rW87uR622LWUq DZ3mUXN8d42j68rSVdOw4= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id 919E07F6; Sat, 22 Oct 2011 01:29:36 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id 667AA3506E81; Sat, 22 Oct 2011 01:29: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 FzGXuv6lNLZo; Sat, 22 Oct 2011 01:29:35 +0200 (CEST) Received: from [10.10.155.2] (unknown [198.202.199.254]) by zimbra.skype.net (Postfix) with ESMTPSA id 4483A3506E63; Sat, 22 Oct 2011 01:29:35 +0200 (CEST) Message-ID: <4EA1FFFE.5050302@skype.net> Date: Fri, 21 Oct 2011 16:27:58 -0700 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Randell Jesup References: <9C8CA816-65FB-41A0-999C-4C43128CAAB4@danyork.org> <2E239D6FCD033C4BAF15F386A979BF51159B91@sonusinmail02.sonusnet.com> <4EA1B9E5.8030507@jesup.org> In-Reply-To: <4EA1B9E5.8030507@jesup.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] A plea for simplicity, marketability - and... who are we designing RTCWEB for? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 23:29:39 -0000 On 10/21/2011 11:28 AM, Randell Jesup wrote: > > This is the rough equivalent to saying "instead of exchanging email in > a standard format, and letting people use whatever > client/webmail-client they want to read it; if you want to read an > email from a gmail user you should log into gmail using their > interface; from an aol user log into AOL and their interface, etc. > Oh, and history, phonebooks, etc would all be separate." Yes, it > avoids standard 'federation' formats and conversions, but... > > Of course this is exactly what the various walled-garden websites of the world (see Facebook for a prime example) want to happen. That email was already widely federated isn't a feature for them at all. Matthew Kaufman From matthew.kaufman@skype.net Fri Oct 21 16: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 ADF7F11E8085 for ; Fri, 21 Oct 2011 16:33:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OT64GTzbIiRT for ; Fri, 21 Oct 2011 16:33:55 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id 9C3E111E8082 for ; Fri, 21 Oct 2011 16:33:55 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id C50651707; Sat, 22 Oct 2011 01:33:54 +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=IDwDGVwtiFH4tQ+ycvVU9fSQ2io=; b=Tclp8RbRZ rQWWncW7DvZ0IRlE5A9FyUom8CErs8avyRPM3GbVhVqRri/Xr5Vufh/8BtSmgrGq /U8nLlbrMutQWYfX5KwZtZpqh2yxlVf2X/jDQenvvEyoUq4O61vx4CkBpEj5k0fA 91Kv7mlNkBCmPETHshty4DKucITUvgfwvA= 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=pPXds5KQJgAn6pk2m1Bavrxhjae/cwNQHJlB+JGNA/hxjqVW Um6eu1yPcWKvq4XEY5daRvEMc3UXzZr7spEqNf4ZFHhKrGnf1yaNdnLXqBHisAi/ 46wPtSypeD/zpsjWq6GpJ0UL4rdeKrbk0ClmR60Gb1TjDuhKFjYgFoZcR0c= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id C363D7F6; Sat, 22 Oct 2011 01:33:54 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id 900193506EB0; Sat, 22 Oct 2011 01:33:54 +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 o+PrTp1CQ6Sp; Sat, 22 Oct 2011 01:33:53 +0200 (CEST) Received: from [10.10.155.2] (unknown [198.202.199.254]) by zimbra.skype.net (Postfix) with ESMTPSA id F1BE83506E81; Sat, 22 Oct 2011 01:33:52 +0200 (CEST) Message-ID: <4EA20101.8090401@skype.net> Date: Fri, 21 Oct 2011 16:32:17 -0700 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Ted Hardie References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------010109040807090304080909" Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] ROAP Example Application X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 23:33:56 -0000 This is a multi-part message in MIME format. --------------010109040807090304080909 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 10/21/2011 12:01 PM, Ted Hardie wrote: > On Fri, Oct 21, 2011 at 10:37 AM, Matthew Kaufman > > wrote: > > Thought experiment: > > If one had a connection object that supported an underlying > protocol that could send one or more encrypted flows of both > real-time media and reliable data, what information would you need > to exchange between the two browser endpoints in order to ensure > that any pair of browsers with any future audio or video codec > could use the best mutually-supported codecs? > > > I think I am missing your point slightly. Do you mean the connection > object talks to an abstraction layer that manages how the flows are > sent, and the swapping occurs in what it manages, or do you mean the > connection object should be able to swap out whether it is talking to > ICE, DTLS-SRTP, or TCP-over-UDP transparently? or something else? I mean "what if the connection object was sitting on top of something like RTMFP", in other words a protocol that can trivially be asked to open a secure (encrypted and authenticated) NAT-traversing session between your browser and another browser and then can deliver multiple parallel flows of partially-reliable media and fully-reliable data (prioritized appropriately) to the far end. Then the next question I asked is, IF you had a connection object like that, what is the minimum you need to get the latest-and-greatest-codec-just-works behavior that Cullen, et. al. have described? Matthew Kaufman --------------010109040807090304080909 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 10/21/2011 12:01 PM, Ted Hardie wrote:
On Fri, Oct 21, 2011 at 10:37 AM, Matthew Kaufman <matthew.kaufman@skype.net> wrote:
Thought experiment:

If one had a connection object that supported an underlying protocol that could send one or more encrypted flows of both real-time media and reliable data, what information would you need to exchange between the two browser endpoints in order to ensure that any pair of browsers with any future audio or video codec could use the best mutually-supported codecs?


I think I am missing your point slightly.  Do you mean the connection object talks to an abstraction layer that manages how the flows are sent, and the swapping occurs in what it manages, or do you mean the connection object should be able to swap out whether it is talking to ICE, DTLS-SRTP, or TCP-over-UDP transparently?  or something else?

I mean "what if the connection object was sitting on top of something like RTMFP", in other words a protocol that can trivially be asked to open a secure (encrypted and authenticated) NAT-traversing session between your browser and another browser and then can deliver multiple parallel flows of partially-reliable media and fully-reliable data (prioritized appropriately)  to the far end.

Then the next question I asked is, IF you had a connection object like that, what is the minimum you need to get the latest-and-greatest-codec-just-works behavior that Cullen, et. al. have described?

Matthew Kaufman
--------------010109040807090304080909-- From HKaplan@acmepacket.com Fri Oct 21 18:12: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 1278611E8082 for ; Fri, 21 Oct 2011 18:12:19 -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.174, 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 9q8h+gKwZbaD for ; Fri, 21 Oct 2011 18:12:18 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id EEC9011E8081 for ; Fri, 21 Oct 2011 18:12:17 -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, 21 Oct 2011 21:12:13 -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, 21 Oct 2011 21:12:14 -0400 From: Hadriel Kaplan To: Matthew Kaufman Thread-Topic: [rtcweb] ROAP Example Application Thread-Index: AQHMkFeiF8ArvBWhokW+l9dVUejvrA== Date: Sat, 22 Oct 2011 01:12:13 +0000 Message-ID: <405C23A2-8E22-464E-A0A3-038E497237B4@acmepacket.com> References: <4EA20101.8090401@skype.net> In-Reply-To: <4EA20101.8090401@skype.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="iso-8859-1" Content-ID: <360EE829277B2F4BA1215CF767A7D776@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] ROAP Example Application X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Oct 2011 01:12:19 -0000 I think what you're getting at is: if we threw out SDP and re-designed how/= what devices indicated/negotiated media-plan stuff, we wouldn't end up with= SDP again - neither in syntax nor semantics nor even architecture, as we'd= likely separate the higher-layer info portion, transport portion, and the = pure codec-type negotiation stuff into separate components; and we'd probab= ly move the codec negotiation into the media-path itself potentially, for e= xample. Is that what you mean? I don't disagree with that, and it's been raised many times in the SIP-rela= ted working groups over the years. We know SDP isn't "clean" in terms of e= ither syntax or semantics, but obviously in the SIP world it was way too la= te to change, and folks now use the info all being together in the SIP sign= aling-plane to their advantage. I think though you can sort of emulate the separation in RTCWeb, even with = the SDP offer/answer and ROAP. You create a MediaStream with a track of "d= ata" type, put it in a PeerConnection, and issue the SDP Offer. Then when = the data connection is open to the peer Browser/device, you create your aud= io/video tracks/streams and add them in, and when the new Offer is issued b= y the Browser you send the ROAP over the data connection to the peer, who d= oes likewise for the Answer. That might work. -hadriel On Oct 21, 2011, at 7:32 PM, Matthew Kaufman wrote: > On 10/21/2011 12:01 PM, Ted Hardie wrote: >> On Fri, Oct 21, 2011 at 10:37 AM, Matthew Kaufman wrote: >> Thought experiment: >>=20 >> If one had a connection object that supported an underlying protocol tha= t could send one or more encrypted flows of both real-time media and reliab= le data, what information would you need to exchange between the two browse= r endpoints in order to ensure that any pair of browsers with any future au= dio or video codec could use the best mutually-supported codecs? >>=20 >>=20 >> I think I am missing your point slightly. Do you mean the connection ob= ject talks to an abstraction layer that manages how the flows are sent, and= the swapping occurs in what it manages, or do you mean the connection obje= ct should be able to swap out whether it is talking to ICE, DTLS-SRTP, or T= CP-over-UDP transparently? or something else? >=20 > I mean "what if the connection object was sitting on top of something lik= e RTMFP", in other words a protocol that can trivially be asked to open a s= ecure (encrypted and authenticated) NAT-traversing session between your bro= wser and another browser and then can deliver multiple parallel flows of pa= rtially-reliable media and fully-reliable data (prioritized appropriately) = to the far end. >=20 > Then the next question I asked is, IF you had a connection object like th= at, what is the minimum you need to get the latest-and-greatest-codec-just-= works behavior that Cullen, et. al. have described? >=20 > Matthew Kaufman > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From randell-ietf@jesup.org Fri Oct 21 20:29: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 01F4F1F0C3C for ; Fri, 21 Oct 2011 20:29:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.055, 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 up+ycDakBz+d for ; Fri, 21 Oct 2011 20:29: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 4F3361F0C34 for ; Fri, 21 Oct 2011 20:29: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 1RHSHM-00040p-Hv for rtcweb@ietf.org; Fri, 21 Oct 2011 22:29:48 -0500 Message-ID: <4EA2378E.4010502@jesup.org> Date: Fri, 21 Oct 2011 23:25:02 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4EA20101.8090401@skype.net> <405C23A2-8E22-464E-A0A3-038E497237B4@acmepacket.com> In-Reply-To: <405C23A2-8E22-464E-A0A3-038E497237B4@acmepacket.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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] ROAP Example Application X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Oct 2011 03:29:50 -0000 On 10/21/2011 9:12 PM, Hadriel Kaplan wrote: > I think what you're getting at is: if we threw out SDP and re-designed how/what devices indicated/negotiated media-plan stuff, we wouldn't end up with SDP again - neither in syntax nor semantics nor even architecture, as we'd likely separate the higher-layer info portion, transport portion, and the pure codec-type negotiation stuff into separate components; and we'd probably move the codec negotiation into the media-path itself potentially, for example. Is that what you mean? Actually, I think Matthew is thinking of something else entirely (though you're right that SDP is not what we'd do with a clean piece of paper - but that would be a multi-year effort, and in the end unless there was a major driving adopter, it would fall by the wayside like SDP-ng (and for that matter, cap-neg)). > I don't disagree with that, and it's been raised many times in the SIP-related working groups over the years. We know SDP isn't "clean" in terms of either syntax or semantics, but obviously in the SIP world it was way too late to change, and folks now use the info all being together in the SIP signaling-plane to their advantage. > > I think though you can sort of emulate the separation in RTCWeb, even with the SDP offer/answer and ROAP. You create a MediaStream with a track of "data" type, put it in a PeerConnection, and issue the SDP Offer. Then when the data connection is open to the peer Browser/device, you create your audio/video tracks/streams and add them in, and when the new Offer is issued by the Browser you send the ROAP over the data connection to the peer, who does likewise for the Answer. That might work. This isn't what Matthew was thinking of - he wanted to know if with these tools, it would ease negotiating codecs that didn't exist when the web-app was written (especially with a low-level API to the browser and its codecs). What you describe is simply a way for the JS App to do "renegotiations" without using the "high path" through the servers. Eminently doable, but not fundamentally different. It may make renegotiations faster. No reason an app can't do that, and I have some services built on WebRTC in mind that may depend on this usage. > -hadriel > > > On Oct 21, 2011, at 7:32 PM, Matthew Kaufman wrote: > >> On 10/21/2011 12:01 PM, Ted Hardie wrote: >>> On Fri, Oct 21, 2011 at 10:37 AM, Matthew Kaufman wrote: >>> Thought experiment: >>> >>> If one had a connection object that supported an underlying protocol that could send one or more encrypted flows of both real-time media and reliable data, what information would you need to exchange between the two browser endpoints in order to ensure that any pair of browsers with any future audio or video codec could use the best mutually-supported codecs? >>> >>> >>> I think I am missing your point slightly. Do you mean the connection object talks to an abstraction layer that manages how the flows are sent, and the swapping occurs in what it manages, or do you mean the connection object should be able to swap out whether it is talking to ICE, DTLS-SRTP, or TCP-over-UDP transparently? or something else? >> I mean "what if the connection object was sitting on top of something like RTMFP", in other words a protocol that can trivially be asked to open a secure (encrypted and authenticated) NAT-traversing session between your browser and another browser and then can deliver multiple parallel flows of partially-reliable media and fully-reliable data (prioritized appropriately) to the far end. >> >> Then the next question I asked is, IF you had a connection object like that, what is the minimum you need to get the latest-and-greatest-codec-just-works behavior that Cullen, et. al. have described? >> >> Matthew Kaufman >> -- Randell Jesup randell-ietf@jesup.org From stefan.lk.hakansson@ericsson.com Fri Oct 21 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 B16E621F86FF for ; Fri, 21 Oct 2011 23:52:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.224 X-Spam-Level: X-Spam-Status: No, score=-6.224 tagged_above=-999 required=5 tests=[AWL=0.075, 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 5MeNxwjib-4N for ; Fri, 21 Oct 2011 23:52: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 8C30521F86A5 for ; Fri, 21 Oct 2011 23:52:18 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-e4-4ea26820181a Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id C2.9F.20773.02862AE4; Sat, 22 Oct 2011 08:52:16 +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; Sat, 22 Oct 2011 08:52:15 +0200 Message-ID: <4EA2681F.2090808@ericsson.com> Date: Sat, 22 Oct 2011 08:52:15 +0200 From: =?UTF-8?B?U3RlZmFuIEjDpWthbnNzb24=?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110922 Lightning/1.0b2 Thunderbird/3.1.15 MIME-Version: 1.0 To: "robert@ocallahan.org" References: In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" , "public-webrtc@w3.org" Subject: Re: [rtcweb] a couple of comments on the latest API draft X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Oct 2011 06:52:19 -0000 Rob, thanks for providing this input. However, the right place to discuss this kind of things is the public-webrtc@w3.org list (cc'd), not the IETF rtcweb list. Thanks, Stefan (one of the webrtc chairs) On 10/21/2011 10:53 PM, Robert O'Callahan wrote: > http://dev.w3.org/2011/webrtc/editor/webrtc-20111017.html > > I'm not sure that "blackness" is the appropriate output for a finished > MediaStream. HTML media elements that aren't playing anything are > transparent. For consistency, it's probably better for MediaStreams that > aren't playing anything to also be transparent. > > When a |MediaStream > | > object ends for any reason (e.g. because the user rescinds the > permission for the page to use the local camera, or because the data > comes from a finite file and the file's end has been reached and the > user has not requested that it be looped, or because the stream > comes from a remote peer and the remote peer has permanently stopped > sending data, it is said to be finished . > > > What if the user reinstates permission for the page to use a camera, or > the author modifies the source to add looping or otherwise replenish the > data (e.g. by restarting the source via some API)? In general, > especially as we add more sources, it's going to be hard to ensure that > the ended/finished state (I think probably you should remove all > mentions of "finished" in favour of "ended") is truly permanent. > Certainly if we allow arbitrary media elements to be used as sources (as > I think we will want to), the author can cause the media element to play > again after it's finished. > > I'm not sure what to do about this, but if we could allow MediaStreams > to exit the "ended" state, that would be good. > > Rob > -- > "If we claim to be without sin, we deceive ourselves and the truth is > not in us. If we confess our sins, he is faithful and just and will > forgive us our sins and purify us from all unrighteousness. If we claim > we have not sinned, we make him out to be a liar and his word is not in > us." [1 John 1:8-10] From harald@alvestrand.no Sat Oct 22 01:34: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 1A8C921F8B8A for ; Sat, 22 Oct 2011 01:34:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.53 X-Spam-Level: X-Spam-Status: No, score=-110.53 tagged_above=-999 required=5 tests=[AWL=0.068, 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 KBwvyWKaVZ9T for ; Sat, 22 Oct 2011 01:34:01 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 65FBF21F8B85 for ; Sat, 22 Oct 2011 01:33:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C43F039E162; Sat, 22 Oct 2011 10:33: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 mLA7pOq-BQKb; Sat, 22 Oct 2011 10:33:50 +0200 (CEST) Received: from [192.168.1.58] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 38BCF39E038; Sat, 22 Oct 2011 10:33:50 +0200 (CEST) Message-ID: <4EA27FEE.4060804@alvestrand.no> Date: Sat, 22 Oct 2011 10:33:50 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: robert@ocallahan.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------040905060605030204070800" Cc: "rtcweb@ietf.org" , "public-webrtc@w3.org" Subject: Re: [rtcweb] a couple of comments on the latest API draft X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "public-webrtc@w3.org" List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Oct 2011 08:34:03 -0000 This is a multi-part message in MIME format. --------------040905060605030204070800 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit This is (for once) purely a W3C WG matter, reply-to: header set appropriately. On 10/21/2011 10:53 PM, Robert O'Callahan wrote: > http://dev.w3.org/2011/webrtc/editor/webrtc-20111017.html > > I'm not sure that "blackness" is the appropriate output for a finished > MediaStream. HTML media elements that aren't playing anything are > transparent. For consistency, it's probably better for MediaStreams > that aren't playing anything to also be transparent. Seems to me that an ended MediaStream should not contribute anything to its playout element, so the playout element should be the one deciding what to do. Good point. > > When a |MediaStream > | > object ends for any reason (e.g. because the user rescinds the > permission for the page to use the local camera, or because the > data comes from a finite file and the file's end has been reached > and the user has not requested that it be looped, or because the > stream comes from a remote peer and the remote peer has > permanently stopped sending data, it is said to be finished . > > > What if the user reinstates permission for the page to use a camera, > or the author modifies the source to add looping or otherwise > replenish the data (e.g. by restarting the source via some API)? In > general, especially as we add more sources, it's going to be hard to > ensure that the ended/finished state (I think probably you should > remove all mentions of "finished" in favour of "ended") is truly > permanent. Certainly if we allow arbitrary media elements to be used > as sources (as I think we will want to), the author can cause the > media element to play again after it's finished. The way it's currently written, "finished" is permanent, but "disabled" is changeable. We don't have any API to re-request permission for camera, GetUserMedia generates a new stream, it doesn't refresh an old one. We can always emulate "restart" by creating a new stream and attaching it to the same playout elements. It's a programming-style issue whether we do that, or just disable on "end". > > I'm not sure what to do about this, but if we could allow MediaStreams > to exit the "ended" state, that would be good. > > Rob > -- > "If we claim to be without sin, we deceive ourselves and the truth is > not in us. If we confess our sins, he is faithful and just and will > forgive us our sins and purify us from all unrighteousness. If we > claim we have not sinned, we make him out to be a liar and his word is > not in us." [1 John 1:8-10] > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --------------040905060605030204070800 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit This is (for once) purely a W3C WG matter, reply-to: header set appropriately.

On 10/21/2011 10:53 PM, Robert O'Callahan wrote:
http://dev.w3.org/2011/webrtc/editor/webrtc-20111017.html

I'm not sure that "blackness" is the appropriate output for a finished MediaStream. HTML media elements that aren't playing anything are transparent. For consistency, it's probably better for MediaStreams that aren't playing anything to also be transparent.
Seems to me that an ended MediaStream should not contribute anything to its playout element, so the playout element should be the one deciding what to do. Good point.

When a MediaStream object ends for any reason (e.g. because the user rescinds the permission for the page to use the local camera, or because the data comes from a finite file and the file's end has been reached and the user has not requested that it be looped, or because the stream comes from a remote peer and the remote peer has permanently stopped sending data, it is said to be finished .

What if the user reinstates permission for the page to use a camera, or the author modifies the source to add looping or otherwise replenish the data (e.g. by restarting the source via some API)? In general, especially as we add more sources, it's going to be hard to ensure that the ended/finished state (I think probably you should remove all mentions of "finished" in favour of "ended") is truly permanent. Certainly if we allow arbitrary media elements to be used as sources (as I think we will want to), the author can cause the media element to play again after it's finished.
The way it's currently written, "finished" is permanent, but "disabled" is changeable.
We don't have any API to re-request permission for camera, GetUserMedia generates a new stream, it doesn't refresh an old one.

We can always emulate "restart" by creating a new stream and attaching it to the same playout elements. It's a programming-style issue whether we do that, or just disable on "end".

I'm not sure what to do about this, but if we could allow MediaStreams to exit the "ended" state, that would be good.

Rob
--
"If we claim to be without sin, we deceive ourselves and the truth is not in us. If we confess our sins, he is faithful and just and will forgive us our sins and purify us from all unrighteousness. If we claim we have not sinned, we make him out to be a liar and his word is not in us." [1 John 1:8-10]

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

--------------040905060605030204070800-- From HKaplan@acmepacket.com Sat Oct 22 10:13: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 6064C21F85B9 for ; Sat, 22 Oct 2011 10:13:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.418 X-Spam-Level: X-Spam-Status: No, score=-2.418 tagged_above=-999 required=5 tests=[AWL=0.181, 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 Q0PKNw2sWDyq for ; Sat, 22 Oct 2011 10:13:09 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id AEC2121F85B8 for ; Sat, 22 Oct 2011 10:13:09 -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, 22 Oct 2011 13:13:04 -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; Sat, 22 Oct 2011 13:13:04 -0400 From: Hadriel Kaplan To: "rtcweb@ietf.org" , "public-webrtc@w3.org" Thread-Topic: RTCWeb Terminology Thread-Index: AQHMkN3c87Lt2+tvdEyozCfd9rxlhQ== Date: Sat, 22 Oct 2011 17:13:04 +0000 Message-ID: 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= Subject: [rtcweb] RTCWeb Terminology X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Oct 2011 17:13:10 -0000 Howdy, this may seem like a silly question, but what are the actual names and capi= talization schemes for the overall architecture, mechanism/protocol, API an= d such? I believe the Working Group names are "RTCWEB" in IETF and "WEBRTC" in W3C.= But in the W3C it appears the name of the API doc is "WebRTC". Is the overall thing "RTCWEB", "RTCWeb", "RTCweb", or "rtcweb"? I've seen = all 4 uses in IETF drafts. Meanwhile in W3C they call the overall architec= ture and protocol "WEBRTC" in the "WebRTC" document. Which is it? Is the Browser API itself an "RTCWeb API" or "WebRTC API" or what? The draft-ietf-rtcweb-overview draft has a terminology section but does not= cover this. I know this is silly, but I've gotten the question several times from custo= mers and marketing folks. (plus it would be nice to be consistent in both I= ETF and W3C docs) I apologize if this question has already been asked and answered. I google= d but found conflicting terms and usage in those results as well. -hadriel From ibc@aliax.net Sat Oct 22 10:18: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 68A7321F8A55 for ; Sat, 22 Oct 2011 10:18:40 -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 BBR6M85xi7+s for ; Sat, 22 Oct 2011 10:18: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 C788821F8A4E for ; Sat, 22 Oct 2011 10:18:39 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so4840346vcb.31 for ; Sat, 22 Oct 2011 10:18:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.184.103 with SMTP id et7mr17981630vdc.35.1319303918198; Sat, 22 Oct 2011 10:18:38 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Sat, 22 Oct 2011 10:18:38 -0700 (PDT) In-Reply-To: References: Date: Sat, 22 Oct 2011 19:18: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: "rtcweb@ietf.org" , "public-webrtc@w3.org" Subject: Re: [rtcweb] RTCWeb Terminology X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Oct 2011 17:18:40 -0000 2011/10/22 Hadriel Kaplan : > Is the overall thing "RTCWEB", "RTCWeb", "RTCweb", or "rtcweb"? =C2=A0I'v= e seen all 4 uses in IETF drafts. And also "RTC-Web". --=20 I=C3=B1aki Baz Castillo From HKaplan@acmepacket.com Sat Oct 22 21:33: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 01DE121F8B05 for ; Sat, 22 Oct 2011 21:33:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.422 X-Spam-Level: X-Spam-Status: No, score=-2.422 tagged_above=-999 required=5 tests=[AWL=0.177, 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 V8QzU5CUXNjk for ; Sat, 22 Oct 2011 21:33:32 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 4391821F8B04 for ; Sat, 22 Oct 2011 21:33: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; Sun, 23 Oct 2011 00:33:31 -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; Sun, 23 Oct 2011 00:33:31 -0400 From: Hadriel Kaplan To: Randell Jesup Thread-Topic: [rtcweb] ROAP Example Application Thread-Index: AQHMkTzqIPS33yu45ku7Rql3YT8OCw== Date: Sun, 23 Oct 2011 04:33:30 +0000 Message-ID: <5D11719A-F62F-4340-8A41-202D218B4DE9@acmepacket.com> References: <4EA20101.8090401@skype.net> <405C23A2-8E22-464E-A0A3-038E497237B4@acmepacket.com> <4EA2378E.4010502@jesup.org> In-Reply-To: <4EA2378E.4010502@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] ROAP Example Application X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Oct 2011 04:33:33 -0000 On Oct 21, 2011, at 11:25 PM, Randell Jesup wrote: >> I think though you can sort of emulate the separation in RTCWeb, even wi= th the SDP offer/answer and ROAP. You create a MediaStream with a track of= "data" type, put it in a PeerConnection, and issue the SDP Offer. Then wh= en the data connection is open to the peer Browser/device, you create your = audio/video tracks/streams and add them in, and when the new Offer is issue= d by the Browser you send the ROAP over the data connection to the peer, wh= o does likewise for the Answer. That might work. >=20 > This isn't what Matthew was thinking of - he wanted to know if with these= tools, it would ease negotiating codecs that didn't exist when the web-app= was written (especially with a low-level API to the browser and its codecs= ). >=20 > What you describe is simply a way for the JS App to do "renegotiations" w= ithout using the "high path" through the servers. Eminently doable, but no= t fundamentally different. It may make renegotiations faster. No reason a= n app can't do that, and I have some services built on WebRTC in mind that = may depend on this usage. Well one really good reason to do it would be to be able to get a session o= n/off-hold (ie, start/stop RTP using SDP direction attributes), or add/remo= ve streams, without clipping and without loading the Web Server down passin= g ROAP messages back/forth. That might be almost necessary in some applica= tions. For example one where you have a lot of separate video sessions up = on a screen and change which one is active at any given time by a mouseover= /click. Or a game application, where you might have a direct data channel = open between all participants anyway, and want to do audio/video whenever t= he users are in the same area of the game or by team-commands or whatever. -hadriel From harald@alvestrand.no Sun Oct 23 00:38: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 59A4521F8AF6 for ; Sun, 23 Oct 2011 00:38:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.542 X-Spam-Level: X-Spam-Status: No, score=-110.542 tagged_above=-999 required=5 tests=[AWL=0.057, 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 4K84EGz1CLj0 for ; Sun, 23 Oct 2011 00:38:33 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 811F621F8AF4 for ; Sun, 23 Oct 2011 00:38:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1C90639E0D2 for ; Sun, 23 Oct 2011 09:31: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 augJntMzK9dD for ; Sun, 23 Oct 2011 09:31:21 +0200 (CEST) Received: from [192.168.1.16] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 555CF39E072 for ; Sun, 23 Oct 2011 09:31:21 +0200 (CEST) Message-ID: <4EA3C324.8050309@alvestrand.no> Date: Sun, 23 Oct 2011 09:32:52 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110922 Thunderbird/3.1.15 MIME-Version: 1.0 To: rtcweb@ietf.org References: <9C8CA816-65FB-41A0-999C-4C43128CAAB4@danyork.org> <2E239D6FCD033C4BAF15F386A979BF51159B91@sonusinmail02.sonusnet.com> <4EA1B9E5.8030507@jesup.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [rtcweb] A plea for simplicity, marketability - and... who are we designing RTCWEB for? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Oct 2011 07:38:34 -0000 On 10/21/2011 09:04 PM, Iñaki Baz Castillo wrote: > 2011/10/21 Randell Jesup: >> This is the rough equivalent to saying "instead of exchanging email in a standard format, and letting people use whatever client/webmail-client they want to read it; if you want to read an email from a gmail user you should log into gmail using their interface; from an aol user log into AOL and their interface, etc. > This is because SMTP is a successful protocol that exists from long > time ago and allows each user to have a globaly reachable > identificator (a mailto: URI). Note (speaking as an emai veteran): These are 3 points (successful, existed for a long time, and allows a globally reachable ID). As of ~1992, I don't believe that any of them were uncontroversial. It took a lot of engineering work to get to where they were obvious truths. > Will RTCweb define an unique > identificator for each user in the world? Not at all. RTCweb will be > implemented by independent websites, so each website decides the > identificator grammar of its users. Please don't try to make analogy > between SMTP and RTCweb because it's not the same. RTCWEB won't, but SIP and XMPP already have. If people deploy applications that implement SIP or XMPP on top of RTCWEB, one of them might eventually turn out to be "obvious" in the same way. That's a hope of many, but far from the only use case for RTCWEB. From likepeng@huawei.com Sun Oct 23 18:19:01 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBB7F21F8A35 for ; Sun, 23 Oct 2011 18:19:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.097 X-Spam-Level: X-Spam-Status: No, score=-5.097 tagged_above=-999 required=5 tests=[AWL=-1.502, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bCbNG6U3oHZ6 for ; Sun, 23 Oct 2011 18:19:01 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 2301E21F89B8 for ; Sun, 23 Oct 2011 18:19:01 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTJ007YOQAZVK@szxga03-in.huawei.com> for rtcweb@ietf.org; Mon, 24 Oct 2011 09:18:35 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTJ0046VQAZO8@szxga03-in.huawei.com> for rtcweb@ietf.org; Mon, 24 Oct 2011 09:18:35 +0800 (CST) Received: from szxeml201-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEJ36473; Mon, 24 Oct 2011 09:18:33 +0800 Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 24 Oct 2011 09:18:32 +0800 Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.181]) by szxeml401-hub.china.huawei.com ([10.82.67.31]) with mapi id 14.01.0270.001; Mon, 24 Oct 2011 09:18:25 +0800 Date: Mon, 24 Oct 2011 01:18:24 +0000 From: Likepeng In-reply-to: X-Originating-IP: [10.70.109.109] To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= , Hadriel Kaplan Message-id: <34966E97BE8AD64EAE9D3D6E4DEE36F2CF5241@szxeml525-mbs.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: [rtcweb] RTCWeb Terminology Thread-index: AQHMkN3c87Lt2+tvdEyozCfd9rxlhZWIFW4AgAKeImA= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: Cc: "rtcweb@ietf.org" , "public-webrtc@w3.org" Subject: Re: [rtcweb] RTCWeb Terminology X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 01:19:01 -0000 PiBBbmQgYWxzbyAiUlRDLVdlYiIuDQoNCkkgcHJlZmVyIHRoaXMgb25lLg0KDQpLaW5kIFJlZ2Fy ZHMNCktlcGVuZw0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHJ0Y3dlYi1ib3Vu Y2VzQGlldGYub3JnIFttYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiBJP2FraSBCYXogQ2FzdGlsbG8NClNlbnQ6IFN1bmRheSwgT2N0b2JlciAyMywgMjAxMSAxOjE5 IEFNDQpUbzogSGFkcmllbCBLYXBsYW4NCkNjOiBydGN3ZWJAaWV0Zi5vcmc7IHB1YmxpYy13ZWJy dGNAdzMub3JnDQpTdWJqZWN0OiBSZTogW3J0Y3dlYl0gUlRDV2ViIFRlcm1pbm9sb2d5DQoNCjIw MTEvMTAvMjIgSGFkcmllbCBLYXBsYW4gPEhLYXBsYW5AYWNtZXBhY2tldC5jb20+Og0KPiBJcyB0 aGUgb3ZlcmFsbCB0aGluZyAiUlRDV0VCIiwgIlJUQ1dlYiIsICJSVEN3ZWIiLCBvciAicnRjd2Vi Ij8gwqBJJ3ZlIHNlZW4gYWxsIDQgdXNlcyBpbiBJRVRGIGRyYWZ0cy4NCg0KQW5kIGFsc28gIlJU Qy1XZWIiLg0KDQotLSANCknDsWFraSBCYXogQ2FzdGlsbG8NCjxpYmNAYWxpYXgubmV0Pg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnJ0Y3dlYiBtYWls aW5nIGxpc3QNCnJ0Y3dlYkBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9ydGN3ZWINCg== From chris.cavigioli@intel.com Sun Oct 23 21: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 20AD921F8C1B for ; Sun, 23 Oct 2011 21:10:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2EJI4LvCD1qK for ; Sun, 23 Oct 2011 21:10:18 -0700 (PDT) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by ietfa.amsl.com (Postfix) with ESMTP id EB69921F8BAB for ; Sun, 23 Oct 2011 21:10:17 -0700 (PDT) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga101.fm.intel.com with ESMTP; 23 Oct 2011 21:10:12 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.69,396,1315206000"; d="scan'208";a="81011979" Received: from orsmsx603.amr.corp.intel.com ([10.22.226.49]) by fmsmga002.fm.intel.com with ESMTP; 23 Oct 2011 21:10:12 -0700 Received: from orsmsx605.amr.corp.intel.com (10.22.226.10) by orsmsx603.amr.corp.intel.com (10.22.226.49) with Microsoft SMTP Server (TLS) id 8.2.255.0; Sun, 23 Oct 2011 21:10:12 -0700 Received: from orsmsx505.amr.corp.intel.com ([10.22.226.208]) by orsmsx605.amr.corp.intel.com ([10.22.226.10]) with mapi; Sun, 23 Oct 2011 21:10:11 -0700 From: "Cavigioli, Chris" To: Hadriel Kaplan , "rtcweb@ietf.org" , "public-webrtc@w3.org" Date: Sun, 23 Oct 2011 21:10:00 -0700 Thread-Topic: RTCWeb Terminology Thread-Index: AQHMkN3c87Lt2+tvdEyozCfd9rxlhZWK44gg Message-ID: <1AA206FBD08B004C82025A41283CCE9EE55DCD91@orsmsx505.amr.corp.intel.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [rtcweb] RTCWeb Terminology X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 04:10:52 -0000 Very good question - been bugging me too. -chris=20 -----Original Message----- From: public-webrtc-request@w3.org [mailto:public-webrtc-request@w3.org] On= Behalf Of Hadriel Kaplan Sent: Saturday, October 22, 2011 10:13 AM To: rtcweb@ietf.org; public-webrtc@w3.org Subject: RTCWeb Terminology Howdy, this may seem like a silly question, but what are the actual names and capi= talization schemes for the overall architecture, mechanism/protocol, API an= d such? I believe the Working Group names are "RTCWEB" in IETF and "WEBRTC" in W3C.= But in the W3C it appears the name of the API doc is "WebRTC". Is the overall thing "RTCWEB", "RTCWeb", "RTCweb", or "rtcweb"? I've seen = all 4 uses in IETF drafts. Meanwhile in W3C they call the overall architec= ture and protocol "WEBRTC" in the "WebRTC" document. Which is it? Is the Browser API itself an "RTCWeb API" or "WebRTC API" or what? The draft-ietf-rtcweb-overview draft has a terminology section but does not= cover this. I know this is silly, but I've gotten the question several times from custo= mers and marketing folks. (plus it would be nice to be consistent in both I= ETF and W3C docs) I apologize if this question has already been asked and answered. I google= d but found conflicting terms and usage in those results as well. -hadriel From wolfgang.beck01@googlemail.com Mon Oct 24 00:28: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 166AE21F8B88 for ; Mon, 24 Oct 2011 00:28:42 -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 0jPOTleKwvIf for ; Mon, 24 Oct 2011 00:28:41 -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 35F9A21F8B83 for ; Mon, 24 Oct 2011 00:28:38 -0700 (PDT) Received: by yxi11 with SMTP id 11so1268460yxi.31 for ; Mon, 24 Oct 2011 00:28:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+9C7XmxN0oZefE9l0Fwv0TLKp4xXVsMkilLGoI8ZtGY=; b=NGVcKw6m5hhQAdDj6NAc3P2n7n7JD6ykXE9cYLc0MlDwT8jsfTp2ujsohm+DXiRP2/ ZFrHR3WoHQ3Dq+VX7rVfR/QxPLuwBkqxCxSc+n5MXdN7lGi3RQfz9QY1Sh4PgLf1gX+z 8fkq1k0eEAP4Rvi0D2FDG0w6rkFfhXRl7BVs8= MIME-Version: 1.0 Received: by 10.68.16.69 with SMTP id e5mr13459359pbd.67.1319441317297; Mon, 24 Oct 2011 00:28:37 -0700 (PDT) Received: by 10.68.55.230 with HTTP; Mon, 24 Oct 2011 00:28:37 -0700 (PDT) In-Reply-To: <4EA1558F.4030203@alvestrand.no> References: <931AFC17-0745-439C-ADB4-6E4581855645@phonefromhere.com> <4EA1558F.4030203@alvestrand.no> Date: Mon, 24 Oct 2011 09:28:37 +0200 Message-ID: From: Wolfgang Beck To: Harald Alvestrand Content-Type: text/plain; charset=ISO-8859-1 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Summary of Signaling Components in RTCweb (clarifications) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 07:28:42 -0000 On Fri, Oct 21, 2011 at 1:20 PM, Harald Alvestrand wrote: > Tim Panton wrote: >> So in short, I think that treating the SDP-like as a blob has significant >> disadvantages. > > A point on which we agree .... Yes, I also think we need to have the ability > to open the blob at the point that makes sense for the application - whether > that's in the browser, the JS, the server, or somewhere else. > _______________________________________________ ROAP only makes sense if the JS application has no full understanding of the blob. If it can understand everything that's in the blob, it could just use the ROAP API as a low-level API. Maybe that's the way forward.. Wolfgang From wolfgang.beck01@googlemail.com Mon Oct 24 00: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 0D3EB21F8B87 for ; Mon, 24 Oct 2011 00:46:01 -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 nV+BfgiR6ceB for ; Mon, 24 Oct 2011 00:46:00 -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 69D2421F8B66 for ; Mon, 24 Oct 2011 00:46:00 -0700 (PDT) Received: by pzk34 with SMTP id 34so16265154pzk.9 for ; Mon, 24 Oct 2011 00:46:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=aPwmGzjkwIv+WwLAYsKtFAv3OrT9oOCwrvAylZyE8t4=; b=Xunvp81UYN1VFN0yxeABQbcOHBH9tJdtWWKBv5CiHikSlPVUjsXLAXbwAN0lF22X6p I89SvdQzMtPeYn5KMp12pXN8YxgvVWsccyM/iw2RfUy6ftzUcT0UiURi53DaIuOzALZi gMeVcZu3t4AWbGsKmyoychsRgsPafHO8rwUAQ= MIME-Version: 1.0 Received: by 10.68.9.69 with SMTP id x5mr5477400pba.118.1319442360105; Mon, 24 Oct 2011 00:46:00 -0700 (PDT) Received: by 10.68.55.230 with HTTP; Mon, 24 Oct 2011 00:45:59 -0700 (PDT) In-Reply-To: <4EA1B9E5.8030507@jesup.org> References: <9C8CA816-65FB-41A0-999C-4C43128CAAB4@danyork.org> <2E239D6FCD033C4BAF15F386A979BF51159B91@sonusinmail02.sonusnet.com> <4EA1B9E5.8030507@jesup.org> Date: Mon, 24 Oct 2011 09:45:59 +0200 Message-ID: From: Wolfgang Beck To: Randell Jesup Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] A plea for simplicity, marketability - and... who are we designing RTCWEB for? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 07:46:01 -0000 On Fri, Oct 21, 2011 at 8:28 PM, Randell Jesup wro= te: > > This is the rough equivalent to saying "instead of exchanging email in a > standard format, and letting people use whatever client/webmail-client th= ey > want to read it; if you want to read an email from a gmail user you shoul= d > log into gmail using their interface; from an aol user log into AOL and > their interface, etc. =A0Oh, and history, phonebooks, etc would all be > separate." =A0Yes, it avoids standard 'federation' formats and conversion= s, > but... Phonebooks aren't a problem. They're called 'Bookmarks' in my browser. Call history doesn't look impossible to me as well. You can either just use the browser's history or setup some bookmarking web site that keeps track of your calls. I used to defend Usenet using all of your arguments. The Web has won. Wolfgang From ibc@aliax.net Mon Oct 24 03:38: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 3792521F8CE9 for ; Mon, 24 Oct 2011 03:38:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.636 X-Spam-Level: X-Spam-Status: No, score=-2.636 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OizWQLGaEc0Q for ; Mon, 24 Oct 2011 03:38:38 -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 C996821F86A6 for ; Mon, 24 Oct 2011 03:38:31 -0700 (PDT) Received: by vws5 with SMTP id 5so5178505vws.31 for ; Mon, 24 Oct 2011 03:38:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.28.141 with SMTP id b13mr22075162vdh.128.1319452710136; Mon, 24 Oct 2011 03:38:30 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Mon, 24 Oct 2011 03:38:30 -0700 (PDT) In-Reply-To: References: <9C8CA816-65FB-41A0-999C-4C43128CAAB4@danyork.org> <2E239D6FCD033C4BAF15F386A979BF51159B91@sonusinmail02.sonusnet.com> <4EA1B9E5.8030507@jesup.org> Date: Mon, 24 Oct 2011 12:38:30 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Wolfgang Beck Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Randell Jesup , rtcweb@ietf.org Subject: Re: [rtcweb] A plea for simplicity, marketability - and... who are we designing RTCWEB for? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 10:38:39 -0000 2011/10/24 Wolfgang Beck : > On Fri, Oct 21, 2011 at 8:28 PM, Randell Jesup w= rote: >> >> This is the rough equivalent to saying "instead of exchanging email in a >> standard format, and letting people use whatever client/webmail-client t= hey >> want to read it; if you want to read an email from a gmail user you shou= ld >> log into gmail using their interface; from an aol user log into AOL and >> their interface, etc. =C2=A0Oh, and history, phonebooks, etc would all b= e >> separate." =C2=A0Yes, it avoids standard 'federation' formats and conver= sions, >> but... > Phonebooks aren't a problem. They're called 'Bookmarks' in my browser. > Call history doesn't look impossible to me as well. You can either > just use the browser's > history or setup some bookmarking web site that keeps track of your calls= . Hi Wolfgang. When you send a text message via Facebook or via Twitter, can you check later all those messages *together* in some "messages history" section within your browser? If the answer is not (and it is not), why do you expect that it should be different for calls? Also, what do you expect such "call history" to show you? In case you make an audio call in Facebook its entry in the call-history list would display your Facebook id as originator and the receiver Facebook user as destination. But in case you join a web game in which RTCweb is used for *automatically* receive audio from other gamers, what do you expect the entry in the call-history to display? Also the fact that your browser has received a RTCweb audio call from a web game does not mean that you can make an outgoing call to the caller (the website could be designed in a way that just calls from server to clients make sense). It could occur that such incoming call from the web game has not an "originator" (as such information is up to the website). Nobody is mandating that a RTCweb call MUST contains a "From" and a "To". RTC-Web is not SIP and it is not about legacy telephony, neither it's designed to be an Skype on the web. > I used to defend Usenet using all of your arguments. The Web has won. IMHO I'm defending the Web model. Regards. --=20 I=C3=B1aki Baz Castillo From wolfgang.beck01@googlemail.com Mon Oct 24 04:33: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 B2A9221F8C22 for ; Mon, 24 Oct 2011 04:33:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.827 X-Spam-Level: X-Spam-Status: No, score=-2.827 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 1AeGcqb+1Ozw for ; Mon, 24 Oct 2011 04:33:12 -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 D7B2B21F8C1E for ; Mon, 24 Oct 2011 04:33:11 -0700 (PDT) Received: by ggnv1 with SMTP id v1so6807077ggn.31 for ; Mon, 24 Oct 2011 04:33:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=OU0j+FCyM7Dh9zYAatXMX3b4pCYPTwaLAAjGEQdIbq0=; b=U1oHz4oPAaC47yiEtg0jyzRkTUBLEfr9ohKVjCP4hGAJM2pzdMUfHQTO4QTfjoPoS4 1lBuUGUork/4heV+OYtH76dxDofdvrbxxe28Nf7hazVdDewNEQLhYxNUorXwgUdRfJeZ Z9N65AWD3hfhe92yhq9qeFNrcqziA8/1hYeQo= MIME-Version: 1.0 Received: by 10.68.30.5 with SMTP id o5mr48499106pbh.9.1319455991215; Mon, 24 Oct 2011 04:33:11 -0700 (PDT) Received: by 10.68.49.169 with HTTP; Mon, 24 Oct 2011 04:33:10 -0700 (PDT) In-Reply-To: References: <9C8CA816-65FB-41A0-999C-4C43128CAAB4@danyork.org> <2E239D6FCD033C4BAF15F386A979BF51159B91@sonusinmail02.sonusnet.com> <4EA1B9E5.8030507@jesup.org> Date: Mon, 24 Oct 2011 13:33:10 +0200 Message-ID: From: Wolfgang Beck To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Randell Jesup , rtcweb@ietf.org Subject: Re: [rtcweb] A plea for simplicity, marketability - and... who are we designing RTCWEB for? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 11:33:12 -0000 On Mon, Oct 24, 2011 at 12:38 PM, I=F1aki Baz Castillo wrot= e: > Hi Wolfgang. When you send a text message via Facebook or via Twitter, > can you check later all those messages *together* in some "messages > history" section within your browser? If the answer is not (and it is > not), why do you expect that it should be different for calls? Sure with text message it is difficult to have a local history. But it is different for voice/video calls. Very few phones routinely store the entire call. A browser implementation could do this, just like it provides bookmark and browsing history functions. > > Also, what do you expect such "call history" to show you? In case you > make an audio call in Facebook its entry in the call-history list > would display your Facebook id as originator and the receiver Facebook > user as destination. But in case you join a web game in which RTCweb > is used for *automatically* receive audio from other gamers, what do > you expect the entry in the call-history to display? My point was to show Randell that the single server model can provide phone book and call history functions if you need this. Either through the browser itself or through some extra web site. Even the trapezoid model can't guarantee that a phone book/call history will always work as expected. If a caller decides to suppress her caller ID, you'll just see that someone unknown called. If you call some company's number you can't be sure that you will be connected to the same phone that you reached during your last call. If we stick to the trapezoid model, the intra-server protocol will be a serious barrier to innovation. If you need something that doesn't translate well to and from SIP, it won't work between your different JS applications. Tunneling a protocol through SIP just shifts the problem to this new protocol, which would need to be standardized as well. Wolfgang From ibc@aliax.net Mon Oct 24 07:20: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 14C6621F8B7D for ; Mon, 24 Oct 2011 07:20:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.636 X-Spam-Level: X-Spam-Status: No, score=-2.636 tagged_above=-999 required=5 tests=[AWL=0.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 k9zdLrrci0wi for ; Mon, 24 Oct 2011 07:20:50 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6539921F84D4 for ; Mon, 24 Oct 2011 07:20:50 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so5893233vcb.31 for ; Mon, 24 Oct 2011 07:20:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.193.67 with SMTP id dt3mr1760598vcb.61.1319466049670; Mon, 24 Oct 2011 07:20:49 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Mon, 24 Oct 2011 07:20:49 -0700 (PDT) In-Reply-To: References: <9C8CA816-65FB-41A0-999C-4C43128CAAB4@danyork.org> <2E239D6FCD033C4BAF15F386A979BF51159B91@sonusinmail02.sonusnet.com> <4EA1B9E5.8030507@jesup.org> Date: Mon, 24 Oct 2011 16:20:49 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Wolfgang Beck Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Randell Jesup , rtcweb@ietf.org Subject: Re: [rtcweb] A plea for simplicity, marketability - and... who are we designing RTCWEB for? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 14:20:51 -0000 2011/10/24 Wolfgang Beck : > If a caller decides to suppress her caller ID, you'll > just see that someone unknown called. Why are you assuming that a RTCweb call has always a caller ID? Imagine a web game. A visitor enters the web and automatically receives an audio "call" from the website. The user is prompted "website mygame.com is attempting to establish an audio call with you, do you accept?". The user presses OK and is entered into a multiconf with all the web users. There is NO need at all for having a "caller-id" in this kind of call. Again I insist that RTC-Web should not be designed *just* to cover the use cases of current VoIP protocols. --=20 I=C3=B1aki Baz Castillo From fluffy@cisco.com Mon Oct 24 08:03: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 0F1B421F851F for ; Mon, 24 Oct 2011 08:03:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.292 X-Spam-Level: X-Spam-Status: No, score=-106.292 tagged_above=-999 required=5 tests=[AWL=0.307, 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 Qs2tdOMKQKnJ for ; Mon, 24 Oct 2011 08:03:54 -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 4718D21F8CDE for ; Mon, 24 Oct 2011 08:03:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=1577; q=dns/txt; s=iport; t=1319468630; x=1320678230; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=D6sn77WrLdXNcFb2NhbvmiFkZ/e0JQghqhgy6MO7TQI=; b=G0HamTaRFx95t8jJf81Fup9E4zYAzaNgRrHZUnEVdweA0DRxurOWgTqt g3XaqS64//o6hbw7XHOk5ynP35AZPyOVQEOt3vCzl31uIwvJWtQKzQf3q kcdCFl+hrtwB21ul/gtzDMDFdtVcR851Dm58IRD9BOF0/bcjzy1FPQGgs I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAAJ+pU6rRDoI/2dsb2JhbABDqRKBBYFuAQEBAQIBAQEBDwEnNAEKBQsLDgQ0JyIOBhMih14IlVgBngIEh19hBIgGjAOFLIxO X-IronPort-AV: E=Sophos;i="4.69,398,1315180800"; d="scan'208";a="9866599" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 24 Oct 2011 15:03:39 +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 p9OF3cAF030994; Mon, 24 Oct 2011 15:03:38 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: Date: Mon, 24 Oct 2011 09:03:38 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <42322A10-14A7-4600-820D-7612A1B12592@cisco.com> References: To: Hadriel Kaplan X-Mailer: Apple Mail (2.1084) Cc: "rtcweb@ietf.org" , "public-webrtc@w3.org" Subject: Re: [rtcweb] RTCWeb Terminology X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 15:03:55 -0000 I don't think there is an answer to this yet so I guess we need to = figure it out. I'm ore concerned about the long term explanation to = people outside W3C or IETF. Hadriel, with you marketing hat on, you have = any suggestions of what we should call the whole thing? On Oct 22, 2011, at 11:13 AM, Hadriel Kaplan wrote: > Howdy, > this may seem like a silly question, but what are the actual names and = capitalization schemes for the overall architecture, mechanism/protocol, = API and such? >=20 > I believe the Working Group names are "RTCWEB" in IETF and "WEBRTC" in = W3C. But in the W3C it appears the name of the API doc is "WebRTC". >=20 > Is the overall thing "RTCWEB", "RTCWeb", "RTCweb", or "rtcweb"? I've = seen all 4 uses in IETF drafts. Meanwhile in W3C they call the overall = architecture and protocol "WEBRTC" in the "WebRTC" document. Which is = it? >=20 > Is the Browser API itself an "RTCWeb API" or "WebRTC API" or what? >=20 > The draft-ietf-rtcweb-overview draft has a terminology section but = does not cover this. >=20 > I know this is silly, but I've gotten the question several times from = customers and marketing folks. (plus it would be nice to be consistent = in both IETF and W3C docs) >=20 > I apologize if this question has already been asked and answered. I = googled but found conflicting terms and usage in those results as well. >=20 > -hadriel >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From ekr@rtfm.com Mon Oct 24 08:06: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 A216421F8C5B for ; Mon, 24 Oct 2011 08:06:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.965 X-Spam-Level: X-Spam-Status: No, score=-102.965 tagged_above=-999 required=5 tests=[AWL=0.012, 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 M7W869KcHVKx for ; Mon, 24 Oct 2011 08:06: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 1455821F8C49 for ; Mon, 24 Oct 2011 08:06:40 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so5951261vcb.31 for ; Mon, 24 Oct 2011 08:06:38 -0700 (PDT) Received: by 10.220.3.68 with SMTP id 4mr1688597vcm.231.1319468797189; Mon, 24 Oct 2011 08:06:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.161.20 with HTTP; Mon, 24 Oct 2011 08:05:57 -0700 (PDT) In-Reply-To: <42322A10-14A7-4600-820D-7612A1B12592@cisco.com> References: <42322A10-14A7-4600-820D-7612A1B12592@cisco.com> From: Eric Rescorla Date: Mon, 24 Oct 2011 08:05:57 -0700 Message-ID: To: Cullen Jennings Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" , "public-webrtc@w3.org" Subject: Re: [rtcweb] RTCWeb Terminology X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 15:06:40 -0000 How about SuperAwesomeWebCalling (TM). -Ekr On Mon, Oct 24, 2011 at 8:03 AM, Cullen Jennings wrote: > > I don't think there is an answer to this yet so I guess we need to figure= it out. =A0I'm ore concerned about the long term explanation to people out= side W3C or IETF. Hadriel, with you marketing hat on, you have any suggesti= ons of what we should call the whole thing? > > > On Oct 22, 2011, at 11:13 AM, Hadriel Kaplan wrote: > >> Howdy, >> this may seem like a silly question, but what are the actual names and c= apitalization schemes for the overall architecture, mechanism/protocol, API= and such? >> >> I believe the Working Group names are "RTCWEB" in IETF and "WEBRTC" in W= 3C. =A0But in the W3C it appears the name of the API doc is "WebRTC". >> >> Is the overall thing "RTCWEB", "RTCWeb", "RTCweb", or "rtcweb"? =A0I've = seen all 4 uses in IETF drafts. =A0Meanwhile in W3C they call the overall a= rchitecture and protocol "WEBRTC" in the "WebRTC" document. =A0Which is it? >> >> Is the Browser API itself an "RTCWeb API" or "WebRTC API" or what? >> >> The draft-ietf-rtcweb-overview draft has a terminology section but does = not cover this. >> >> I know this is silly, but I've gotten the question several times from cu= stomers and marketing folks. (plus it would be nice to be consistent in bot= h IETF and W3C docs) >> >> I apologize if this question has already been asked and answered. =A0I g= oogled but found conflicting terms and usage in those results as well. >> >> -hadriel >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From wolfgang.beck01@googlemail.com Mon Oct 24 08:38: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 87EC71F0C42 for ; Mon, 24 Oct 2011 08:38:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.818 X-Spam-Level: X-Spam-Status: No, score=-2.818 tagged_above=-999 required=5 tests=[AWL=-0.141, 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 xwnJfbkmpLTl for ; Mon, 24 Oct 2011 08:38:50 -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 CE1671F0C41 for ; Mon, 24 Oct 2011 08:38:49 -0700 (PDT) Received: by ggnv1 with SMTP id v1so7073711ggn.31 for ; Mon, 24 Oct 2011 08:38:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=zNAhkOtDDkpM/7LCkY3ZTc6bs1H+wJV9XQFwoRG95xo=; b=ceaH5KN9uuI1J1tU7smnbisLEV1obojlSroHKucuNcrfz//jw6TWWtH+VMqKNtfhFx OrRBsp8hSYqVh5sQScSB+x/LjLXK6IIk9BJXinffyvpFwgdRgYnG4wVm3rHkT85Cbpdr eYBGM7ex/qMlBiRhHE/4nEzAFPVlrr4HGpG2I= MIME-Version: 1.0 Received: by 10.68.32.234 with SMTP id m10mr28999293pbi.43.1319470728985; Mon, 24 Oct 2011 08:38:48 -0700 (PDT) Received: by 10.68.49.169 with HTTP; Mon, 24 Oct 2011 08:38:48 -0700 (PDT) In-Reply-To: References: <9C8CA816-65FB-41A0-999C-4C43128CAAB4@danyork.org> <2E239D6FCD033C4BAF15F386A979BF51159B91@sonusinmail02.sonusnet.com> <4EA1B9E5.8030507@jesup.org> Date: Mon, 24 Oct 2011 17:38:48 +0200 Message-ID: From: Wolfgang Beck To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Randell Jesup , rtcweb@ietf.org Subject: Re: [rtcweb] A plea for simplicity, marketability - and... who are we designing RTCWEB for? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 15:38:50 -0000 On Mon, Oct 24, 2011 at 4:20 PM, I=F1aki Baz Castillo wrote= : > 2011/10/24 Wolfgang Beck : >> If a caller decides to suppress her caller ID, you'll >> just see that someone unknown called. > > Why are you assuming that a RTCweb call has always a caller ID? > I do not assume this. I was referring to Randell's question about phone books and call lists which are only useful if you have some kind of caller id. But of course there are many scenarios where you don't have one. Wolfgang From HKaplan@acmepacket.com Mon Oct 24 09:56: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 4FE4921F8ABC for ; Mon, 24 Oct 2011 09:56:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.925 X-Spam-Level: X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[AWL=-0.326, BAYES_00=-2.599, J_BACKHAIR_27=1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bMVAGSbj5Ftg for ; Mon, 24 Oct 2011 09:56:20 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id B5EA621F84A5 for ; Mon, 24 Oct 2011 09:56: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, 24 Oct 2011 12:56:18 -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; Mon, 24 Oct 2011 12:56:19 -0400 From: Hadriel Kaplan To: Cullen Jennings Thread-Topic: [rtcweb] RTCWeb Terminology Thread-Index: AQHMkm3ZWlVgOvN8GUaOFts2KjZpww== Date: Mon, 24 Oct 2011 16:56:18 +0000 Message-ID: <3747C7CB-C039-4D15-A46C-8FDB9A47AF3A@acmepacket.com> References: <42322A10-14A7-4600-820D-7612A1B12592@cisco.com> In-Reply-To: <42322A10-14A7-4600-820D-7612A1B12592@cisco.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="us-ascii" Content-ID: <253ECA8D6EE0164E853BAA260F257524@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "rtcweb@ietf.org" , "public-webrtc@w3.org" Subject: Re: [rtcweb] RTCWeb Terminology X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 16:56:21 -0000 On Oct 24, 2011, at 11:03 AM, Cullen Jennings wrote: >=20 > I don't think there is an answer to this yet so I guess we need to figure= it out. I'm ore concerned about the long term explanation to people outsi= de W3C or IETF. Hadriel, with you marketing hat on, you have any suggestion= s of what we should call the whole thing? Web 4.0. ;) I asked a couple other folks and the consensus seems to be: "WebRTC" for th= e whole thing. The rationale is that it's still the Web but with native real-time-communic= ation support, as opposed to real-time-communication but with web support. = For example if you wrote a book about how to write Web-apps for it, you wo= uld probably use the term "WebRTC" in the book title. Another rationale wa= s that it follows the naming scheme for WebM and WebP. For the API, the consensus was it would be confusing to people if we weren'= t consistent with W3C docs. So I propose the following: WebRTC: the whole shebang WebRTC API: the JS<->Browser API. -hadriel p.s. personally I've gotten used to the term "RTCWeb", but it may be becaus= e of my IETF focus rather than W3C/Web focus. From ag@ag-projects.com Mon Oct 24 10:01: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 1D95721F8AFE for ; Mon, 24 Oct 2011 10:01:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.988 X-Spam-Level: X-Spam-Status: No, score=-0.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, J_BACKHAIR_27=1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZrSH+IYiv-io for ; Mon, 24 Oct 2011 10:01:31 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 8B5C621F8B3B for ; Mon, 24 Oct 2011 10:01:31 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id EDB4FB01B1; Mon, 24 Oct 2011 19:01:29 +0200 (CEST) Received: from ag-blink.lan (169.86.209.88.static.monaco.mc [88.209.86.169]) by mail.sipthor.net (Postfix) with ESMTPSA id 1C75DB017D; Mon, 24 Oct 2011 19:01:29 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Adrian Georgescu In-Reply-To: <3747C7CB-C039-4D15-A46C-8FDB9A47AF3A@acmepacket.com> Date: Mon, 24 Oct 2011 19:01:28 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <42322A10-14A7-4600-820D-7612A1B12592@cisco.com> <3747C7CB-C039-4D15-A46C-8FDB9A47AF3A@acmepacket.com> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Mon, 24 Oct 2011 10:12:30 -0700 Cc: "rtcweb@ietf.org" , "public-webrtc@w3.org" Subject: Re: [rtcweb] RTCWeb Terminology X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 17:01:32 -0000 WebRTC sounds great! Adrian On Oct 24, 2011, at 6:56 PM, Hadriel Kaplan wrote: >=20 > On Oct 24, 2011, at 11:03 AM, Cullen Jennings wrote: >=20 >>=20 >> I don't think there is an answer to this yet so I guess we need to = figure it out. I'm ore concerned about the long term explanation to = people outside W3C or IETF. Hadriel, with you marketing hat on, you have = any suggestions of what we should call the whole thing? >=20 > Web 4.0. ;) >=20 > I asked a couple other folks and the consensus seems to be: "WebRTC" = for the whole thing. >=20 > The rationale is that it's still the Web but with native = real-time-communication support, as opposed to real-time-communication = but with web support. For example if you wrote a book about how to = write Web-apps for it, you would probably use the term "WebRTC" in the = book title. Another rationale was that it follows the naming scheme for = WebM and WebP. >=20 > For the API, the consensus was it would be confusing to people if we = weren't consistent with W3C docs. >=20 > So I propose the following: >=20 > WebRTC: the whole shebang > WebRTC API: the JS<->Browser API. >=20 > -hadriel > p.s. personally I've gotten used to the term "RTCWeb", but it may be = because of my IETF focus rather than W3C/Web focus. >=20 >=20 From fluffy@cisco.com Mon Oct 24 10:18: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 2D09A21F8C9F for ; Mon, 24 Oct 2011 10:18:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.804 X-Spam-Level: X-Spam-Status: No, score=-105.804 tagged_above=-999 required=5 tests=[AWL=-0.205, BAYES_00=-2.599, J_BACKHAIR_27=1, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7NjzGzOh+lus for ; Mon, 24 Oct 2011 10:18:21 -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 0A63A21F8C90 for ; Mon, 24 Oct 2011 10:18:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=1440; q=dns/txt; s=iport; t=1319476700; x=1320686300; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=9wKaEQCkKk4HvbXugnuhBM6Lh8rTLhXw0/ue6WszgI0=; b=Vw89Zxvrlu1Xsy/55buLIKn21AZSUzMMb6NBxR5wVAxopQNGarVnVV1N fBwuOQRj4xCdCkN66LzU04dp3k6o7eMGSWdeYy9xl03oe0ifXR0dawxQM DggenLBhta1gwl3XUrK3pQ49exodVAd4zanS8yLLxL3Zuk1ZlWtge0to1 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAACdpU6rRDoH/2dsb2JhbABDqRKBBYFuAQEBAQIBEgEUEzUKBQsLDgouVwY1h16VcQGeHIdfYQSIBowDhSyMTg X-IronPort-AV: E=Sophos;i="4.69,399,1315180800"; d="scan'208";a="9194638" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 24 Oct 2011 17:18:20 +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 p9OHIKBV008515; Mon, 24 Oct 2011 17:18:20 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: Date: Mon, 24 Oct 2011 11:18:19 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <1107BC89-1AB6-47F7-970A-BCF25955D1E0@cisco.com> References: <42322A10-14A7-4600-820D-7612A1B12592@cisco.com> <3747C7CB-C039-4D15-A46C-8FDB9A47AF3A@acmepacket.com> To: Adrian Georgescu X-Mailer: Apple Mail (2.1084) Cc: "rtcweb@ietf.org" , "public-webrtc@w3.org" Subject: Re: [rtcweb] RTCWeb Terminology X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 17:18:22 -0000 +1=20 On Oct 24, 2011, at 11:01 AM, Adrian Georgescu wrote: > WebRTC sounds great! >=20 > Adrian >=20 > On Oct 24, 2011, at 6:56 PM, Hadriel Kaplan wrote: >=20 >>=20 >> On Oct 24, 2011, at 11:03 AM, Cullen Jennings wrote: >>=20 >>>=20 >>> I don't think there is an answer to this yet so I guess we need to = figure it out. I'm ore concerned about the long term explanation to = people outside W3C or IETF. Hadriel, with you marketing hat on, you have = any suggestions of what we should call the whole thing? >>=20 >> Web 4.0. ;) >>=20 >> I asked a couple other folks and the consensus seems to be: "WebRTC" = for the whole thing. >>=20 >> The rationale is that it's still the Web but with native = real-time-communication support, as opposed to real-time-communication = but with web support. For example if you wrote a book about how to = write Web-apps for it, you would probably use the term "WebRTC" in the = book title. Another rationale was that it follows the naming scheme for = WebM and WebP. >>=20 >> For the API, the consensus was it would be confusing to people if we = weren't consistent with W3C docs. >>=20 >> So I propose the following: >>=20 >> WebRTC: the whole shebang >> WebRTC API: the JS<->Browser API. >>=20 >> -hadriel >> p.s. personally I've gotten used to the term "RTCWeb", but it may be = because of my IETF focus rather than W3C/Web focus. >>=20 >>=20 >=20 From ibc@aliax.net Mon Oct 24 10:21: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 1DE3D21F8BDB for ; Mon, 24 Oct 2011 10:21:04 -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 amjhZTGqC0R4 for ; Mon, 24 Oct 2011 10:21:03 -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 46EA421F8BD7 for ; Mon, 24 Oct 2011 10:21:03 -0700 (PDT) Received: by vws5 with SMTP id 5so5644726vws.31 for ; Mon, 24 Oct 2011 10:21:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.30.79 with SMTP id q15mr23458839vdh.111.1319476862491; Mon, 24 Oct 2011 10:21:02 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Mon, 24 Oct 2011 10:21:02 -0700 (PDT) In-Reply-To: References: <42322A10-14A7-4600-820D-7612A1B12592@cisco.com> <3747C7CB-C039-4D15-A46C-8FDB9A47AF3A@acmepacket.com> Date: Mon, 24 Oct 2011 19:21:02 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Adrian Georgescu Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" , "public-webrtc@w3.org" Subject: Re: [rtcweb] RTCWeb Terminology X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 17:21:04 -0000 2011/10/24 Adrian Georgescu : > WebRTC sounds great! And just involves changing the name of the WG, the maillist, the project domain and all the existing drafts. :) But I agree. --=20 I=C3=B1aki Baz Castillo From victor.pascual.avila@gmail.com Mon Oct 24 10:32: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 8D1211F0C3F for ; Mon, 24 Oct 2011 10:32:37 -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, J_BACKHAIR_27=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 3XrUv9e8WrCX for ; Mon, 24 Oct 2011 10:32:36 -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 0B5F921F8C9F for ; Mon, 24 Oct 2011 10:32:27 -0700 (PDT) Received: by ggnv1 with SMTP id v1so7200559ggn.31 for ; Mon, 24 Oct 2011 10:32:27 -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=j9QH7M4uQSUyHsfB0NnAXkRjTzOxC+P3+s7rb78MbB8=; b=c0L6fJZ5E3hesOW3Py23U22jeYTRyP0r+wiCA0sJgljalX/VRRO2mv+CNX+KllfVlq THdAJ1T3R5GxwKuYc7dHafAkTREVaSuLu2Az3jTOgHFxDcaqHC4pWjaqF3ViLN/clxlz YX0r1/5/nzM4/6X8UWcKTu7E+pwO+5YIc6Ajo= MIME-Version: 1.0 Received: by 10.68.72.73 with SMTP id b9mr49887273pbv.100.1319477547243; Mon, 24 Oct 2011 10:32:27 -0700 (PDT) Received: by 10.142.172.10 with HTTP; Mon, 24 Oct 2011 10:32:27 -0700 (PDT) In-Reply-To: References: <42322A10-14A7-4600-820D-7612A1B12592@cisco.com> <3747C7CB-C039-4D15-A46C-8FDB9A47AF3A@acmepacket.com> Date: Mon, 24 Oct 2011 19:32:27 +0200 Message-ID: From: Victor Pascual Avila To: Adrian Georgescu Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" , "public-webrtc@w3.org" Subject: Re: [rtcweb] RTCWeb Terminology X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 17:32:37 -0000 +1 On Mon, Oct 24, 2011 at 7:01 PM, Adrian Georgescu wrot= e: > WebRTC sounds great! > > Adrian > > On Oct 24, 2011, at 6:56 PM, Hadriel Kaplan wrote: > >> >> On Oct 24, 2011, at 11:03 AM, Cullen Jennings wrote: >> >>> >>> I don't think there is an answer to this yet so I guess we need to figu= re it out. =C2=A0I'm ore concerned about the long term explanation to peopl= e outside W3C or IETF. Hadriel, with you marketing hat on, you have any sug= gestions of what we should call the whole thing? >> >> Web 4.0. =C2=A0;) >> >> I asked a couple other folks and the consensus seems to be: "WebRTC" for= the whole thing. >> >> The rationale is that it's still the Web but with native real-time-commu= nication support, as opposed to real-time-communication but with web suppor= t. =C2=A0For example if you wrote a book about how to write Web-apps for it= , you would probably use the term "WebRTC" in the book title. =C2=A0Another= rationale was that it follows the naming scheme for WebM and WebP. >> >> For the API, the consensus was it would be confusing to people if we wer= en't consistent with W3C docs. >> >> So I propose the following: >> >> WebRTC: the whole shebang >> WebRTC API: the JS<->Browser API. >> >> -hadriel >> p.s. personally I've gotten used to the term "RTCWeb", but it may be bec= ause of my IETF focus rather than W3C/Web focus. >> >> > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --=20 Victor Pascual =C3=81vila From cary.bran.standards@gmail.com Mon Oct 24 13:59: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 95D8E21F8C74 for ; Mon, 24 Oct 2011 13:59:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_BACKHAIR_27=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 uscPB2bwFsKX for ; Mon, 24 Oct 2011 13:59:36 -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 E710921F8C78 for ; Mon, 24 Oct 2011 13:59:35 -0700 (PDT) Received: by ggnv1 with SMTP id v1so7398777ggn.31 for ; Mon, 24 Oct 2011 13:59:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=6PswSbkSSuAtwS8PWG0J9Du6HUTXZg7gzquKIoWww7M=; b=FuYvhQwui0Huw4fhRqzE/V5AWFWlJJx1fIJoQTZkITk+vmUYon1VTDR2lM7sSvWq1N +dIyYumxsOjhWP5FBIE4w2caJ3SBDUBarDgVOEw8ChJotej5WeKtIbfz2yZo2BxhMFDc ddRADp2S/e7yf9W1VGWc+ovYOpjz43NRZ8b2s= Received: by 10.68.58.7 with SMTP id m7mr32813156pbq.106.1319489556891; Mon, 24 Oct 2011 13:52:36 -0700 (PDT) Received: from [10.0.1.5] (c-98-247-103-106.hsd1.wa.comcast.net. [98.247.103.106]) by mx.google.com with ESMTPS id x7sm1230486pbf.5.2011.10.24.13.52.35 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 24 Oct 2011 13:52:36 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cary Bran In-Reply-To: <1107BC89-1AB6-47F7-970A-BCF25955D1E0@cisco.com> Date: Mon, 24 Oct 2011 13:52:34 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <42322A10-14A7-4600-820D-7612A1B12592@cisco.com> <3747C7CB-C039-4D15-A46C-8FDB9A47AF3A@acmepacket.com> <1107BC89-1AB6-47F7-970A-BCF25955D1E0@cisco.com> To: Cullen Jennings X-Mailer: Apple Mail (2.1084) Cc: "rtcweb@ietf.org" , Adrian Georgescu , "public-webrtc@w3.org" Subject: Re: [rtcweb] RTCWeb Terminology X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 20:59:36 -0000 +1 On Oct 24, 2011, at 10:18 AM, Cullen Jennings wrote: >=20 > +1=20 >=20 > On Oct 24, 2011, at 11:01 AM, Adrian Georgescu wrote: >=20 >> WebRTC sounds great! >>=20 >> Adrian >>=20 >> On Oct 24, 2011, at 6:56 PM, Hadriel Kaplan wrote: >>=20 >>>=20 >>> On Oct 24, 2011, at 11:03 AM, Cullen Jennings wrote: >>>=20 >>>>=20 >>>> I don't think there is an answer to this yet so I guess we need to = figure it out. I'm ore concerned about the long term explanation to = people outside W3C or IETF. Hadriel, with you marketing hat on, you have = any suggestions of what we should call the whole thing? >>>=20 >>> Web 4.0. ;) >>>=20 >>> I asked a couple other folks and the consensus seems to be: "WebRTC" = for the whole thing. >>>=20 >>> The rationale is that it's still the Web but with native = real-time-communication support, as opposed to real-time-communication = but with web support. For example if you wrote a book about how to = write Web-apps for it, you would probably use the term "WebRTC" in the = book title. Another rationale was that it follows the naming scheme for = WebM and WebP. >>>=20 >>> For the API, the consensus was it would be confusing to people if we = weren't consistent with W3C docs. >>>=20 >>> So I propose the following: >>>=20 >>> WebRTC: the whole shebang >>> WebRTC API: the JS<->Browser API. >>>=20 >>> -hadriel >>> p.s. personally I've gotten used to the term "RTCWeb", but it may be = because of my IETF focus rather than W3C/Web focus. >>>=20 >>>=20 >>=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From randell-ietf@jesup.org Mon Oct 24 15:49: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 7F96911E81C8 for ; Mon, 24 Oct 2011 15:49:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.546 X-Spam-Level: X-Spam-Status: No, score=-2.546 tagged_above=-999 required=5 tests=[AWL=0.052, 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 Ja2UitlY5H87 for ; Mon, 24 Oct 2011 15:49:14 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 03E0111E81CD for ; Mon, 24 Oct 2011 15:49:13 -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 1RITKT-0002q2-AU for rtcweb@ietf.org; Mon, 24 Oct 2011 17:49:13 -0500 Message-ID: <4EA5EA46.1010803@jesup.org> Date: Mon, 24 Oct 2011 18:44:22 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "rtcweb@ietf.org" 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] draft-jesup-rtcweb-data-00 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: Mon, 24 Oct 2011 22:49:14 -0000 A new version of I-D, draft-jesup-rtcweb-data-00.txt has been successfully submitted by Randell Jesup and posted to the IETF repository. Filename: draft-jesup-rtcweb-data Revision: 00 Title: RTCWeb Datagram Connection Creation date: 2011-10-25 WG ID: Individual Submission Number of pages: 11 Abstract: This document investigates the possibilities for designing a generic transport service that allows Web Browser to exchange generic data in a peer to peer way. Different transport protocols and their properties are investigated in order to identify the most appropriate one. URL: http://www.ietf.org/id/draft-jesup-rtcweb-data-00.txt -- Randell Jesup randell-ietf@jesup.org From ibc@aliax.net Mon Oct 24 16:05: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 07F2211E8105 for ; Mon, 24 Oct 2011 16:05:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.638 X-Spam-Level: X-Spam-Status: No, score=-2.638 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YQPOMuqT9k7z for ; Mon, 24 Oct 2011 16:05:12 -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 13C1A11E8103 for ; Mon, 24 Oct 2011 16:05:11 -0700 (PDT) Received: by vws5 with SMTP id 5so5972860vws.31 for ; Mon, 24 Oct 2011 16:05:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.28.141 with SMTP id b13mr24792864vdh.128.1319497511386; Mon, 24 Oct 2011 16:05:11 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Mon, 24 Oct 2011 16:05:11 -0700 (PDT) Date: Tue, 25 Oct 2011 01:05:11 +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-sipdoc-rtcweb-open-wire-protocol-00 (Open In-The-Wire Protocol for RTC-Web) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 23:05:13 -0000 A new I-D draft-sipdoc-rtcweb-open-wire-protocol-00.txt has been successfully submitted by I=C3=B1aki Baz Castillo, Sa=C3=BAl Ibarra Corret= g=C3=A9 and Jos=C3=A9 Luis Mill=C3=A1n Villegas, and posted to the IETF repository. Filename: =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-sipdoc-rtcweb-open-wire-protocol= Revision: =C2=A000Title: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Open In-The-Wire Protocol= for RTC-WebCreation date: =C2=A0 2011-10-25WG ID: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual= SubmissionNumber of pages: 22 http://tools.ietf.org/html/draft-sipdoc-rtcweb-open-wire-protocol-00 http://www.ietf.org/id/draft-sipdoc-rtcweb-open-wire-protocol-00.txt Abstract:=C2=A0 RTC-Web clients communicate with a server in order to request or=C2=A0 manage realtime communications with other users. =C2=A0Thi= s document=C2=A0 exposes four hypothetical and different RTC-Web scenarios and=C2=A0 analyzes the requirements of the in-the-wire protocol in each of them. =C2=A0 The aim of this document is to make RTC-Web properly fit in the nature of the Web. --=20 I=C3=B1aki Baz Castillo Sa=C3=BAl Ibarra Corretg=C3=A9 Jos=C3=A9 Luis Mill=C3=A1n Villegas From HKaplan@acmepacket.com Mon Oct 24 16:30: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 01E5611E81E8 for ; Mon, 24 Oct 2011 16:30:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.426 X-Spam-Level: X-Spam-Status: No, score=-2.426 tagged_above=-999 required=5 tests=[AWL=0.173, 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 NaDz-GLDP9Hu for ; Mon, 24 Oct 2011 16:30:14 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id E171F11E81DE for ; Mon, 24 Oct 2011 16:30:13 -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, 24 Oct 2011 19:30:12 -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; Mon, 24 Oct 2011 19:30:12 -0400 From: Hadriel Kaplan To: "rtcweb@ietf.org" Thread-Topic: draft-kaplan-rtcweb-sip-interworking-requirements-00 Thread-Index: AQHMkqTg+ZnmTyb6QUGCzFAZ7bjkHA== Date: Mon, 24 Oct 2011 23:30:11 +0000 Message-ID: <6EB8679A-13D5-4AD7-97F2-BC35FC0966F0@acmepacket.com> References: <20111024224257.28459.65554.idtracker@ietfa.amsl.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="us-ascii" Content-ID: <7164EA7634B8554E8387A2DC90738B2A@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Subject: [rtcweb] draft-kaplan-rtcweb-sip-interworking-requirements-00 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 23:30:15 -0000 Howdy, I've submitted a draft listing some use-cases and resulting requirements fo= r interworking from RTCWeb (or "WebRTC" as the case may be), to deployed SI= P domains/devices. The draft also discusses the functions which may be required in an interwor= king device, should some of the requirements not be met. The purpose of the draft is to put pen-to-paper on some of the emails flyin= g around the past month, to stimulate discussion, and hopefully drive conse= nsus decisions sooner rather than later. Info below. Note that most of the doc is about media-plane issues, rather than about SI= P/SDP as I expect Cullen's soon-to-be-announced ROAP signaling-gateway draf= t will be. -hadriel Begin forwarded message: > From: > Subject: I-D Action: draft-kaplan-rtcweb-sip-interworking-requirements-00= .txt > Date: October 24, 2011 6:42:57 PM EDT > To: > Reply-To: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. >=20 > Title : Requirements for Interworking RTCWeb with Current SIP = Deployments > Author(s) : Hadriel Kaplan > Filename : draft-kaplan-rtcweb-sip-interworking-requirements-00.t= xt > Pages : 22 > Date : 2011-10-24 >=20 > The IETF RTCWEB WG has been discussing how to interwork with > deployed SIP equipment and domains. Doing so may require an > Interworking Function middlebox in the media-plane. This document > lists some RTCWeb-to-SIP use-cases, the RTCWeb requirements to > support such, and the complexity involved in interworking if the > requirements cannot be met. >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-kaplan-rtcweb-sip-interworking-= requirements-00.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-kaplan-rtcweb-sip-interworking-r= equirements-00.txt > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From rocallahan@gmail.com Mon Oct 24 17:04: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 0931C21F8CBB for ; Mon, 24 Oct 2011 17:04:14 -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 7IBefvzrquIE for ; Mon, 24 Oct 2011 17:04:13 -0700 (PDT) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id A7F0321F8CB8 for ; Mon, 24 Oct 2011 17:04:12 -0700 (PDT) Received: by wwn22 with SMTP id 22so4378611wwn.1 for ; Mon, 24 Oct 2011 17:04:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:reply-to:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=QflXaPqAq6QpUaJu81iTYJjfoOCPCJSJZ4M2R9OZa/c=; b=BQuvi4dR6rJzM/Zic5EDYNnxIUAWdyN/WIRxl4wNcqAYDxDCJ7oIXvgnfds78ubuin 2Y6boLcSuXPXsgwbtlX9POzBwe1y2Xnmi9TQiAVhYls8k9f8m5YZVEiA+aYK7Dom1Mgr vee1PLy0mqGEnPsX1b/MoZMqZWCiylD4VvZTY= MIME-Version: 1.0 Received: by 10.227.208.81 with SMTP id gb17mr65198wbb.24.1319501051819; Mon, 24 Oct 2011 17:04:11 -0700 (PDT) Sender: rocallahan@gmail.com Received: by 10.227.136.73 with HTTP; Mon, 24 Oct 2011 17:04:11 -0700 (PDT) In-Reply-To: <4EA27FEE.4060804@alvestrand.no> References: <4EA27FEE.4060804@alvestrand.no> Date: Tue, 25 Oct 2011 13:04:11 +1300 X-Google-Sender-Auth: q03U2FbGlour7fpWbA4a7EYAevo Message-ID: From: "Robert O'Callahan" To: "public-webrtc@w3.org" Content-Type: multipart/alternative; boundary=0015174c1a1c7976f004b0144761 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] a couple of comments on the latest API draft X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@ocallahan.org List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 00:04:14 -0000 --0015174c1a1c7976f004b0144761 Content-Type: text/plain; charset=UTF-8 On Sat, Oct 22, 2011 at 9:33 PM, Harald Alvestrand wrote: > ** > On 10/21/2011 10:53 PM, Robert O'Callahan wrote: > > http://dev.w3.org/2011/webrtc/editor/webrtc-20111017.html > > I'm not sure that "blackness" is the appropriate output for a finished > MediaStream. HTML media elements that aren't playing anything are > transparent. For consistency, it's probably better for MediaStreams that > aren't playing anything to also be transparent. > > Seems to me that an ended MediaStream should not contribute anything to its > playout element, so the playout element should be the one deciding what to > do. Good point. > Yeah. Actually video elements normally keep showing the last frame when they end, so we'll want a way to support that too. The way it's currently written, "finished" is permanent, but "disabled" is > changeable. > "finished" == "ended", right? :-) OK, I will try to write the ProcessedMediaStream spec so that "ended" is a permanent state. This means that when you get a MediaStream for an HTML media element, the MediaStream will have to be tied to the currently playing media resource, and when playback ends that MediaStream will become inactive and a new MediaStream generated if the author seeks the media resource and starts playing it again, or loads a new media resource. Rob -- "If we claim to be without sin, we deceive ourselves and the truth is not in us. If we confess our sins, he is faithful and just and will forgive us our sins and purify us from all unrighteousness. If we claim we have not sinned, we make him out to be a liar and his word is not in us." [1 John 1:8-10] --0015174c1a1c7976f004b0144761 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sat, Oct 22, 2011 at 9:33 PM, Harald Alvestrand <harald@alvestrand.no> w= rote:
=20 =20 =20
On 10/21/2011 10:53 PM, Robert O'Callahan wrote:

http= ://dev.w3.org/2011/webrtc/editor/webrtc-20111017.html

I'm not sure that "blackness" is the appropriate output= for a finished MediaStream. HTML media elements that aren't playing anything are transparent. For consistency, it's probably better for MediaStreams that aren't playing anything to also be transparent.
Seems to me that an ended MediaStream should not contribute anything to its playout element, so the playout element should be the one deciding what to do. Good point.

Yeah. Actua= lly video elements normally keep showing the last frame when they end, so w= e'll want a way to support that too.

The way it's currently writte= n, "finished" is permanent, but "disabled" is changeable.

&quo= t;finished" =3D=3D "ended", right? :-)

OK, I will try to write the ProcessedMediaStr= eam spec so that "ended" is a permanent state. This means that wh= en you get a MediaStream for an HTML media element, the MediaStream will ha= ve to be tied to the currently playing media resource, and when playback en= ds that MediaStream will become inactive and a new MediaStream generated if= the author seeks the media resource and starts playing it again, or loads = a new media resource.

Rob
--
"If we claim to be without sin, we deceive ourselves= and the truth is not in us. If we confess our sins, he is faithful and jus= t and will forgive us our sins and purify us from all unrighteousness. If w= e claim we have not sinned, we make him out to be a liar and his word is no= t in us." [1 John 1:8-10]
--0015174c1a1c7976f004b0144761-- From jonathan@vidyo.com Mon Oct 24 18:01: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 DD43B11E808C for ; Mon, 24 Oct 2011 18:01:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[AWL=0.427, 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 EG56UyRRuU4a for ; Mon, 24 Oct 2011 18:01:55 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id 52BD311E8083 for ; Mon, 24 Oct 2011 18:01:55 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 9F7AC553560 for ; Mon, 24 Oct 2011 21:01:54 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB012.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 2CD3955352A for ; Mon, 24 Oct 2011 21:01:54 -0400 (EDT) Received: from BE235.mail.lan ([10.110.32.235]) by HUB012.mail.lan ([10.110.17.12]) with mapi; Mon, 24 Oct 2011 21:01:47 -0400 From: Jonathan Lennox To: "rtcweb@ietf.org" Date: Mon, 24 Oct 2011 21:01:51 -0400 Thread-Topic: I-D Action: draft-lennox-rtcweb-rtp-media-type-mux-00.txt Thread-Index: AcySsaYJEwYOt8fTRnO+b237+nttlA== Message-ID: References: <20111024232740.11885.97235.idtracker@ietfa.amsl.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 Subject: [rtcweb] Fwd: I-D Action: draft-lennox-rtcweb-rtp-media-type-mux-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 01:01:56 -0000 Hello all -- Jonathan Rosenberg and I have written a draft (as promised at the Qu=E9bec = IETF) describing RTP-level procedures for multiplexing multiple media types= into a single RTP session. Comments are welcome. Begin forwarded message: > From: "internet-drafts@ietf.org" > Date: October 24, 2011 7:27:40 PM EDT > To: "i-d-announce@ietf.org" > Subject: I-D Action: draft-lennox-rtcweb-rtp-media-type-mux-00.txt > Reply-To: "internet-drafts@ietf.org" >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. >=20 > Title : Multiplexing Multiple Media Types In a Single Real-Tim= e Transport Protocol (RTP) Session > Author(s) : Jonathan Lennox > Jonathan Rosenberg > Filename : draft-lennox-rtcweb-rtp-media-type-mux-00.txt > Pages : 11 > Date : 2011-10-24 >=20 > This document describes mechanisms and recommended practice for > transmitting media streams of multiple media types (e.g., audio and > video) over a single Real-Time Transport Protocol (RTP) session, > primarily for the use of Real-Time Communication for the Web > (rtcweb). >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-lennox-rtcweb-rtp-media-type-mu= x-00.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-lennox-rtcweb-rtp-media-type-mux= -00.txt > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 -- Jonathan Lennox jonathan@vidyo.com From harald@alvestrand.no Mon Oct 24 18:13: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 3D6B211E81DF for ; Mon, 24 Oct 2011 18:13:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.599 X-Spam-Level: X-Spam-Status: No, score=-109.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_BACKHAIR_27=1, 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 Ah32sqr2GGFN for ; Mon, 24 Oct 2011 18:13:19 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id DA84A21F8CF1 for ; Mon, 24 Oct 2011 18:13:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D79C539E0F0; Tue, 25 Oct 2011 03:13: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 oYMsLmcqRNrp; Tue, 25 Oct 2011 03:13:17 +0200 (CEST) Received: from [172.19.28.23] (216-239-45-4.google.com [216.239.45.4]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 354F539E0A7; Tue, 25 Oct 2011 03:13:16 +0200 (CEST) Message-ID: <4EA60D2A.9060101@alvestrand.no> Date: Mon, 24 Oct 2011 18:13:14 -0700 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: Cullen Jennings References: <42322A10-14A7-4600-820D-7612A1B12592@cisco.com> <3747C7CB-C039-4D15-A46C-8FDB9A47AF3A@acmepacket.com> <1107BC89-1AB6-47F7-970A-BCF25955D1E0@cisco.com> In-Reply-To: <1107BC89-1AB6-47F7-970A-BCF25955D1E0@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" , Adrian Georgescu , "public-webrtc@w3.org" Subject: Re: [rtcweb] RTCWeb Terminology X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 01:13:20 -0000 Google's been using "WebRTC" (capitalized as such) for their opensource implementation of the technologies involved too. On 10/24/2011 10:18 AM, Cullen Jennings wrote: > +1 > > On Oct 24, 2011, at 11:01 AM, Adrian Georgescu wrote: > >> WebRTC sounds great! >> >> Adrian >> >> On Oct 24, 2011, at 6:56 PM, Hadriel Kaplan wrote: >> >>> On Oct 24, 2011, at 11:03 AM, Cullen Jennings wrote: >>> >>>> I don't think there is an answer to this yet so I guess we need to figure it out. I'm ore concerned about the long term explanation to people outside W3C or IETF. Hadriel, with you marketing hat on, you have any suggestions of what we should call the whole thing? >>> Web 4.0. ;) >>> >>> I asked a couple other folks and the consensus seems to be: "WebRTC" for the whole thing. >>> >>> The rationale is that it's still the Web but with native real-time-communication support, as opposed to real-time-communication but with web support. For example if you wrote a book about how to write Web-apps for it, you would probably use the term "WebRTC" in the book title. Another rationale was that it follows the naming scheme for WebM and WebP. >>> >>> For the API, the consensus was it would be confusing to people if we weren't consistent with W3C docs. >>> >>> So I propose the following: >>> >>> WebRTC: the whole shebang >>> WebRTC API: the JS<->Browser API. >>> >>> -hadriel >>> p.s. personally I've gotten used to the term "RTCWeb", but it may be because of my IETF focus rather than W3C/Web focus. >>> >>> > > From rocallahan@gmail.com Mon Oct 24 18:29: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 081F611E8213 for ; Mon, 24 Oct 2011 18:29:09 -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 VPcBv1MtPhv4 for ; Mon, 24 Oct 2011 18:29:08 -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 0500C11E81DF for ; Mon, 24 Oct 2011 18:29:07 -0700 (PDT) Received: by wwe6 with SMTP id 6so6934866wwe.13 for ; Mon, 24 Oct 2011 18:29:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:reply-to:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=jCRkDbJHWM+LH4zKEwfx/rOJQHt807ovyF4kF1Lh3gc=; b=bgiRAf9E7DcZbpZzB6wr9HgAnlOLLsW50XXeKb7hQHy7Jx2Xe2o9iantj7C2nc7LZC i28ZRGWRPYZlGBuZs/MtUAOjCzHdAR/1XbeJnsXhB0c7wu6FfjUpArW9TymdJBCM1xow ZahOU4e91ARALFYw+lk7hifMTokQDa1/X71j4= MIME-Version: 1.0 Received: by 10.227.205.20 with SMTP id fo20mr347795wbb.20.1319506147137; Mon, 24 Oct 2011 18:29:07 -0700 (PDT) Sender: rocallahan@gmail.com Received: by 10.227.136.73 with HTTP; Mon, 24 Oct 2011 18:29:07 -0700 (PDT) In-Reply-To: References: <4EA27FEE.4060804@alvestrand.no> Date: Tue, 25 Oct 2011 14:29:07 +1300 X-Google-Sender-Auth: ire8Tu4vWJj15fDU6MBrGeQH0Hs Message-ID: From: "Robert O'Callahan" To: "public-webrtc@w3.org" Content-Type: multipart/alternative; boundary=0015174c462e2ddaa904b015775a Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] a couple of comments on the latest API draft X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@ocallahan.org List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 01:29:09 -0000 --0015174c462e2ddaa904b015775a Content-Type: text/plain; charset=UTF-8 On Tue, Oct 25, 2011 at 1:04 PM, Robert O'Callahan wrote: > On Sat, Oct 22, 2011 at 9:33 PM, Harald Alvestrand wrote: > > The way it's currently written, "finished" is permanent, but "disabled" is >> changeable. >> > > "finished" == "ended", right? :-) > Actually, since it's already well-established that "ended" on media elements is not permanent --- you can seek or reload the resource --- I think it would reduce confusion to use the term "finished" for the permanent MediaStream state, instead of "ended". Including in the API names. Can we do that? OK, I will try to write the ProcessedMediaStream spec so that "ended" is a > permanent state. This means that when you get a MediaStream for an HTML > media element, the MediaStream will have to be tied to the currently playing > media resource, and when playback ends that MediaStream will become inactive > and a new MediaStream generated if the author seeks the media resource and > starts playing it again, or loads a new media resource. At this stage it looks like we'll just make the stream emitted by a media element never end ... and maybe we'll add an finish() API to force a MediaStream to end permanently. Rob -- "If we claim to be without sin, we deceive ourselves and the truth is not in us. If we confess our sins, he is faithful and just and will forgive us our sins and purify us from all unrighteousness. If we claim we have not sinned, we make him out to be a liar and his word is not in us." [1 John 1:8-10] --0015174c462e2ddaa904b015775a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Oct 25, 2011 at 1:04 PM, Robert O'Callahan &l= t;robert@ocallahan.org> wrote:
On Sat, Oct 22, 2011 at 9:33 PM, Harald Alvestrand <h= arald@alvestrand.no> wrote:

The way it's currently writte= n, "finished" is permanent, but "disabled" is changeable.
"finished" =3D=3D "ended", right? :-)

Actually, since it's already well-est= ablished that "ended" on media elements is not permanent --- you = can seek or reload the resource --- I think it would reduce confusion to us= e the term "finished" for the permanent MediaStream state, instea= d of "ended". Including in the API names. Can we do that?

OK, I w= ill try to write the ProcessedMediaStream spec so that "ended" is= a permanent state. This means that when you get a MediaStream for an HTML = media element, the MediaStream will have to be tied to the currently playin= g media resource, and when playback ends that MediaStream will become inact= ive and a new MediaStream generated if the author seeks the media resource = and starts playing it again, or loads a new media resource.

At this stage it looks like we'll just make the stream emitted= by a media element never end ... and maybe we'll add an finish() API t= o force a MediaStream to end permanently.

Rob
--
"If we claim to be without sin, we deceive ourselves and= the truth is not in us. If we confess our sins, he is faithful and just an= d will forgive us our sins and purify us from all unrighteousness. If we cl= aim we have not sinned, we make him out to be a liar and his word is not in= us." [1 John 1:8-10]
--0015174c462e2ddaa904b015775a-- From pravindran@sonusnet.com Mon Oct 24 21:34: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 61F7311E80F6 for ; Mon, 24 Oct 2011 21:34:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.246 X-Spam-Level: X-Spam-Status: No, score=-2.246 tagged_above=-999 required=5 tests=[AWL=-0.647, BAYES_00=-2.599, J_BACKHAIR_27=1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g4aPQTfl5gNk for ; Mon, 24 Oct 2011 21:34:58 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id CD01911E80F4 for ; Mon, 24 Oct 2011 21:34: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 p9P4Yf95009713; Tue, 25 Oct 2011 00:34:41 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail06.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 25 Oct 2011 00:34:06 -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, 25 Oct 2011 10:04:03 +0530 Message-ID: <2E239D6FCD033C4BAF15F386A979BF51159C2A@sonusinmail02.sonusnet.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] RTCWeb Terminology thread-index: AcySkX5DGBiUaI2rTVGnscZr8DOrgwAPc/7w References: <42322A10-14A7-4600-820D-7612A1B12592@cisco.com> <3747C7CB-C039-4D15-A46C-8FDB9A47AF3A@acmepacket.com> From: "Ravindran Parthasarathi" To: "Adrian Georgescu" , "Hadriel Kaplan" X-OriginalArrivalTime: 25 Oct 2011 04:34:06.0048 (UTC) FILETIME=[54804600:01CC92CF] Cc: rtcweb@ietf.org, public-webrtc@w3.org Subject: Re: [rtcweb] RTCWeb Terminology X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 04:34:58 -0000 +1 >-----Original Message----- >From: public-webrtc-request@w3.org [mailto:public-webrtc-request@w3.org] >On Behalf Of Adrian Georgescu >Sent: Monday, October 24, 2011 10:31 PM >To: Hadriel Kaplan >Cc: Cullen Jennings; rtcweb@ietf.org; public-webrtc@w3.org >Subject: Re: [rtcweb] RTCWeb Terminology > >WebRTC sounds great! > >Adrian > >On Oct 24, 2011, at 6:56 PM, Hadriel Kaplan wrote: > >> >> On Oct 24, 2011, at 11:03 AM, Cullen Jennings wrote: >> >>> >>> I don't think there is an answer to this yet so I guess we need to >figure it out. I'm ore concerned about the long term explanation to >people outside W3C or IETF. Hadriel, with you marketing hat on, you have >any suggestions of what we should call the whole thing? >> >> Web 4.0. ;) >> >> I asked a couple other folks and the consensus seems to be: "WebRTC" >for the whole thing. >> >> The rationale is that it's still the Web but with native real-time- >communication support, as opposed to real-time-communication but with >web support. For example if you wrote a book about how to write Web- >apps for it, you would probably use the term "WebRTC" in the book title. >Another rationale was that it follows the naming scheme for WebM and >WebP. >> >> For the API, the consensus was it would be confusing to people if we >weren't consistent with W3C docs. >> >> So I propose the following: >> >> WebRTC: the whole shebang >> WebRTC API: the JS<->Browser API. >> >> -hadriel >> p.s. personally I've gotten used to the term "RTCWeb", but it may be >because of my IETF focus rather than W3C/Web focus. >> >> > > From pravindran@sonusnet.com Mon Oct 24 21:57: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 A862F11E80DB for ; Mon, 24 Oct 2011 21:57:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.725 X-Spam-Level: X-Spam-Status: No, score=-2.725 tagged_above=-999 required=5 tests=[AWL=-0.126, 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 eTSWuygnqWic for ; Mon, 24 Oct 2011 21:57:15 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id D305C11E80BC for ; Mon, 24 Oct 2011 21:57:14 -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 p9P4vm02024702; Tue, 25 Oct 2011 00:57:48 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail07.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 25 Oct 2011 00:56:39 -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, 25 Oct 2011 10:26:38 +0530 Message-ID: <2E239D6FCD033C4BAF15F386A979BF51159C32@sonusinmail02.sonusnet.com> In-Reply-To: <6EB8679A-13D5-4AD7-97F2-BC35FC0966F0@acmepacket.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] draft-kaplan-rtcweb-sip-interworking-requirements-00 thread-index: AQHMkqTg+ZnmTyb6QUGCzFAZ7bjkHJWMed4w References: <20111024224257.28459.65554.idtracker@ietfa.amsl.com> <6EB8679A-13D5-4AD7-97F2-BC35FC0966F0@acmepacket.com> From: "Ravindran Parthasarathi" To: "Hadriel Kaplan" , X-OriginalArrivalTime: 25 Oct 2011 04:56:39.0789 (UTC) FILETIME=[7B64C1D0:01CC92D2] Subject: Re: [rtcweb] draft-kaplan-rtcweb-sip-interworking-requirements-00 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 04:57:15 -0000 Hadriel, It is nice to see the discussion on Federation protocol for WebRTC (RTCWeb). I agree that the high level architecture will be same as you projected in your draft. Even in case ROAP is accepted as standard interface, there will be no change in the architecture. But I'm not in agreement with the requirement in Sec 6 and Sec 7 of your document because it influence the specific implementation.=20 I'll take A1-1 requirement of SIP forking wherein it is very much possible for RTCWEB-SIP gateway to hide the forking functionality from browser and it is normal B2BUA (SBC in market term) functionality in SIP wherein originating SIP UA does not support forking properly. IOW, please don't add requirement in RTCWeb for the sake SIP interop and it is possible to design the better gateway if required. I'm looking for standard RTCWeb signaling protocol like ROAP by which better solution for RTCWeb-federation gateway is documented in IETF. Also, I'm interested in hearing about other RTCWeb federation protocol like Jingle before doing the deep-dive into the requirement because my gut feeling is that we will end-up in multiple federation protocol rather than single. Thanks Partha=20 >-----Original Message----- >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf >Of Hadriel Kaplan >Sent: Tuesday, October 25, 2011 5:00 AM >To: rtcweb@ietf.org >Subject: [rtcweb] draft-kaplan-rtcweb-sip-interworking-requirements-00 > >Howdy, >I've submitted a draft listing some use-cases and resulting requirements >for interworking from RTCWeb (or "WebRTC" as the case may be), to >deployed SIP domains/devices. >The draft also discusses the functions which may be required in an >interworking device, should some of the requirements not be met. > >The purpose of the draft is to put pen-to-paper on some of the emails >flying around the past month, to stimulate discussion, and hopefully >drive consensus decisions sooner rather than later. >Info below. > >Note that most of the doc is about media-plane issues, rather than about >SIP/SDP as I expect Cullen's soon-to-be-announced ROAP signaling-gateway >draft will be. > >-hadriel > > >Begin forwarded message: > >> From: >> Subject: I-D Action: draft-kaplan-rtcweb-sip-interworking- >requirements-00.txt >> Date: October 24, 2011 6:42:57 PM EDT >> To: >> Reply-To: >> >> A New Internet-Draft is available from the on-line Internet-Drafts >directories. >> >> Title : Requirements for Interworking RTCWeb with >Current SIP Deployments >> Author(s) : Hadriel Kaplan >> Filename : draft-kaplan-rtcweb-sip-interworking- >requirements-00.txt >> Pages : 22 >> Date : 2011-10-24 >> >> The IETF RTCWEB WG has been discussing how to interwork with >> deployed SIP equipment and domains. Doing so may require an >> Interworking Function middlebox in the media-plane. This document >> lists some RTCWeb-to-SIP use-cases, the RTCWeb requirements to >> support such, and the complexity involved in interworking if the >> requirements cannot be met. >> >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-kaplan-rtcweb-sip- >interworking-requirements-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-kaplan-rtcweb-sip- >interworking-requirements-00.txt >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb From pravindran@sonusnet.com Mon Oct 24 23:11: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 EF65E21F8AA9 for ; Mon, 24 Oct 2011 23:11:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.722 X-Spam-Level: X-Spam-Status: No, score=-2.722 tagged_above=-999 required=5 tests=[AWL=-0.123, 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 L+4EpPhqMY-Z for ; Mon, 24 Oct 2011 23:11:05 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id F204721F8AA8 for ; Mon, 24 Oct 2011 23:11:04 -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 p9P6BbRj008162; Tue, 25 Oct 2011 02:11:37 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail04.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 25 Oct 2011 02:06:54 -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, 25 Oct 2011 11:36:52 +0530 Message-ID: <2E239D6FCD033C4BAF15F386A979BF51159C4A@sonusinmail02.sonusnet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] draft-kaplan-rtcweb-sip-interworking-requirements-00 thread-index: AQHMkqTg+ZnmTyb6QUGCzFAZ7bjkHJWMed4wgAAYQSA= References: <20111024224257.28459.65554.idtracker@ietfa.amsl.com> <6EB8679A-13D5-4AD7-97F2-BC35FC0966F0@acmepacket.com> From: "Ravindran Parthasarathi" To: "Hadriel Kaplan" , X-OriginalArrivalTime: 25 Oct 2011 06:06:54.0214 (UTC) FILETIME=[4B62FA60:01CC92DC] Subject: Re: [rtcweb] draft-kaplan-rtcweb-sip-interworking-requirements-00 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 06:11:06 -0000 Just adding one more point regarding architecture, Media plane interworking function is an optional element for the next generation (release) of SIP devices wherein Media agent of SIP UA will be able to interop directly with browser media plane without intermediate media-plane gateways. Thanks Partha >-----Original Message----- >From: Ravindran Parthasarathi >Sent: Tuesday, October 25, 2011 10:27 AM >To: 'Hadriel Kaplan'; rtcweb@ietf.org >Subject: RE: [rtcweb] draft-kaplan-rtcweb-sip-interworking-requirements- >00 > >Hadriel, > >It is nice to see the discussion on Federation protocol for WebRTC >(RTCWeb). I agree that the high level architecture will be same as you >projected in your draft. Even in case ROAP is accepted as standard >interface, there will be no change in the architecture. But I'm not in >agreement with the requirement in Sec 6 and Sec 7 of your document >because it influence the specific implementation. > >I'll take A1-1 requirement of SIP forking wherein it is very much >possible for RTCWEB-SIP gateway to hide the forking functionality from >browser and it is normal B2BUA (SBC in market term) functionality in SIP >wherein originating SIP UA does not support forking properly. IOW, >please don't add requirement in RTCWeb for the sake SIP interop and it >is possible to design the better gateway if required. I'm looking for >standard RTCWeb signaling protocol like ROAP by which better solution >for RTCWeb-federation gateway is documented in IETF. > >Also, I'm interested in hearing about other RTCWeb federation protocol >like Jingle before doing the deep-dive into the requirement because my >gut feeling is that we will end-up in multiple federation protocol >rather than single. > >Thanks >Partha > >>-----Original Message----- >>From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >Behalf >>Of Hadriel Kaplan >>Sent: Tuesday, October 25, 2011 5:00 AM >>To: rtcweb@ietf.org >>Subject: [rtcweb] draft-kaplan-rtcweb-sip-interworking-requirements-00 >> >>Howdy, >>I've submitted a draft listing some use-cases and resulting >requirements >>for interworking from RTCWeb (or "WebRTC" as the case may be), to >>deployed SIP domains/devices. >>The draft also discusses the functions which may be required in an >>interworking device, should some of the requirements not be met. >> >>The purpose of the draft is to put pen-to-paper on some of the emails >>flying around the past month, to stimulate discussion, and hopefully >>drive consensus decisions sooner rather than later. >>Info below. >> >>Note that most of the doc is about media-plane issues, rather than >about >>SIP/SDP as I expect Cullen's soon-to-be-announced ROAP signaling- >gateway >>draft will be. >> >>-hadriel >> >> >>Begin forwarded message: >> >>> From: >>> Subject: I-D Action: draft-kaplan-rtcweb-sip-interworking- >>requirements-00.txt >>> Date: October 24, 2011 6:42:57 PM EDT >>> To: >>> Reply-To: >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>directories. >>> >>> Title : Requirements for Interworking RTCWeb with >>Current SIP Deployments >>> Author(s) : Hadriel Kaplan >>> Filename : draft-kaplan-rtcweb-sip-interworking- >>requirements-00.txt >>> Pages : 22 >>> Date : 2011-10-24 >>> >>> The IETF RTCWEB WG has been discussing how to interwork with >>> deployed SIP equipment and domains. Doing so may require an >>> Interworking Function middlebox in the media-plane. This document >>> lists some RTCWeb-to-SIP use-cases, the RTCWeb requirements to >>> support such, and the complexity involved in interworking if the >>> requirements cannot be met. >>> >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-kaplan-rtcweb-sip- >>interworking-requirements-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-kaplan-rtcweb-sip- >>interworking-requirements-00.txt >>> _______________________________________________ >>> I-D-Announce mailing list >>> I-D-Announce@ietf.org >>> https://www.ietf.org/mailman/listinfo/i-d-announce >>> Internet-Draft directories: http://www.ietf.org/shadow.html >>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >>_______________________________________________ >>rtcweb mailing list >>rtcweb@ietf.org >>https://www.ietf.org/mailman/listinfo/rtcweb From HKaplan@acmepacket.com Mon Oct 24 23: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 4921511E8086 for ; Mon, 24 Oct 2011 23:33:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.432 X-Spam-Level: X-Spam-Status: No, score=-2.432 tagged_above=-999 required=5 tests=[AWL=0.167, 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 TsnFxmHUBxlS for ; Mon, 24 Oct 2011 23:33:08 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id BED9F11E8073 for ; Mon, 24 Oct 2011 23:33: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; Tue, 25 Oct 2011 02:33:07 -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; Tue, 25 Oct 2011 02:33:07 -0400 From: Hadriel Kaplan To: Ravindran Parthasarathi Thread-Topic: [rtcweb] draft-kaplan-rtcweb-sip-interworking-requirements-00 Thread-Index: AQHMkt/0LiaBls1gvU+ybY3yKJ2ohw== Date: Tue, 25 Oct 2011 06:33:05 +0000 Message-ID: <1788B702-7D48-48A1-9F37-A05AB0CFD149@acmepacket.com> References: <20111024224257.28459.65554.idtracker@ietfa.amsl.com> <6EB8679A-13D5-4AD7-97F2-BC35FC0966F0@acmepacket.com> <2E239D6FCD033C4BAF15F386A979BF51159C32@sonusinmail02.sonusnet.com> In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF51159C32@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: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [rtcweb] draft-kaplan-rtcweb-sip-interworking-requirements-00 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 06:33:11 -0000 Partha, comments inline... On Oct 25, 2011, at 12:56 AM, Ravindran Parthasarathi wrote: > But I'm not in > agreement with the requirement in Sec 6 and Sec 7 of your document > because it influence the specific implementation.=20 Just to be clear, and the draft is a bit confusing about this: the draft is= n't stating that the RTCWEB Working Group has to comply with all the requir= ements - in fact, I expect some can't be complied with due to security issu= es or IPR issues. It's merely stating what has to be done to avoid needing= an interworking function in the signaling and/or media-planes, for various= common use-cases; and what the complexity is for the different interworkin= g functions should they be needed. There was an expressed desire from some of the WG members that interworking= with deployed SIP devices be possible, with as little complexity as possib= le, and this draft is just stating what that would entail for various use-c= ases. That way we can come to some consensus on what RTCWeb needs to suppo= rt and how. > I'll take A1-1 requirement of SIP forking wherein it is very much > possible for RTCWEB-SIP gateway to hide the forking functionality from > browser and it is normal B2BUA (SBC in market term) functionality in SIP > wherein originating SIP UA does not support forking properly. IOW, > please don't add requirement in RTCWeb for the sake SIP interop and it > is possible to design the better gateway if required. I'm looking for > standard RTCWeb signaling protocol like ROAP by which better solution > for RTCWeb-federation gateway is documented in IETF. Of course an SBC or gateway could do that - an SBC or gateway can do all of= it, obviously, and some already do most of it already today. That's not t= he point. The point is there's complexity involved in the functions, which= translates to cost ultimately, and if we want to keep the complexity down = we need to try to avoid needing to do them, or as many of them as possible/= practical. For example many SBCs can do transcoding, but it costs money an= d potentially impacts call quality, so we should try avoiding that... espec= ially since it's easy to avoid in the G.711 case. (G.711 is trivial to impl= ement and not under IPR, afaik) > Also, I'm interested in hearing about other RTCWeb federation protocol > like Jingle before doing the deep-dive into the requirement because my > gut feeling is that we will end-up in multiple federation protocol > rather than single. The draft isn't suggesting SIP be a mandated "federation" protocol. I don'= t believe we can nor should mandate a federation protocol, nor any protocol= outside of RTCWeb. But SIP is an IETF protocol and quite popular, so this= is just an Informational draft stating what would be needed to do so, to/f= rom deployed SIP domains/devices. Also, I don't use the word "federation" in the draft for a reason: an obvio= us use-case for RTCWeb is one where an Enterprise uses RTCWeb on their Web = servers, for either their employees or for customer pages such as support o= r sales pages, but needs to interwork that to SIP internally to their SIP s= ystems for numerous reasons. Likewise a SIP Service Provider could use RTC= Web as another means of customer universal access, and interface it to SIP = to reach their SIP devices/systems. It's not "federation" - it's just goin= g from RTCWeb to deployed SIP devices/systems, possibly in the same adminis= trative organization/company. -hadriel From HKaplan@acmepacket.com Mon Oct 24 23: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 2301711E80D9 for ; Mon, 24 Oct 2011 23:45:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[AWL=0.164, 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 VGsqLSaT-XHD for ; Mon, 24 Oct 2011 23:45:20 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 8425011E8086 for ; Mon, 24 Oct 2011 23:45: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; Tue, 25 Oct 2011 02:45:19 -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; Tue, 25 Oct 2011 02:45:19 -0400 From: Hadriel Kaplan To: Ravindran Parthasarathi Thread-Topic: [rtcweb] draft-kaplan-rtcweb-sip-interworking-requirements-00 Thread-Index: AQHMkuGo4oKL9jzYW0yCTTm4OInomQ== Date: Tue, 25 Oct 2011 06:45:18 +0000 Message-ID: References: <20111024224257.28459.65554.idtracker@ietfa.amsl.com> <6EB8679A-13D5-4AD7-97F2-BC35FC0966F0@acmepacket.com> <2E239D6FCD033C4BAF15F386A979BF51159C4A@sonusinmail02.sonusnet.com> In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF51159C4A@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: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [rtcweb] draft-kaplan-rtcweb-sip-interworking-requirements-00 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 06:45:21 -0000 On Oct 25, 2011, at 2:06 AM, Ravindran Parthasarathi wrote: > Just adding one more point regarding architecture, Media plane > interworking function is an optional element for the next generation > (release) of SIP devices wherein Media agent of SIP UA will be able to > interop directly with browser media plane without intermediate > media-plane gateways. Do you mean that statement as an argument against the draft? That was why = I kept using the term "deployed" throughout the draft. :) Or did you mean it in the sense of an additional requirement that should be= added to draft? That would make sense and I can add it. Something like: "It MUST be possible to determine whether interworking is required on a ses= sion-by-session basis in order to avoid performing interworking when it is = not needed." Does that capture what you meant? I think that's possible to do for pretty much everything in the draft, exce= pt RTCP generation. (which is possibly the ugliest interworking to have to = do in the whole doc) -hadriel From HKaplan@acmepacket.com Tue Oct 25 01:02: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 E48C121F8AEA for ; Tue, 25 Oct 2011 01:02:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[AWL=0.159, 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 Yn-bdBd+3JNu for ; Tue, 25 Oct 2011 01:02:49 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 4897121F8AE9 for ; Tue, 25 Oct 2011 01:02: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; Tue, 25 Oct 2011 04:02:48 -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; Tue, 25 Oct 2011 04:02:48 -0400 From: Hadriel Kaplan To: Randell Jesup Thread-Topic: [rtcweb] draft-jesup-rtcweb-data-00 posted Thread-Index: AQHMkux7p3eML1qZxUCx8kT0lNDE/g== Date: Tue, 25 Oct 2011 08:02:47 +0000 Message-ID: References: <4EA5EA46.1010803@jesup.org> In-Reply-To: <4EA5EA46.1010803@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: <7D336C06A696F04994A4A5AD6FCD8F9D@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] draft-jesup-rtcweb-data-00 posted X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 08:02:50 -0000 Hi Randell, What do you think about the following additional requirements: Req. 7: Data streams MUST provide fragmentation at a layer above UDP, such = that IP-layer fragmentation does not occur no matter how large a message/bu= ffer the Javascript application passes down to the Browser to be sent out. Req. 8: The data stream transport protocol MUST NOT encode IP addresses ins= ide its protocol fields; doing so reveals potentially private information, = and leads to failure if the address is depended upon.=20 Req. 9: The data stream protocol SHOULD support unbounded-length "messages"= (i.e., a virtual socket stream) at the application layer, for such things = as image-file-transfer; or else it MUST support at least a maximum applicat= ion-layer message size of 4GB. Req. 10: The data stream packet format/encoding MUST be such that it is imp= ossible for a malicious Javascript to generate an application message craft= ed such that it could be interpreted as a native protocol over UDP - such a= s UPnP, RTP, SNMP, STUN, etc.=20 I believe SCTP can do 7+8+9 the above if its options are chosen right, and = of course TCP can. And I'm guessing DTLS will satisfy 10 above, as would websockets-style mask= ing. -hadriel On Oct 24, 2011, at 6:44 PM, Randell Jesup wrote: > A new version of I-D, draft-jesup-rtcweb-data-00.txt has been successfull= y submitted by Randell Jesup and posted to the IETF repository. >=20 > Filename: draft-jesup-rtcweb-data > Revision: 00 > Title: RTCWeb Datagram Connection > Creation date: 2011-10-25 > WG ID: Individual Submission > Number of pages: 11 >=20 > Abstract: > This document investigates the possibilities for designing a generic > transport service that allows Web Browser to exchange generic data in > a peer to peer way. Different transport protocols and their > properties are investigated in order to identify the most appropriate > one. >=20 >=20 > URL: http://www.ietf.org/id/draft-jesup-rtcweb-data-00.txt >=20 > --=20 > Randell Jesup > randell-ietf@jesup.org > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From ibc@aliax.net Tue Oct 25 01: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 88E4121F8C04 for ; Tue, 25 Oct 2011 01:39:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.638 X-Spam-Level: X-Spam-Status: No, score=-2.638 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DytTklU6F-cz for ; Tue, 25 Oct 2011 01:39:14 -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 DE29F21F8C00 for ; Tue, 25 Oct 2011 01:39:13 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so226889vcb.31 for ; Tue, 25 Oct 2011 01:39:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.30.79 with SMTP id q15mr26336117vdh.111.1319531953108; Tue, 25 Oct 2011 01:39:13 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Tue, 25 Oct 2011 01:39:13 -0700 (PDT) In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF51159C32@sonusinmail02.sonusnet.com> References: <20111024224257.28459.65554.idtracker@ietfa.amsl.com> <6EB8679A-13D5-4AD7-97F2-BC35FC0966F0@acmepacket.com> <2E239D6FCD033C4BAF15F386A979BF51159C32@sonusinmail02.sonusnet.com> Date: Tue, 25 Oct 2011 10:39:13 +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-kaplan-rtcweb-sip-interworking-requirements-00 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 08:39:14 -0000 2011/10/25 Ravindran Parthasarathi : > I'll take A1-1 requirement of SIP forking wherein it is very much > possible for RTCWEB-SIP gateway to hide the forking functionality from > browser and it is normal B2BUA (SBC in market term) functionality in SIP > wherein originating SIP UA does not support forking properly. IOW, > please don't add requirement in RTCWeb for the sake SIP interop and it > is possible to design the better gateway if required. Please take into account that some of us also desire to interoperate with SIP but we *don't* need a B2BUA/SBC neither a protocol gateway for such interconnection (instead we are using *now* a SIP proxy implementing SIP over WebSocket so the JavaScript application becomes a real SIP UA). Having said that, SIP forking is a *feature* rather than a punishment. It adds complexity of course, but still it's an useful feature. Some of us want to deal with that complexity at UA level (JavaScript). Some others would prefer not to allow forking in their RTC-Web scenarios so have no need to deal with forking. Let's the people choose it. > I'm looking for > standard RTCWeb signaling protocol like ROAP by which better solution > for RTCWeb-federation gateway is documented in IETF. Yes, you want to mandate some specific in-the-wire signaling protocol in RTCweb and force me, and others, to use a RTCWeb-SIP gateway box (regardless I already have my RTCweb solution ready to interop with a SIP network in the signaling plane without using protocol gateways). I would ask you to read this draft in which different RTCweb scenarios are described: http://tools.ietf.org/html/draft-sipdoc-rtcweb-open-wire-protocol-00 > Also, I'm interested in hearing about other RTCWeb federation protocol > like Jingle before doing the deep-dive into the requirement because my > gut feeling is that we will end-up in multiple federation protocol > rather than single. I hope that we will end with *no one* federation protocol so each website can decide what to use in case it wants to federate with other website. Web will decide, as it always does. The important point here is to leave the Web the freedom to choose whichever federation mechanism. Some mechanism/protocol will success more than others and will become de facto RTCweb federation protocol in the Web. This is how things work in the Web. Regards. --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Tue Oct 25 02:50:37 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CA8021F8C5A for ; Tue, 25 Oct 2011 02:50:37 -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 MqkXWN74pwjl for ; Tue, 25 Oct 2011 02:50:36 -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 76D6321F8C59 for ; Tue, 25 Oct 2011 02:50:36 -0700 (PDT) Received: by vws5 with SMTP id 5so284407vws.31 for ; Tue, 25 Oct 2011 02:50:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.114.232 with SMTP id jj8mr26591870vdb.94.1319536204284; Tue, 25 Oct 2011 02:50:04 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Tue, 25 Oct 2011 02:50:04 -0700 (PDT) In-Reply-To: <6EB8679A-13D5-4AD7-97F2-BC35FC0966F0@acmepacket.com> References: <20111024224257.28459.65554.idtracker@ietfa.amsl.com> <6EB8679A-13D5-4AD7-97F2-BC35FC0966F0@acmepacket.com> Date: Tue, 25 Oct 2011 11:50:04 +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: "rtcweb@ietf.org" Subject: Re: [rtcweb] draft-kaplan-rtcweb-sip-interworking-requirements-00 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 09:50:37 -0000 2011/10/25 Hadriel Kaplan : > I've submitted a draft listing some use-cases and resulting requirements = for interworking from RTCWeb (or "WebRTC" as the case may be), to deployed = SIP domains/devices. I think this draft is useful, but IMHO this WG is becoming too much oriented to "interoperability with SIP", even worse, "interoperability with *already* existing SIP domains" (those that don't implement security at all given the fact that most of the SIP deployments run in private or trusted networks). I expect that 99% of websites interested in offering RTCweb capabilities won't be interested (or won't need) interoperability with a SIP network neither inter-federation with other RTCweb "domains". IMHO RTCweb should focus on making easy the RTCweb adoption by those 99% of websites. Interoperability with SIP is important, but IMHO it should not be the main purpose of RTCweb. Having said that, more participation of Web folks in this WG would be nice. Probably they cannot help in technical RTC subjects by they can give us a real vision of what is needed in the current Web model (just my opinion). > The draft also discusses the functions which may be required in an interw= orking device, should some of the requirements not be met. Let me a question about section 4.2.2: ---------------------------- 4.2.2 =C2=A0 =C2=A0 SRTP Termination=C2=A0=C2=A0 =C2=A0[...]=C2=A0 =C2=A0It= should be noted that if SRTP is required to be used for every=C2=A0=C2=A0 =C2=A0call by RTCWeb but the [= SDES] key exchange model cannot be used on=C2=A0=C2=A0 =C2=A0the RTCWeb side, then th= e Interworking Function likely has to=C2=A0=C2=A0 =C2=A0terminate SRTP from R= TCWeb even if the SIP-domain supports SRTP,=C2=A0=C2=A0 =C2=A0because [SDES] is the mo= st commonly used form of key exchange in SIP today.------------------------------ I was not aware of such limitation. Could you please point me to some draft or mail thread in which that limitation (SDES key exchange model cannot be used on=C2=A0the RTCWeb side) is explained? Thanks a lot. --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Tue Oct 25 02:56: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 1E4D121F8B2B for ; Tue, 25 Oct 2011 02:56:03 -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 LxEogGm8wm92 for ; Tue, 25 Oct 2011 02:56:02 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8D99521F8B2A for ; Tue, 25 Oct 2011 02:56:02 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so287896vcb.31 for ; Tue, 25 Oct 2011 02:56:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.114.232 with SMTP id jj8mr26615760vdb.94.1319536561857; Tue, 25 Oct 2011 02:56:01 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Tue, 25 Oct 2011 02:56:01 -0700 (PDT) In-Reply-To: References: <20111024224257.28459.65554.idtracker@ietfa.amsl.com> <6EB8679A-13D5-4AD7-97F2-BC35FC0966F0@acmepacket.com> Date: Tue, 25 Oct 2011 11:56:01 +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: "rtcweb@ietf.org" Subject: Re: [rtcweb] draft-kaplan-rtcweb-sip-interworking-requirements-00 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 09:56:03 -0000 2011/10/25 I=C3=B1aki Baz Castillo : > Having said that, more participation of Web folks in this WG would be > nice. Probably they cannot help in technical RTC subjects by they can > give us a real vision of what is needed in the current Web model (just > my opinion). Sorry: s/by they can/but they can/ --=20 I=C3=B1aki Baz Castillo From ekr@rtfm.com Tue Oct 25 07:20: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 B65D721F84CE for ; Tue, 25 Oct 2011 07:20:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.965 X-Spam-Level: X-Spam-Status: No, score=-102.965 tagged_above=-999 required=5 tests=[AWL=0.012, 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 mAkbeOLooz5Z for ; Tue, 25 Oct 2011 07:20:58 -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 223F421F84CD for ; Tue, 25 Oct 2011 07:20:58 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so592976vcb.31 for ; Tue, 25 Oct 2011 07:20:57 -0700 (PDT) Received: by 10.52.175.165 with SMTP id cb5mr27802569vdc.47.1319552457604; Tue, 25 Oct 2011 07:20:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.161.20 with HTTP; Tue, 25 Oct 2011 07:20:17 -0700 (PDT) In-Reply-To: References: <4EA5EA46.1010803@jesup.org> From: Eric Rescorla Date: Tue, 25 Oct 2011 07:20:17 -0700 Message-ID: To: Hadriel Kaplan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Randell Jesup , "rtcweb@ietf.org" Subject: Re: [rtcweb] draft-jesup-rtcweb-data-00 posted X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 14:20:58 -0000 On Tue, Oct 25, 2011 at 1:02 AM, Hadriel Kaplan wr= ote: > > Hi Randell, > What do you think about the following additional requirements: > > Req. 7: Data streams MUST provide fragmentation at a layer above UDP, suc= h that IP-layer fragmentation does not occur no matter how large a message/= buffer the Javascript application passes down to the Browser to be sent out= . > > Req. 8: The data stream transport protocol MUST NOT encode IP addresses i= nside its protocol fields; doing so reveals potentially private information= , and leads to failure if the address is depended upon. I don't really understand what this means. In general, the peer has access to your IP address information from ICE. > Req. 9: The data stream protocol SHOULD support unbounded-length "message= s" (i.e., a virtual socket stream) at the application layer, for such thing= s as image-file-transfer; or else it MUST support at least a maximum applic= ation-layer message size of 4GB. > > Req. 10: The data stream packet format/encoding MUST be such that it is i= mpossible for a malicious Javascript to generate an application message cra= fted such that it could be interpreted as a native protocol over UDP - such= as UPnP, RTP, SNMP, STUN, etc. I'm not sure this is really an issue the way you raise it. It's clear that you shouldn't be able to generate messages that appear to be STUN or RTP but that's necessary for demux to work right. However, given that the other side has consented, I don't see that confusion with other protocols being an issue. The kind of intercepting proxies that we found for HTTP don't seem to be a feature of the UDP environment. -Ekr From randell-ietf@jesup.org Tue Oct 25 07:47: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 117F021F8B7E for ; Tue, 25 Oct 2011 07:47:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cBQw5bgmjzvD for ; Tue, 25 Oct 2011 07:47: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 2AD0E21F8B64 for ; Tue, 25 Oct 2011 07:47: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 1RIiI3-0000Fn-Io; Tue, 25 Oct 2011 09:47:43 -0500 Message-ID: <4EA6CAEA.5060906@jesup.org> Date: Tue, 25 Oct 2011 10:42:50 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4EA5EA46.1010803@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: Michael Tuexen Subject: Re: [rtcweb] draft-jesup-rtcweb-data-00 posted X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 14:47:46 -0000 On 10/25/2011 4:02 AM, Hadriel Kaplan wrote: > > Hi Randell, > What do you think about the following additional requirements: > > Req. 7: Data streams MUST provide fragmentation at a layer above UDP, such > that IP-layer fragmentation does not occur no matter how large a message/buffer > the Javascript application passes down to the Browser to be sent out. > > Req. 8: The data stream transport protocol MUST NOT encode IP addresses > inside its protocol fields; doing so reveals potentially private information, > and leads to failure if the address is depended upon. > > Req. 9: The data stream protocol SHOULD support unbounded-length "messages" > (i.e., a virtual socket stream) at the application layer, for such things as > image-file-transfer; or else it MUST support at least a maximum > application-layer message size of 4GB. > > Req. 10: The data stream packet format/encoding MUST be such that it is > impossible for a malicious Javascript to generate an application message > crafted such that it could be interpreted as a native protocol over UDP - > such as UPnP, RTP, SNMP, STUN, etc. Thanks, those look useful. I'm not sure if Req 8 should be reworded to be more explicit (local IP address?) For Req 7, I think that when applied to unreliable data channels, entire fragmented messages must be delivered or none of the fragments delivered to the application. > I believe SCTP can do 7+8+9 the above if its options are chosen right, and of course TCP can. Yes, I believe so - for Req 9, SOCK_STREAM can be used to provide a TCP-like interface to SCTP. Do any of the above only apply to reliable data channels, in particular Req 9? > And I'm guessing DTLS will satisfy 10 above, as would websockets-style masking. Yes. -- Randell Jesup randell-ietf@jesup.org From ted.ietf@gmail.com Tue Oct 25 07:56: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 75A7F21F8B1B for ; Tue, 25 Oct 2011 07:56:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.284 X-Spam-Level: X-Spam-Status: No, score=-3.284 tagged_above=-999 required=5 tests=[AWL=0.314, 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 fpzEsSRLP81u for ; Tue, 25 Oct 2011 07:56:50 -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 D669521F8AF4 for ; Tue, 25 Oct 2011 07:56:49 -0700 (PDT) Received: by gyh20 with SMTP id 20so688043gyh.31 for ; Tue, 25 Oct 2011 07:56:49 -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=gBQSBLdq4VEP1Hq2+7TEc63CDfEo8tCgMgFtY2OUiFU=; b=Vse5BDXsURlaHSnFiGrdZxQD1RASccmiHV39SX3UAn7l0xnCC/aC5sOUcZazSXw3wh orZ7J0bIiHkMbaXp/aXsqg/cbA0WGPD1DvPlbh8Ed4Ocee7Qvi63V5yZ2reJ4Rx6YmJ6 ciIox4NonZK9uFwZLUota8aUHMBmxSqhfZgjc= MIME-Version: 1.0 Received: by 10.236.177.100 with SMTP id c64mr42142289yhm.109.1319554609504; Tue, 25 Oct 2011 07:56:49 -0700 (PDT) Received: by 10.236.105.169 with HTTP; Tue, 25 Oct 2011 07:56:49 -0700 (PDT) In-Reply-To: References: <4EA5EA46.1010803@jesup.org> Date: Tue, 25 Oct 2011 07:56:49 -0700 Message-ID: From: Ted Hardie To: Hadriel Kaplan Content-Type: multipart/alternative; boundary=20cf303f656ac2e39404b020bffc Cc: Randell Jesup , "rtcweb@ietf.org" Subject: Re: [rtcweb] draft-jesup-rtcweb-data-00 posted X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 14:56:50 -0000 --20cf303f656ac2e39404b020bffc Content-Type: text/plain; charset=ISO-8859-1 Hi Hadriel, I'm finding this requirement to be oddly worded: Req. 7: Data streams MUST provide fragmentation at a layer above UDP, such > that IP-layer fragmentation does not occur no matter how large a > message/buffer the Javascript application passes down to the Browser to be > sent out. > > Isn't the issue that the data stream must understand the path MTU and must chunk the data so as to avoid IP fragmentation? If it did not, it could run into IP-layer fragmentation even with a relatively small amount of traffic to send. Why tie that requirement either to a "layer above UDP" (since running this over UDP is not decided) or to the size of the data to be passed? I'm guessing that at the back of this is a requirement like "Please, don't make the downloaded javascript application figure out how to chop up the data to make it pass unmolested over the path". I heartily agree with that, but if I'm understanding you right, that would be: Req. 7: Data streams must avoid IP-layer fragmentation without requiring the Javascript application to restrict the size of messages to be passed over the channel. Does that make sense? regards, Ted --20cf303f656ac2e39404b020bffc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Hadriel,

I'm finding this requirement to be oddly worded:
=

Req. 7: Data streams MUST provide fragmentation at a layer above UDP, such = that IP-layer fragmentation does not occur no matter how large a message/bu= ffer the Javascript application passes down to the Browser to be sent out.<= br>

Isn't the issue that the data stream must und= erstand the path MTU and must chunk the data so as to avoid IP fragmentatio= n?=A0 If it did not, it could run into IP-layer fragmentation even with a r= elatively small amount of traffic to send.=A0 Why tie that requirement eith= er to a "layer above UDP" (since running this over UDP is not dec= ided) or to the size of the data to be passed?

I'm guessing that at the back of this is a requirement like "P= lease, don't make the downloaded javascript application figure out how = to chop up the data to make it pass unmolested over the path".=A0 I he= artily agree with that, but if I'm understanding you right, that would = be:

Req. 7:=A0 Data streams must avoid IP-layer fragmentation without requi= ring the Javascript application to restrict the size of messages to be pass= ed over the channel.

Does that make sense?

regards,

Ted
--20cf303f656ac2e39404b020bffc-- From HKaplan@acmepacket.com Tue Oct 25 08:31: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 77F9D21F8AF4 for ; Tue, 25 Oct 2011 08:31:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.443 X-Spam-Level: X-Spam-Status: No, score=-2.443 tagged_above=-999 required=5 tests=[AWL=0.156, 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 jqWkQCBMX1Ci for ; Tue, 25 Oct 2011 08:31:32 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id BDEC521F8B19 for ; Tue, 25 Oct 2011 08:31: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; Tue, 25 Oct 2011 11:31:30 -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; Tue, 25 Oct 2011 11:31:30 -0400 From: Hadriel Kaplan To: Eric Rescorla Thread-Topic: [rtcweb] draft-jesup-rtcweb-data-00 posted Thread-Index: AQHMkysr+E1fB7NJXkSnRl1LfSuhnQ== Date: Tue, 25 Oct 2011 15:31:30 +0000 Message-ID: References: <4EA5EA46.1010803@jesup.org> 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: <862783F40BEBAF4EAF6B41D5E9B5251F@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: Randell Jesup , "rtcweb@ietf.org" Subject: Re: [rtcweb] draft-jesup-rtcweb-data-00 posted X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 15:31:33 -0000 On Oct 25, 2011, at 10:20 AM, Eric Rescorla wrote: > On Tue, Oct 25, 2011 at 1:02 AM, Hadriel Kaplan = wrote: >>=20 >> Req. 8: The data stream transport protocol MUST NOT encode IP addresses = inside its protocol fields; doing so reveals potentially private informatio= n, and leads to failure if the address is depended upon. >=20 > I don't really understand what this means. In general, the peer has > access to your IP address > information from ICE. >From a privacy perspective: if a person uses a Web-site designed with priva= cy/anonymity in mind (e.g., battered-spouse forum), then the site would rel= ay your media-plane stuff through a type of TURN server that does ICE itsel= f both ways. But if the SCTP layer on top of UDP encodes your local IP usi= ng one of the optional SCTP fields in RFC 4960 or 5061, then you lose that = anonymity. Since the SCTP layer is built into the Browser and not under co= ntrol of the Javascript, a site can't prevent it from revealing that info. >From a failure perspective: if the SCTP layer on top of UDP encodes local o= r remote IP addresses using an SCTP field, presumably it does so for some p= urpose. Since history has shown that relying on embedded IP Addresses for = anything is prone to failure due to the proliferation of NATs, double-NATs,= v4-v6 NATs, etc., then we shouldn't want SCTP to rely on such being useful= . The best way to make sure it can't rely on them, is not to use any to be= gin with. :) >> Req. 10: The data stream packet format/encoding MUST be such that it is = impossible for a malicious Javascript to generate an application message cr= afted such that it could be interpreted as a native protocol over UDP - suc= h as UPnP, RTP, SNMP, STUN, etc. >=20 > I'm not sure this is really an issue the way you raise it. It's clear > that you shouldn't be able to > generate messages that appear to be STUN or RTP but that's necessary > for demux to work > right. Yes I didn't mean to imply it would be hard to satisfy the requirement, or = not necessary for other reasons. I suggested it because some people wanted= to do raw UDP a while ago and this requirement's there to show we can't do= raw UDP. > However, given that the other side has consented, I don't see > that confusion with > other protocols being an issue. The kind of intercepting proxies that > we found for > HTTP don't seem to be a feature of the UDP environment. I don't know that intercepting middleboxes don't exist for any/all random U= DP-based protocol. I wouldn't be surprised to find there are for DNS, for = example. But you're talking about for ever, not just now. I don't have a = crystal ball. Regardless, I would expect this requirement to be achieved e= asily, no? -hadriel From ekr@rtfm.com Tue Oct 25 08: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 66AD521F8B9A for ; Tue, 25 Oct 2011 08:39:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.966 X-Spam-Level: X-Spam-Status: No, score=-102.966 tagged_above=-999 required=5 tests=[AWL=0.011, 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 a-1fugSgn4KR for ; Tue, 25 Oct 2011 08:38:59 -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 B6B2F21F8B8D for ; Tue, 25 Oct 2011 08:38:59 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so692989vcb.31 for ; Tue, 25 Oct 2011 08:38:59 -0700 (PDT) Received: by 10.52.29.9 with SMTP id f9mr28133202vdh.30.1319557139092; Tue, 25 Oct 2011 08:38:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.161.20 with HTTP; Tue, 25 Oct 2011 08:38:19 -0700 (PDT) In-Reply-To: References: <4EA5EA46.1010803@jesup.org> From: Eric Rescorla Date: Tue, 25 Oct 2011 08:38:19 -0700 Message-ID: To: Hadriel Kaplan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Randell Jesup , "rtcweb@ietf.org" Subject: Re: [rtcweb] draft-jesup-rtcweb-data-00 posted X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 15:39:00 -0000 On Tue, Oct 25, 2011 at 8:31 AM, Hadriel Kaplan wr= ote: > > On Oct 25, 2011, at 10:20 AM, Eric Rescorla wrote: > >> On Tue, Oct 25, 2011 at 1:02 AM, Hadriel Kaplan = wrote: >>> >>> Req. 8: The data stream transport protocol MUST NOT encode IP addresses= inside its protocol fields; doing so reveals potentially private informati= on, and leads to failure if the address is depended upon. >> >> I don't really understand what this means. In general, the peer has >> access to your IP address >> information from ICE. > > From a privacy perspective: if a person uses a Web-site designed with pri= vacy/anonymity in mind (e.g., battered-spouse forum), then the site would r= elay your media-plane stuff through a type of TURN server that does ICE its= elf both ways. =A0But if the SCTP layer on top of UDP encodes your local IP= using one of the optional SCTP fields in RFC 4960 or 5061, then you lose t= hat anonymity. =A0Since the SCTP layer is built into the Browser and not un= der control of the Javascript, a site can't prevent it from revealing that = info. > > From a failure perspective: if the SCTP layer on top of UDP encodes local= or remote IP addresses using an SCTP field, presumably it does so for some= purpose. =A0Since history has shown that relying on embedded IP Addresses = for anything is prone to failure due to the proliferation of NATs, double-N= ATs, v4-v6 NATs, etc., then we shouldn't want SCTP to rely on such being us= eful. =A0The best way to make sure it can't rely on them, is not to use any= to begin with. :) > >=3D OK. Sold. >>> Req. 10: The data stream packet format/encoding MUST be such that it is= impossible for a malicious Javascript to generate an application message c= rafted such that it could be interpreted as a native protocol over UDP - su= ch as UPnP, RTP, SNMP, STUN, etc. >> >> I'm not sure this is really an issue the way you raise it. It's clear >> that you shouldn't be able to >> generate messages that appear to be STUN or RTP but that's necessary >> for demux to work >> right. > > Yes I didn't mean to imply it would be hard to satisfy the requirement, o= r not necessary for other reasons. =A0I suggested it because some people wa= nted to do raw UDP a while ago and this requirement's there to show we can'= t do raw UDP. OK. > >> However, given that the other side has consented, I don't see >> that confusion with >> other protocols being an issue. The kind of intercepting proxies that >> we found for >> HTTP don't seem to be a feature of the UDP environment. > > > I don't know that intercepting middleboxes don't exist for any/all random= UDP-based protocol. =A0I wouldn't be surprised to find there are for DNS, = for example. =A0But you're talking about for ever, not just now. =A0I don't= have a crystal ball. =A0Regardless, I would expect this requirement to be = achieved easily, no? So, I was thinking no, but now that I think about it harder, the answer is yes. :) [*] -Ekr [*] The technical reason here is that it's not easy for TLS < 1.1, but it is easy for DTLS, due to the way CBC mode is used in the different protocols. From ted.ietf@gmail.com Tue Oct 25 09: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 C620321F8B64 for ; Tue, 25 Oct 2011 09:11:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.305 X-Spam-Level: X-Spam-Status: No, score=-3.305 tagged_above=-999 required=5 tests=[AWL=0.293, 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 kSAOfxL+LJ3s for ; Tue, 25 Oct 2011 09:11:29 -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 2F6DE21F8AA9 for ; Tue, 25 Oct 2011 09:11:29 -0700 (PDT) Received: by ywt2 with SMTP id 2so772859ywt.31 for ; Tue, 25 Oct 2011 09:11:28 -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=DHIP9R2hhzdNfsOdiTj07VtMBxuvHYFqL89swgPSB0s=; b=tsaJZpwl/6sUA4ubn+u3KwvB5DIJYrk0Znfyfkz9GXVwdVJpXHOjpq3G14ySGYHyTZ 38v9g9+htb6ipO85LmlRaA535EcSMC7Smf1xs2LtlqrdB+e7xF9lKH6XL/67EuDc1v0D CzqFTp8h1DDruZSvNoBKvClX4AEFbkO3q9xL0= MIME-Version: 1.0 Received: by 10.236.191.71 with SMTP id f47mr13631722yhn.7.1319559088859; Tue, 25 Oct 2011 09:11:28 -0700 (PDT) Received: by 10.236.105.169 with HTTP; Tue, 25 Oct 2011 09:11:28 -0700 (PDT) Date: Tue, 25 Oct 2011 09:11:28 -0700 Message-ID: From: Ted Hardie To: rtcweb@ietf.org Content-Type: multipart/alternative; boundary=20cf303f6496c068c704b021ca50 Subject: [rtcweb] High level agenda for Taipei meeting X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 16:11:30 -0000 --20cf303f6496c068c704b021ca50 Content-Type: text/plain; charset=ISO-8859-1 Hi folks, We're currently allocated meetings on Tuesday and Thursday morning, each of which is 2 1/2 hours long. The chairs' current thinking is to allocate the time along these lines: Draft high-level Agenda for the Taipei meeting Tuesday: 10 Administrivia + pointers to other meetings in the week 90 Signaling discussion 30 Glare proposal 10 Update from AVTCore on multiplexing Thursday: 90 Security 30 Data Channel 30 Codecs Please send any initial thoughts on this split to the list. thanks, Ted, Cullen, and Magnus --20cf303f6496c068c704b021ca50 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi folks,

We're currently allocated meetings on Tuesday and Thur= sday morning, each of which is 2 1/2 hours long.=A0 The chairs' current= thinking is to allocate the time along these lines:

Draft high-leve= l Agenda for the Taipei meeting

Tuesday:

10 Administrivia + pointers to other meetings in the we= ek
90 Signaling discussion
30 Glare proposal
10 Update from AVTCor= e on multiplexing

Thursday:
90 Security
30 Data Channel
30 Codecs

Please send any initial thoughts on thi= s split to the list.

thanks,

Ted, Cullen,=A0 and Magnus
--20cf303f6496c068c704b021ca50-- From HKaplan@acmepacket.com Tue Oct 25 09:50: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 441E121F84BC for ; Tue, 25 Oct 2011 09:50:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.145 X-Spam-Level: X-Spam-Status: No, score=-2.145 tagged_above=-999 required=5 tests=[AWL=-0.147, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=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 58rvlisMpEWr for ; Tue, 25 Oct 2011 09:50:54 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id D65E921F8C58 for ; Tue, 25 Oct 2011 09:50: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, 25 Oct 2011 11:50:47 -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; Tue, 25 Oct 2011 11:50:47 -0400 From: Hadriel Kaplan To: Ted Hardie Thread-Topic: [rtcweb] draft-jesup-rtcweb-data-00 posted Thread-Index: AQHMky3cZQqP1ujCGEKVF1TBv3YWpQ== Date: Tue, 25 Oct 2011 15:50:47 +0000 Message-ID: <4DBA01DA-EAEB-4B4B-BB42-9DF23B86D8E0@acmepacket.com> References: <4EA5EA46.1010803@jesup.org> 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_4DBA01DAEAEB4B4BBB429DF23B86D8E0acmepacketcom_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: Randell Jesup , "rtcweb@ietf.org" Subject: Re: [rtcweb] draft-jesup-rtcweb-data-00 posted X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 16:50:55 -0000 --_000_4DBA01DAEAEB4B4BBB429DF23B86D8E0acmepacketcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Actually that is also a requirement, but not the one I was worried about. := ) My concern is that there will be IP-layer fragmentation - even if the IP fr= agments successfully get delivered to the far end. Consumer NATs, Corp Fir= ewalls, and CGNs have a really hard time with IP-layer fragmentation; in so= me cases they will block it altogether, in other cases they'll handle a sma= ll restricted volume of it. Some IP routers and CGNs, for example, play tr= icks with the MSS in TCP to prevent IP-layer fragmentation of TCP segments. Since UDP has no MSS-equivalent, and no UDP-layer segmentation/chunking, we= need it at a layer above UDP so that every IP+UDP packet coming out of the= Browser's OS is a whole UDP packet and no IP-layer fragmentation occurs. In fact, I wonder if we shouldn't add an MSS-type thing for this data chann= el, in STUN/ICE since it's now a virtual connection "handshake". -hadriel On Oct 25, 2011, at 10:56 AM, Ted Hardie wrote: Hi Hadriel, I'm finding this requirement to be oddly worded: Req. 7: Data streams MUST provide fragmentation at a layer above UDP, such = that IP-layer fragmentation does not occur no matter how large a message/bu= ffer the Javascript application passes down to the Browser to be sent out. Isn't the issue that the data stream must understand the path MTU and must = chunk the data so as to avoid IP fragmentation? If it did not, it could ru= n into IP-layer fragmentation even with a relatively small amount of traffi= c to send. Why tie that requirement either to a "layer above UDP" (since r= unning this over UDP is not decided) or to the size of the data to be passe= d? I'm guessing that at the back of this is a requirement like "Please, don't = make the downloaded javascript application figure out how to chop up the da= ta to make it pass unmolested over the path". I heartily agree with that, = but if I'm understanding you right, that would be: Req. 7: Data streams must avoid IP-layer fragmentation without requiring t= he Javascript application to restrict the size of messages to be passed ove= r the channel. Does that make sense? regards, Ted --_000_4DBA01DAEAEB4B4BBB429DF23B86D8E0acmepacketcom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable

Actually that is also a requirement, but not the one I was worried abo= ut. :)

My concern is that there will be IP-layer fragmentation - even if the = IP fragments successfully get delivered to the far end.  Consumer NATs= , Corp Firewalls, and CGNs have a really hard time with IP-layer fragmentat= ion; in some cases they will block it altogether, in other cases they'll handle a small restricted volume of it.=  Some IP routers and CGNs, for example, play tricks with the MSS in T= CP to prevent IP-layer fragmentation of TCP segments. 

Since UDP has no MSS-equivalent, and no UDP-layer segmentation/chunkin= g, we need it at a layer above UDP so that every IP+UDP packet coming o= ut of the Browser's OS is a whole UDP packet and no IP-layer fragmentation = occurs.

In fact, I wonder if we shouldn't add an MSS-type thing for this data = channel, in STUN/ICE since it's now a virtual connection "handshake&qu= ot;. 

-hadriel


On Oct 25, 2011, at 10:56 AM, Ted Hardie wrote:

Hi Hadriel,

I'm finding this requirement to be oddly worded:


Req. 7: Data streams MUST provide fragmentation at a layer above UDP, such = that IP-layer fragmentation does not occur no matter how large a message/bu= ffer the Javascript application passes down to the Browser to be sent out.<= br>

Isn't the issue that the data stream must understand the path MTU and must = chunk the data so as to avoid IP fragmentation?  If it did not, it cou= ld run into IP-layer fragmentation even with a relatively small amount of t= raffic to send.  Why tie that requirement either to a "layer above UDP" (since running this over UDP is no= t decided) or to the size of the data to be passed?

I'm guessing that at the back of this is a requirement like "Please, d= on't make the downloaded javascript application figure out how to chop up t= he data to make it pass unmolested over the path".  I heartily ag= ree with that, but if I'm understanding you right, that would be:

Req. 7:  Data streams must avoid IP-layer fragmentation without requir= ing the Javascript application to restrict the size of messages to be passe= d over the channel.

Does that make sense?

regards,

Ted

--_000_4DBA01DAEAEB4B4BBB429DF23B86D8E0acmepacketcom_-- From HKaplan@acmepacket.com Tue Oct 25 10: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 A663621F8BAE for ; Tue, 25 Oct 2011 10:32:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.293 X-Spam-Level: X-Spam-Status: No, score=-2.293 tagged_above=-999 required=5 tests=[AWL=0.006, 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 139-6gcuME6X for ; Tue, 25 Oct 2011 10:32:47 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 1125321F8BA7 for ; Tue, 25 Oct 2011 10: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; Tue, 25 Oct 2011 13:32:41 -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; Tue, 25 Oct 2011 13:32:41 -0400 From: Hadriel Kaplan To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= Thread-Topic: [rtcweb] draft-kaplan-rtcweb-sip-interworking-requirements-00 Thread-Index: AQHMkzwYC3D0vszPzU6fGvL68kihrg== Date: Tue, 25 Oct 2011 17:32:40 +0000 Message-ID: <0E8ADE67-75ED-4117-B27D-19FB714DD2D3@acmepacket.com> References: <20111024224257.28459.65554.idtracker@ietfa.amsl.com> <6EB8679A-13D5-4AD7-97F2-BC35FC0966F0@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: 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] draft-kaplan-rtcweb-sip-interworking-requirements-00 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 17:32:47 -0000 On Oct 25, 2011, at 5:50 AM, I=F1aki Baz Castillo wrote: > Let me a question about section 4.2.2: >=20 > ---------------------------- > 4.2.2 SRTP Termination [...] It should be noted that if SRTP > is required to be used for every call by RTCWeb but the [SDES] key > exchange model cannot be used on the RTCWeb side, then the > Interworking Function likely has to terminate SRTP from RTCWeb even > if the SIP-domain supports SRTP, because [SDES] is the most > commonly used form of key exchange in SIP > today.------------------------------ >=20 > I was not aware of such limitation. Could you please point me to some > draft or mail thread in which that limitation (SDES key exchange model > cannot be used on the RTCWeb side) is explained? There were discussions at a previous meeting and an email thread a while ba= ck on whether (1) SRTP should be mandatory to use, and (2) on whether it mu= st be dtls-srtp key exchange. I believe one thread on this was started here: http://www.ietf.org/mail-archive/web/rtcweb/current/msg00460.html I don't know if a conclusion/consensus was reached. Thus I wrote that secti= on of the draft assuming it could go either way.=20 -hadriel From randell-ietf@jesup.org Tue Oct 25 13:13: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 B9F9521F8A80 for ; Tue, 25 Oct 2011 13:13:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mqghi4MxOHCm for ; Tue, 25 Oct 2011 13:13: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 3D5E621F8A7D for ; Tue, 25 Oct 2011 13:13: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 1RInMr-0003lJ-GQ for rtcweb@ietf.org; Tue, 25 Oct 2011 15:13:01 -0500 Message-ID: <4EA71726.7090900@jesup.org> Date: Tue, 25 Oct 2011 16:08:06 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 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] High level agenda for Taipei meeting X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 20:13:02 -0000 On 10/25/2011 12:11 PM, Ted Hardie wrote: > We're currently allocated meetings on Tuesday and Thursday morning, > each of which is 2 1/2 hours long. The chairs' current thinking is to > allocate the time along these lines: > > Draft high-level Agenda for the Taipei meeting > > Tuesday: > > 10 Administrivia + pointers to other meetings in the week > 90 Signaling discussion > 30 Glare proposal > 10 Update from AVTCore on multiplexing > > Thursday: > 90 Security > 30 Data Channel > 30 Codecs We should try to allocate some time for congestion control. I didn't write a separate draft on it, but we can use Harald's draft as the vehicle for the discussion, with updates about our current thinking added perhaps. Note: I won't be there in person, though I'll be attempting to follow it remotely. Perhaps steal a few minutes from Glare? I'm open. -- Randell Jesup randell-ietf@jesup.org From fluffy@cisco.com Tue Oct 25 14:31: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 163A711E808C for ; Tue, 25 Oct 2011 14:31:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.335 X-Spam-Level: X-Spam-Status: No, score=-106.335 tagged_above=-999 required=5 tests=[AWL=0.264, 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 u1Hgls36nUER for ; Tue, 25 Oct 2011 14:31:16 -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 83B6411E8083 for ; Tue, 25 Oct 2011 14:31:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=825; q=dns/txt; s=iport; t=1319578276; x=1320787876; h=from:content-transfer-encoding:subject:date:message-id: cc:to:mime-version; bh=c0y5aRcNwXOCYdffEIHNYvX/vn61k1GYrD9LcTA6c7c=; b=UpAy6vPBtWMRQc8KbowKKSF4XsmL0G2LHwVokzhqizjY7FQGu7x/A/Q/ 82MagCCIVOpALVke3LYTPxOR72BC10nE6/y5+0g3S9ATy1SjUH/+zAFDD M5y1uS3BUfKTgQywW8g5l7n+8FMMMdBnRtB3D1jBNEiu/X0cnBGCq6eMR I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArYHADYqp06rRDoJ/2dsb2JhbABCmiOPAIEFggcBJz+Bc51NAZ5kh3VhBIgGjASFLIxR X-IronPort-AV: E=Sophos;i="4.69,405,1315180800"; d="scan'208";a="10242373" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 25 Oct 2011 21:31:16 +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 p9PLVFet000539; Tue, 25 Oct 2011 21:31:16 GMT From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 25 Oct 2011 15:31:15 -0600 Message-Id: To: rtcweb@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [rtcweb] Request for proposals on system security X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 21:31:17 -0000 The WG has been talking for a long time about problems and requirements = around security. By security I loosely mean everything from how we = secure media and how you know who you are talking to through to user = interfaces for authorizing access to cameras and microphones. =20 Magnus, Ted, and I believe the Ekr's draft has made a good start = outlining the problem space, but that it is time to have proposals for = the system which answers those problems. If you have a model and a set = of mechanisms in mind, please start a thread to discuss how it meets = them. If you are going to make a proposal, please start a thread with an = outline before Oct 30 so we can spend time in Taipei discussing the = ideas that need face to face time based on the list discussion.=20 Thanks, Cullen, Magnus, & Ted. From HKaplan@acmepacket.com Tue Oct 25 14:43: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 206D021F8BFE for ; Tue, 25 Oct 2011 14:43:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.446 X-Spam-Level: X-Spam-Status: No, score=-2.446 tagged_above=-999 required=5 tests=[AWL=0.153, 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 VrJg9tsKL72k for ; Tue, 25 Oct 2011 14:43:18 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 7159021F8BE9 for ; Tue, 25 Oct 2011 14:43: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; Tue, 25 Oct 2011 17:43:16 -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; Tue, 25 Oct 2011 17:43:17 -0400 From: Hadriel Kaplan To: Ted Hardie Thread-Topic: [rtcweb] High level agenda for Taipei meeting Thread-Index: AQHMk18aYhTZnFvQ20GDijNOxmMweg== Date: Tue, 25 Oct 2011 21:43:16 +0000 Message-ID: <5806E943-CFB4-41F0-BEF2-2FA2F98B0B50@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: [10.0.0.30] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <6B666B8B07B5294981780EBAC636AB54@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [rtcweb] High level agenda for Taipei meeting X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 21:43:19 -0000 Similar to the "Update from AVTCore on multiplexing", can we allocate some = time (10 mins?) and get an update on what's going on on the W3C side, like = any outcomes relevant to us from next-week's meeting?=20 I gather it's a closed-door meeting, but still it would be nice to know wha= t's up - like on the UI security/permissions, which may impact what we can = do in the IETF for SRTP and DTLS. -hadriel On Oct 25, 2011, at 12:11 PM, Ted Hardie wrote: > Hi folks, >=20 > We're currently allocated meetings on Tuesday and Thursday morning, each = of which is 2 1/2 hours long. The chairs' current thinking is to allocate = the time along these lines: >=20 > Draft high-level Agenda for the Taipei meeting >=20 > Tuesday: >=20 > 10 Administrivia + pointers to other meetings in the week > 90 Signaling discussion > 30 Glare proposal > 10 Update from AVTCore on multiplexing >=20 > Thursday: > 90 Security > 30 Data Channel > 30 Codecs >=20 > Please send any initial thoughts on this split to the list. >=20 > thanks, >=20 > Ted, Cullen, and Magnus >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From harald@alvestrand.no Tue Oct 25 16:22: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 DA0531F0C4E for ; Tue, 25 Oct 2011 16:22:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.099 X-Spam-Level: X-Spam-Status: No, score=-110.099 tagged_above=-999 required=5 tests=[AWL=0.500, 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-eJY0iZyWRP for ; Tue, 25 Oct 2011 16:22:12 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 200ED1F0C4B for ; Tue, 25 Oct 2011 16:22:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2130039E0F3; Wed, 26 Oct 2011 01:22:11 +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 L3X0juardvfz; Wed, 26 Oct 2011 01:22:10 +0200 (CEST) Received: from [172.19.28.23] (216-239-45-4.google.com [216.239.45.4]) by eikenes.alvestrand.no (Postfix) with ESMTPS id BC5B639E089; Wed, 26 Oct 2011 01:22:09 +0200 (CEST) Message-ID: <4EA7449F.8010109@alvestrand.no> Date: Tue, 25 Oct 2011 16:22:07 -0700 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: Hadriel Kaplan References: <5806E943-CFB4-41F0-BEF2-2FA2F98B0B50@acmepacket.com> In-Reply-To: <5806E943-CFB4-41F0-BEF2-2FA2F98B0B50@acmepacket.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "" Subject: [rtcweb] W3C attendance (Re: High level agenda for Taipei meeting) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 23:22:13 -0000 Just to give further information on the W3C meeting. On 10/25/2011 02:43 PM, Hadriel Kaplan wrote: > Similar to the "Update from AVTCore on multiplexing", can we allocate some time (10 mins?) and get an update on what's going on on the W3C side, like any outcomes relevant to us from next-week's meeting? > > I gather it's a closed-door meeting, but still it would be nice to know what's up - like on the UI security/permissions, which may impact what we can do in the IETF for SRTP and DTLS. W3C meetings are formally members-only, but the chairs can permit observers as far as the facilities will allow. People who wish observer status should email the chairs in advance. I'll be happy to give an update on the discussions in Taipei. Harald > -hadriel > > > On Oct 25, 2011, at 12:11 PM, Ted Hardie wrote: > >> Hi folks, >> >> We're currently allocated meetings on Tuesday and Thursday morning, each of which is 2 1/2 hours long. The chairs' current thinking is to allocate the time along these lines: >> >> Draft high-level Agenda for the Taipei meeting >> >> Tuesday: >> >> 10 Administrivia + pointers to other meetings in the week >> 90 Signaling discussion >> 30 Glare proposal >> 10 Update from AVTCore on multiplexing >> >> Thursday: >> 90 Security >> 30 Data Channel >> 30 Codecs >> >> Please send any initial thoughts on this split to the list. >> >> thanks, >> >> Ted, Cullen, and Magnus >> >> _______________________________________________ >> 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 HKaplan@acmepacket.com Tue Oct 25 19:17: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 A3D2C11E8082 for ; Tue, 25 Oct 2011 19:17:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.453 X-Spam-Level: X-Spam-Status: No, score=-2.453 tagged_above=-999 required=5 tests=[AWL=0.146, 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 FReWVVku--JD for ; Tue, 25 Oct 2011 19:17:47 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 0568721F8AFB for ; Tue, 25 Oct 2011 19:17: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, 25 Oct 2011 22:17: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; Tue, 25 Oct 2011 22:17:45 -0400 From: Hadriel Kaplan To: Harald Alvestrand Thread-Topic: W3C attendance (Re: [rtcweb] High level agenda for Taipei meeting) Thread-Index: AQHMk4VybVudu/5qTEu6gZgE8j0vew== Date: Wed, 26 Oct 2011 02:17:44 +0000 Message-ID: References: <5806E943-CFB4-41F0-BEF2-2FA2F98B0B50@acmepacket.com> <4EA7449F.8010109@alvestrand.no> In-Reply-To: <4EA7449F.8010109@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] W3C attendance (Re: High level agenda for Taipei meeting) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2011 02:17:47 -0000 On Oct 25, 2011, at 7:22 PM, Harald Alvestrand wrote: >> I gather it's a closed-door meeting, but still it would be nice to know = what's up - like on the UI security/permissions, which may impact what we c= an do in the IETF for SRTP and DTLS. > W3C meetings are formally members-only, but the chairs can permit observe= rs as far as the facilities will allow. > People who wish observer status should email the chairs in advance. Ahh, good to know - I was told it was for members only and when I went on t= he website I saw the word "observer" used but figured that was for some sor= t of specific roles like liaisons or something.=20 > I'll be happy to give an update on the discussions in Taipei. Great, thanks! -hadriel From Markus.Isomaki@nokia.com Wed Oct 26 00: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 980F621F8557 for ; Wed, 26 Oct 2011 00:34:20 -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] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24KHf6KYNRNY for ; Wed, 26 Oct 2011 00:34:20 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id C724421F8549 for ; Wed, 26 Oct 2011 00:34:16 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-sa01.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p9Q7YANj019743 for ; Wed, 26 Oct 2011 10:34:15 +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, 26 Oct 2011 10:33:29 +0300 Received: from 008-AM1MMR1-005.mgdnok.nokia.com (65.54.30.60) by NOK-AM1MHUB-04.mgdnok.nokia.com (65.54.30.8) with Microsoft SMTP Server (TLS) id 8.2.255.0; Wed, 26 Oct 2011 09:33:29 +0200 Received: from 008-AM1MPN1-043.mgdnok.nokia.com ([169.254.3.167]) by 008-AM1MMR1-005.mgdnok.nokia.com ([65.54.30.60]) with mapi id 14.01.0339.002; Wed, 26 Oct 2011 09:33:29 +0200 From: To: Thread-Topic: Relationship of ROAP and PeerConnection? Thread-Index: AcyTrUF2bQp0uHgLRMajaerMxZL05Q== Date: Wed, 26 Oct 2011 07:33:28 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.21.75.47] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 26 Oct 2011 07:33:29.0712 (UTC) FILETIME=[8E8ECF00:01CC93B1] X-Nokia-AV: Clean Subject: [rtcweb] Relationship of ROAP and PeerConnection? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2011 07:34:20 -0000 Hi, I have been trying to figure out how ROAP and the W3C PeerConnection object= are intended to work together. The sequence diagrams in the ROAP I-D give = some idea about that, but I'd like to clarify if my understanding is correc= t. If I understand correctly, the SDP (ROAP) offer-answer and ICE state machin= es are implemented within the browser (UA). The browser gathers the ICE can= didates and does the end-to-end STUN connectivity check. The browser does n= ot however really send/receive the SDP/ROAP messages. Rather, that is left = to the Javascrip app. PeerConnection has the processSignalingMessage() meth= od by which the JS app can pass a message to the browser, and the signaling= Callback function for passing the message in the other direction. ROAP defi= nes the syntax and semantics of these messages (based on SDP O/A) and expla= ins how they drive the state machine within the browser. The JS app can use= any means to carry the messages to the other browser (in principle using X= mlHttpRequest or Websocket towards the web server). It can change the synta= x (e.g. to "real" SDP or Jingle XML or whatever), add or remove anything, a= s long as it is able to give a valid message to the other peer using proces= sSignalingMessage(). Is this roughly how this is supposed to work? If we take this approach, wouldn't it be better to integrate the ROAP defin= ition to the W3C API spec? If they are separate documents as they are at th= e moment, it is a bit difficult to do the mapping. I understand that curren= tly it is like it is because W3C is responsible for the API and IETF for th= e protocol. Markus From ibc@aliax.net Wed Oct 26 01:46: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 CE92821F8922 for ; Wed, 26 Oct 2011 01:46:43 -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 TmKsbeo5Ztk6 for ; Wed, 26 Oct 2011 01:46:42 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 359B921F87D9 for ; Wed, 26 Oct 2011 01:46:37 -0700 (PDT) Received: by qadc10 with SMTP id c10so1561312qad.31 for ; Wed, 26 Oct 2011 01:46:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.115.106 with SMTP id jn10mr1129747obb.54.1319618796555; Wed, 26 Oct 2011 01:46:36 -0700 (PDT) Received: by 10.182.220.66 with HTTP; Wed, 26 Oct 2011 01:46:36 -0700 (PDT) In-Reply-To: References: Date: Wed, 26 Oct 2011 10:46:36 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Markus.Isomaki@nokia.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Relationship of ROAP and PeerConnection? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2011 08:46:43 -0000 2011/10/26 : > If I understand correctly, the SDP (ROAP) offer-answer and ICE state mach= ines are implemented within the browser (UA). The browser gathers the ICE c= andidates and does the end-to-end STUN connectivity check. The browser does= not however really send/receive the SDP/ROAP messages. Rather, that is lef= t to the Javascrip app. PeerConnection has the processSignalingMessage() me= thod by which the JS app can pass a message to the browser, and the signali= ngCallback function for passing the message in the other direction. ROAP de= fines the syntax and semantics of these messages (based on SDP O/A) and exp= lains how they drive the state machine within the browser. The JS app can u= se any means to carry the messages to the other browser (in principle using= XmlHttpRequest or Websocket towards the web server). It can change the syn= tax (e.g. to "real" SDP or Jingle XML or whatever), add or remove anything,= as long as it is able to give a valid message to the other peer using proc= essSignalingMessa > =C2=A0ge(). > > Is this roughly how this is supposed to work? Hi Markus. I hope that is supposed to work exactly as you describe above. But indeed, it would be great if this WG confirms it so we can move on. Recently we have written an informational draft exposing the same as in your mail: http://tools.ietf.org/html/draft-sipdoc-rtcweb-open-wire-protocol-00 The RTCweb example scenarios (sections 4 and 5 in the draft) are designed whit this assumption in mind. Regards. --=20 I=C3=B1aki Baz Castillo From fluffy@cisco.com Wed Oct 26 07:41: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 9DB7521F8AEA for ; Wed, 26 Oct 2011 07:41:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.344 X-Spam-Level: X-Spam-Status: No, score=-106.344 tagged_above=-999 required=5 tests=[AWL=0.255, 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 ThFUkfzRP4UN for ; Wed, 26 Oct 2011 07:41:58 -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 E90E621F8AE1 for ; Wed, 26 Oct 2011 07:41:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=3252; q=dns/txt; s=iport; t=1319640119; x=1320849719; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=uHtbYIEbEOetFLYbsyTWnEvDHc0XgFpNu3jS4/ZAYAc=; b=TjsbuYhxaB9tpG6iXQiYa0vUEsoeRBd+EDi9XrHM8zaKcn9iOIvUx9uK b4amSDmBiCCQxvZttq7sngoALPRJZ8Je9xAkWqSqmj1TvLgDmjU0Lz9QF VC0yjMpnk8E549PHiYCHSlk8gMHJ4YZ9g0bsu+Sxri5QGRRX6poiCk08X M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAFwbqE6rRDoJ/2dsb2JhbABCqT+BBYFuAQEBAwEBAQEPASc0BAcFCwtGJzAGEyKHXgiWLQGeYASICWEEiAaMBIUtjFE X-IronPort-AV: E=Sophos;i="4.69,409,1315180800"; d="scan'208";a="10380480" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 26 Oct 2011 14:41:57 +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 p9QEfvnR026600; Wed, 26 Oct 2011 14:41:57 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: Date: Wed, 26 Oct 2011 08:41:56 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <1D1CC4EE-0002-4638-B42F-760C2D6F29B8@cisco.com> References: To: "" X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Relationship of ROAP and PeerConnection? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2011 14:41:59 -0000 On Oct 26, 2011, at 1:33 AM, = wrote: > Hi, >=20 > I have been trying to figure out how ROAP and the W3C PeerConnection = object are intended to work together. The sequence diagrams in the ROAP = I-D give some idea about that, but I'd like to clarify if my = understanding is correct. >=20 > If I understand correctly, the SDP (ROAP) offer-answer and ICE state = machines are implemented within the browser (UA). The browser gathers = the ICE candidates and does the end-to-end STUN connectivity check. The = browser does not however really send/receive the SDP/ROAP messages. = Rather, that is left to the Javascrip app. PeerConnection has the = processSignalingMessage() method by which the JS app can pass a message = to the browser, and the signalingCallback function for passing the = message in the other direction. ROAP defines the syntax and semantics of = these messages (based on SDP O/A) and explains how they drive the state = machine within the browser. The JS app can use any means to carry the = messages to the other browser (in principle using XmlHttpRequest or = Websocket towards the web server). It can change the syntax (e.g. to = "real" SDP or Jingle XML or whatever), add or remove anything, as long = as it is able to give a valid message to the other peer using = processSignalingMessa > ge(). >=20 > Is this roughly how this is supposed to work? Yes. However, a signaling gateway would probably want to implement ROAP = over Websockets over TLS. =20 >=20 > If we take this approach, wouldn't it be better to integrate the ROAP = definition to the W3C API spec? If they are separate documents as they = are at the moment, it is a bit difficult to do the mapping. Right now the W3C API and ROAP are way out of sync so it makes it = particularly hard to do the mapping in ones head. Eventually we will = need to sort out which spec defines the JSON object as the string form = of that is the ROAP protocol and also would be passed across the RTCWeb = API. There are arguments either way but I'm sure that we want it defined = one place and the other place to point at it. I think as we get this all = sorted out, it will become relatively clear which document to put the = text in. Right now, I'm just trying to focus on does the idea look like = it is on the right path regardless of which document it is in. The fact = the various specs are so out of sync makes it hard to get ones head = around the whole idea. In the meantime, the ROAP JSON object is = primarily about a concrete instantiation of the abstract RFC 3264 = Offer/Answer protocol and is key to the over the wire ROAP protocol to a = signaling gateway so I think it fairly reasonable to be driving the = discussion from and IETF document vs a W3C one. =46rom W3C API point of = view, it is more of an opaque contain of information used for IETF = protocols.=20 > I understand that currently it is like it is because W3C is = responsible for the API and IETF for the protocol. >=20 > Markus >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From fluffy@cisco.com Wed Oct 26 10: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 2DFA121F89B8 for ; Wed, 26 Oct 2011 10:17:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.859 X-Spam-Level: X-Spam-Status: No, score=-105.859 tagged_above=-999 required=5 tests=[AWL=-0.260, BAYES_00=-2.599, J_BACKHAIR_27=1, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c7x8NKPoLvRX for ; Wed, 26 Oct 2011 10:17: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 C089D21F85C7 for ; Wed, 26 Oct 2011 10:17:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=684; q=dns/txt; s=iport; t=1319649468; x=1320859068; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=e3qFe6cFDhLMVcKpT/K87wZtkeXP9LUujk8OtTZJsPE=; b=fHz2aJo4qRdqHyv8XAT0KLMIFHCeyiAP1bkq4pm/tQ9hrMJT1NcVFXr8 rCwkPMAgbyfJppwp8yA7qKUje0/nJjOKB2gnkJE9ZqLJij98x+dHK9bmy WDVAQAS8poiwY0FeS8T8ufy+lgf0Ll5ThzQgrHEZln5qQNMJheLtFJZaI g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmMGAPM/qE6rRDoG/2dsb2JhbABCmkaPBYEFgW4BAQEDARIBFBM0CwULUVcZIodelkQBnmGICWEEiAaMBIUtjFE X-IronPort-AV: E=Sophos;i="4.69,410,1315180800"; d="scan'208";a="10438391" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 26 Oct 2011 17:17:48 +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 p9QHHlZw013403; Wed, 26 Oct 2011 17:17:47 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <3747C7CB-C039-4D15-A46C-8FDB9A47AF3A@acmepacket.com> Date: Wed, 26 Oct 2011 11:17:47 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <42322A10-14A7-4600-820D-7612A1B12592@cisco.com> <3747C7CB-C039-4D15-A46C-8FDB9A47AF3A@acmepacket.com> To: rtcweb@ietf.org X-Mailer: Apple Mail (2.1084) Subject: [rtcweb] Consensus Call: RTCWeb Terminology X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2011 17:17:49 -0000 With my chair hat on ...=20 I'd like to declare we currently have consensus for Hadriel's proposal = that the technology should be referred to as "WebRTC" and the API as the = "WebRTC API". The IETF WG name is still RTCWeb, the mailing list is = still rtcweb@ietf.org, the IETF drafts should still have "-rtcweb-" in = them to indicate the WG name.=20 Cullen On Oct 24, 2011, at 10:56 AM, Hadriel Kaplan wrote: > For the API, the consensus was it would be confusing to people if we = weren't consistent with W3C docs. >=20 > So I propose the following: >=20 > WebRTC: the whole shebang > WebRTC API: the JS<->Browser API. >=20 > -hadriel From giles@thaumas.net Wed Oct 26 10:33: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 318D611E8085 for ; Wed, 26 Oct 2011 10:33:58 -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 F+aCh26c3L+f for ; Wed, 26 Oct 2011 10:33:57 -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 5EBA71F0C3C for ; Wed, 26 Oct 2011 10:33:57 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so1998317vcb.31 for ; Wed, 26 Oct 2011 10:33:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.187.139 with SMTP id cw11mr450448vcb.67.1319650436725; Wed, 26 Oct 2011 10:33:56 -0700 (PDT) Received: by 10.220.192.8 with HTTP; Wed, 26 Oct 2011 10:33:56 -0700 (PDT) X-Originating-IP: [184.71.166.126] In-Reply-To: References: <42322A10-14A7-4600-820D-7612A1B12592@cisco.com> <3747C7CB-C039-4D15-A46C-8FDB9A47AF3A@acmepacket.com> Date: Wed, 26 Oct 2011 10:33:56 -0700 Message-ID: From: Ralph Giles To: Cullen Jennings Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Consensus Call: RTCWeb Terminology X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2011 17:33:58 -0000 On 26 October 2011 10:17, Cullen Jennings wrote: > I'd like to declare we currently have consensus for Hadriel's proposal th= at the technology should be referred to as "WebRTC" and the API as the "Web= RTC API". The IETF WG name is still RTCWeb, the mailing list is still rtcwe= b@ietf.org, the IETF drafts should still have "-rtcweb-" in them to indicat= e the WG name. Sounds appropriate to me! -r From igor.faynberg@alcatel-lucent.com Wed Oct 26 10:42:09 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7852521F85AA for ; Wed, 26 Oct 2011 10:42:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.999 X-Spam-Level: X-Spam-Status: No, score=-4.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_BACKHAIR_27=1, J_CHICKENPOX_66=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 t-WJsQn4W2-s for ; Wed, 26 Oct 2011 10:42:09 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id C5ECD21F86C1 for ; Wed, 26 Oct 2011 10:42:08 -0700 (PDT) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p9QHg70s029283 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 26 Oct 2011 12:42:07 -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 p9QHg7OK023166 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 26 Oct 2011 12:42:07 -0500 Received: from [135.222.134.155] (USMUYN0L055118.mh.lucent.com [135.222.134.155]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p9QHg5G4020861; Wed, 26 Oct 2011 12:42:06 -0500 (CDT) Message-ID: <4EA8466D.9090808@alcatel-lucent.com> Date: Wed, 26 Oct 2011 13:42:05 -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: <42322A10-14A7-4600-820D-7612A1B12592@cisco.com> <3747C7CB-C039-4D15-A46C-8FDB9A47AF3A@acmepacket.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.10 Subject: Re: [rtcweb] Consensus Call: RTCWeb Terminology 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, 26 Oct 2011 17:42:09 -0000 Having passed this milestone, maybe it is time to start a Terminology RFC? Igor On 10/26/2011 1:17 PM, Cullen Jennings wrote: > With my chair hat on ... > > I'd like to declare we currently have consensus for Hadriel's proposal that the technology should be referred to as "WebRTC" and the API as the "WebRTC API". The IETF WG name is still RTCWeb, the mailing list is still rtcweb@ietf.org, the IETF drafts should still have "-rtcweb-" in them to indicate the WG name. > > Cullen > > > On Oct 24, 2011, at 10:56 AM, Hadriel Kaplan wrote: > >> For the API, the consensus was it would be confusing to people if we weren't consistent with W3C docs. >> >> So I propose the following: >> >> WebRTC: the whole shebang >> WebRTC API: the JS<->Browser API. >> >> -hadriel > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From jmpolk@cisco.com Wed Oct 26 10:56: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 9651021F86D0 for ; Wed, 26 Oct 2011 10:56:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.069 X-Spam-Level: X-Spam-Status: No, score=-106.069 tagged_above=-999 required=5 tests=[AWL=-0.470, BAYES_00=-2.599, J_BACKHAIR_27=1, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qtD0THGpS++3 for ; Wed, 26 Oct 2011 10:56:49 -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 0EB3E21F86A5 for ; Wed, 26 Oct 2011 10:56:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=987; q=dns/txt; s=iport; t=1319651809; x=1320861409; h=message-id:date:to:from:subject:cc:in-reply-to: references:mime-version; bh=/8ZUYoaRsBBdTfyk6vmusLvf6oXaukO/sWVjhvp0tUs=; b=RWSZLWMAKkMEUGWv60s3yK/jKM3Z4OeeDPXNN9on8Lz9GR6vJS8NH3f3 L+Wpg4CBBPSczpGMtXOyWUpDXzq5X3tr51P27cPOr5i0FWoQxHIVUu6Eh Y30eE153ckU999c/EsPyr6VJOI12SB7iXGk195p8jWJfuX3gldCmmD2h+ k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAE5JqE6rRDoG/2dsb2JhbABCqUyBBYFuAQEBBAEBAQ8BFBECNAsQBwQOCh4QGQ4wBhMih2aWNgGeXASIagSIBp4B X-IronPort-AV: E=Sophos;i="4.69,410,1315180800"; d="scan'208";a="10449518" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 26 Oct 2011 17:56:47 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8713.cisco.com [10.99.80.20]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p9QHuke7006749; Wed, 26 Oct 2011 17:56:46 GMT Message-Id: <201110261756.p9QHuke7006749@mtv-core-1.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 26 Oct 2011 12:56:44 -0500 To: Hadriel Kaplan From: "James M. Polk" In-Reply-To: References: <42322A10-14A7-4600-820D-7612A1B12592@cisco.com> <3747C7CB-C039-4D15-A46C-8FDB9A47AF3A@acmepacket.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Consensus Call: RTCWeb Terminology X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2011 17:56:49 -0000 Hadriel now that you named it, you have to fix it (or otherwise make it work) ... ;-) James At 12:17 PM 10/26/2011, Cullen Jennings wrote: >With my chair hat on ... > >I'd like to declare we currently have consensus for Hadriel's >proposal that the technology should be referred to as "WebRTC" and >the API as the "WebRTC API". The IETF WG name is still RTCWeb, the >mailing list is still rtcweb@ietf.org, the IETF drafts should still >have "-rtcweb-" in them to indicate the WG name. > >Cullen > > >On Oct 24, 2011, at 10:56 AM, Hadriel Kaplan wrote: > > > For the API, the consensus was it would be confusing to people if > we weren't consistent with W3C docs. > > > > So I propose the following: > > > > WebRTC: the whole shebang > > WebRTC API: the JS<->Browser API. > > > > -hadriel > >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb From christer.holmberg@ericsson.com Wed Oct 26 10:58: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 962B921F8AA8 for ; Wed, 26 Oct 2011 10:58:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.729 X-Spam-Level: X-Spam-Status: No, score=-5.729 tagged_above=-999 required=5 tests=[AWL=-0.130, BAYES_00=-2.599, J_BACKHAIR_27=1, 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 v+3yuT4CiHYg for ; Wed, 26 Oct 2011 10:58: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 C3F7B21F8A7E for ; Wed, 26 Oct 2011 10:58:41 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-26-4ea84a507ca3 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 42.B4.20773.05A48AE4; Wed, 26 Oct 2011 19:58:41 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Wed, 26 Oct 2011 19:58:40 +0200 From: Christer Holmberg To: "'James M. Polk'" , Hadriel Kaplan Date: Wed, 26 Oct 2011 19:58:39 +0200 Thread-Topic: [rtcweb] Consensus Call: RTCWeb Terminology Thread-Index: AcyUCKR75ts33OY/SEWRptad5hBcZwAAChsg Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852233D45FF4@ESESSCMS0356.eemea.ericsson.se> References: <42322A10-14A7-4600-820D-7612A1B12592@cisco.com> <3747C7CB-C039-4D15-A46C-8FDB9A47AF3A@acmepacket.com> <201110261756.p9QHuke7006749@mtv-core-1.cisco.com> In-Reply-To: <201110261756.p9QHuke7006749@mtv-core-1.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Consensus Call: RTCWeb Terminology X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2011 17:58:42 -0000 Why does Hadriel care - an SBC can always change the terminology ;)=20 -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= James M. Polk Sent: 26. lokakuuta 2011 20:57 To: Hadriel Kaplan Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Consensus Call: RTCWeb Terminology Hadriel now that you named it, you have to fix it (or otherwise make it work) ... ;-) James At 12:17 PM 10/26/2011, Cullen Jennings wrote: >With my chair hat on ... > >I'd like to declare we currently have consensus for Hadriel's proposal=20 >that the technology should be referred to as "WebRTC" and the API as=20 >the "WebRTC API". The IETF WG name is still RTCWeb, the mailing list is=20 >still rtcweb@ietf.org, the IETF drafts should still have "-rtcweb-" in=20 >them to indicate the WG name. > >Cullen > > >On Oct 24, 2011, at 10:56 AM, Hadriel Kaplan wrote: > > > For the API, the consensus was it would be confusing to people if > we weren't consistent with W3C docs. > > > > So I propose the following: > > > > WebRTC: the whole shebang > > WebRTC API: the JS<->Browser API. > > > > -hadriel > >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From jmpolk@cisco.com Wed Oct 26 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 D47E521F8B04 for ; Wed, 26 Oct 2011 12:14:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.002 X-Spam-Level: X-Spam-Status: No, score=-106.002 tagged_above=-999 required=5 tests=[AWL=-0.403, BAYES_00=-2.599, J_BACKHAIR_27=1, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wEE1nQr-cgrZ for ; Wed, 26 Oct 2011 12:14:30 -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 4A0F421F8A96 for ; Wed, 26 Oct 2011 12:14:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=1592; q=dns/txt; s=iport; t=1319656470; x=1320866070; h=message-id:date:to:from:subject:cc:in-reply-to: references:mime-version; bh=B4j5aOiJwI4d/vZB1tJIZ025YenrglbUoncEbWyvToc=; b=jEsbo6+fj5cYJRIW4M3WwlT8H0cCXE5nFTjqK04x0vM1AbvQPHf6E6EN paQVPhwmX/QEHh1LuNZQhjnVeoYWRjgKArQaDgIwtGcQsgNo7MahHO0+P 5Y6aq0dZd/MXqWbQvK8U+N/f/lH0O/T1uP0Cl23yA/CPwQRoBWYCJiId0 4=; X-IronPort-AV: E=Sophos;i="4.69,411,1315180800"; d="scan'208";a="10481131" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 26 Oct 2011 19:14:30 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8713.cisco.com [10.99.80.20]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p9QJETpn019583; Wed, 26 Oct 2011 19:14:29 GMT Message-Id: <201110261914.p9QJETpn019583@mtv-core-3.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 26 Oct 2011 14:14:27 -0500 To: Christer Holmberg , "'James M. Polk'" , Hadriel Kaplan From: "James M. Polk" In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852233D45FF4@ESESSCMS0356.ee mea.ericsson.se> References: <42322A10-14A7-4600-820D-7612A1B12592@cisco.com> <3747C7CB-C039-4D15-A46C-8FDB9A47AF3A@acmepacket.com> <201110261756.p9QHuke7006749@mtv-core-1.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233D45FF4@ESESSCMS0356.eemea.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Consensus Call: RTCWeb Terminology X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2011 19:14:30 -0000 At 12:58 PM 10/26/2011, Christer Holmberg wrote: >Why does Hadriel care - an SBC can always change the terminology ;) very nice! > > >-----Original Message----- >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >Behalf Of James M. Polk >Sent: 26. lokakuuta 2011 20:57 >To: Hadriel Kaplan >Cc: rtcweb@ietf.org >Subject: Re: [rtcweb] Consensus Call: RTCWeb Terminology > >Hadriel > >now that you named it, you have to fix it (or otherwise make it work) ... > >;-) > >James > >At 12:17 PM 10/26/2011, Cullen Jennings wrote: > > >With my chair hat on ... > > > >I'd like to declare we currently have consensus for Hadriel's proposal > >that the technology should be referred to as "WebRTC" and the API as > >the "WebRTC API". The IETF WG name is still RTCWeb, the mailing list is > >still rtcweb@ietf.org, the IETF drafts should still have "-rtcweb-" in > >them to indicate the WG name. > > > >Cullen > > > > > >On Oct 24, 2011, at 10:56 AM, Hadriel Kaplan wrote: > > > > > For the API, the consensus was it would be confusing to people if > > we weren't consistent with W3C docs. > > > > > > So I propose the following: > > > > > > WebRTC: the whole shebang > > > WebRTC API: the JS<->Browser API. > > > > > > -hadriel > > > >_______________________________________________ > >rtcweb mailing list > >rtcweb@ietf.org > >https://www.ietf.org/mailman/listinfo/rtcweb > >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb From HKaplan@acmepacket.com Wed Oct 26 12:29: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 465A611E8073 for ; Wed, 26 Oct 2011 12:29:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.955 X-Spam-Level: X-Spam-Status: No, score=-1.955 tagged_above=-999 required=5 tests=[AWL=-0.356, BAYES_00=-2.599, J_BACKHAIR_27=1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OKuxzSmUYEKX for ; Wed, 26 Oct 2011 12:29:10 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id B30A221F888A for ; Wed, 26 Oct 2011 12:29: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; Wed, 26 Oct 2011 15:29:06 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.232]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Wed, 26 Oct 2011 15:29:07 -0400 From: Hadriel Kaplan To: Christer Holmberg Thread-Topic: [rtcweb] Consensus Call: RTCWeb Terminology Thread-Index: AQHMlBWGEKECh+8lQkm6uqfqXW9quA== Date: Wed, 26 Oct 2011 19:29:05 +0000 Message-ID: <03898B72-CEEB-4A75-850A-5E453213418D@acmepacket.com> References: <42322A10-14A7-4600-820D-7612A1B12592@cisco.com> <3747C7CB-C039-4D15-A46C-8FDB9A47AF3A@acmepacket.com> <201110261756.p9QHuke7006749@mtv-core-1.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233D45FF4@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852233D45FF4@ESESSCMS0356.eemea.ericsson.se> 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: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Consensus Call: RTCWeb Terminology X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2011 19:29:11 -0000 I think you mean a WebSBC. ;) On Oct 26, 2011, at 1:58 PM, Christer Holmberg wrote: >=20 > Why does Hadriel care - an SBC can always change the terminology ;)=20 >=20 > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf = Of James M. Polk > Sent: 26. lokakuuta 2011 20:57 > To: Hadriel Kaplan > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] Consensus Call: RTCWeb Terminology >=20 > Hadriel >=20 > now that you named it, you have to fix it (or otherwise make it work) ... >=20 > ;-) >=20 > James >=20 > At 12:17 PM 10/26/2011, Cullen Jennings wrote: >=20 >> With my chair hat on ... >>=20 >> I'd like to declare we currently have consensus for Hadriel's proposal=20 >> that the technology should be referred to as "WebRTC" and the API as=20 >> the "WebRTC API". The IETF WG name is still RTCWeb, the mailing list is= =20 >> still rtcweb@ietf.org, the IETF drafts should still have "-rtcweb-" in=20 >> them to indicate the WG name. >>=20 >> Cullen >>=20 >>=20 >> On Oct 24, 2011, at 10:56 AM, Hadriel Kaplan wrote: >>=20 >>> For the API, the consensus was it would be confusing to people if >> we weren't consistent with W3C docs. >>>=20 >>> So I propose the following: >>>=20 >>> WebRTC: the whole shebang >>> WebRTC API: the JS<->Browser API. >>>=20 >>> -hadriel >>=20 >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From ibc@aliax.net Wed Oct 26 12:48: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 4E98911E80A1 for ; Wed, 26 Oct 2011 12:48:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.64 X-Spam-Level: X-Spam-Status: No, score=-2.64 tagged_above=-999 required=5 tests=[AWL=0.037, 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 DZ1M0tM0+c6l for ; Wed, 26 Oct 2011 12:48:15 -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 B19DA11E8090 for ; Wed, 26 Oct 2011 12:48:15 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so2141044vcb.31 for ; Wed, 26 Oct 2011 12:48:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.106.134 with SMTP id x6mr393940vco.26.1319658493006; Wed, 26 Oct 2011 12:48:13 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Wed, 26 Oct 2011 12:48:12 -0700 (PDT) In-Reply-To: <03898B72-CEEB-4A75-850A-5E453213418D@acmepacket.com> References: <42322A10-14A7-4600-820D-7612A1B12592@cisco.com> <3747C7CB-C039-4D15-A46C-8FDB9A47AF3A@acmepacket.com> <201110261756.p9QHuke7006749@mtv-core-1.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233D45FF4@ESESSCMS0356.eemea.ericsson.se> <03898B72-CEEB-4A75-850A-5E453213418D@acmepacket.com> Date: Wed, 26 Oct 2011 21:48:12 +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: "rtcweb@ietf.org" Subject: Re: [rtcweb] Consensus Call: RTCWeb Terminology X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2011 19:48:16 -0000 2011/10/26 Hadriel Kaplan : > I think you mean a WebSBC. > > ;) I'll be happy if I never see a "WebRTC ALG Router" :) --=20 I=C3=B1aki Baz Castillo From HKaplan@acmepacket.com Wed Oct 26 13: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 AC05F21F854F for ; Wed, 26 Oct 2011 13:09:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=-0.001, 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 SLBx-1dGy-wA for ; Wed, 26 Oct 2011 13:09:17 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 29D7E21F854D for ; Wed, 26 Oct 2011 13:09:16 -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, 26 Oct 2011 16:09:12 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.232]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Wed, 26 Oct 2011 16:09:13 -0400 From: Hadriel Kaplan To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= Thread-Topic: [rtcweb] Consensus Call: RTCWeb Terminology Thread-Index: AQHMlBsgEKECh+8lQkm6uqfqXW9quA== Date: Wed, 26 Oct 2011 20:09:11 +0000 Message-ID: <05A4533D-5AB0-4E2B-9AEA-6B1D65BB493F@acmepacket.com> References: <42322A10-14A7-4600-820D-7612A1B12592@cisco.com> <3747C7CB-C039-4D15-A46C-8FDB9A47AF3A@acmepacket.com> <201110261756.p9QHuke7006749@mtv-core-1.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233D45FF4@ESESSCMS0356.eemea.ericsson.se> <03898B72-CEEB-4A75-850A-5E453213418D@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: text/plain; charset="iso-8859-1" Content-ID: <6803D20D17F18D4AA8661D6EE2C1BF0D@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Consensus Call: RTCWeb Terminology X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2011 20:09:17 -0000 Agreed - ALGs are bad. B2BUAs, on the other hand, are quite useful. ;) On Oct 26, 2011, at 3:48 PM, I=F1aki Baz Castillo wrote: > 2011/10/26 Hadriel Kaplan : >> I think you mean a WebSBC. >>=20 >> ;) >=20 > I'll be happy if I never see a "WebRTC ALG Router" :) >=20 > --=20 > I=F1aki Baz Castillo > From HKaplan@acmepacket.com Wed Oct 26 13:11: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 4AE6A21F84FB for ; Wed, 26 Oct 2011 13:11:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.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 El2xJw762zv4 for ; Wed, 26 Oct 2011 13:11:35 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id BBC6221F84F9 for ; Wed, 26 Oct 2011 13:11:35 -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, 26 Oct 2011 16:11:34 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.232]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Wed, 26 Oct 2011 16:11:35 -0400 From: Hadriel Kaplan To: "" Thread-Topic: [rtcweb] Consensus Call: RTCWeb Terminology Thread-Index: AQHMlBt1EKECh+8lQkm6uqfqXW9quA== Date: Wed, 26 Oct 2011 20:11:33 +0000 Message-ID: References: <42322A10-14A7-4600-820D-7612A1B12592@cisco.com> <3747C7CB-C039-4D15-A46C-8FDB9A47AF3A@acmepacket.com> <4EA8466D.9090808@alcatel-lucent.com> In-Reply-To: <4EA8466D.9090808@alcatel-lucent.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="us-ascii" Content-ID: <856B358777C31241A0E79604399A6BB7@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [rtcweb] Consensus Call: RTCWeb Terminology X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2011 20:11:36 -0000 On Oct 26, 2011, at 1:42 PM, Igor Faynberg wrote: > Having passed this milestone, maybe it is time to start a Terminology RFC= ? I propose we do that in draft-ietf-rtcweb-overview, which already has a ter= minology section, but needs the new terminology added. I think people would naturally gravitate to reading an "Overview" document = first, so having the terminology within it makes sense methinks. -hadriel From igor.faynberg@alcatel-lucent.com Wed Oct 26 13:13: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 EE21B21F8505 for ; Wed, 26 Oct 2011 13:13:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.799 X-Spam-Level: X-Spam-Status: No, score=-5.799 tagged_above=-999 required=5 tests=[AWL=0.800, 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 avusSe6X0sSn for ; Wed, 26 Oct 2011 13:13:14 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 4D39021F84F9 for ; Wed, 26 Oct 2011 13:13:14 -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 p9QKDDWe007012 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 26 Oct 2011 15:13:13 -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 p9QKDCoM027280 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 26 Oct 2011 15:13:13 -0500 Received: from [135.222.134.155] (USMUYN0L055118.mh.lucent.com [135.222.134.155]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p9QKDA9F002580; Wed, 26 Oct 2011 15:13:11 -0500 (CDT) Message-ID: <4EA869D6.2000505@alcatel-lucent.com> Date: Wed, 26 Oct 2011 16:13:10 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------050101040203040404020101" X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Subject: Re: [rtcweb] High level agenda for Taipei meeting 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, 26 Oct 2011 20:13:15 -0000 This is a multi-part message in MIME format. --------------050101040203040404020101 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Ted, I am pretty happy with the list as is, but personally I would prefer starting the security and codec discussions on Tuesday (so that they could spill into Thursday if unfinished). Igor On 10/25/2011 12:11 PM, Ted Hardie wrote: > Hi folks, > > We're currently allocated meetings on Tuesday and Thursday morning, > each of which is 2 1/2 hours long. The chairs' current thinking is to > allocate the time along these lines: > > Draft high-level Agenda for the Taipei meeting > > Tuesday: > > 10 Administrivia + pointers to other meetings in the week > 90 Signaling discussion > 30 Glare proposal > 10 Update from AVTCore on multiplexing > > Thursday: > 90 Security > 30 Data Channel > 30 Codecs > > Please send any initial thoughts on this split to the list. > > thanks, > > Ted, Cullen, and Magnus > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --------------050101040203040404020101 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Ted,

I am pretty happy with the list as is, but personally I would prefer starting the security and codec discussions on Tuesday (so that they could spill into Thursday if unfinished).

Igor

On 10/25/2011 12:11 PM, Ted Hardie wrote:
Hi folks,

We're currently allocated meetings on Tuesday and Thursday morning, each of which is 2 1/2 hours long.  The chairs' current thinking is to allocate the time along these lines:

Draft high-level Agenda for the Taipei meeting

Tuesday:

10 Administrivia + pointers to other meetings in the week
90 Signaling discussion
30 Glare proposal
10 Update from AVTCore on multiplexing

Thursday:
90 Security
30 Data Channel
30 Codecs

Please send any initial thoughts on this split to the list.

thanks,

Ted, Cullen,  and Magnus


_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb
--------------050101040203040404020101-- From HKaplan@acmepacket.com Wed Oct 26 13:28: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 AC67E21F8B54 for ; Wed, 26 Oct 2011 13:28:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.452 X-Spam-Level: X-Spam-Status: No, score=-2.452 tagged_above=-999 required=5 tests=[AWL=0.147, 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 bL4KV3VnS7GW for ; Wed, 26 Oct 2011 13:28:58 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id EF05B21F8B5A for ; Wed, 26 Oct 2011 13:28: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; Wed, 26 Oct 2011 16:28:52 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.232]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Wed, 26 Oct 2011 16:28:53 -0400 From: Hadriel Kaplan To: "rtcweb@ietf.org" Thread-Topic: Layers in draft-jesup-rtcweb-data-00 Thread-Index: AQHMlB3fbG1JmEkK/Ei1cwlsKo8CDg== Date: Wed, 26 Oct 2011 20:28:51 +0000 Message-ID: <32CC659B-8EBF-4C16-8605-5D823DA22A8D@acmepacket.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="us-ascii" Content-ID: <7B29662E6877774ABDEDAB6320CA7964@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Subject: [rtcweb] Layers in draft-jesup-rtcweb-data-00 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2011 20:28:58 -0000 Howdy, Just to make sure I understand this right, the choice isn't really this: +------+ +------+ |WEBAPP| |WEBAPP| +------+ +------+ | DTLS | | SCTP | +-------------+ +-------------+ | STUN | SCTP | | STUN | DTLS | +-------------+ +-------------+ | UDP | | UDP | +-------------+ +-------------+ But rather this: +------+ +------+ |WEBAPP| |WEBAPP| +------+------+------+ +------+------+------+ | DTLS | Audio| Video| | SCTP | Audio| Video| +---------------------------+ +---------------------------+ | STUN | SCTP |S/RTP |S/RTP | | STUN | DTLS |S/RTP |S/RTP | +---------------------------+ +---------------------------+ | Mux/Demux | | Mux/Demux | +---------------------------+ +---------------------------+ | UDP | | UDP | +---------------------------+ +---------------------------+ [Note: "S/RTP" =3D SRTP/SRTCP or RTP/RTCP, "Mux/Demux" =3D tiny logic to mu= x/demux] Because the audio/video streams may be using the same UDP port, right? And the two "S/RTP" boxes may be just one box depending on how the MMUSIC m= ultiplexing decision turns out. So if we want to choose the left one, because we expect/want that someday t= he Operating System provides a SCTP/UDP stack in the kernel, and I think we= do, could it do so while demuxing and letting STUN, RTP, and DTLS go up to= the app layer? (i.e., given a socket/BIO/FD model) I have no idea about = such things... just asking. -hadriel From christer.holmberg@ericsson.com Wed Oct 26 13:34: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 D4C6E11E8097 for ; Wed, 26 Oct 2011 13:34:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.189 X-Spam-Level: X-Spam-Status: No, score=-6.189 tagged_above=-999 required=5 tests=[AWL=0.410, 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 5IEP3UyOeyZU for ; Wed, 26 Oct 2011 13:34:24 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 1690A11E8090 for ; Wed, 26 Oct 2011 13:34:23 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-a4-4ea86eceb66d Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 0A.8E.20773.ECE68AE4; Wed, 26 Oct 2011 22:34:22 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Wed, 26 Oct 2011 22:34:21 +0200 From: Christer Holmberg To: Hadriel Kaplan , "rtcweb@ietf.org" Date: Wed, 26 Oct 2011 22:31:55 +0200 Thread-Topic: Layers in draft-jesup-rtcweb-data-00 Thread-Index: AQHMlB3fbG1JmEkK/Ei1cwlsKo8CDpWPFF4n Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852233C3B82B@ESESSCMS0356.eemea.ericsson.se> References: <32CC659B-8EBF-4C16-8605-5D823DA22A8D@acmepacket.com> In-Reply-To: <32CC659B-8EBF-4C16-8605-5D823DA22A8D@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== Subject: Re: [rtcweb] Layers in draft-jesup-rtcweb-data-00 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2011 20:34:25 -0000 Hi, > And the two "S/RTP" boxes may be just one box depending on how the MMUSIC= multiplexing decision turns out. In MMUSIC we will discuss how to negotiate multiplexing using SDP, but how = the multiplexing itself is actually done I think will be discussed elsewher= e (avtcore?). Regards, Christer From Michael.Tuexen@lurchi.franken.de Wed Oct 26 13: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 E60E921F8B89 for ; Wed, 26 Oct 2011 13:45:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.684 X-Spam-Level: X-Spam-Status: No, score=-1.684 tagged_above=-999 required=5 tests=[AWL=0.615, 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 GWq8KdjQDzn6 for ; Wed, 26 Oct 2011 13:45:04 -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 1F1AF21F8B88 for ; Wed, 26 Oct 2011 13:45:03 -0700 (PDT) Received: from [192.168.1.200] (p508F9F31.dip.t-dialin.net [80.143.159.49]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id A2F9D1C0B4622; Wed, 26 Oct 2011 22:45:01 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Michael_T=FCxen?= In-Reply-To: <32CC659B-8EBF-4C16-8605-5D823DA22A8D@acmepacket.com> Date: Wed, 26 Oct 2011 22:45:00 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8624F864-AB28-4CE7-AB8D-8A55B08AD745@lurchi.franken.de> References: <32CC659B-8EBF-4C16-8605-5D823DA22A8D@acmepacket.com> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1251.1) Cc: rtcweb@ietf.org, Randall Stewart Subject: Re: [rtcweb] Layers in draft-jesup-rtcweb-data-00 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2011 20:45:05 -0000 On Oct 26, 2011, at 10:28 PM, Hadriel Kaplan wrote: > Howdy, > Just to make sure I understand this right, the choice isn't really = this: >=20 > +------+ +------+ > |WEBAPP| |WEBAPP| > +------+ +------+ > | DTLS | | SCTP | > +-------------+ +-------------+ > | STUN | SCTP | | STUN | DTLS | > +-------------+ +-------------+ > | UDP | | UDP | > +-------------+ +-------------+ >=20 > But rather this: >=20 > +------+ +------+ > |WEBAPP| |WEBAPP| > +------+------+------+ +------+------+------+ > | DTLS | Audio| Video| | SCTP | Audio| Video| > +---------------------------+ +---------------------------+ > | STUN | SCTP |S/RTP |S/RTP | | STUN | DTLS |S/RTP |S/RTP | > +---------------------------+ +---------------------------+ > | Mux/Demux | | Mux/Demux | > +---------------------------+ +---------------------------+ > | UDP | | UDP | > +---------------------------+ +---------------------------+ >=20 > [Note: "S/RTP" =3D SRTP/SRTCP or RTP/RTCP, "Mux/Demux" =3D tiny logic = to mux/demux] >=20 > Because the audio/video streams may be using the same UDP port, right? >=20 > And the two "S/RTP" boxes may be just one box depending on how the = MMUSIC multiplexing decision turns out. >=20 > So if we want to choose the left one, because we expect/want that = someday the Operating System provides a SCTP/UDP stack in the kernel, = and I think we do, could it do so while demuxing and letting STUN, RTP, = and DTLS go up to the app layer? (i.e., given a socket/BIO/FD model) I = have no idea about such things... just asking. This is not possible today. The demultiplexing seems to be specific to = this scenario. Not sure it fits. For demuxing you use the first byte to distinguish = STUN from DTLS and SRTP. The first byte us the high order byte of the source port. Once could = require SCTP to use source ports with the high order byte > 192. That might = work. However, you would need to get the Mux/Demux into the kernel. Could be = done using a socket option. But I'm not sure it really fits. Maybe Randy has = an opinion. Best regards Michael >=20 > -hadriel >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 From igor.faynberg@alcatel-lucent.com Wed Oct 26 14:28: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 CFAA221F8B3A for ; Wed, 26 Oct 2011 14:28:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.199 X-Spam-Level: X-Spam-Status: No, score=-6.199 tagged_above=-999 required=5 tests=[AWL=0.400, 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 hIJprJQyp8-j for ; Wed, 26 Oct 2011 14:28:47 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 43CB121F8B34 for ; Wed, 26 Oct 2011 14:28:47 -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 p9QLSk4S010121 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 26 Oct 2011 16:28:46 -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 p9QLSkv4031990 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 26 Oct 2011 16:28:46 -0500 Received: from [135.222.134.155] (USMUYN0L055118.mh.lucent.com [135.222.134.155]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p9QLSjhI001510; Wed, 26 Oct 2011 16:28:45 -0500 (CDT) Message-ID: <4EA87B8D.40409@alcatel-lucent.com> Date: Wed, 26 Oct 2011 17:28:45 -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: <5806E943-CFB4-41F0-BEF2-2FA2F98B0B50@acmepacket.com> In-Reply-To: <5806E943-CFB4-41F0-BEF2-2FA2F98B0B50@acmepacket.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.12 Subject: Re: [rtcweb] High level agenda for Taipei meeting 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, 26 Oct 2011 21:28:47 -0000 +1 Igor On 10/25/2011 5:43 PM, Hadriel Kaplan wrote: > Similar to the "Update from AVTCore on multiplexing", can we allocate some time (10 mins?) and get an update on what's going on on the W3C side, like any outcomes relevant to us from next-week's meeting? > > I gather it's a closed-door meeting, but still it would be nice to know what's up - like on the UI security/permissions, which may impact what we can do in the IETF for SRTP and DTLS. > > -hadriel > > > On Oct 25, 2011, at 12:11 PM, Ted Hardie wrote: > >> Hi folks, >> >> We're currently allocated meetings on Tuesday and Thursday morning, each of which is 2 1/2 hours long. The chairs' current thinking is to allocate the time along these lines: >> >> Draft high-level Agenda for the Taipei meeting >> >> Tuesday: >> >> 10 Administrivia + pointers to other meetings in the week >> 90 Signaling discussion >> 30 Glare proposal >> 10 Update from AVTCore on multiplexing >> >> Thursday: >> 90 Security >> 30 Data Channel >> 30 Codecs >> >> Please send any initial thoughts on this split to the list. >> >> thanks, >> >> Ted, Cullen, and Magnus >> >> _______________________________________________ >> 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 D.Malas@cablelabs.com Wed Oct 26 14: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 1B16421F8B34 for ; Wed, 26 Oct 2011 14:33:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.463 X-Spam-Level: X-Spam-Status: No, score=-100.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TjCaQbP15uch for ; Wed, 26 Oct 2011 14:33:27 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 89A4921F8AB0 for ; Wed, 26 Oct 2011 14:33:27 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id p9QLXK4l001552; Wed, 26 Oct 2011 15:33:21 -0600 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Wed, 26 Oct 2011 15:33:20 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Wed, 26 Oct 2011 15:33:21 -0600 From: Daryl Malas To: Hadriel Kaplan , "" Date: Wed, 26 Oct 2011 15:33:20 -0600 Thread-Topic: [rtcweb] Consensus Call: RTCWeb Terminology Thread-Index: AcyUJuIxjVRKWmFaQL62iJe6mhRyjA== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Approved: ondar Cc: "" Subject: Re: [rtcweb] Consensus Call: RTCWeb Terminology X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2011 21:33:28 -0000 I agree with Hadriel. I think including all general WebRTC terminology in the overview is the right thing to do. --Daryl On 10/26/11 2:11 PM, "Hadriel Kaplan" wrote: > >On Oct 26, 2011, at 1:42 PM, Igor Faynberg wrote: > >> Having passed this milestone, maybe it is time to start a Terminology >>RFC? > >I propose we do that in draft-ietf-rtcweb-overview, which already has a >terminology section, but needs the new terminology added. >I think people would naturally gravitate to reading an "Overview" >document first, so having the terminology within it makes sense methinks. > >-hadriel > >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb From harald@alvestrand.no Wed Oct 26 15:29: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 256D221F8B75 for ; Wed, 26 Oct 2011 15:29:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.999 X-Spam-Level: X-Spam-Status: No, score=-108.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_BACKHAIR_27=1, J_CHICKENPOX_66=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 4fnrTTFpuR+E for ; Wed, 26 Oct 2011 15:29:36 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 82B2611E8080 for ; Wed, 26 Oct 2011 15:29:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D269339E106 for ; Thu, 27 Oct 2011 00:29: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 aWDrtJ1yidmZ for ; Thu, 27 Oct 2011 00:29:35 +0200 (CEST) Received: from [172.31.154.128] (unknown [72.14.229.81]) by eikenes.alvestrand.no (Postfix) with ESMTPS id A9C8439E082 for ; Thu, 27 Oct 2011 00:29:34 +0200 (CEST) Message-ID: <4EA889CC.3090001@alvestrand.no> Date: Wed, 26 Oct 2011 15:29:32 -0700 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: rtcweb@ietf.org References: <42322A10-14A7-4600-820D-7612A1B12592@cisco.com> <3747C7CB-C039-4D15-A46C-8FDB9A47AF3A@acmepacket.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [rtcweb] WebRTC definition (Re: Consensus Call: RTCWeb Terminology) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2011 22:29:37 -0000 On 10/26/2011 10:17 AM, Cullen Jennings wrote: > With my chair hat on ... > > I'd like to declare we currently have consensus for Hadriel's proposal that the technology should be referred to as "WebRTC" and the API as the "WebRTC API". The IETF WG name is still RTCWeb, the mailing list is still rtcweb@ietf.org, the IETF drafts should still have "-rtcweb-" in them to indicate the WG name. As -overview editor, I'm happy to include this definition. Just because I have to write it in a terminology list, I wonder how I should define it. Is it an effort? A technology? A project? It should be something like: WebRTC A that to enable peer to peer audio and video between browsers on the Internet. Components of WebRTC include a protocol profile, defined in the IETF, of which this document gives an overview, and an API, defined in the W3C, and specified in Suggestions for the s (or alternate formulations) would be most welcome. Harald > Cullen > > > On Oct 24, 2011, at 10:56 AM, Hadriel Kaplan wrote: > >> For the API, the consensus was it would be confusing to people if we weren't consistent with W3C docs. >> >> So I propose the following: >> >> WebRTC: the whole shebang >> WebRTC API: the JS<->Browser API. >> >> -hadriel > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From jim.mceachern@genband.com Wed Oct 26 19:21: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 ACCB021F85AA for ; Wed, 26 Oct 2011 19:21:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.999 X-Spam-Level: X-Spam-Status: No, score=-4.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_BACKHAIR_27=1, J_CHICKENPOX_66=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 hvh1nN-uppWz for ; Wed, 26 Oct 2011 19:21:29 -0700 (PDT) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id 9207F21F84B3 for ; Wed, 26 Oct 2011 19:21:22 -0700 (PDT) Received: from mail.genband.com ([63.149.188.88]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP; Wed, 26 Oct 2011 19:21:25 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); Wed, 26 Oct 2011 21:21:01 -0500 Received: from GBPLMAIL02.genband.com ([fe80::9455:4039:582f:aee8]) by gbex02.genband.com ([fe80::d038:d922:68b6:b18e%14]) with mapi id 14.01.0339.001; Wed, 26 Oct 2011 21:20:56 -0500 From: Jim McEachern To: Harald Alvestrand , "rtcweb@ietf.org" Thread-Topic: [rtcweb] WebRTC definition (Re: Consensus Call: RTCWeb Terminology) Thread-Index: AQHMlC6/wB/LrtI+pkWxD+xy+BZUrZWPcxXw Date: Thu, 27 Oct 2011 02:20:55 +0000 Message-ID: <8584590C8D7DD141AA96D01920FC6C698C8CBDB5@gbplmail02.genband.com> References: <42322A10-14A7-4600-820D-7612A1B12592@cisco.com> <3747C7CB-C039-4D15-A46C-8FDB9A47AF3A@acmepacket.com> <4EA889CC.3090001@alvestrand.no> In-Reply-To: <4EA889CC.3090001@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.35.81.184] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 27 Oct 2011 02:21:01.0101 (UTC) FILETIME=[11ED8DD0:01CC944F] X-TM-AS-Product-Ver: SMEX-8.0.0.4160-6.500.1024-18474.003 X-TM-AS-Result: No--24.502800-5.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Subject: Re: [rtcweb] WebRTC definition (Re: Consensus Call: RTCWeb Terminology) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 02:21:29 -0000 How about this? WebRTC A collaborative standards effort between the IETF and W3C that specif= ies a JavaScript API and architectural context, to enable real-time peer to= peer audio, video and data communication between browsers on the Internet. Components of WebRTC include a protocol profile, defined in the IETF, = of which this document gives an overview, and an API, defined in the W3C, and specified in Jim > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of Harald Alvestrand > Sent: Wednesday, October 26, 2011 6:30 PM > To: rtcweb@ietf.org > Subject: [rtcweb] WebRTC definition (Re: Consensus Call: RTCWeb > Terminology) >=20 > On 10/26/2011 10:17 AM, Cullen Jennings wrote: > > With my chair hat on ... > > > > I'd like to declare we currently have consensus for Hadriel's proposal = that > the technology should be referred to as "WebRTC" and the API as the > "WebRTC API". The IETF WG name is still RTCWeb, the mailing list is still > rtcweb@ietf.org, the IETF drafts should still have "-rtcweb-" in them to > indicate the WG name. >=20 > As -overview editor, I'm happy to include this definition. >=20 > Just because I have to write it in a terminology list, I wonder how I sho= uld > define it. >=20 > Is it an effort? A technology? A project? >=20 > It should be something like: >=20 > WebRTC > A that to enable peer to peer audio and vide= o > between browsers > on the Internet. > Components of WebRTC include a protocol profile, defined in the IETF= , of > which this document > gives an overview, and an API, defined in the W3C, and specified in > >=20 > Suggestions for the s (or alternate formulations) would be mos= t > welcome. >=20 > Harald >=20 >=20 >=20 > > Cullen > > > > > > On Oct 24, 2011, at 10:56 AM, Hadriel Kaplan wrote: > > > >> For the API, the consensus was it would be confusing to people if we > weren't consistent with W3C docs. > >> > >> So I propose the following: > >> > >> WebRTC: the whole shebang > >> WebRTC API: the JS<->Browser API. > >> > >> -hadriel > > _______________________________________________ > > 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 HKaplan@acmepacket.com Wed Oct 26 21:41: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 4065621F85A1 for ; Wed, 26 Oct 2011 21:41:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.654 X-Spam-Level: X-Spam-Status: No, score=-1.654 tagged_above=-999 required=5 tests=[AWL=-0.655, BAYES_00=-2.599, J_BACKHAIR_27=1, J_CHICKENPOX_66=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 rB1T7yzWD6zd for ; Wed, 26 Oct 2011 21:41:31 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 9A7F421F858C for ; Wed, 26 Oct 2011 21:41:31 -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, 27 Oct 2011 00:41:27 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.232]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Thu, 27 Oct 2011 00:41:26 -0400 From: Hadriel Kaplan To: Jim McEachern Thread-Topic: [rtcweb] WebRTC definition (Re: Consensus Call: RTCWeb Terminology) Thread-Index: AQHMlGKv81f3yWlf70+pG1hOEUcEFw== Date: Thu, 27 Oct 2011 04:41:25 +0000 Message-ID: <6B150F64-7D66-4A6D-B1B1-579CFC9363C0@acmepacket.com> References: <42322A10-14A7-4600-820D-7612A1B12592@cisco.com> <3747C7CB-C039-4D15-A46C-8FDB9A47AF3A@acmepacket.com> <4EA889CC.3090001@alvestrand.no> <8584590C8D7DD141AA96D01920FC6C698C8CBDB5@gbplmail02.genband.com> In-Reply-To: <8584590C8D7DD141AA96D01920FC6C698C8CBDB5@gbplmail02.genband.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] WebRTC definition (Re: Consensus Call: RTCWeb Terminology) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 04:41:32 -0000 How about: WebRTC A technology and platform that enables real-time, interactive peer to = peer audio, video and data communication between browsers on the Internet. = Components of WebRTC include a protocol profile, defined in the IETF, of w= hich this document gives an overview, and an API, defined in the W3C, and s= pecified in . -hadriel On Oct 26, 2011, at 10:20 PM, Jim McEachern wrote: > How about this? >=20 > WebRTC > A collaborative standards effort between the IETF and W3C that speci= fies a JavaScript API and architectural context, to enable real-time peer t= o peer audio, video and data communication between browsers > on the Internet. > Components of WebRTC include a protocol profile, defined in the IETF,= of which this document > gives an overview, and an API, defined in the W3C, and specified in <= reference> >=20 > Jim >=20 >> -----Original Message----- >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >> Behalf Of Harald Alvestrand >> Sent: Wednesday, October 26, 2011 6:30 PM >> To: rtcweb@ietf.org >> Subject: [rtcweb] WebRTC definition (Re: Consensus Call: RTCWeb >> Terminology) >>=20 >> On 10/26/2011 10:17 AM, Cullen Jennings wrote: >>> With my chair hat on ... >>>=20 >>> I'd like to declare we currently have consensus for Hadriel's proposal = that >> the technology should be referred to as "WebRTC" and the API as the >> "WebRTC API". The IETF WG name is still RTCWeb, the mailing list is stil= l >> rtcweb@ietf.org, the IETF drafts should still have "-rtcweb-" in them to >> indicate the WG name. >>=20 >> As -overview editor, I'm happy to include this definition. >>=20 >> Just because I have to write it in a terminology list, I wonder how I sh= ould >> define it. >>=20 >> Is it an effort? A technology? A project? >>=20 >> It should be something like: >>=20 >> WebRTC >> A that to enable peer to peer audio and vide= o >> between browsers >> on the Internet. >> Components of WebRTC include a protocol profile, defined in the IETF= , of >> which this document >> gives an overview, and an API, defined in the W3C, and specified in >> >>=20 >> Suggestions for the s (or alternate formulations) would be mo= st >> welcome. >>=20 >> Harald >>=20 >>=20 >>=20 >>> Cullen >>>=20 >>>=20 >>> On Oct 24, 2011, at 10:56 AM, Hadriel Kaplan wrote: >>>=20 >>>> For the API, the consensus was it would be confusing to people if we >> weren't consistent with W3C docs. >>>>=20 >>>> So I propose the following: >>>>=20 >>>> WebRTC: the whole shebang >>>> WebRTC API: the JS<->Browser API. >>>>=20 >>>> -hadriel >>> _______________________________________________ >>> 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 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From ibc@aliax.net Thu Oct 27 01:55: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 24B5221F86A5 for ; Thu, 27 Oct 2011 01:55:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.64 X-Spam-Level: X-Spam-Status: No, score=-2.64 tagged_above=-999 required=5 tests=[AWL=0.037, 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 5ENE2E+7Ld88 for ; Thu, 27 Oct 2011 01:55:05 -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 898E421F8672 for ; Thu, 27 Oct 2011 01:55:05 -0700 (PDT) Received: by qyk34 with SMTP id 34so419693qyk.10 for ; Thu, 27 Oct 2011 01:55:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.73.36 with SMTP id i4mr6215773obv.24.1319705704679; Thu, 27 Oct 2011 01:55:04 -0700 (PDT) Received: by 10.182.220.66 with HTTP; Thu, 27 Oct 2011 01:55:04 -0700 (PDT) In-Reply-To: References: Date: Thu, 27 Oct 2011 10:55:04 +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] draft-sipdoc-rtcweb-open-wire-protocol-00 (Open In-The-Wire Protocol for RTC-Web) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 08:55:06 -0000 2011/10/25 I=C3=B1aki Baz Castillo : > A new I-D draft-sipdoc-rtcweb-open-wire-protocol-00.txt has been > successfully submitted by I=C3=B1aki Baz Castillo, =C2=A0Sa=C3=BAl Ibarra= Corretg=C3=A9 > and Jos=C3=A9 Luis Mill=C3=A1n Villegas, and posted to the IETF repositor= y. > > Filename: =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-sipdoc-rtcweb-open-wire-protoc= olRevision: > =C2=A000Title: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Open In-The-Wire Protoc= ol for RTC-WebCreation > date: =C2=A0 2011-10-25WG ID: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individu= al SubmissionNumber of > pages: 22 > > > http://tools.ietf.org/html/draft-sipdoc-rtcweb-open-wire-protocol-00 > http://www.ietf.org/id/draft-sipdoc-rtcweb-open-wire-protocol-00.txt > > > Abstract:=C2=A0 RTC-Web clients communicate with a server in order to > request or=C2=A0 manage realtime communications with other users. =C2=A0T= his > document=C2=A0 exposes four hypothetical and different RTC-Web scenarios > and=C2=A0 analyzes the requirements of the in-the-wire protocol in each o= f > them. > =C2=A0 The aim of this document is to make RTC-Web properly fit in the > nature of the Web. Hi, just wondering if somebody has read this informational draft. I'd would really appreciate if folks agree with the conclusiones and requirements exposed in the document or want to discuss about them. The draft tries to clarify the scope of RTC-Web, and IMHO that's an important milestone before we can move on. Thanks a lot. --=20 I=C3=B1aki Baz Castillo From Markus.Isomaki@nokia.com Thu Oct 27 03: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 D04F421F8A7B for ; Thu, 27 Oct 2011 03:59:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.849 X-Spam-Level: X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[AWL=-0.250, 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 pSMuIUHBgFG1 for ; Thu, 27 Oct 2011 03:59:29 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 0DAD821F86A5 for ; Thu, 27 Oct 2011 03:59:28 -0700 (PDT) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-sa01.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p9RAxLSr004416; Thu, 27 Oct 2011 13:59:24 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 27 Oct 2011 13:58:58 +0300 Received: from 008-AM1MMR1-004.mgdnok.nokia.com (65.54.30.59) by NOK-AM1MHUB-04.mgdnok.nokia.com (65.54.30.8) with Microsoft SMTP Server (TLS) id 8.2.255.0; Thu, 27 Oct 2011 12:58:58 +0200 Received: from 008-AM1MPN1-042.mgdnok.nokia.com ([169.254.2.190]) by 008-AM1MMR1-004.mgdnok.nokia.com ([65.54.30.59]) with mapi id 14.01.0339.002; Thu, 27 Oct 2011 12:58:57 +0200 From: To: , Thread-Topic: [rtcweb] draft-sipdoc-rtcweb-open-wire-protocol-00 (Open In-The-Wire Protocol for RTC-Web) Thread-Index: AQHMkqFmpMtxG3PM+kiX0/xprSe+EZWPxXIAgABBydA= Date: Thu, 27 Oct 2011 10:58:57 +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: [172.21.73.20] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 27 Oct 2011 10:58:58.0666 (UTC) FILETIME=[6D99A4A0:01CC9497] X-Nokia-AV: Clean Subject: Re: [rtcweb] draft-sipdoc-rtcweb-open-wire-protocol-00 (Open In-The-Wire Protocol for RTC-Web) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 10:59:30 -0000 SGkgScOxYWtpLA0KDQpJw7Fha2kgQmF6IENhc3RpbGxvIHdyb3RlOg0KPg0KPj4NCj4+IGh0dHA6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNpcGRvYy1ydGN3ZWItb3Blbi13aXJlLXByb3Rv Y29sLTAwDQo+PiBodHRwOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LXNpcGRvYy1ydGN3ZWItb3Bl bi13aXJlLXByb3RvY29sLTAwLnR4dA0KPj4NCj4NCj5IaSwganVzdCB3b25kZXJpbmcgaWYgc29t ZWJvZHkgaGFzIHJlYWQgdGhpcyBpbmZvcm1hdGlvbmFsIGRyYWZ0LiBJJ2Qgd291bGQNCj5yZWFs bHkgYXBwcmVjaWF0ZSBpZiBmb2xrcyBhZ3JlZSB3aXRoIHRoZSBjb25jbHVzaW9uZXMgYW5kIHJl cXVpcmVtZW50cw0KPmV4cG9zZWQgaW4gdGhlIGRvY3VtZW50IG9yIHdhbnQgdG8gZGlzY3VzcyBh Ym91dCB0aGVtLg0KDQpZZXMsIEkgZGlkLiBBbmQgSSBkbyBhZ3JlZSB3aXRoIHRoZSBjb25jbHVz aW9ucyBhbmQgdGhlIHJlcXVpcmVtZW50cy4gVGhlcmUgYXJlIG1hbnkgZGlmZmVyZW50IHR5cGVz IG9mIHdlYiBhcHBzIGFuZCB1c2UgY2FzZXMgZm9yIHdoaWNoIHJlYWwtdGltZSBjb21tdW5pY2F0 aW9ucyBpcyB1c2VmdWwuIEZvciBzb21lIGFwcHMgU0lQL1BTVE4gaW50ZXJ3b3JraW5nIGlzIGlt cG9ydGFudC4gT3RoZXJzLCBsaWtlIHRoZSBwb2tlciBzaXRlIGluIHlvdXIgZXhhbXBsZSwganVz dCB3YW50IHRvIGludGVncmF0ZSBzb21ldGhpbmcgc2ltcGxlciwgbGlrZSBhIHZhbmlsbGEgYXVk aW8gY29uZmVyZW5jZSwgdG8gdGhlaXIgZXhpc3Rpbmcgc2VydmljZS4gV2UgbmVlZCB0byBlbmFi bGUgYWxsIG9mIHRoZXNlIGFuZCBob3BlZnVsbHkgYWxzbyBzb21lIG1vcmUgdGhhdCB3ZSBoYXZl bid0IGV2ZW4gdGhvdWdodCBhYm91dCBpbiB0aGUgc3RhbmRhcmRzIGdyb3VwcyBvciB0aGUgY3Vy cmVudCBiaWcgY29ycG9yYXRpb25zLg0KDQpNYXJrdXMNCg== From Markus.Isomaki@nokia.com Thu Oct 27 04:48:29 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75A2E21F85A8 for ; Thu, 27 Oct 2011 04:48:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.266 X-Spam-Level: X-Spam-Status: No, score=-3.266 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 L-ni07YofIOC for ; Thu, 27 Oct 2011 04:48:29 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id D9F1F21F85A7 for ; Thu, 27 Oct 2011 04:48:28 -0700 (PDT) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p9RBmQuT023285; Thu, 27 Oct 2011 14:48:26 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 27 Oct 2011 14:48:25 +0300 Received: from 008-AM1MMR1-009.mgdnok.nokia.com (65.54.30.25) by NOK-am1MHUB-01.mgdnok.nokia.com (65.54.30.5) with Microsoft SMTP Server (TLS) id 8.2.255.0; Thu, 27 Oct 2011 13:48:25 +0200 Received: from 008-AM1MPN1-042.mgdnok.nokia.com ([169.254.2.190]) by 008-AM1MMR1-009.mgdnok.nokia.com ([65.54.30.25]) with mapi id 14.01.0339.002; Thu, 27 Oct 2011 13:48:25 +0200 From: To: Thread-Topic: [rtcweb] Relationship of ROAP and PeerConnection? Thread-Index: AcyTrUF2bQp0uHgLRMajaerMxZL05QAL2O0AAC6zqKA= Date: Thu, 27 Oct 2011 11:48:24 +0000 Message-ID: References: <1D1CC4EE-0002-4638-B42F-760C2D6F29B8@cisco.com> In-Reply-To: <1D1CC4EE-0002-4638-B42F-760C2D6F29B8@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.21.73.20] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 27 Oct 2011 11:48:25.0997 (UTC) FILETIME=[56446BD0:01CC949E] X-Nokia-AV: Clean Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Relationship of ROAP and PeerConnection? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 11:48:29 -0000 Hi Cullen, Cullen Jennings wrote: > >Right now, I'm just trying to >focus on does the idea look like it is on the right path regardless of whi= ch >document it is in. My initial assumption was that we'd not even standardize things on the leve= l of ROAP or SDP O/A, but more along the lines what Hadriel and others have= been advocating. But ROAP and PeerConnection look quite decent, and for in= stance I=F1aki's draft (http://datatracker.ietf.org/doc/draft-sipdoc-rtcweb= -open-wire-protocol) show how they could be used in quite diverse ways. So,= continuing on that path seems fine to me. This way we may have something c= oncrete within a year. At least I don't think we should go any further than= what ROAP does in defining a specific session setup protocol.=20 Markus From ibc@aliax.net Thu Oct 27 04:57: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 84A4621F899F for ; Thu, 27 Oct 2011 04:57:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.64 X-Spam-Level: X-Spam-Status: No, score=-2.64 tagged_above=-999 required=5 tests=[AWL=0.037, 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 AasX-MM1yJsm for ; Thu, 27 Oct 2011 04:57:25 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id EBA8D21F899D for ; Thu, 27 Oct 2011 04:57:24 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so2784465vcb.31 for ; Thu, 27 Oct 2011 04:57:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.1.16 with SMTP id 16mr1001072vcd.166.1319716643068; Thu, 27 Oct 2011 04:57:23 -0700 (PDT) Received: by 10.220.159.134 with HTTP; Thu, 27 Oct 2011 04:57:22 -0700 (PDT) In-Reply-To: References: Date: Thu, 27 Oct 2011 13:57:22 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Markus.Isomaki@nokia.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] draft-sipdoc-rtcweb-open-wire-protocol-00 (Open In-The-Wire Protocol for RTC-Web) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 11:57:25 -0000 2011/10/27 : > I=C3=B1aki Baz Castillo wrote: >>> http://tools.ietf.org/html/draft-sipdoc-rtcweb-open-wire-protocol-00 >>> http://www.ietf.org/id/draft-sipdoc-rtcweb-open-wire-protocol-00.txt >> >>Hi, just wondering if somebody has read this informational draft. I'd wou= ld >>really appreciate if folks agree with the conclusiones and requirements >>exposed in the document or want to discuss about them. > > Yes, I did. And I do agree with the conclusions and the requirements. The= re are many different types of web apps and use cases for which real-time c= ommunications is useful. For some apps SIP/PSTN interworking is important. = Others, like the poker site in your example, just want to integrate somethi= ng simpler, like a vanilla audio conference, to their existing service. We = need to enable all of these and hopefully also some more that we haven't ev= en thought about in the standards groups or the current big corporations. Thanks a lot Markus. --=20 I=C3=B1aki Baz Castillo From jim.mceachern@genband.com Thu Oct 27 06:55: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 291A021F8669 for ; Thu, 27 Oct 2011 06:55:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.799 X-Spam-Level: X-Spam-Status: No, score=-5.799 tagged_above=-999 required=5 tests=[AWL=0.800, 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 S7f4bvjlPm0X for ; Thu, 27 Oct 2011 06:55:18 -0700 (PDT) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 3C18721F8593 for ; Thu, 27 Oct 2011 06:55:14 -0700 (PDT) Received: from mail.genband.com ([63.149.188.88]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP; Thu, 27 Oct 2011 06:55:18 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); Thu, 27 Oct 2011 08:53:29 -0500 Received: from GBPLMAIL02.genband.com ([fe80::9455:4039:582f:aee8]) by gbex02.genband.com ([fe80::d038:d922:68b6:b18e%14]) with mapi id 14.01.0339.001; Thu, 27 Oct 2011 08:53:29 -0500 From: Jim McEachern To: "Markus.Isomaki@nokia.com" , "ibc@aliax.net" , "rtcweb@ietf.org" Thread-Topic: [rtcweb] draft-sipdoc-rtcweb-open-wire-protocol-00 (Open In-The-Wire Protocol for RTC-Web) Thread-Index: AQHMkqFllo9z8scvq0q1srwtRZ4UyJWQOssAgAAinYD//9nsIA== Date: Thu, 27 Oct 2011 13:53:28 +0000 Message-ID: <8584590C8D7DD141AA96D01920FC6C698C8CC504@gbplmail02.genband.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.35.81.184] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 27 Oct 2011 13:53:29.0617 (UTC) FILETIME=[CEC5F810:01CC94AF] X-TM-AS-Product-Ver: SMEX-8.0.0.4160-6.500.1024-18474.007 X-TM-AS-Result: No--26.068600-5.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Subject: Re: [rtcweb] draft-sipdoc-rtcweb-open-wire-protocol-00 (Open In-The-Wire Protocol for RTC-Web) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 13:55:19 -0000 SGkgScOxYWtpLA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IHJ0Y3dl Yi1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmddIE9uDQo+ IEJlaGFsZiBPZiBNYXJrdXMuSXNvbWFraUBub2tpYS5jb20NCj4gU2VudDogVGh1cnNkYXksIE9j dG9iZXIgMjcsIDIwMTEgNjo1OSBBTQ0KPiBUbzogaWJjQGFsaWF4Lm5ldDsgcnRjd2ViQGlldGYu b3JnDQo+IFN1YmplY3Q6IFJlOiBbcnRjd2ViXSBkcmFmdC1zaXBkb2MtcnRjd2ViLW9wZW4td2ly ZS1wcm90b2NvbC0wMCAoT3BlbiBJbi0NCj4gVGhlLVdpcmUgUHJvdG9jb2wgZm9yIFJUQy1XZWIp DQo+IA0KPiBIaSBJw7Fha2ksDQo+IA0KPiBJw7Fha2kgQmF6IENhc3RpbGxvIHdyb3RlOg0KPiA+ DQo+ID4+DQo+ID4+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNpcGRvYy1ydGN3 ZWItb3Blbi13aXJlLXByb3RvY29sLTAwDQo+ID4+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaWQvZHJh ZnQtc2lwZG9jLXJ0Y3dlYi1vcGVuLXdpcmUtcHJvdG9jb2wtMDAudHh0DQo+ID4+DQo+ID4NCj4g PkhpLCBqdXN0IHdvbmRlcmluZyBpZiBzb21lYm9keSBoYXMgcmVhZCB0aGlzIGluZm9ybWF0aW9u YWwgZHJhZnQuIEknZA0KPiA+d291bGQgcmVhbGx5IGFwcHJlY2lhdGUgaWYgZm9sa3MgYWdyZWUg d2l0aCB0aGUgY29uY2x1c2lvbmVzIGFuZA0KPiA+cmVxdWlyZW1lbnRzIGV4cG9zZWQgaW4gdGhl IGRvY3VtZW50IG9yIHdhbnQgdG8gZGlzY3VzcyBhYm91dCB0aGVtLg0KPiANCj4gWWVzLCBJIGRp ZC4gQW5kIEkgZG8gYWdyZWUgd2l0aCB0aGUgY29uY2x1c2lvbnMgYW5kIHRoZSByZXF1aXJlbWVu dHMuIFRoZXJlDQo+IGFyZSBtYW55IGRpZmZlcmVudCB0eXBlcyBvZiB3ZWIgYXBwcyBhbmQgdXNl IGNhc2VzIGZvciB3aGljaCByZWFsLXRpbWUNCj4gY29tbXVuaWNhdGlvbnMgaXMgdXNlZnVsLiBG b3Igc29tZSBhcHBzIFNJUC9QU1ROIGludGVyd29ya2luZyBpcyBpbXBvcnRhbnQuDQo+IE90aGVy cywgbGlrZSB0aGUgcG9rZXIgc2l0ZSBpbiB5b3VyIGV4YW1wbGUsIGp1c3Qgd2FudCB0byBpbnRl Z3JhdGUgc29tZXRoaW5nDQo+IHNpbXBsZXIsIGxpa2UgYSB2YW5pbGxhIGF1ZGlvIGNvbmZlcmVu Y2UsIHRvIHRoZWlyIGV4aXN0aW5nIHNlcnZpY2UuIFdlIG5lZWQgdG8NCj4gZW5hYmxlIGFsbCBv ZiB0aGVzZSBhbmQgaG9wZWZ1bGx5IGFsc28gc29tZSBtb3JlIHRoYXQgd2UgaGF2ZW4ndCBldmVu DQo+IHRob3VnaHQgYWJvdXQgaW4gdGhlIHN0YW5kYXJkcyBncm91cHMgb3IgdGhlIGN1cnJlbnQg YmlnIGNvcnBvcmF0aW9ucy4NCj4gDQo+IE1hcmt1cw0KDQpJJ3ZlIHJlYWQgdGhlIGRyYWZ0IGFz IHdlbGwsIGFuZCBhZ3JlZSB3aXRoIHRoZSBjb25jbHVzaW9ucy4gSSB0aGluayB0aGUgZGVmaW5p dGlvbiBvZiB0ZXJtcywgYW5kIHRoZSBtZXNzYWdlIGZsb3dzIGZvciB0aGUgdXNlIGNhc2VzIHJl YWxseSBoZWxwIHRvIGNsYXJpZnkgd2hhdCB3ZSBhcmUgcG90ZW50aWFsbHkgYWdyZWVpbmcgdG8u IA0KDQpKaW0NCg== From tim@phonefromhere.com Thu Oct 27 07:02: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 1256B21F8B0D for ; Thu, 27 Oct 2011 07:02:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GxCzXiaPRJqQ for ; Thu, 27 Oct 2011 07:02:17 -0700 (PDT) Received: from zimbra.westhawk.co.uk (zimbra.westhawk.co.uk [192.67.4.167]) by ietfa.amsl.com (Postfix) with ESMTP id AA28C21F8AB8 for ; Thu, 27 Oct 2011 07:02:16 -0700 (PDT) Received: from [10.12.78.125] (64-58-7-107.sta.mho.net [64.58.7.107]) by zimbra.westhawk.co.uk (Postfix) with ESMTP id B10D637A91E; Thu, 27 Oct 2011 15:15:00 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/alternative; boundary="Apple-Mail=_7FEDD31C-4BDA-4A68-86B6-C75B6D2D1579" From: Tim Panton In-Reply-To: Date: Thu, 27 Oct 2011 08:02:09 -0600 Message-Id: <9BA5EFBE-C811-4A53-AE2C-6F11FAF95CBD@phonefromhere.com> References: To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= X-Mailer: Apple Mail (2.1251.1) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] draft-sipdoc-rtcweb-open-wire-protocol-00 (Open In-The-Wire Protocol for RTC-Web) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 14:02:18 -0000 --Apple-Mail=_7FEDD31C-4BDA-4A68-86B6-C75B6D2D1579 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 27 Oct 2011, at 02:55, I=F1aki Baz Castillo wrote: > 2011/10/25 I=F1aki Baz Castillo : >> A new I-D draft-sipdoc-rtcweb-open-wire-protocol-00.txt has been >> successfully submitted by I=F1aki Baz Castillo, Sa=FAl Ibarra = Corretg=E9 >> and Jos=E9 Luis Mill=E1n Villegas, and posted to the IETF repository. >>=20 >> Filename: draft-sipdoc-rtcweb-open-wire-protocolRevision: >> 00Title: Open In-The-Wire Protocol for RTC-WebCreation >> date: 2011-10-25WG ID: Individual SubmissionNumber of >> pages: 22 >>=20 >>=20 >> http://tools.ietf.org/html/draft-sipdoc-rtcweb-open-wire-protocol-00 >> http://www.ietf.org/id/draft-sipdoc-rtcweb-open-wire-protocol-00.txt >>=20 >>=20 >> Abstract: RTC-Web clients communicate with a server in order to >> request or manage realtime communications with other users. This >> document exposes four hypothetical and different RTC-Web scenarios >> and analyzes the requirements of the in-the-wire protocol in each of >> them. >> The aim of this document is to make RTC-Web properly fit in the >> nature of the Web. >=20 >=20 > Hi, just wondering if somebody has read this informational draft. I'd > would really appreciate if folks agree with the conclusiones and > requirements exposed in the document or want to discuss about them. > The draft tries to clarify the scope of RTC-Web, and IMHO that's an > important milestone before we can move on. >=20 > Thanks a lot. Thank you for writing this up - before I had to ;-) I agree with almost all of it, but I wonder if you could add a derived = requirement: " 4. It MUST be possible for a website developer to make his RTC-Web scenario to interoperate with a pure SIP or XMPP/Jingle network without requiring a signaling protocol gateway (by using SIP over WebSocket [I-D.ibc-rtcweb-sip-websocket] or XMPP over WebSocket [I-D.moffitt-xmpp-over-websocket]). 5. It must be possible for a website developer to make his RTC-Web scenario to interoperate without adding new infrastructure unless = they wish to interop with the wider world - i.e. if the=20 mysite.com example wished to operate as an 'island' they would not need to add additional telephony or expertise=20 servers, as all the neccessary server side work could be done in = php by his existing web programmers. " I think this is implied by your document, but I feel it is critically = important=20 so worth explicitly stating it.=20 Tim.= --Apple-Mail=_7FEDD31C-4BDA-4A68-86B6-C75B6D2D1579 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
2011/10/25 I=F1aki Baz Castillo <ibc@aliax.net>:
A new I-D draft-sipdoc-rtcweb-open-wire-protocol-00.txt = has been
successfully = submitted by I=F1aki Baz Castillo,  Sa=FAl Ibarra = Corretg=E9
and Jos=E9 Luis = Mill=E1n Villegas, and posted to the IETF = repository.

Filename: =       =  draft-sipdoc-rtcweb-open-wire-protocolRevision:
 00Title:           = Open In-The-Wire Protocol for = RTC-WebCreation
date:   = 2011-10-25WG ID:           Individual = SubmissionNumber of
pages: = 22


http://tools.ietf.org/html/draft-sipdoc-rtcweb-open-wire-protocol-00
http://www.ietf.org/id/draft-sipdoc-rtcweb-open-wire-protocol-00.txt


Abstract:  = RTC-Web clients communicate with a server in order = to
request or  manage = realtime communications with other users. =  This
document  = exposes four hypothetical and different RTC-Web = scenarios
and  analyzes = the requirements of the in-the-wire protocol in each = of
them.
  The = aim of this document is to make RTC-Web properly fit in = the
nature of the = Web.


Hi, just wondering if somebody has read = this informational draft. I'd
would really appreciate if folks agree = with the conclusiones and
requirements exposed in the document or = want to discuss about them.
The draft tries to clarify the scope of = RTC-Web, and IMHO that's an
important milestone before we can move = on.

Thanks a lot.

Thank you for = writing this up - before I had to ;-)
I agree with almost all of it, = but I wonder if you could add a derived requirement:
"  4. =  It MUST be possible for a website developer to make his = RTC-Web
      scenario to interoperate = with a pure SIP or XMPP/Jingle = network
      without requiring a = signaling protocol gateway (by using SIP = over
      WebSocket = [I-D.ibc-rtcweb-sip-websocket] or XMPP over = WebSocket
      [I-D.moffitt-xmpp-over-we= bsocket]).
 5. It must be possible for a website developer to = make his RTC-Web
      scenario to = interoperate without adding new infrastructure unless they wish = to
      interop with the wider world - = i.e. if the 
      mysite.com example wished to = operate as an 'island' they
      would = not need to add additional telephony or = expertise 
      servers, as all = the neccessary server side work could be done in = php
      by his existing web = programmers.  "

I think this is implied by your document, = but I feel it is critically important 
so worth explicitly = stating it. 

Tim.= --Apple-Mail=_7FEDD31C-4BDA-4A68-86B6-C75B6D2D1579-- From tim@phonefromhere.com Thu Oct 27 07:03: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 A4C9A21F8B0D for ; Thu, 27 Oct 2011 07:03:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.298 X-Spam-Level: X-Spam-Status: No, score=-1.298 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_FROM=2.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n7xEhMYFu0pm for ; Thu, 27 Oct 2011 07:03: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 E863921F8507 for ; Thu, 27 Oct 2011 07:03:41 -0700 (PDT) Received: from [10.12.78.125] (64-58-7-107.sta.mho.net [64.58.7.107]) by zimbra.westhawk.co.uk (Postfix) with ESMTP id DEB5337A91E; Thu, 27 Oct 2011 15:16:30 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/alternative; boundary="Apple-Mail=_76C90237-ADBD-454F-9F62-C344F5037EC8" From: Tim Panton In-Reply-To: <1D1CC4EE-0002-4638-B42F-760C2D6F29B8@cisco.com> Date: Thu, 27 Oct 2011 08:03:39 -0600 Message-Id: References: <1D1CC4EE-0002-4638-B42F-760C2D6F29B8@cisco.com> To: Cullen Jennings X-Mailer: Apple Mail (2.1251.1) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Relationship of ROAP and PeerConnection? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 14:03:42 -0000 --Apple-Mail=_76C90237-ADBD-454F-9F62-C344F5037EC8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 26 Oct 2011, at 08:41, Cullen Jennings wrote: >=20 > Right now the W3C API and ROAP are way out of sync so it makes it = particularly hard to do the mapping in ones head. Eventually we will = need to sort out which spec defines the JSON object as the string form = of that is the ROAP protocol and also would be passed across the RTCWeb = API. There are arguments either way but I'm sure that we want it defined = one place and the other place to point at it. I think as we get this all = sorted out, it will become relatively clear which document to put the = text in. Right now, I'm just trying to focus on does the idea look like = it is on the right path regardless of which document it is in. The fact = the various specs are so out of sync makes it hard to get ones head = around the whole idea. In the meantime, the ROAP JSON object is = primarily about a concrete instantiation of the abstract RFC 3264 = Offer/Answer protocol and is key to the over the wire ROAP protocol to a = signaling gateway so I think it fairly reasonable to be driving the = discussion fr > om and IETF document vs a W3C one. =46rom W3C API point of view, it is = more of an opaque contain of information used for IETF protocols.=20 Agreed, with the exception that we need the W3C to help specify an API = for the 'Hints' and 'Properties' interfaces that we agreed were required in the last call. Tim.= --Apple-Mail=_76C90237-ADBD-454F-9F62-C344F5037EC8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

Right now the = W3C API and ROAP are way out of sync so it makes it particularly hard to = do the mapping in ones head. Eventually we will need to sort out which = spec defines the JSON object as the string form of that is the ROAP = protocol and also would be passed across the RTCWeb API. There are = arguments either way but I'm sure that we want it defined one place and = the other place to point at it. I think as we get this all sorted out, = it will become relatively clear which document to put the text in. Right = now, I'm just trying to focus on does the idea look like it is on the = right path regardless of which document it is in. The fact the various = specs are so out of sync makes it hard to get ones head around the whole = idea. In the meantime, the ROAP JSON object is primarily about a = concrete instantiation of the abstract RFC 3264 Offer/Answer protocol = and is key to the over the wire ROAP protocol to a signaling gateway so = I think it fairly reasonable to be driving the discussion fr
om and = IETF document vs a W3C one. =46rom W3C API point of view, it is more of = an opaque contain of information used for IETF protocols. =

Agreed, with the exception that we = need the W3C to help specify an API for the 'Hints' and 'Properties' = interfaces
that we agreed were required in the last = call.

Tim.
= --Apple-Mail=_76C90237-ADBD-454F-9F62-C344F5037EC8-- From csp@csperkins.org Thu Oct 27 08:12: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 7137121F8B24 for ; Thu, 27 Oct 2011 08:12:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.357 X-Spam-Level: X-Spam-Status: No, score=-103.357 tagged_above=-999 required=5 tests=[AWL=0.242, 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 fGdZyPapTEBT for ; Thu, 27 Oct 2011 08:12:25 -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 AEAC221F8B21 for ; Thu, 27 Oct 2011 08:12:25 -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 1RJRd2-0001zB-ac; Thu, 27 Oct 2011 15:12:24 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Colin Perkins In-Reply-To: Date: Thu, 27 Oct 2011 16:12:23 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <462F77C3-8CAD-4699-9238-71B5C9EF7F9B@csperkins.org> References: <20111024232740.11885.97235.idtracker@ietfa.amsl.com> To: Jonathan Lennox X-Mailer: Apple Mail (2.1084) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Fwd: I-D Action: draft-lennox-rtcweb-rtp-media-type-mux-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 15:12:26 -0000 Jonathan, Thanks for submitting. This is a good draft. One comment: Section 3.1 suggests that a source generating multiple RTP = streams, with multiple SSRCs, should not send RTCP reports for its own = media, and should pick a single SSRC to use when sending reports on = other media. I agree that this would save a small amount of bandwidth, = but I think the savings are negligible, it complicates the monitoring = model, and so is a mistake. We talk about this in = draft-westerlund-avtcore-multiplex-architecture-00 (Section 9, in = particular). Cheers, Colin On 25 Oct 2011, at 02:01, Jonathan Lennox wrote: > Hello all -- >=20 > Jonathan Rosenberg and I have written a draft (as promised at the = Qu=E9bec IETF) describing RTP-level procedures for multiplexing multiple = media types into a single RTP session. >=20 > Comments are welcome. >=20 > Begin forwarded message: >=20 >> From: "internet-drafts@ietf.org" >> Date: October 24, 2011 7:27:40 PM EDT >> To: "i-d-announce@ietf.org" >> Subject: I-D Action: draft-lennox-rtcweb-rtp-media-type-mux-00.txt >> Reply-To: "internet-drafts@ietf.org" >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >>=20 >> Title : Multiplexing Multiple Media Types In a Single = Real-Time Transport Protocol (RTP) Session >> Author(s) : Jonathan Lennox >> Jonathan Rosenberg >> Filename : draft-lennox-rtcweb-rtp-media-type-mux-00.txt >> Pages : 11 >> Date : 2011-10-24 >>=20 >> This document describes mechanisms and recommended practice for >> transmitting media streams of multiple media types (e.g., audio and >> video) over a single Real-Time Transport Protocol (RTP) session, >> primarily for the use of Real-Time Communication for the Web >> (rtcweb). >>=20 >>=20 >> A URL for this Internet-Draft is: >> = http://www.ietf.org/internet-drafts/draft-lennox-rtcweb-rtp-media-type-mux= -00.txt >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> This Internet-Draft can be retrieved at: >> = ftp://ftp.ietf.org/internet-drafts/draft-lennox-rtcweb-rtp-media-type-mux-= 00.txt >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>=20 >=20 > -- > Jonathan Lennox > jonathan@vidyo.com >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --=20 Colin Perkins http://csperkins.org/ From jonathan@vidyo.com Thu Oct 27 08: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 3800521F8C2F; Thu, 27 Oct 2011 08:58:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.385 X-Spam-Level: X-Spam-Status: No, score=-2.385 tagged_above=-999 required=5 tests=[AWL=0.214, 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 8UOscupigXxk; Thu, 27 Oct 2011 08:58:16 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id ACC4721F8C2B; Thu, 27 Oct 2011 08:58:16 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id D3BF47A0B3B; Thu, 27 Oct 2011 11:58:15 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB028.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 915647A0C63; Thu, 27 Oct 2011 11:57:54 -0400 (EDT) Received: from BE235.mail.lan ([10.110.32.235]) by HUB028.mail.lan ([10.110.17.28]) with mapi; Thu, 27 Oct 2011 11:57:51 -0400 From: Jonathan Lennox To: Colin Perkins Date: Thu, 27 Oct 2011 11:57:53 -0400 Thread-Topic: [rtcweb] Fwd: I-D Action: draft-lennox-rtcweb-rtp-media-type-mux-00.txt Thread-Index: AcyUwSaqbGDvgmXZTuGxetCa4yUwng== Message-ID: <0B68D2E0-3480-47FB-8427-4032FD7B18F6@vidyo.com> References: <20111024232740.11885.97235.idtracker@ietfa.amsl.com> <462F77C3-8CAD-4699-9238-71B5C9EF7F9B@csperkins.org> In-Reply-To: <462F77C3-8CAD-4699-9238-71B5C9EF7F9B@csperkins.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" , IETF AVTCore WG Subject: Re: [rtcweb] Fwd: I-D Action: draft-lennox-rtcweb-rtp-media-type-mux-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 15:58:17 -0000 Hi, Colin -- Thanks for taking a look my draft! I saw this recommendation in the multiplex-architecture draft, after I fini= shed my own (I didn't get a chance to read any other -00 drafts before fini= shing my own before the deadline). I think this is an AVTCore issue, so I'm following up there...further discu= ssion should probably just be on AVTCore, unless there are WebRTC-specific = issues. The multiplexing-architecture draft in general is a very good draft -- it's= extremely thorough and useful -- but I admit to not being very convinced b= y that section of it. At small numbers of sources, self-reporting and cross-reporting does indeed= use a fairly small amount of bandwidth, but the problem is that their band= width usage is quadratic in the number of sources, since every source must = report on every other. So as the number of sources grows, they begin to con= sume all RTCP bandwidth sending redundant or trivial information. And this for the sake of third-party monitors, which (personally) I've neve= r seen deployed outside a research environment, and seem architecturally du= bious to me, at least for offer-answer negotiated streams. (IPTV and other = declarative-SDP architectures are probably different.) On Oct 27, 2011, at 11:12 AM, Colin Perkins wrote: > Jonathan, >=20 > Thanks for submitting. This is a good draft. >=20 > One comment: Section 3.1 suggests that a source generating multiple RTP s= treams, with multiple SSRCs, should not send RTCP reports for its own media= , and should pick a single SSRC to use when sending reports on other media.= I agree that this would save a small amount of bandwidth, but I think the = savings are negligible, it complicates the monitoring model, and so is a mi= stake. We talk about this in draft-westerlund-avtcore-multiplex-architectur= e-00 (Section 9, in particular). >=20 > Cheers, > Colin -- Jonathan Lennox jonathan@vidyo.com From HKaplan@acmepacket.com Thu Oct 27 10: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 9092421F8BA9 for ; Thu, 27 Oct 2011 10:09:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.297 X-Spam-Level: X-Spam-Status: No, score=-2.297 tagged_above=-999 required=5 tests=[AWL=0.002, 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 n8W3wnr0IOcq for ; Thu, 27 Oct 2011 10:09:24 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 096C321F8AAC for ; Thu, 27 Oct 2011 10:09:24 -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, 27 Oct 2011 13:09:22 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.232]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Thu, 27 Oct 2011 13:09:23 -0400 From: Hadriel Kaplan To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= Thread-Topic: [rtcweb] draft-sipdoc-rtcweb-open-wire-protocol-00 (Open In-The-Wire Protocol for RTC-Web) Thread-Index: AQHMlMssvteB8lVcoE6/q4k46SOGUw== Date: Thu, 27 Oct 2011 17:09:22 +0000 Message-ID: <715A5714-B44A-4E1D-AC2F-7CC2EAD42D0F@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: [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: "" Subject: Re: [rtcweb] draft-sipdoc-rtcweb-open-wire-protocol-00 (Open In-The-Wire Protocol for RTC-Web) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 17:09:24 -0000 On Oct 27, 2011, at 4:55 AM, I=F1aki Baz Castillo wrote: >=20 > Hi, just wondering if somebody has read this informational draft. I'd > would really appreciate if folks agree with the conclusiones and > requirements exposed in the document or want to discuss about them. > The draft tries to clarify the scope of RTC-Web, and IMHO that's an > important milestone before we can move on. I read it as well, and agreed with its statements and conclusions. What I = don't know is whether you wrote it for the purpose of becoming a WG documen= t, or simply as an FYI-type draft. It has some requirements in it, which I= think can be moved into draft-ietf-rtcweb-use-cases-and-requirements (assu= ming we get consensus to do so). I thought the requirements were like self= -obvious, but some people may not agree, so it's great that you documented = them and we can debate them. One process-based concern about making requirement 4 a WG requirement: you = can't actually do SIP over Websocket with a "pure SIP network" until we get= Websocket into a SIP-extending RFC as a new transport type. I wouldn't wa= nt to hold up WebRTC docs becoming RFCs, waiting for the DISPATCH and proba= ble SIPCORE process to make a websocket SIP transport into a RFC. I *want*= to add Websocket as a SIP transport type, but it's not actually as trivial= as one would think. One other minor nit: the draft naming scheme doesn't follow IETF convention= s. The convention is to have the main author/editor's last name as the wor= d after "draft-". -hadriel From ibc@aliax.net Thu Oct 27 10:44: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 875F921F8B48 for ; Thu, 27 Oct 2011 10:44:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.641 X-Spam-Level: X-Spam-Status: No, score=-2.641 tagged_above=-999 required=5 tests=[AWL=0.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 QFL1cvE5i5rt for ; Thu, 27 Oct 2011 10:44: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 DBEE521F8B37 for ; Thu, 27 Oct 2011 10:44:43 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so3226875vcb.31 for ; Thu, 27 Oct 2011 10:44:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.106.134 with SMTP id x6mr1026473vco.26.1319737482265; Thu, 27 Oct 2011 10:44:42 -0700 (PDT) Received: by 10.220.159.134 with HTTP; Thu, 27 Oct 2011 10:44:41 -0700 (PDT) In-Reply-To: <715A5714-B44A-4E1D-AC2F-7CC2EAD42D0F@acmepacket.com> References: <715A5714-B44A-4E1D-AC2F-7CC2EAD42D0F@acmepacket.com> Date: Thu, 27 Oct 2011 19:44:41 +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] draft-sipdoc-rtcweb-open-wire-protocol-00 (Open In-The-Wire Protocol for RTC-Web) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 17:44:44 -0000 2011/10/27 Hadriel Kaplan : > On Oct 27, 2011, at 4:55 AM, I=C3=B1aki Baz Castillo wrote: >> >> Hi, just wondering if somebody has read this informational draft. I'd >> would really appreciate if folks agree with the conclusiones and >> requirements exposed in the document or want to discuss about them. >> The draft tries to clarify the scope of RTC-Web, and IMHO that's an >> important milestone before we can move on. > > I read it as well, and agreed with its statements and conclusions. =C2=A0= What I don't know is whether you wrote it for the purpose of becoming a WG = document, or simply as an FYI-type draft. =C2=A0It has some requirements in= it, which I think can be moved into draft-ietf-rtcweb-use-cases-and-requir= ements (assuming we get consensus to do so). =C2=A0I thought the requiremen= ts were like self-obvious, but some people may not agree, so it's great tha= t you documented them and we can debate them. Hi Hadriel. Indeed I do think that this draft should NOT exist, but given the fact that some folks in this WG (AFAIK just one) insist on standarizing and mandating the RTCweb in-the-wire protocol and message format, we wrote this informational draft just in order to justify and explain why the in-the-wire protocol and message format MUST be up to the developer. IMHO mandating the in-the-wire protocol and message format is just useful for those who plan to build and sell "RTCWeb-to-SIP" gateway boxes, and that should never be the motivation of a IETF spec. So if we all (or all but one) agree on this, I think we can move on. The draft is just a helper indeed. > One process-based concern about making requirement 4 a WG requirement: yo= u can't actually do SIP over Websocket with a "pure SIP network" until we g= et Websocket into a SIP-extending RFC as a new transport type. =C2=A0I woul= dn't want to hold up WebRTC docs becoming RFCs, Neither me want that :) Note however that this is just an informational draft (we don't want it to become an RFC) and we just expose the example of "SIP over WebSocket" because we strongly believe in it ;) > waiting for the DISPATCH and probable SIPCORE process to make a websocket= SIP transport into a RFC. That's indeed our next step. We plan to propose the draft (sip-over-websocket) in DISPATCH or SIPCORE. Let's some time ;) >=C2=A0I *want* to add Websocket as a SIP transport type, but it's not actu= ally as trivial as one would think. Regardless it becomes a RFC or not, take into account that the in-the-wire protocol and message format in RTCweb is free, so people can implement SIP over WebSocket if they want :) > One other minor nit: the draft naming scheme doesn't follow IETF conventi= ons. =C2=A0The convention is to have the main author/editor's last name as = the word after "draft-". Good to know, I will take it into account for a next draft. Thanks a lot. --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Thu Oct 27 10:46: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 83BEF21F8672 for ; Thu, 27 Oct 2011 10:46:26 -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 28n9p4bpw8K7 for ; Thu, 27 Oct 2011 10:46:25 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id B80C921F8573 for ; Thu, 27 Oct 2011 10:46:25 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so3228923vcb.31 for ; Thu, 27 Oct 2011 10:46:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.175.134 with SMTP id ba6mr494036vcb.61.1319737585258; Thu, 27 Oct 2011 10:46:25 -0700 (PDT) Received: by 10.220.159.134 with HTTP; Thu, 27 Oct 2011 10:46:25 -0700 (PDT) In-Reply-To: References: Date: Thu, 27 Oct 2011 19:46:25 +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] draft-sipdoc-rtcweb-open-wire-protocol-00 (Open In-The-Wire Protocol for RTC-Web) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 17:46:26 -0000 2011/10/27 Tim Panton : > Thank you for writing this up - before I had to ;-) > I agree with almost all of it, but I wonder if you could add a derived re= quirement: > " =C2=A04. =C2=A0It MUST be possible for a website developer to make his = RTC-Web > =C2=A0 =C2=A0 =C2=A0 scenario to interoperate with a pure SIP or XMPP/Jin= gle network > =C2=A0 =C2=A0 =C2=A0 without requiring a signaling protocol gateway (by u= sing SIP over > =C2=A0 =C2=A0 =C2=A0 WebSocket [I-D.ibc-rtcweb-sip-websocket] or XMPP ove= r WebSocket > =C2=A0 =C2=A0 =C2=A0 [I-D.moffitt-xmpp-over-websocket]). > =C2=A05. It must be possible for a website developer to make his RTC-Web > =C2=A0 =C2=A0 =C2=A0 scenario to interoperate without adding new infrastr= ucture unless they wish to > =C2=A0 =C2=A0 =C2=A0 interop with the wider world - i.e. if the > =C2=A0 =C2=A0 =C2=A0 mysite.com example wished to operate as an 'island' = they > =C2=A0 =C2=A0 =C2=A0 would not need to add additional telephony or expert= ise > =C2=A0 =C2=A0 =C2=A0 servers, as all the neccessary server side work coul= d be done in php > =C2=A0 =C2=A0 =C2=A0 by his existing web programmers. =C2=A0" > > I think this is implied by your document, but I feel it is critically imp= ortant > so worth explicitly stating it. Good point. IMHO it's not needed (I hope) to update the draft as I think we all agree on the conclusions in it (including your new point 5). If not, I'll add it in a new revision. Thanks a lot. --=20 I=C3=B1aki Baz Castillo From harald@alvestrand.no Thu Oct 27 11:53: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 B2C8621F8B67 for ; Thu, 27 Oct 2011 11:53:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.282 X-Spam-Level: X-Spam-Status: No, score=-110.282 tagged_above=-999 required=5 tests=[AWL=0.017, 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 5Y9DDQksQdJe for ; Thu, 27 Oct 2011 11:53:21 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 9DC3821F8B62 for ; Thu, 27 Oct 2011 11:53:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6D38239E0FC; Thu, 27 Oct 2011 20:53: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 I0Rdw3x0NAGs; Thu, 27 Oct 2011 20:53:16 +0200 (CEST) Received: from [172.19.29.10] (216-239-45-4.google.com [216.239.45.4]) by eikenes.alvestrand.no (Postfix) with ESMTPS id BE45539E098; Thu, 27 Oct 2011 20:53:15 +0200 (CEST) Message-ID: <4EA9A899.4020804@alvestrand.no> Date: Thu, 27 Oct 2011 11:53:13 -0700 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: =?UTF-8?B?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] draft-sipdoc-rtcweb-open-wire-protocol-00 (Open In-The-Wire Protocol for RTC-Web) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 18:53:22 -0000 I've read the draft. I note a lot of stuff that (if it has the consensus of the WG) should really be part of the -overview- draft, and the subsequent debate has indicated that it seems they are reasonably close to WG consensus. I'll try to incorporate these things in the -overview- revision. There is some terminology I don't think I want to adopt, but we'll see once the revision gets out. It's unlikely that such a revision occurs before Taipei (not that much time left this week, and discussions in Taipei may also influence -overview-), but it's my intent to do so. Apologies for not (so far) sending a detailed review. One query: Who is this -sipdoc- person? It seems to be the name of none of the authors, but since it got past the I-D submission machinery, it is presumably an author ID. See http://www.ietf.org/id-info/guidelines.html#naming Harald On 10/27/2011 01:55 AM, Iñaki Baz Castillo wrote: > 2011/10/25 Iñaki Baz Castillo: >> A new I-D draft-sipdoc-rtcweb-open-wire-protocol-00.txt has been >> successfully submitted by Iñaki Baz Castillo, Saúl Ibarra Corretgé >> and José Luis Millán Villegas, and posted to the IETF repository. >> >> Filename: draft-sipdoc-rtcweb-open-wire-protocolRevision: >> 00Title: Open In-The-Wire Protocol for RTC-WebCreation >> date: 2011-10-25WG ID: Individual SubmissionNumber of >> pages: 22 >> >> >> http://tools.ietf.org/html/draft-sipdoc-rtcweb-open-wire-protocol-00 >> http://www.ietf.org/id/draft-sipdoc-rtcweb-open-wire-protocol-00.txt >> >> >> Abstract: RTC-Web clients communicate with a server in order to >> request or manage realtime communications with other users. This >> document exposes four hypothetical and different RTC-Web scenarios >> and analyzes the requirements of the in-the-wire protocol in each of >> them. >> The aim of this document is to make RTC-Web properly fit in the >> nature of the Web. > > Hi, just wondering if somebody has read this informational draft. I'd > would really appreciate if folks agree with the conclusiones and > requirements exposed in the document or want to discuss about them. > The draft tries to clarify the scope of RTC-Web, and IMHO that's an > important milestone before we can move on. > > Thanks a lot. > > From randell-ietf@jesup.org Thu Oct 27 12: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 B0A7521F8B7F for ; Thu, 27 Oct 2011 12:06:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[AWL=0.046, 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 4yjYAd+MP1sj for ; Thu, 27 Oct 2011 12:06: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 EEB0F21F8B7A for ; Thu, 27 Oct 2011 12:06: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 1RJVHt-0005ES-Te; Thu, 27 Oct 2011 14:06:49 -0500 Message-ID: <4EA9ABC1.1000201@jesup.org> Date: Thu, 27 Oct 2011 15:06:41 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4EA5EA46.1010803@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: "public-webrtc@w3.org" Subject: Re: [rtcweb] draft-jesup-rtcweb-data-00 posted X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 19:06:51 -0000 On 10/25/2011 11:31 AM, Hadriel Kaplan wrote: > On Oct 25, 2011, at 10:20 AM, Eric Rescorla wrote: > >> On Tue, Oct 25, 2011 at 1:02 AM, Hadriel Kaplan wrote: >>> Req. 8: The data stream transport protocol MUST NOT encode IP addresses inside its protocol fields; doing so reveals potentially private information, and leads to failure if the address is depended upon. >> I don't really understand what this means. In general, the peer has >> access to your IP address >> information from ICE. > From a privacy perspective: if a person uses a Web-site designed with privacy/anonymity in mind (e.g., battered-spouse forum), then the site would relay your media-plane stuff through a type of TURN server that does ICE itself both ways. But if the SCTP layer on top of UDP encodes your local IP using one of the optional SCTP fields in RFC 4960 or 5061, then you lose that anonymity. Since the SCTP layer is built into the Browser and not under control of the Javascript, a site can't prevent it from revealing that info. There's a corollary: a user should be able to set their browser and/or App to force all incoming calls (and maybe outgoing) through a TURN server. (There may be other uses for this ability, like corporate firewall traversal, but the case you mention is one of them). Witness the recent attack on identity info on Skype using call-setup protocols, without even decoding them: http://www.theregister.co.uk/2011/10/21/skype_bittorrent_stalking/print.html and http://cis.poly.edu/~ross/papers/skypeIMC2011.pdf In theory it could be more nuanced - direct connections for people in your phonebook, or listed as friends, etc. But that may be too confusing for generic users, and too likely to mess up. This is more likely a W3C issue, so CC-ing that list -- Randell Jesup randell-ietf@jesup.org From ibc@aliax.net Thu Oct 27 12:13: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 7D4CA21F8BA9 for ; Thu, 27 Oct 2011 12:13:59 -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 sL0jbAlddbXE for ; Thu, 27 Oct 2011 12:13:59 -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 E533521F8BA6 for ; Thu, 27 Oct 2011 12:13:58 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so3330391vcb.31 for ; Thu, 27 Oct 2011 12:13:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.1.16 with SMTP id 16mr1222579vcd.166.1319742838328; Thu, 27 Oct 2011 12:13:58 -0700 (PDT) Received: by 10.220.159.134 with HTTP; Thu, 27 Oct 2011 12:13:58 -0700 (PDT) In-Reply-To: <4EA9A899.4020804@alvestrand.no> References: <4EA9A899.4020804@alvestrand.no> Date: Thu, 27 Oct 2011 21:13:58 +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] draft-sipdoc-rtcweb-open-wire-protocol-00 (Open In-The-Wire Protocol for RTC-Web) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 19:13:59 -0000 2011/10/27 Harald Alvestrand : > I've read the draft. > > I note a lot of stuff that (if it has the consensus of the WG) should rea= lly > be part of the -overview- draft, and the subsequent debate has indicated > that it seems they are reasonably close to WG consensus. I'll try to > incorporate these things in the -overview- revision. That's really great. > There is some terminology I don't think I want to adopt, but we'll see on= ce > the revision gets out. Sure. There is a lot of unclear terminology in RTCweb and it's hard to select the best term :) > One query: Who is this -sipdoc- person? It seems to be the name of none o= f > the authors, but since it got past the I-D submission machinery, it is > presumably an author ID. Sorry, our fault. I didn't aware about the draft naming conventions. --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Thu Oct 27 12:38: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 1C39821F8B2F for ; Thu, 27 Oct 2011 12:38: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 I24QOmVj4BnD for ; Thu, 27 Oct 2011 12:38:09 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 846C221F8B2A for ; Thu, 27 Oct 2011 12:38:09 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so3355238vcb.31 for ; Thu, 27 Oct 2011 12:38:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.117.199 with SMTP id s7mr1248404vcq.201.1319744287029; Thu, 27 Oct 2011 12:38:07 -0700 (PDT) Received: by 10.220.159.134 with HTTP; Thu, 27 Oct 2011 12:38:06 -0700 (PDT) In-Reply-To: <4EA9A899.4020804@alvestrand.no> References: <4EA9A899.4020804@alvestrand.no> Date: Thu, 27 Oct 2011 21:38:06 +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] draft-sipdoc-rtcweb-open-wire-protocol-00 (Open In-The-Wire Protocol for RTC-Web) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 19:38:10 -0000 2011/10/27 Harald Alvestrand : > One query: Who is this -sipdoc- person? It seems to be the name of none o= f > the authors, but since it got past the I-D submission machinery, it is > presumably an author ID. > > See http://www.ietf.org/id-info/guidelines.html#naming Hi, BTW does somebody know how to submit a new draft with name YYYY as continuation of a previous draft with name XXXX? See for example draft-ietf-hybi-thewebsocketprotocol which previously was named draft-hixie-thewebsocketprotocol, and the current draft shows also a reference to the old name ("Versions" field on top of the draft): http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-17 Thanks a lot. --=20 I=C3=B1aki Baz Castillo From randell-ietf@jesup.org Thu Oct 27 13:39: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 AD8D421F8B87 for ; Thu, 27 Oct 2011 13:39:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lABrjMpI00Ho for ; Thu, 27 Oct 2011 13:39:15 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 18C5121F8BA0 for ; Thu, 27 Oct 2011 13:39:15 -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 1RJWjK-0002yB-MR for rtcweb@ietf.org; Thu, 27 Oct 2011 15:39:14 -0500 Message-ID: <4EA9C16A.4090600@jesup.org> Date: Thu, 27 Oct 2011 16:39:06 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "rtcweb@ietf.org" 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] Congestion control, Taiwan X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 20:39:15 -0000 Just so the rest of the community here knows, I posted some proposed requirements for congestion control to the rtcweb-congestion mailing list (http://www.alvestrand.no/mailman/listinfo/rtp-congestion). Hopefully we can get some time at IETF 82 in Taiwan for discussion of congestion control; Harald would probably be leading the discussion as I won't be able to attend in person (I'll be on by phone/IRC as best I can, and Tim Terriberry of Mozilla should be there in person and hopefully relaying any comments I have). If you're interested in the congestion-control aspects, please join the R-C list and read the archives there (unlike here, they aren't huge!) -- Randell Jesup randell-ietf@jesup.org From HKaplan@acmepacket.com Thu Oct 27 15:37: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 AC57411E8085 for ; Thu, 27 Oct 2011 15:37:10 -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] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Elckw0eODO5A for ; Thu, 27 Oct 2011 15:37:10 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 170C811E807F for ; Thu, 27 Oct 2011 15:37:09 -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, 27 Oct 2011 18:37:08 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.232]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Thu, 27 Oct 2011 18:37:08 -0400 From: Hadriel Kaplan To: "rtcweb@ietf.org" Thread-Topic: Security issue: initial consent Thread-Index: AQHMlPj1/y+eNK3yskqILmPug7WDLg== Date: Thu, 27 Oct 2011 22:37:07 +0000 Message-ID: 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: <314CC3ED04E18245B9A5CCE5813E7029@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Subject: [rtcweb] Security issue: initial consent X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 22:37:10 -0000 Howdy, per the request made by the Chairs for threads on the security daft, I'm st= arting this one on the topic of initial media-stream consent. This is rela= ted to section 4.2 and in particular 4.2.3 of draft-ietf-rtcweb-security. With regards to initial consent, earlier proposals to use receipt of RTP fr= om the peer as the consent have failed due to it being easy for a malicious= JS site to generate a few RTP packets to accomplish it. Earlier proposals= to send some limited RTP and use receipt of RTCP Receiver Reports have fai= led because the entropy of RTCP RR's is too low, and thus malicious JS can = spoof them too easily; there's also the problem that some legacy devices do= n't do RTCP.=20 IF the above is true, then ISTM the only solution choices are one of the fo= llowing: 1) Require ICE be used for all connections on the WebRTC Browser, and eithe= r ICE or ICE-Lite on the peer. 2) Require either ICE as above _or_ DTLS-SRTP be used for all RTP connectio= n consent, since DTLS-SRTP handshake is sufficient consent. In other words= , if the Browser's peer uses DTLS-SRTP but not ICE, the Browser can use tha= t as initial consent and continue. If the Browser's peer does ICE, that pr= ovides initial consent. Are there any others?? SDES-SRTP can't be used instead of DTLS-SRTP for such consent, because the = JS will know the SDES key.=20 I don't believe we need to worry about consent for purely data-stream conne= ctions, assuming we pick either SCTP/UDP, SCTP/DTLS/UDP, or TCP/UDP; becaus= e there's a handshake of sufficient entropy. But I could be wrong about th= at. I also believe there's one issue regarding consent which has not been docum= ented: ICE-based or DTLS-based resource attacks. If a malicious JS can tri= gger STUN-ICE, TURN-allocate, or DTLS-handshake messages to be sent to any = destination by feeding the Browser malicious ROAP, the packet rates of thos= e themselves can create a DDoS attack. I think this needs to be documented= so that Browsers throttle the number of such messages they generate. ICE,= for example, can mimic RTP rates during initial connectivity checks; so a = malicious JS can simply cause ICE to restart often. -hadriel From ekr@rtfm.com Thu Oct 27 15: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 703B021F858C for ; Thu, 27 Oct 2011 15:40:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.967 X-Spam-Level: X-Spam-Status: No, score=-102.967 tagged_above=-999 required=5 tests=[AWL=0.010, 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 eSRjyVPQNSPW for ; Thu, 27 Oct 2011 15:40: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 E26C821F8564 for ; Thu, 27 Oct 2011 15:40:25 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so3524609vcb.31 for ; Thu, 27 Oct 2011 15:40:25 -0700 (PDT) Received: by 10.220.194.139 with SMTP id dy11mr8895vcb.126.1319755225153; Thu, 27 Oct 2011 15:40:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.118.132 with HTTP; Thu, 27 Oct 2011 15:39:44 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Thu, 27 Oct 2011 15:39:44 -0700 Message-ID: To: Hadriel Kaplan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Security issue: initial consent X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 22:40:26 -0000 On Thu, Oct 27, 2011 at 3:37 PM, Hadriel Kaplan wr= ote: > SDES-SRTP can't be used instead of DTLS-SRTP for such consent, because th= e JS will know the SDES key. > > I don't believe we need to worry about consent for purely data-stream con= nections, assuming we pick either SCTP/UDP, SCTP/DTLS/UDP, or TCP/UDP; beca= use there's a handshake of sufficient entropy. =A0But I could be wrong abou= t that. Still thinking about this, but... Can you clarify what TCP/UDP means? Is it TCP over UDP? -Ekr From ibc@aliax.net Thu Oct 27 15: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 6565121F8511 for ; Thu, 27 Oct 2011 15:41:28 -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 2v2zbRF0SGwq for ; Thu, 27 Oct 2011 15:41: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 E7AFB21F84D8 for ; Thu, 27 Oct 2011 15:41:27 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so3525349vcb.31 for ; Thu, 27 Oct 2011 15:41:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.151.129 with SMTP id c1mr1289739vcw.271.1319755287409; Thu, 27 Oct 2011 15:41:27 -0700 (PDT) Received: by 10.220.159.134 with HTTP; Thu, 27 Oct 2011 15:41:27 -0700 (PDT) In-Reply-To: References: Date: Fri, 28 Oct 2011 00:41:27 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Security issue: initial consent X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 22:41:28 -0000 2011/10/28 Eric Rescorla : > Can you clarify what TCP/UDP means? Is it TCP over UDP? Yes. --=20 I=C3=B1aki Baz Castillo From ekr@rtfm.com Thu Oct 27 15:59: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 76BF321F8493 for ; Thu, 27 Oct 2011 15:59:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.818 X-Spam-Level: X-Spam-Status: No, score=-102.818 tagged_above=-999 required=5 tests=[AWL=-0.141, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id khO6CcMdsHQr for ; Thu, 27 Oct 2011 15:59: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 EFC9A21F848D for ; Thu, 27 Oct 2011 15:59:27 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so3533964vcb.31 for ; Thu, 27 Oct 2011 15:59:27 -0700 (PDT) Received: by 10.220.150.141 with SMTP id y13mr11190vcv.196.1319756367392; Thu, 27 Oct 2011 15:59:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.118.132 with HTTP; Thu, 27 Oct 2011 15:58:46 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Thu, 27 Oct 2011 15:58:46 -0700 Message-ID: To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Security issue: initial consent X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 22:59:28 -0000 On Thu, Oct 27, 2011 at 3:41 PM, I=F1aki Baz Castillo wrote= : > 2011/10/28 Eric Rescorla : >> Can you clarify what TCP/UDP means? Is it TCP over UDP? > > Yes. In that case, it's not clear that there is enough entropy. The TCP ISN has (at most 32 bits) and since ISN ACK forgery is not exactly a priority for ordinary stacks, it's not clear that they generate the ISN securely. -Ekr From HKaplan@acmepacket.com Thu Oct 27 16:39: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 31FF621F8494 for ; Thu, 27 Oct 2011 16:39:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.451 X-Spam-Level: X-Spam-Status: No, score=-2.451 tagged_above=-999 required=5 tests=[AWL=0.148, 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 Z+LpgGtQVPT8 for ; Thu, 27 Oct 2011 16:39:24 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 9298A21F848E for ; Thu, 27 Oct 2011 16:39:24 -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, 27 Oct 2011 19:39:22 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.232]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Thu, 27 Oct 2011 19:39:22 -0400 From: Hadriel Kaplan To: Eric Rescorla Thread-Topic: [rtcweb] Security issue: initial consent Thread-Index: AQHMlQGmyFPtD8jLPUmNjSQBJ9GUIw== Date: Thu, 27 Oct 2011 23:39:21 +0000 Message-ID: <99DF5455-9961-41E6-A506-1DD09AF6D1C0@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: [10.0.0.30] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <6BBE7347606C7A45826088D05B1BB4ED@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Security issue: initial consent X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 23:39:25 -0000 On Oct 27, 2011, at 6:58 PM, Eric Rescorla wrote: > On Thu, Oct 27, 2011 at 3:41 PM, I=F1aki Baz Castillo wro= te: >> 2011/10/28 Eric Rescorla : >>> Can you clarify what TCP/UDP means? Is it TCP over UDP? >>=20 >> Yes. >=20 > In that case, it's not clear that there is enough entropy. The TCP ISN ha= s > (at most 32 bits) and since ISN ACK forgery is not exactly a priority > for ordinary > stacks, it's not clear that they generate the ISN securely. Right but we haven't defined what "TCP over UDP" means. :) The "TCP" is in the Browser, so we can improve things. We could, for examp= le, decide that the JS cannot learn the ephemeral source port number of the= TCP-layer from the Browser, and that it be chosen randomly every time from= the full 16-bit range (as opposed to the small ephemeral range used by mos= t OS's), giving another 16-bits of entropy. And of course we'd specify tha= t the ISN be chosen securely. Heck, we could even mandate using a new TCP = header option to be reflected by the other side, similar to the TCP Timesta= mp option, but put a random number in it. -hadriel From matthew.kaufman@skype.net Thu Oct 27 16: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 5BE4421F84C3 for ; Thu, 27 Oct 2011 16:42: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=[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 EUHxt3ST9JBs for ; Thu, 27 Oct 2011 16:42:12 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id 3EAE221F84BA for ; Thu, 27 Oct 2011 16:42:12 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id EA3881712; Fri, 28 Oct 2011 01:42:09 +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=0JLfJbwYfjcNFi pSpl8r+4tVCCU=; b=SYAECkGvAT8RxPGM7iuF9gKCbcTlsFBbNCYhT4YGh5Yr4Q Vq4pM7ZBAgiG5oSFIi5JUFR3JySRnUxBmpKGuthGaWZPWzdvEWWpzIArvwTtMojX ombx/Vu314nigsWUC+4UnyAYigNVgGc0TntvhRUKdsupIIU16F8T4NLCbZnBA= 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=d5BJJ/wh7vW1WrdMcw0Kcn 54Ev6EmyBa1EC3sDabaZcN/Y87fU+6sXR+oa7rDy7OG9utYFk/N4tdQJmmlQJxnc IH8n3Sp6yh27cyrQ2NYVqg3CmdKADutctZ4fPpaEyrLEX9xZ+9WZDYxPK3uOICaF uasnoJ/s91sM0hqFg71j0= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id E85787F6; Fri, 28 Oct 2011 01:42:09 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id AAB271672682; Fri, 28 Oct 2011 01:42:09 +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 4dmA3NHhHw8A; Fri, 28 Oct 2011 01:42:09 +0200 (CEST) Received: from Matthew-Kaufman-Air.local (unknown [89.105.27.6]) by zimbra.skype.net (Postfix) with ESMTPSA id 2788D1672681; Fri, 28 Oct 2011 01:42:07 +0200 (CEST) Message-ID: <4EA9EC4F.2010706@skype.net> Date: Fri, 28 Oct 2011 00:42:07 +0100 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Hadriel Kaplan References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Security issue: initial consent X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 23:42:13 -0000 On 10/27/11 11:37 PM, Hadriel Kaplan wrote: > IF the above is true, then ISTM the only solution choices are one of the following: > 1) Require ICE be used for all connections on the WebRTC Browser, and either ICE or ICE-Lite on the peer. This works. > 2) Require either ICE as above _or_ DTLS-SRTP be used for all RTP connection consent, since DTLS-SRTP handshake is sufficient consent. In other words, if the Browser's peer uses DTLS-SRTP but not ICE, the Browser can use that as initial consent and continue. If the Browser's peer does ICE, that provides initial consent. I'm not at all sure how DTLS-SRTP can be used as consent. ICE works as consent because there must be a shared out-of-band secret in order for the authentication to succeed. DTLS-SRTP on the other hand can be negotiated with any cooperative far end, unless the far end is looking at a client-provided certificate, which seems unlikely. > > Are there any others?? > > SDES-SRTP can't be used instead of DTLS-SRTP for such consent, because the JS will know the SDES key. > > I don't believe we need to worry about consent for purely data-stream connections, assuming we pick either SCTP/UDP, SCTP/DTLS/UDP, or TCP/UDP; because there's a handshake of sufficient entropy. But I could be wrong about that. I don't think this is true either, because 1) if any other far end would do that handshake, you could connect to it without a shared secret (for instance, you could port-scan looking for SCTP/UDP thinks to talk to behind a firewall) and 2) As ekr said, I don't think there's enough entropy to prevent spoofing the consent either. > > I also believe there's one issue regarding consent which has not been documented: ICE-based or DTLS-based resource attacks. If a malicious JS can trigger STUN-ICE, TURN-allocate, or DTLS-handshake messages to be sent to any destination by feeding the Browser malicious ROAP, the packet rates of those themselves can create a DDoS attack. I think this needs to be documented so that Browsers throttle the number of such messages they generate. ICE, for example, can mimic RTP rates during initial connectivity checks; so a malicious JS can simply cause ICE to restart often. Agree that the browser must enforce rate limits when sending to things that have not consented, no matter what the Javascript does. Matthew Kaufman From matthew.kaufman@skype.net Thu Oct 27 16:44: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 2485421F84CC for ; Thu, 27 Oct 2011 16:44: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 kbLSP7bOeSlQ for ; Thu, 27 Oct 2011 16:44:44 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id 61CDF21F84CE for ; Thu, 27 Oct 2011 16:44:44 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id A96C31712; Fri, 28 Oct 2011 01:44: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=ha5kN3J9r7pnQG Rby94XIrK4lfo=; b=QN7KPgHdzAUnTaDPeq7NOatAmJ7W36tPXkl4n57a6+bOtl s0Hj3vkt8/qdxFRK7zjK6XB4HtMV3TJayHX1ZGaXxOKaWLlR4pyOHZGjBZueK6De 0zxS6QqmbXFuD2xNRhWNYFoJ1g0wRkqP25JuJuvBQTByF3FW+QbuMdGj/LVak= 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=FvBJuIwTCbP7FPLwb7+IYw gu+dj+doFHJ+jGpego9Kxzw7TEDxxvkG6T17DWUggLmuQ869CIcJt/ipXRL6a1fu VxL/5KxBjym607BN0LwqDutvhOONH8yI8Nq+bX0pfumqVaZaP0rMPEuT868xk+3z HFFlF0M/qW0pT7u5r79jw= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id A6C497F6; Fri, 28 Oct 2011 01:44:43 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id 8407F1672684; Fri, 28 Oct 2011 01:44: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 IX5zsW2kPneY; Fri, 28 Oct 2011 01:44:42 +0200 (CEST) Received: from Matthew-Kaufman-Air.local (unknown [89.105.27.6]) by zimbra.skype.net (Postfix) with ESMTPSA id 2E75E1672682; Fri, 28 Oct 2011 01:44:42 +0200 (CEST) Message-ID: <4EA9ECE9.4050500@skype.net> Date: Fri, 28 Oct 2011 00:44:41 +0100 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Hadriel Kaplan References: <99DF5455-9961-41E6-A506-1DD09AF6D1C0@acmepacket.com> In-Reply-To: <99DF5455-9961-41E6-A506-1DD09AF6D1C0@acmepacket.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Security issue: initial consent X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 23:44:45 -0000 On 10/28/11 12:39 AM, Hadriel Kaplan wrote: > ... > Heck, we could even mandate using a new TCP header option to be reflected by the other side, similar to the TCP Timestamp option, but put a random number in it. > Again, the STUN connectivity test used by ICE does more than simply prove that the far end got the packet and can reflect it back. The reflection isn't even done unless the long-term credentials are valid. Matthew Kaufman From HKaplan@acmepacket.com Thu Oct 27 17:02: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 172A811E80AB for ; Thu, 27 Oct 2011 17:02:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.453 X-Spam-Level: X-Spam-Status: No, score=-2.453 tagged_above=-999 required=5 tests=[AWL=0.146, 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 H5oVPaKTW9rA for ; Thu, 27 Oct 2011 17:02:29 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 6FD9311E80AE for ; Thu, 27 Oct 2011 17:02:29 -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, 27 Oct 2011 20:02:27 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.232]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Thu, 27 Oct 2011 20:02:27 -0400 From: Hadriel Kaplan To: "rtcweb@ietf.org" Thread-Topic: Security issue: consent refresh Thread-Index: AQHMlQTgiHXhZE2WfUyh0p8ZGXLngw== Date: Fri, 28 Oct 2011 00:02:26 +0000 Message-ID: <3FACD0E9-449A-4897-8997-F76B5A41A34E@acmepacket.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="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Subject: [rtcweb] Security issue: consent refresh X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 00:02:30 -0000 Howdy, per the request made by the Chairs for threads on the security daft, I'm st= arting this one on the topic of media-stream consent refresh. This is rela= ted to section 4.2.3 of draft-ietf-rtcweb-security. The concern here is to make sure the other side wants to keep receiving RTP= , since a malicious JS can prevent the Browser learning the far-end no long= er wants to communicate via the high-path. It also provides protection aga= inst certain non-malicious failure cases, especially with automated systems= like media servers.=20 Receipt of RTP cannot be used for consent refresh since the session may be = in sendonly/recvonly mode, and RTP can be easily spoofed. One proposal was= to use receipt of RTCP as consent refresh. =20 ISTM the problem with using RTCP is (1) some deployed devices don't do RTCP= and faking it in a gateway is bad mojo, and (2) if RTCP wasn't entropic en= ough for initial consent, why is it for consent refresh? Alternative Proposal: I think one obvious solution is to use a STUN request/response check as a c= onsent refresh. The STUN check does not need to use SHA-1 stuff, just resp= onding with the same transaction ID as the request should provide enough en= tropy. The STUN message could be an existing one from RFC 5389, but it wou= ld take a new draft to say "do this" and indicate it in SDP. The benefits of this are that it doesn't rely on RTCP entropy, or even RTCP= period. It is easier to implement in a gateway than fake RTCP generation.= And it allows interworking gateways to get out of the way (not be in the = media-plane) because they can know both sides do the consent refresh, which= they don't know about just RTCP. The downside is any existing RTP devices that already support ICE and RTCP = would need to be upgraded in order to talk to WebRTC. I think there's a sol= ution to that too if people think we need to interop with them without upgr= ading. One idea is IF RTCP is sufficiently entropic for consent refresh, t= hen we have an escape clause that if the peer doesn't indicate support for = this new STUN-based consent refresh, then we allow it to use RTCP as consen= t refresh.=20 -hadriel From HKaplan@acmepacket.com Thu Oct 27 17:32: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 54A7821F8551 for ; Thu, 27 Oct 2011 17:32:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.455 X-Spam-Level: X-Spam-Status: No, score=-2.455 tagged_above=-999 required=5 tests=[AWL=0.144, 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 WQNeWbIQIT0L for ; Thu, 27 Oct 2011 17:32:40 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id ABC6D21F854F for ; Thu, 27 Oct 2011 17:32:40 -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, 27 Oct 2011 20:32:37 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.232]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Thu, 27 Oct 2011 20:32:37 -0400 From: Hadriel Kaplan To: Matthew Kaufman Thread-Topic: [rtcweb] Security issue: initial consent Thread-Index: AQHMlQkXoO3eI6taAk2EK6qgMyXoAw== Date: Fri, 28 Oct 2011 00:32:37 +0000 Message-ID: References: <99DF5455-9961-41E6-A506-1DD09AF6D1C0@acmepacket.com> <4EA9ECE9.4050500@skype.net> In-Reply-To: <4EA9ECE9.4050500@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: "rtcweb@ietf.org" Subject: Re: [rtcweb] Security issue: initial consent X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 00:32:41 -0000 On Oct 27, 2011, at 7:44 PM, Matthew Kaufman wrote: > On 10/28/11 12:39 AM, Hadriel Kaplan wrote: >> ... >> Heck, we could even mandate using a new TCP header option to be reflec= ted by the other side, similar to the TCP Timestamp option, but put a rando= m number in it. >>=20 >=20 > Again, the STUN connectivity test used by ICE does more than simply prove= that the far end got the packet and can reflect it back. The reflection is= n't even done unless the long-term credentials are valid. Yes I know the ICE/STUN user/pass proves a shared secret, but what attacker= /attack are you protecting against? The JS obviously knows the ICE secrets, so the secret does not prevent the = JS from spoofing to cause a hammer attack - only the reflected trans-id doe= s. A MitM may not know the secret, but if we didn't do ICE, what advantage cou= ld the MitM gain by responding to the TCP SYN or DTLS handshake? If it's a= MitM it can allow ICE to succeed anyway end-to-end, and then respond to th= e TCP SYN or DTLS. =20 And I'm not suggesting just because they have a handshake that it makes TCP= /UDP or SCTP/UDP secure from MitM eavesdropping or impersonation. ICE does= n't either obviously. I'm only saying that it makes it hard for a *non-Mit= M* to spoof. =20 The main concern was that a malicious JS can cause a hammer/DDoS attack on = another target, without being a MitM of the media-plane. That's particular= ly difficult given RTP/RTCP have no handshake; or more to the point UDP has= no handshake. DTLS, TCP/UDP, and SCTP/UDP have it. The question is if th= ey're entropic enough to prevent the malicious JS from spoofing the handsha= ke when it's not a MitM on the media-plane. If the JS *is* a MitM on the m= edia-plane, then the JS doesn't gain much by making the Browser perform the= attack since the JS is now being attacked too. No? Maybe I'm missing something basic. -hadriel From matthew.kaufman@skype.net Thu Oct 27 18:07: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 BA00711E8099 for ; Thu, 27 Oct 2011 18:07:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MBXKO4gp83gb for ; Thu, 27 Oct 2011 18:07:14 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id B4CB411E808F for ; Thu, 27 Oct 2011 18:07:13 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id 805981712; Fri, 28 Oct 2011 03:07: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=Xb8vHQk034CxZq Wr1LISpabu2sY=; b=Wyf/r975l2rZ4+GHNgQFOJNXg238+267qBgfH2CVNbaEGm hWp1wvHsbyFarU4We6qrCkgaaoInTvQpUwfU1apHEuZVK7VebTWqCTTzyFvnBjk9 s9MxkiLklSm/zn74x7u7ueb/UMltgGHBIyBo4V9Gl+Nn+IF9BOdbixfEkZGZc= 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=JXzMYeTq2WFbu3fI4qFGjL yIxohdBtz4tXc6BbYkCZiuCPnCUFYYOEBV3Q4XPcuticrInSjwQob/mzPoq3xwir 8a/6pGqGt/O5kXx2kA51lpNDUWRhrl6YP7v/eSyEROpUNHeFfeZ0dqEwAX3djQQO Mw+Q6oxjr8185DgAA1nio= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id 74C127F8; Fri, 28 Oct 2011 03:07:11 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id 1C89D3506F00; Fri, 28 Oct 2011 03:07: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 rSh34MjMZnOO; Fri, 28 Oct 2011 03:07:09 +0200 (CEST) Received: from Matthew-Kaufman-Air.local (unknown [89.105.27.6]) by zimbra.skype.net (Postfix) with ESMTPSA id 46DA83506E14; Fri, 28 Oct 2011 03:07:09 +0200 (CEST) Message-ID: <4EAA003C.7010702@skype.net> Date: Fri, 28 Oct 2011 02:07:08 +0100 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Hadriel Kaplan References: <99DF5455-9961-41E6-A506-1DD09AF6D1C0@acmepacket.com> <4EA9ECE9.4050500@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] Security issue: initial consent X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 01:07:14 -0000 On 10/28/11 1:32 AM, Hadriel Kaplan wrote: > On Oct 27, 2011, at 7:44 PM, Matthew Kaufman wrote: > >> On 10/28/11 12:39 AM, Hadriel Kaplan wrote: >>> ... >>> Heck, we could even mandate using a new TCP header option to be reflected by the other side, similar to the TCP Timestamp option, but put a random number in it. >>> >> Again, the STUN connectivity test used by ICE does more than simply prove that the far end got the packet and can reflect it back. The reflection isn't even done unless the long-term credentials are valid. > Yes I know the ICE/STUN user/pass proves a shared secret, but what attacker/attack are you protecting against? > > The JS obviously knows the ICE secrets, so the secret does not prevent the JS from spoofing to cause a hammer attack - only the reflected trans-id does. > > A MitM may not know the secret, but if we didn't do ICE, what advantage could the MitM gain by responding to the TCP SYN or DTLS handshake? If it's a MitM it can allow ICE to succeed anyway end-to-end, and then respond to the TCP SYN or DTLS. > > And I'm not suggesting just because they have a handshake that it makes TCP/UDP or SCTP/UDP secure from MitM eavesdropping or impersonation. ICE doesn't either obviously. I'm only saying that it makes it hard for a *non-MitM* to spoof. > > The main concern was that a malicious JS can cause a hammer/DDoS attack on another target, without being a MitM of the media-plane. That's particularly difficult given RTP/RTCP have no handshake; or more to the point UDP has no handshake. DTLS, TCP/UDP, and SCTP/UDP have it. The question is if they're entropic enough to prevent the malicious JS from spoofing the handshake when it's not a MitM on the media-plane. If the JS *is* a MitM on the media-plane, then the JS doesn't gain much by making the Browser perform the attack since the JS is now being attacked too. > > No? Maybe I'm missing something basic. > The "malicious JavaScript" comes in the form of a banner ad, delivered to your web browser that is running behind your corporate firewall. There is a public address system that plays whatever it receives over RTP out over the speakers in the building, with no signaling. Without the ICE handshake, the banner ad can now play arbitrary media to the public address system once it finds the address. With the ICE handshake, that is prevented. If that public address system also does DTLS-SRTP, and you don't require ICE in that case, the banner ad can *again* play arbitrary media to the public address system. Not acceptable. There is also a SCTP/UDP controlled welding robot behind the firewall. With the ICE handshake, the browser can't command it to burn holes through the wall. Without the handshake, the browser can negotiate a SCTP/UDP connection to the robot and send it arbitrary commands. Also not acceptable. Matthew Kaufman From harald@alvestrand.no Thu Oct 27 18:40: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 542DB11E808D for ; Thu, 27 Oct 2011 18:40:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.817 X-Spam-Level: X-Spam-Status: No, score=-109.817 tagged_above=-999 required=5 tests=[AWL=-0.457, BAYES_00=-2.599, 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 F+OjgLYxnlZt for ; Thu, 27 Oct 2011 18:40:23 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 1411A11E8073 for ; Thu, 27 Oct 2011 18:40:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 32CED39E0FC for ; Fri, 28 Oct 2011 03:40: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 Q1ABiNGWLATJ for ; Fri, 28 Oct 2011 03:40:20 +0200 (CEST) Received: from [172.19.29.10] (216-239-45-4.google.com [216.239.45.4]) by eikenes.alvestrand.no (Postfix) with ESMTPS id DB4F639E098 for ; Fri, 28 Oct 2011 03:40:19 +0200 (CEST) Message-ID: <4EAA0801.3030701@alvestrand.no> Date: Thu, 27 Oct 2011 18:40:17 -0700 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: rtcweb@ietf.org References: <99DF5455-9961-41E6-A506-1DD09AF6D1C0@acmepacket.com> <4EA9ECE9.4050500@skype.net> In-Reply-To: <4EA9ECE9.4050500@skype.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Security issue: initial consent X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 01:40:27 -0000 On 10/27/2011 04:44 PM, Matthew Kaufman wrote: > On 10/28/11 12:39 AM, Hadriel Kaplan wrote: >> ... >> Heck, we could even mandate using a new TCP header option to be >> reflected by the other side, similar to the TCP Timestamp option, but >> put a random number in it. >> > > Again, the STUN connectivity test used by ICE does more than simply > prove that the far end got the packet and can reflect it back. The > reflection isn't even done unless the long-term credentials are valid. Nit: the STUN usage I have seen so far uses short-term credentials (ephemeral username + password, RFC 5389 section 10.1) per RFC 5245 section 7.1.2.3, not long-term credentials (realm + username + password, RFC 5389 section 10.2). Since "short term" and "long term" are used with specific meaning in ICE, I hope we're using them in the same way in this discussion. From HKaplan@acmepacket.com Thu Oct 27 19:56: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 075FE1F0C4D for ; Thu, 27 Oct 2011 19:56:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.156 X-Spam-Level: X-Spam-Status: No, score=-2.156 tagged_above=-999 required=5 tests=[AWL=-0.157, 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 s0cskh6LyPQA for ; Thu, 27 Oct 2011 19:56:49 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 47F531F0C42 for ; Thu, 27 Oct 2011 19:56: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; Thu, 27 Oct 2011 22:56:47 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.232]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Thu, 27 Oct 2011 22:56:47 -0400 From: Hadriel Kaplan To: Matthew Kaufman Thread-Topic: [rtcweb] Security issue: initial consent Thread-Index: AQHMlR06v6EzMhiqPk6A29dP/AxYIQ== Date: Fri, 28 Oct 2011 02:56:46 +0000 Message-ID: <8EDFB02E-20AA-4D5B-B781-68BFD26B0859@acmepacket.com> References: <99DF5455-9961-41E6-A506-1DD09AF6D1C0@acmepacket.com> <4EA9ECE9.4050500@skype.net> <4EAA003C.7010702@skype.net> In-Reply-To: <4EAA003C.7010702@skype.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="iso-8859-1" Content-ID: <3D9CDA845638684298EA8F2F3EFE05F9@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Security issue: initial consent X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 02:56:50 -0000 On Oct 27, 2011, at 9:07 PM, Matthew Kaufman wrote: > On 10/28/11 1:32 AM, Hadriel Kaplan wrote: >>=20 >> No? Maybe I'm missing something basic. >>=20 >=20 > The "malicious JavaScript" comes in the form of a banner ad, delivered to= your web browser that is running behind your corporate firewall. >=20 > There is a public address system that plays whatever it receives over RTP= out over the speakers in the building, with no signaling. >=20 > Without the ICE handshake, the banner ad can now play arbitrary media to = the public address system once it finds the address. With the ICE handshake= , that is prevented. >=20 > If that public address system also does DTLS-SRTP, and you don't require = ICE in that case, the banner ad can *again* play arbitrary media to the pub= lic address system. Not acceptable. >=20 Ahh right. So the answer to the "Maybe I'm missing something basic" would = be "yes". :) In fact I think you may have explained this once before and I've forgotten = it 'cause now I'm getting deja vu. > There is also a SCTP/UDP controlled welding robot behind the firewall. Wi= th the ICE handshake, the browser can't command it to burn holes through th= e wall. Without the handshake, the browser can negotiate a SCTP/UDP connect= ion to the robot and send it arbitrary commands. Also not acceptable. Hmmm, I'm not sure that would be possible... can you give me the IP:port of= your welding robot? ;) OK then, we need a per-session shared secret proof, as a form of per-sessio= n CORS in a way. Will anything other than ICE accomplish it? If we had a form of CORS, such that the host being sent RTP or SCTP/UDP or = TCP/UDP published a list of allowed JS origins somehow, would that be suffi= cient? For example if you're using your own Enterprise's Web Server and ma= king a call to your own Enterprise's conference server or PSTN gateway or w= hatever from inside; if your conference server could somehow indicate "I tr= ust JS from https://www.enteprise.com", similar to the Access-Control-Allow= -Origin header. =20 -hadriel From HKaplan@acmepacket.com Thu Oct 27 21: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 46F3E1F0C5C for ; Thu, 27 Oct 2011 21:05:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.453 X-Spam-Level: X-Spam-Status: No, score=-2.453 tagged_above=-999 required=5 tests=[AWL=0.146, 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 CPgQJRLq4hD0 for ; Thu, 27 Oct 2011 21:05:50 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 1212A21F8507 for ; Thu, 27 Oct 2011 21:05: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, 28 Oct 2011 00:05:48 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.232]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Fri, 28 Oct 2011 00:05:48 -0400 From: Hadriel Kaplan To: Randell Jesup Thread-Topic: [rtcweb] draft-jesup-rtcweb-data-00 posted Thread-Index: AQHMlSbfryRjmuXL80mAKnEEGwJbpA== Date: Fri, 28 Oct 2011 04:05:47 +0000 Message-ID: <3F4E6007-6858-49F5-93B0-E3B5ADBB1E97@acmepacket.com> References: <4EA5EA46.1010803@jesup.org> <4EA9ABC1.1000201@jesup.org> In-Reply-To: <4EA9ABC1.1000201@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: <9B6C4FD4A8E79E4A9D58EA1F397DEBDA@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" , "public-webrtc@w3.org" Subject: Re: [rtcweb] draft-jesup-rtcweb-data-00 posted X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 04:05:51 -0000 Yeah I've kept meaning to email that draft-ietf-rtcweb-security-00 is great= but misses a class of issues around privacy we've had to deal with in SIP.= For example if a session-request is received by the Browser and ICE proce= dures are allowed to start before the human user issues consent, then the f= ar-end peer learns your local IP or your Firewall pinhole. One of the thin= gs they can do with that, for example, is learn roughly where you are, give= n current IP-geo databases. For example if I use Facebook to call Domino's for pizza, Domino's learns t= he town I live in. They would consider that a feature. :) But if the delivery guy in Domino's can someday later make a call back to m= e through Domino's Facebook account and using wireshark see if my ICE-learn= ed IP isn't in my town or even State, without me even accepting the session= request, that's not good. Heck, I'm not even sure it's good to do if I do= accept the session request. The problem is I'm not sure there's any way to explain these types of thing= s and warn Web-app domain admins or JS developers to think about, let alone= normal users, without causing WebRTC to get a bad reputation or scare peop= le. -hadriel On Oct 27, 2011, at 3:06 PM, Randell Jesup wrote: > On 10/25/2011 11:31 AM, Hadriel Kaplan wrote: >> On Oct 25, 2011, at 10:20 AM, Eric Rescorla wrote: >>=20 >>> On Tue, Oct 25, 2011 at 1:02 AM, Hadriel Kaplan= wrote: >>>> Req. 8: The data stream transport protocol MUST NOT encode IP addresse= s inside its protocol fields; doing so reveals potentially private informat= ion, and leads to failure if the address is depended upon. >>> I don't really understand what this means. In general, the peer has >>> access to your IP address >>> information from ICE. >> From a privacy perspective: if a person uses a Web-site designed with pr= ivacy/anonymity in mind (e.g., battered-spouse forum), then the site would = relay your media-plane stuff through a type of TURN server that does ICE it= self both ways. But if the SCTP layer on top of UDP encodes your local IP = using one of the optional SCTP fields in RFC 4960 or 5061, then you lose th= at anonymity. Since the SCTP layer is built into the Browser and not under= control of the Javascript, a site can't prevent it from revealing that inf= o. >=20 >=20 > There's a corollary: a user should be able to set their browser and/or Ap= p to force all incoming calls (and maybe outgoing) through a TURN server. = (There may be other uses for this ability, like corporate firewall traversa= l, but the case you mention is one of them). Witness the recent attack on = identity info on Skype using call-setup protocols, without even decoding th= em: >=20 > http://www.theregister.co.uk/2011/10/21/skype_bittorrent_stalking/print.h= tml > and > http://cis.poly.edu/~ross/papers/skypeIMC2011.pdf >=20 > In theory it could be more nuanced - direct connections for people in you= r phonebook, or listed as friends, etc. But that may be too confusing for = generic users, and too likely to mess up. >=20 > This is more likely a W3C issue, so CC-ing that list >=20 > --=20 > Randell Jesup > randell-ietf@jesup.org >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From ekr@rtfm.com Thu Oct 27 21:09: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 80E4C1F0C55 for ; Thu, 27 Oct 2011 21:09:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.959 X-Spam-Level: X-Spam-Status: No, score=-102.959 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l+WtZHsw3AIe for ; Thu, 27 Oct 2011 21:09:42 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3DF221F0C42 for ; Thu, 27 Oct 2011 21:09:39 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so3646459vcb.31 for ; Thu, 27 Oct 2011 21:09:35 -0700 (PDT) Received: by 10.220.2.19 with SMTP id 19mr173747vch.161.1319774974170; Thu, 27 Oct 2011 21:09:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.118.132 with HTTP; Thu, 27 Oct 2011 21:08:52 -0700 (PDT) In-Reply-To: <3F4E6007-6858-49F5-93B0-E3B5ADBB1E97@acmepacket.com> References: <4EA5EA46.1010803@jesup.org> <4EA9ABC1.1000201@jesup.org> <3F4E6007-6858-49F5-93B0-E3B5ADBB1E97@acmepacket.com> From: Eric Rescorla Date: Thu, 27 Oct 2011 21:08:52 -0700 Message-ID: To: Hadriel Kaplan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Randell Jesup , "" , "public-webrtc@w3.org" Subject: Re: [rtcweb] draft-jesup-rtcweb-data-00 posted X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 04:09:43 -0000 Thanks for pointing this out. I'll amend the document to mention this issue= ... -Ekr On Thu, Oct 27, 2011 at 9:05 PM, Hadriel Kaplan wr= ote: > > Yeah I've kept meaning to email that draft-ietf-rtcweb-security-00 is gre= at but misses a class of issues around privacy we've had to deal with in SI= P. =A0For example if a session-request is received by the Browser and ICE p= rocedures are allowed to start before the human user issues consent, then t= he far-end peer learns your local IP or your Firewall pinhole. =A0One of th= e things they can do with that, for example, is learn roughly where you are= , given current IP-geo databases. > > For example if I use Facebook to call Domino's for pizza, Domino's learns= the town I live in. =A0They would consider that a feature. :) > But if the delivery guy in Domino's can someday later make a call back to= me through Domino's Facebook account and using wireshark see if my ICE-lea= rned IP isn't in my town or even State, without me even accepting the sessi= on request, that's not good. =A0Heck, I'm not even sure it's good to do if = I do accept the session request. > > The problem is I'm not sure there's any way to explain these types of thi= ngs and warn Web-app domain admins or JS developers to think about, let alo= ne normal users, without causing WebRTC to get a bad reputation or scare pe= ople. > > -hadriel > > On Oct 27, 2011, at 3:06 PM, Randell Jesup wrote: > >> On 10/25/2011 11:31 AM, Hadriel Kaplan wrote: >>> On Oct 25, 2011, at 10:20 AM, Eric Rescorla wrote: >>> >>>> On Tue, Oct 25, 2011 at 1:02 AM, Hadriel Kaplan =A0wrote: >>>>> Req. 8: The data stream transport protocol MUST NOT encode IP address= es inside its protocol fields; doing so reveals potentially private informa= tion, and leads to failure if the address is depended upon. >>>> I don't really understand what this means. In general, the peer has >>>> access to your IP address >>>> information from ICE. >>> From a privacy perspective: if a person uses a Web-site designed with p= rivacy/anonymity in mind (e.g., battered-spouse forum), then the site would= relay your media-plane stuff through a type of TURN server that does ICE i= tself both ways. =A0But if the SCTP layer on top of UDP encodes your local = IP using one of the optional SCTP fields in RFC 4960 or 5061, then you lose= that anonymity. =A0Since the SCTP layer is built into the Browser and not = under control of the Javascript, a site can't prevent it from revealing tha= t info. >> >> >> There's a corollary: a user should be able to set their browser and/or A= pp to force all incoming calls (and maybe outgoing) through a TURN server. = =A0(There may be other uses for this ability, like corporate firewall trave= rsal, but the case you mention is one of them). =A0Witness the recent attac= k on identity info on Skype using call-setup protocols, without even decodi= ng them: >> >> http://www.theregister.co.uk/2011/10/21/skype_bittorrent_stalking/print.= html >> and >> http://cis.poly.edu/~ross/papers/skypeIMC2011.pdf >> >> In theory it could be more nuanced - direct connections for people in yo= ur phonebook, or listed as friends, etc. =A0But that may be too confusing f= or generic users, and too likely to mess up. >> >> This is more likely a W3C issue, so CC-ing that list >> >> -- >> 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 randell-ietf@jesup.org Thu Oct 27 22:52: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 2B56511E80A2 for ; Thu, 27 Oct 2011 22:52:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.257 X-Spam-Level: X-Spam-Status: No, score=-2.257 tagged_above=-999 required=5 tests=[AWL=-0.258, 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 6wx7Uuplbcby for ; Thu, 27 Oct 2011 22:52: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 1874C11E80A1 for ; Thu, 27 Oct 2011 22:52: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 1RJfMx-00058f-5g for rtcweb@ietf.org; Fri, 28 Oct 2011 00:52:43 -0500 Message-ID: <4EAA4321.8080707@jesup.org> Date: Fri, 28 Oct 2011 01:52:33 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <99DF5455-9961-41E6-A506-1DD09AF6D1C0@acmepacket.com> <4EA9ECE9.4050500@skype.net> <4EAA003C.7010702@skype.net> <8EDFB02E-20AA-4D5B-B781-68BFD26B0859@acmepacket.com> In-Reply-To: <8EDFB02E-20AA-4D5B-B781-68BFD26B0859@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] Security issue: initial consent X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 05:52:45 -0000 On 10/27/2011 10:56 PM, Hadriel Kaplan wrote: > > Hmmm, I'm not sure that would be possible... can you give me the IP:port of your welding robot? ;) > > OK then, we need a per-session shared secret proof, as a form of per-session CORS in a way. > Will anything other than ICE accomplish it? > > If we had a form of CORS, such that the host being sent RTP or SCTP/UDP or TCP/UDP published a list of allowed JS origins somehow, would that be sufficient? For example if you're using your own Enterprise's Web Server and making a call to your own Enterprise's conference server or PSTN gateway or whatever from inside; if your conference server could somehow indicate "I trust JS from https://www.enteprise.com", similar to the Access-Control-Allow-Origin header. Since this has come up again... I spent a while exploring CORS as an option privately with Cullen. Cullen shot down most of my ideas, though a limited version still survived, I think. I'll quote from my last email on the subject: We'll start by dropping the DNS-based approach. Too bad, but I don't see a way to make it work securely. A Forward-confirmed reverse-DNS lookup would be a good start, but that's spoofable in theory with enough work. Close, but no cigar. Though I'll digress into this for a second: The forward-confirmed reverse-dns approach is spoofable if the attacker can poison the DNS server or has sufficient MITM control to spoof DNS responses. However, the ICE verification method is also spoofable if the attacker is in a MITM position, so the only real added vulnerability is to DNS poisoning. While in general this might not be a reasonable DoS vulnerability, it might I suppose be relevant in targeted attacks. So we're left with CORS (using pre-flight) to the same IP address. CORS is also vulnerable to MITM attacks if not over https (and as it's to an IP address, it's hard to validate the cert given has anything to do with the IP address, and so even https is in effect vulnerable to MITM). Ignoring the MitM effect (and I believe ICE equally MitM-able), CORS has one big advantage over ICE - it only has to be done once every X, where X can be large (using max-age). Another might be lower impact on Hadriel's SBC media processors. They would have to roll it out to their SBCs/etc, but support for responding (tirvially) to an http request is much easier than responding to ICE - and they could in their data center re-route port 80 (or 443) traffic to a generic webserver and not touch the gateways. That would require firewall changes, but might avoid having to touch the gateways. The question would be "is this workable now", and also "is this worth it?" CORS in this case means CORS to the same IP address you want to verify consent with (probably signaled ahead of time by the JS app, so we know to skip ICE). Note that the CORS request, while to the same IP address, does not have to be the same server - website routers can route the 80/443 traffic to a different non-media server if you like, so the existing gateways wouldn't have to be touched. There might be some other ways to leverage this class of idea (using a different port at the same IP, routed differently at the gateway's firewall) to provide consent authorization. -- Randell Jesup randell-ietf@jesup.org From ibc@aliax.net Fri Oct 28 02: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 92F2321F84A7 for ; Fri, 28 Oct 2011 02:24:45 -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 VlYWmrvBgCgU for ; Fri, 28 Oct 2011 02:24: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 9C28821F85F7 for ; Fri, 28 Oct 2011 02:24:44 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so3793052vcb.31 for ; Fri, 28 Oct 2011 02:24:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.210.137 with SMTP id gk9mr322491vcb.131.1319793883774; Fri, 28 Oct 2011 02:24:43 -0700 (PDT) Received: by 10.220.159.134 with HTTP; Fri, 28 Oct 2011 02:24:43 -0700 (PDT) In-Reply-To: References: Date: Fri, 28 Oct 2011 11:24:43 +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] draft-sipdoc-rtcweb-open-wire-protocol-00 (Open In-The-Wire Protocol for RTC-Web) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 09:24:45 -0000 2011/10/27 Tim Panton : > =C2=A05. It must be possible for a website developer to make his RTC-Web > =C2=A0 =C2=A0 =C2=A0 scenario to interoperate without adding new infrastr= ucture unless they wish to > =C2=A0 =C2=A0 =C2=A0 interop with the wider world - i.e. if the > =C2=A0 =C2=A0 =C2=A0 mysite.com example wished to operate as an 'island' = they > =C2=A0 =C2=A0 =C2=A0 would not need to add additional telephony or expert= ise > =C2=A0 =C2=A0 =C2=A0 servers, as all the neccessary server side work coul= d be done in php > =C2=A0 =C2=A0 =C2=A0 by his existing web programmers. =C2=A0" A comment about this requirement: the website could need to add a TURN server in order to allow RTP communication between two users behind symmetriuc NAT. Since this case will be very common the requirement cannot be "mandatory" IMHO. Regards. --=20 I=C3=B1aki Baz Castillo From magnus.westerlund@ericsson.com Fri Oct 28 02:51: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 4C1DC21F8AD6 for ; Fri, 28 Oct 2011 02:51:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.56 X-Spam-Level: X-Spam-Status: No, score=-106.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NdfZe90Oxzuj for ; Fri, 28 Oct 2011 02:51:07 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 4AA0321F87E2 for ; Fri, 28 Oct 2011 02:51:07 -0700 (PDT) X-AuditID: c1b4fb3d-b7c26ae0000035b9-a3-4eaa7b050a8d Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 62.D0.13753.50B7AAE4; Fri, 28 Oct 2011 11:51:02 +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, 28 Oct 2011 11:51:02 +0200 Message-ID: <4EAA7B02.4010400@ericsson.com> Date: Fri, 28 Oct 2011 11:50:58 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Hadriel Kaplan References: <3FACD0E9-449A-4897-8997-F76B5A41A34E@acmepacket.com> In-Reply-To: <3FACD0E9-449A-4897-8997-F76B5A41A34E@acmepacket.com> X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Security issue: consent refresh X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 09:51:08 -0000 On 2011-10-28 02:02, Hadriel Kaplan wrote: > Howdy, per the request made by the Chairs for threads on the security > daft, I'm starting this one on the topic of media-stream consent > refresh. This is related to section 4.2.3 of > draft-ietf-rtcweb-security. > > The concern here is to make sure the other side wants to keep > receiving RTP, since a malicious JS can prevent the Browser learning > the far-end no longer wants to communicate via the high-path. It > also provides protection against certain non-malicious failure cases, > especially with automated systems like media servers. > > Receipt of RTP cannot be used for consent refresh since the session > may be in sendonly/recvonly mode, and RTP can be easily spoofed. One > proposal was to use receipt of RTCP as consent refresh. > > ISTM the problem with using RTCP is (1) some deployed devices don't > do RTCP and faking it in a gateway is bad mojo, and The question is if non RTCP sender will be able at all to interact with WEBRTC peers at all due to congestion control reasons. I think we will come back to this issue several times. (2) if RTCP > wasn't entropic enough for initial consent, why is it for consent > refresh? The issue is that as RTCP contains only a limited amount of entropy it takes long time to provide consent that it isn't feasible. The question is if the same is true for consent refresh. This as one can look over a window of the last 30 seconds and see if a sufficient number of correct RTCP Report blocks has been received that matches the RTCP SR that the media sender sent. > > Alternative Proposal: I think one obvious solution is to use a STUN > request/response check as a consent refresh. The STUN check does not > need to use SHA-1 stuff, just responding with the same transaction ID > as the request should provide enough entropy. The STUN message could > be an existing one from RFC 5389, but it would take a new draft to > say "do this" and indicate it in SDP. And the reason you are not needing the SHA-1 stuff is that you see no need for this consent refresh to continue to verify that the one sending the answers echoing the transaction IDs is a node which you provided with the credentials? Or which the "evil" webservice has provisioned with the credentials from the signalling exchange? > > The benefits of this are that it doesn't rely on RTCP entropy, or > even RTCP period. It is easier to implement in a gateway than fake > RTCP generation. And it allows interworking gateways to get out of > the way (not be in the media-plane) because they can know both sides > do the consent refresh, which they don't know about just RTCP. Well, interworking gateways that have peers that terminates their ICE connectivity check capabilities after session establishment and only send STUN indication will not work as you stated. And in the case the peer are not ICE capable and you anyhow need the media plane gateway function to answer the ICE exchanges you get more work in this gateway. > > The downside is any existing RTP devices that already support ICE and > RTCP would need to be upgraded in order to talk to WebRTC. I think > there's a solution to that too if people think we need to interop > with them without upgrading. One idea is IF RTCP is sufficiently > entropic for consent refresh, then we have an escape clause that if > the peer doesn't indicate support for this new STUN-based consent > refresh, then we allow it to use RTCP as consent refresh. If you need this upgrade, why not ensure that they do RTCP? That is more useful for also other purpose and may actually ensure that we can fulfill some minimal congestion control requirements even in the interworking cases. Yes, it is more new code, than tweaking an existing ICE stack to do what you suggest. 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 wolfgang.beck01@googlemail.com Fri Oct 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 5B00721F86EC for ; Fri, 28 Oct 2011 07:40:31 -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.132, 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 Bv4HKBb4uwXH for ; Fri, 28 Oct 2011 07:40:30 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id A8C6921F8AFD for ; Fri, 28 Oct 2011 07:40:30 -0700 (PDT) Received: by qadc10 with SMTP id c10so4679806qad.31 for ; Fri, 28 Oct 2011 07:40:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XAHzxQe0QytxwNLs5xqLjB2OIvI5cjlWrD+wj6enR8I=; b=r1+cUSXF11c+OdnClfD5xP65CCgbulJMq98xYj6BGlrzfPXJzVOff1acX0ry+i8ECz oqHdtf0QatA4vsYGedQhgNhviMjcIOiLRD7Erlvf04CxmkuFysLgiFHryn0Mzatu/rVs NuPqOjj0H1FdDEc5qDuffMaCrnAkDUusyasPs= MIME-Version: 1.0 Received: by 10.68.31.132 with SMTP id a4mr4649655pbi.26.1319812829760; Fri, 28 Oct 2011 07:40:29 -0700 (PDT) Received: by 10.68.49.169 with HTTP; Fri, 28 Oct 2011 07:40:29 -0700 (PDT) In-Reply-To: References: Date: Fri, 28 Oct 2011 16:40:29 +0200 Message-ID: From: Wolfgang Beck To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: text/plain; charset=ISO-8859-1 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] draft-sipdoc-rtcweb-open-wire-protocol-00 (Open In-The-Wire Protocol for RTC-Web) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 14:40:31 -0000 Your document gives a nice overview how RTCWEB (WEBRTC? *sigh*) messages may look. Section 4 is a bit confusing as Bob calls Alice instead of the other way round. It illustrates nicely that trapezoid -style interconnection would only work with a common server-to-server protocol like SIP. Nobody would try to implement all possible combinations of protocol translators to interconnect your four example protocols. With SIP, they "only" have to agree on the subset to implement. If SIP does not support a feature they support, they can't interconnect. Wolfgang Beck From ibc@aliax.net Fri Oct 28 07:55: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 7CDBC21F8A64 for ; Fri, 28 Oct 2011 07:55:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.643 X-Spam-Level: X-Spam-Status: No, score=-2.643 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hc0IgwFSNZV3 for ; Fri, 28 Oct 2011 07:55: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 E819E21F8A71 for ; Fri, 28 Oct 2011 07:55:23 -0700 (PDT) Received: by vws5 with SMTP id 5so4135916vws.31 for ; Fri, 28 Oct 2011 07:55:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.107.81 with SMTP id a17mr470895vcp.96.1319813723457; Fri, 28 Oct 2011 07:55:23 -0700 (PDT) Received: by 10.220.159.134 with HTTP; Fri, 28 Oct 2011 07:55:23 -0700 (PDT) In-Reply-To: References: Date: Fri, 28 Oct 2011 16:55:23 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Wolfgang Beck Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] draft-sipdoc-rtcweb-open-wire-protocol-00 (Open In-The-Wire Protocol for RTC-Web) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 14:55:24 -0000 2011/10/28 Wolfgang Beck : > Your document gives a nice overview how RTCWEB (WEBRTC? *sigh*) > messages may look. Section 4 is a bit confusing as Bob calls Alice > instead of the other way round. IMHO it is time for Bob to call Alice :) > It illustrates nicely that trapezoid -style interconnection would only > work with a common server-to-server protocol like SIP. Nobody would > try to implement all possible combinations of protocol translators to > interconnect your four example protocols. With SIP, they "only" have > to agree on the subset to implement. If SIP does not support a feature > they support, they can't interconnect. Right, but the same already occurs when attempting to interconnect two pure SIP domains. Nothing new here :) Thanks a lot. --=20 I=C3=B1aki Baz Castillo From igor.faynberg@alcatel-lucent.com Fri Oct 28 09:11: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 77A0921F8B23 for ; Fri, 28 Oct 2011 09:11: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 xnxL29P+-aV7 for ; Fri, 28 Oct 2011 09:11:21 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id A8D2E21F8B09 for ; Fri, 28 Oct 2011 09:11:20 -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 p9SGBHeK013195 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 28 Oct 2011 11:11:18 -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 p9SGBHHr016285 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 28 Oct 2011 11:11:17 -0500 Received: from [135.244.42.55] (faynberg.lra.lucent.com [135.244.42.55]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p9SGBG9Z002630; Fri, 28 Oct 2011 11:11:17 -0500 (CDT) Message-ID: <4EAAD424.6040308@alcatel-lucent.com> Date: Fri, 28 Oct 2011 12:11:16 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: rtcweb@ietf.org References: <99DF5455-9961-41E6-A506-1DD09AF6D1C0@acmepacket.com> In-Reply-To: <99DF5455-9961-41E6-A506-1DD09AF6D1C0@acmepacket.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.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Subject: Re: [rtcweb] Security issue: initial consent 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: Fri, 28 Oct 2011 16:11:21 -0000 It would be good to do that, but can we REALLY achieve this?.. (Especially, the the "Heck," clause)? Igor, ever the Pessimist On 10/27/2011 7:39 PM, Hadriel Kaplan wrote: > ... > > > The "TCP" is in the Browser, so we can improve things. We could, for example, decide that the JS cannot learn the ephemeral source port number of the TCP-layer from the Browser, and that it be chosen randomly every time from the full 16-bit range (as opposed to the small ephemeral range used by most OS's), giving another 16-bits of entropy. And of course we'd specify that the ISN be chosen securely. Heck, we could even mandate using a new TCP header option to be reflected by the other side, similar to the TCP Timestamp option, but put a random number in it. > > -hadriel > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From HKaplan@acmepacket.com Fri Oct 28 10: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 B4C5F21F89BA for ; Fri, 28 Oct 2011 10:54:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.454 X-Spam-Level: X-Spam-Status: No, score=-2.454 tagged_above=-999 required=5 tests=[AWL=0.145, 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 5idlgdlqhACl for ; Fri, 28 Oct 2011 10:54:12 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 04DD021F8801 for ; Fri, 28 Oct 2011 10:54:11 -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, 28 Oct 2011 13:54:10 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.232]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Fri, 28 Oct 2011 13:54:10 -0400 From: Hadriel Kaplan To: Randell Jesup Thread-Topic: [rtcweb] Security issue: initial consent Thread-Index: AQHMlZqXV9X3XqSMQEyJ2Ov7GYMyHQ== Date: Fri, 28 Oct 2011 17:54:09 +0000 Message-ID: <7945DFBD-3204-41B3-85BF-5264AADCFBD6@acmepacket.com> References: <99DF5455-9961-41E6-A506-1DD09AF6D1C0@acmepacket.com> <4EA9ECE9.4050500@skype.net> <4EAA003C.7010702@skype.net> <8EDFB02E-20AA-4D5B-B781-68BFD26B0859@acmepacket.com> <4EAA4321.8080707@jesup.org> In-Reply-To: <4EAA4321.8080707@jesup.org> 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: <1E6517D955D1F444A6541255088D50A1@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [rtcweb] Security issue: initial consent X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 17:54:12 -0000 On Oct 28, 2011, at 1:52 AM, Randell Jesup wrote: > The forward-confirmed reverse-dns approach is spoofable if the > attacker can poison the DNS server or has sufficient MITM control to > spoof DNS responses. However, the ICE verification method is also > spoofable if the attacker is in a MITM position, so the only real > added vulnerability is to DNS poisoning. While in general this > might not be a reasonable DoS vulnerability, it might I suppose be > relevant in targeted attacks. I don't know what the DNS proposal was, but in Matthew's inside-Enterprise-= attack scenarios, if the MitM is inside the Enterprise then yes all bets ar= e off; but a MitM of Javascript/HTTP and DNS outside the Enterprise would n= ot be in a position to perform the attack directly, nor spoof ICE for Matth= ew's attack scenario. So doing ICE is safer than using DNS for approval. > So we're left with CORS (using pre-flight) to the same IP address. C= ORS is also vulnerable to MITM attacks if not over https (and as > it's to an IP address, it's hard to validate the cert given has > anything to do with the IP address, and so even https is in effect > vulnerable to MITM).=20 It's nastier than even that possibly - the same IP Address providing CORS d= oes not mean it'll end up being the same application process that gets the = subsequent SCTP or RTP. For example if you're running a virtual hosting si= te and share the same IP for multiple customer apps. Do people do that? (I = would think lots of things would break if they do, but who knows) A nastier example is corporate Firewall-NATs or Carrier-Grade-NATs (CGNs), = where a ton of hosts are represented by a few IP addresses. If you're doin= g this from outside of the Firewall/CGN to a host inside the Firewall/CGN, = then getting a CORS approval from one port number means nothing about reach= ing the same host on another port. > Ignoring the MitM effect (and I believe ICE equally MitM-able), CORS > has one big advantage over ICE - it only has to be done once every > X, where X can be large (using max-age). Another might be lower > impact on Hadriel's SBC media processors. They would have to roll > it out to their SBCs/etc, but support for responding (tirvially) to > an http request is much easier than responding to ICE - and they > could in their data center re-route port 80 (or 443) traffic to a > generic webserver and not touch the gateways. That would require > firewall changes, but might avoid having to touch the gateways. But on a single gateway/SBC doing ICE could be a lot easier than HTTP GETs.= It all depends on your system design/architecture and we can't know which= ones are going to be used. My only argument against ICE has been that doi= ng ICE is harder than not doing it at all, and even if you do ICE then doin= g SHA-1 on a per-STUN-message basis is harder than not doing SHA-1. (where = "harder" would mean more CPU cycles or more cost) > The question would be "is this workable now", and also "is this > worth it?" Good question. I think debating/considering it is free, other than consumi= ng emails and brain cycles. :) -hadriel From pravindran@sonusnet.com Fri Oct 28 10:59: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 CA38521F8AA8 for ; Fri, 28 Oct 2011 10:59:21 -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.249, 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 zvWMyyl5TtNn for ; Fri, 28 Oct 2011 10:59:21 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 38D6C21F8A80 for ; Fri, 28 Oct 2011 10:59:21 -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 p9SHxrML009318; Fri, 28 Oct 2011 13:59:53 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail05.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 28 Oct 2011 13:59: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="utf-8" Content-Transfer-Encoding: base64 Date: Fri, 28 Oct 2011 23:26:15 +0530 Message-ID: <2E239D6FCD033C4BAF15F386A979BF51159D7A@sonusinmail02.sonusnet.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RTCWeb Forking usecase [was RE: [rtcweb] draft-kaplan-rtcweb-sip-interworking-requirements-00] thread-index: AcyS8Za33GZ80oo8Sq6Si3hUzP+/HACqGyUQ References: <20111024224257.28459.65554.idtracker@ietfa.amsl.com><6EB8679A-13D5-4AD7-97F2-BC35FC0966F0@acmepacket.com><2E239D6FCD033C4BAF15F386A979BF51159C32@sonusinmail02.sonusnet.com> From: "Ravindran Parthasarathi" To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= , , "Hadriel Kaplan" X-OriginalArrivalTime: 28 Oct 2011 17:59:17.0822 (UTC) FILETIME=[4FCD35E0:01CC959B] Subject: [rtcweb] RTCWeb Forking usecase [was RE: draft-kaplan-rtcweb-sip-interworking-requirements-00] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 17:59:21 -0000 QnkgbG9va2luZyBhdCBkcmFmdC1pZXRmLXJ0Y3dlYi11c2UtY2FzZXMtYW5kLXJlcXVpcmVtZW50 cy0wNiwgSSBjb3VsZCBub3Qgc2VlIGFueSBzcGVjaWZpYyByZXF1aXJlbWVudCBmb3IgUlRDV2Vi IGZvcmtpbmcuIEluIGNhc2UgU0lQIGZvcmtpbmcgaXMgdGhlIG9ubHkgcmVxdWlyZW1lbnQgZm9y IFJUQ1dlYiBhbmQgYWxzbywgUlRDV2ViIGRvZXMgbm90IGhhdmUgYW55IHNwZWNpZmljIGZvcmtp bmcgcmVxdWlyZW1lbnQsIHRoZW4gdGhlIGdhdGV3YXkgYmV0d2VlbiBSVENXZWIgJiBTSVAgc2hh bGwgdGFrZSBjYXJlIG9mIHRoZSBmdW5jdGlvbmFsaXR5LiBJJ20gYXNraW5nIHRoaXMgcXVlc3Rp b24gdG8gZ2V0IHRoZSBjbGFyaXR5IG9uIHdoZXRoZXIgU0lQIGZvcmtpbmcgZmVhdHVyZSBoYXMg dG8gaW1wYWN0IFJUQ1dlYiBjbGllbnQgcmVxdWlyZW1lbnQgb3Igbm90LiANCg0KVGhhbmtzDQpQ YXJ0aGENCg0KPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+RnJvbTogScOxYWtpIEJheiBD YXN0aWxsbyBbbWFpbHRvOmliY0BhbGlheC5uZXRdDQo+U2VudDogVHVlc2RheSwgT2N0b2JlciAy NSwgMjAxMSAyOjA5IFBNDQo+VG86IFJhdmluZHJhbiBQYXJ0aGFzYXJhdGhpDQo+Q2M6IEhhZHJp ZWwgS2FwbGFuOyBydGN3ZWJAaWV0Zi5vcmcNCj5TdWJqZWN0OiBSZTogW3J0Y3dlYl0gZHJhZnQt a2FwbGFuLXJ0Y3dlYi1zaXAtaW50ZXJ3b3JraW5nLXJlcXVpcmVtZW50cy0NCj4wMA0KPg0KPjIw MTEvMTAvMjUgUmF2aW5kcmFuIFBhcnRoYXNhcmF0aGkgPHByYXZpbmRyYW5Ac29udXNuZXQuY29t PjoNCj4+IEknbGwgdGFrZSBBMS0xIHJlcXVpcmVtZW50IG9mIFNJUCBmb3JraW5nIHdoZXJlaW4g aXQgaXMgdmVyeSBtdWNoDQo+PiBwb3NzaWJsZSBmb3IgUlRDV0VCLVNJUCBnYXRld2F5IHRvIGhp ZGUgdGhlIGZvcmtpbmcgZnVuY3Rpb25hbGl0eSBmcm9tDQo+PiBicm93c2VyIGFuZCBpdCBpcyBu b3JtYWwgQjJCVUEgKFNCQyBpbiBtYXJrZXQgdGVybSkgZnVuY3Rpb25hbGl0eSBpbg0KPlNJUA0K Pj4gd2hlcmVpbiBvcmlnaW5hdGluZyBTSVAgVUEgZG9lcyBub3Qgc3VwcG9ydCBmb3JraW5nIHBy b3Blcmx5LiBJT1csDQo+PiBwbGVhc2UgZG9uJ3QgYWRkIHJlcXVpcmVtZW50IGluIFJUQ1dlYiBm b3IgdGhlIHNha2UgU0lQIGludGVyb3AgYW5kIGl0DQo+PiBpcyBwb3NzaWJsZSB0byBkZXNpZ24g dGhlIGJldHRlciBnYXRld2F5IGlmIHJlcXVpcmVkLg0KPg0KPlBsZWFzZSB0YWtlIGludG8gYWNj b3VudCB0aGF0IHNvbWUgb2YgdXMgYWxzbyBkZXNpcmUgdG8gaW50ZXJvcGVyYXRlDQo+d2l0aCBT SVAgYnV0IHdlICpkb24ndCogbmVlZCBhIEIyQlVBL1NCQyBuZWl0aGVyIGEgcHJvdG9jb2wgZ2F0 ZXdheQ0KPmZvciBzdWNoIGludGVyY29ubmVjdGlvbiAoaW5zdGVhZCB3ZSBhcmUgdXNpbmcgKm5v dyogYSBTSVAgcHJveHkNCj5pbXBsZW1lbnRpbmcgU0lQIG92ZXIgV2ViU29ja2V0IHNvIHRoZSBK YXZhU2NyaXB0IGFwcGxpY2F0aW9uIGJlY29tZXMNCj5hIHJlYWwgU0lQIFVBKS4NCj4NCj5IYXZp bmcgc2FpZCB0aGF0LCBTSVAgZm9ya2luZyBpcyBhICpmZWF0dXJlKiByYXRoZXIgdGhhbiBhIHB1 bmlzaG1lbnQuDQo+SXQgYWRkcyBjb21wbGV4aXR5IG9mIGNvdXJzZSwgYnV0IHN0aWxsIGl0J3Mg YW4gdXNlZnVsIGZlYXR1cmUuIFNvbWUNCj5vZiB1cyB3YW50IHRvIGRlYWwgd2l0aCB0aGF0IGNv bXBsZXhpdHkgYXQgVUEgbGV2ZWwgKEphdmFTY3JpcHQpLiBTb21lDQo+b3RoZXJzIHdvdWxkIHBy ZWZlciBub3QgdG8gYWxsb3cgZm9ya2luZyBpbiB0aGVpciBSVEMtV2ViIHNjZW5hcmlvcyBzbw0K PmhhdmUgbm8gbmVlZCB0byBkZWFsIHdpdGggZm9ya2luZy4gTGV0J3MgdGhlIHBlb3BsZSBjaG9v c2UgaXQuDQo+DQo+DQo+DQo+PiBJJ20gbG9va2luZyBmb3INCj4+IHN0YW5kYXJkIFJUQ1dlYiBz aWduYWxpbmcgcHJvdG9jb2wgbGlrZSBST0FQIGJ5IHdoaWNoIGJldHRlciBzb2x1dGlvbg0KPj4g Zm9yIFJUQ1dlYi1mZWRlcmF0aW9uIGdhdGV3YXkgaXMgZG9jdW1lbnRlZCBpbiBJRVRGLg0KPg0K PlllcywgeW91IHdhbnQgdG8gbWFuZGF0ZSBzb21lIHNwZWNpZmljIGluLXRoZS13aXJlIHNpZ25h bGluZyBwcm90b2NvbA0KPmluIFJUQ3dlYiBhbmQgZm9yY2UgbWUsIGFuZCBvdGhlcnMsIHRvIHVz ZSBhIFJUQ1dlYi1TSVAgZ2F0ZXdheSBib3gNCj4ocmVnYXJkbGVzcyBJIGFscmVhZHkgaGF2ZSBt eSBSVEN3ZWIgc29sdXRpb24gcmVhZHkgdG8gaW50ZXJvcCB3aXRoIGENCj5TSVAgbmV0d29yayBp biB0aGUgc2lnbmFsaW5nIHBsYW5lIHdpdGhvdXQgdXNpbmcgcHJvdG9jb2wgZ2F0ZXdheXMpLiBJ DQo+d291bGQgYXNrIHlvdSB0byByZWFkIHRoaXMgZHJhZnQgaW4gd2hpY2ggZGlmZmVyZW50IFJU Q3dlYiBzY2VuYXJpb3MNCj5hcmUgZGVzY3JpYmVkOg0KPg0KPiAgaHR0cDovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtc2lwZG9jLXJ0Y3dlYi1vcGVuLXdpcmUtcHJvdG9jb2wtMDANCj4NCj4N Cj4NCj4+IEFsc28sIEknbSBpbnRlcmVzdGVkIGluIGhlYXJpbmcgYWJvdXQgb3RoZXIgUlRDV2Vi IGZlZGVyYXRpb24gcHJvdG9jb2wNCj4+IGxpa2UgSmluZ2xlIGJlZm9yZSBkb2luZyB0aGUgZGVl cC1kaXZlIGludG8gdGhlIHJlcXVpcmVtZW50IGJlY2F1c2UgbXkNCj4+IGd1dCBmZWVsaW5nIGlz IHRoYXQgd2Ugd2lsbCBlbmQtdXAgaW4gbXVsdGlwbGUgZmVkZXJhdGlvbiBwcm90b2NvbA0KPj4g cmF0aGVyIHRoYW4gc2luZ2xlLg0KPg0KPkkgaG9wZSB0aGF0IHdlIHdpbGwgZW5kIHdpdGggKm5v IG9uZSogZmVkZXJhdGlvbiBwcm90b2NvbCBzbyBlYWNoDQo+d2Vic2l0ZSBjYW4gZGVjaWRlIHdo YXQgdG8gdXNlIGluIGNhc2UgaXQgd2FudHMgdG8gZmVkZXJhdGUgd2l0aCBvdGhlcg0KPndlYnNp dGUuIFdlYiB3aWxsIGRlY2lkZSwgYXMgaXQgYWx3YXlzIGRvZXMuIFRoZSBpbXBvcnRhbnQgcG9p bnQgaGVyZQ0KPmlzIHRvIGxlYXZlIHRoZSBXZWIgdGhlIGZyZWVkb20gdG8gY2hvb3NlIHdoaWNo ZXZlciBmZWRlcmF0aW9uDQo+bWVjaGFuaXNtLiBTb21lIG1lY2hhbmlzbS9wcm90b2NvbCB3aWxs IHN1Y2Nlc3MgbW9yZSB0aGFuIG90aGVycyBhbmQNCj53aWxsIGJlY29tZSBkZSBmYWN0byBSVEN3 ZWIgZmVkZXJhdGlvbiBwcm90b2NvbCBpbiB0aGUgV2ViLiBUaGlzIGlzDQo+aG93IHRoaW5ncyB3 b3JrIGluIHRoZSBXZWIuDQo+DQo+DQo+UmVnYXJkcy4NCj4NCj4NCj4tLQ0KPknDsWFraSBCYXog Q2FzdGlsbG8NCj48aWJjQGFsaWF4Lm5ldD4NCg== From HKaplan@acmepacket.com Fri Oct 28 11:24: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 86DF721F8A56 for ; Fri, 28 Oct 2011 11:24:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.456 X-Spam-Level: X-Spam-Status: No, score=-2.456 tagged_above=-999 required=5 tests=[AWL=0.143, 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 HwO-QfT7jJxw for ; Fri, 28 Oct 2011 11:24:05 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id D4E3D21F8713 for ; Fri, 28 Oct 2011 11:24: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; Fri, 28 Oct 2011 14:24:01 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.232]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Fri, 28 Oct 2011 14:24:01 -0400 From: Hadriel Kaplan To: Magnus Westerlund Thread-Topic: [rtcweb] Security issue: consent refresh Thread-Index: AQHMlZ7D8XS7IkOhHkahsxLL5uYzkw== Date: Fri, 28 Oct 2011 18:24:01 +0000 Message-ID: <2308DE02-0E63-4CCF-8889-F2E79204C7AF@acmepacket.com> References: <3FACD0E9-449A-4897-8997-F76B5A41A34E@acmepacket.com> <4EAA7B02.4010400@ericsson.com> In-Reply-To: <4EAA7B02.4010400@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.0.0.30] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <92A9BC0DB00EC449BDD8808E8BB02EE2@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Security issue: consent refresh X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 18:24:05 -0000 On Oct 28, 2011, at 5:50 AM, Magnus Westerlund wrote: > On 2011-10-28 02:02, Hadriel Kaplan wrote: >>=20 >> Alternative Proposal: I think one obvious solution is to use a STUN >> request/response check as a consent refresh. The STUN check does not >> need to use SHA-1 stuff, just responding with the same transaction ID >> as the request should provide enough entropy. The STUN message could >> be an existing one from RFC 5389, but it would take a new draft to >> say "do this" and indicate it in SDP. >=20 > And the reason you are not needing the SHA-1 stuff is that you see no > need for this consent refresh to continue to verify that the one sending > the answers echoing the transaction IDs is a node which you provided > with the credentials? Or which the "evil" webservice has provisioned > with the credentials from the signalling exchange? Correct. Let's assume ICE is used for initial consent. If you're past the= initial consent stage, then some far-end accepted your communication.=20 At that point we're at the same stage as if the JS had simply initiated an = HTTP connection to another site and it was approved with CORS. What keeps = such an HTTP connection going is simply TCP "consent-refresh" using ACKs an= d not getting RST/FIN... and we don't need to be stronger than TCP. Arguab= ly the STUN keepalive would actually be stronger than TCP even without SHA-= 1, because the STUN 96-bit Transaction-ID is harder to spoof-guess than two= 16-bit TCP sequence number fields. If there is a MitM physically on the path between the Browser and the peer,= such a MitM can keep the RTP flowing even if we used RTCP, because it coul= d fake RTCP. (and such a MitM can keep TCP and SCTP going too, fwiw) >> The downside is any existing RTP devices that already support ICE and >> RTCP would need to be upgraded in order to talk to WebRTC. I think >> there's a solution to that too if people think we need to interop >> with them without upgrading. One idea is IF RTCP is sufficiently >> entropic for consent refresh, then we have an escape clause that if >> the peer doesn't indicate support for this new STUN-based consent >> refresh, then we allow it to use RTCP as consent refresh. >=20 > If you need this upgrade, why not ensure that they do RTCP? That is more > useful for also other purpose and may actually ensure that we can > fulfill some minimal congestion control requirements even in the > interworking cases. Yes, it is more new code, than tweaking an existing > ICE stack to do what you suggest. Because we can't upgrade devices not under our control, as described in dra= ft-kaplan-rtcweb-sip-interworking-requirements-00 section 3. For some perc= entage of the WebRTC use-cases, interfacing to deployed SIP devices will ne= ed an Inter-Working Function. Having an IWF system generate fake RTCP is a= really bad idea; from a cost, complexity, failure-potential, and architect= ural basis. And such an IWF could never remove itself (let media go direct= ) on a call-by-call basis, because it woul'd never know if the far-end SIP = device implements RTCP. -hadriel From harald@alvestrand.no Fri Oct 28 11:25: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 2093A21F8713 for ; Fri, 28 Oct 2011 11:25:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.387 X-Spam-Level: X-Spam-Status: No, score=-110.387 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599, NORMAL_HTTP_TO_IP=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 Fz6c8ybQ+xwu for ; Fri, 28 Oct 2011 11:25:12 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id E869721F8888 for ; Fri, 28 Oct 2011 11:25:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 51D6839E165; Fri, 28 Oct 2011 20:25: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 GUcF2hWi-zdo; Fri, 28 Oct 2011 20:25:08 +0200 (CEST) Received: from [172.19.29.10] (216-239-45-4.google.com [216.239.45.4]) by eikenes.alvestrand.no (Postfix) with ESMTPS id BE07439E048; Fri, 28 Oct 2011 20:25:07 +0200 (CEST) Message-ID: <4EAAF382.50004@alvestrand.no> Date: Fri, 28 Oct 2011 11:25:06 -0700 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: Hadriel Kaplan References: <99DF5455-9961-41E6-A506-1DD09AF6D1C0@acmepacket.com> <4EA9ECE9.4050500@skype.net> <4EAA003C.7010702@skype.net> <8EDFB02E-20AA-4D5B-B781-68BFD26B0859@acmepacket.com> <4EAA4321.8080707@jesup.org> <7945DFBD-3204-41B3-85BF-5264AADCFBD6@acmepacket.com> In-Reply-To: <7945DFBD-3204-41B3-85BF-5264AADCFBD6@acmepacket.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Randell Jesup , "" Subject: Re: [rtcweb] Security issue: initial consent X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 18:25:13 -0000 On 10/28/2011 10:54 AM, Hadriel Kaplan wrote: > On Oct 28, 2011, at 1:52 AM, Randell Jesup wrote: > >> The forward-confirmed reverse-dns approach is spoofable if the >> attacker can poison the DNS server or has sufficient MITM control to >> spoof DNS responses. However, the ICE verification method is also >> spoofable if the attacker is in a MITM position, so the only real >> added vulnerability is to DNS poisoning. While in general this >> might not be a reasonable DoS vulnerability, it might I suppose be >> relevant in targeted attacks. > I don't know what the DNS proposal was, but in Matthew's inside-Enterprise-attack scenarios, if the MitM is inside the Enterprise then yes all bets are off; but a MitM of Javascript/HTTP and DNS outside the Enterprise would not be in a position to perform the attack directly, nor spoof ICE for Matthew's attack scenario. So doing ICE is safer than using DNS for approval. > > >> So we're left with CORS (using pre-flight) to the same IP address. CORS is also vulnerable to MITM attacks if not over https (and as >> it's to an IP address, it's hard to validate the cert given has >> anything to do with the IP address, and so even https is in effect >> vulnerable to MITM). > It's nastier than even that possibly - the same IP Address providing CORS does not mean it'll end up being the same application process that gets the subsequent SCTP or RTP. For example if you're running a virtual hosting site and share the same IP for multiple customer apps. Do people do that? (I would think lots of things would break if they do, but who knows) All web hosting companies host massive numbers of user sites on the same (set of) IP addresses. I believe the big ones go into the hundreds of thousands of names (~=customers) per IP address. Although, if you go to http:/// you will usually get a "no such customer" page. (try http://74.125.127.121/ which is one IP for www.alvestrand.com, for instance) Things get more complex (along multiple dimensions) if you can ask the client to do the CORS request to http://:port - in that case, if the IP address is a carrier grade NAT box, the attacker can potentially grab one port in order to reply to the CORS, and then attack other customers by feeding in other port numbers to the subsequent SCTP/RTP. > A nastier example is corporate Firewall-NATs or Carrier-Grade-NATs (CGNs), where a ton of hosts are represented by a few IP addresses. If you're doing this from outside of the Firewall/CGN to a host inside the Firewall/CGN, then getting a CORS approval from one port number means nothing about reaching the same host on another port. > > >> Ignoring the MitM effect (and I believe ICE equally MitM-able), CORS >> has one big advantage over ICE - it only has to be done once every >> X, where X can be large (using max-age). Another might be lower >> impact on Hadriel's SBC media processors. They would have to roll >> it out to their SBCs/etc, but support for responding (tirvially) to >> an http request is much easier than responding to ICE - and they >> could in their data center re-route port 80 (or 443) traffic to a >> generic webserver and not touch the gateways. That would require >> firewall changes, but might avoid having to touch the gateways. > But on a single gateway/SBC doing ICE could be a lot easier than HTTP GETs. It all depends on your system design/architecture and we can't know which ones are going to be used. My only argument against ICE has been that doing ICE is harder than not doing it at all, and even if you do ICE then doing SHA-1 on a per-STUN-message basis is harder than not doing SHA-1. (where "harder" would mean more CPU cycles or more cost) > > >> The question would be "is this workable now", and also "is this >> worth it?" > Good question. I think debating/considering it is free, other than consuming emails and brain cycles. :) Ouch, that's expensive! From harald@alvestrand.no Fri Oct 28 11: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 356EF21F8A62 for ; Fri, 28 Oct 2011 11:27:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.418 X-Spam-Level: X-Spam-Status: No, score=-110.418 tagged_above=-999 required=5 tests=[AWL=0.181, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sCwl1nCnoS4y for ; Fri, 28 Oct 2011 11:27:35 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 97E4121F8A7D for ; Fri, 28 Oct 2011 11:27:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id DCB7A39E165; Fri, 28 Oct 2011 20:27: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 jJeKXzolp3kZ; Fri, 28 Oct 2011 20:27:34 +0200 (CEST) Received: from [172.19.29.10] (216-239-45-4.google.com [216.239.45.4]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 94A3939E048; Fri, 28 Oct 2011 20:27:33 +0200 (CEST) Message-ID: <4EAAF413.8030501@alvestrand.no> Date: Fri, 28 Oct 2011 11:27:31 -0700 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: Ravindran Parthasarathi References: <20111024224257.28459.65554.idtracker@ietfa.amsl.com><6EB8679A-13D5-4AD7-97F2-BC35FC0966F0@acmepacket.com><2E239D6FCD033C4BAF15F386A979BF51159C32@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF51159D7A@sonusinmail02.sonusnet.com> In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF51159D7A@sonusinmail02.sonusnet.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] RTCWeb Forking usecase [was RE: draft-kaplan-rtcweb-sip-interworking-requirements-00] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 18:27:36 -0000 On 10/28/2011 10:56 AM, Ravindran Parthasarathi wrote: > By looking at draft-ietf-rtcweb-use-cases-and-requirements-06, I could not see any specific requirement for RTCWeb forking. In case SIP forking is the only requirement for RTCWeb and also, RTCWeb does not have any specific forking requirement, then the gateway between RTCWeb& SIP shall take care of the functionality. I'm asking this question to get the clarity on whether SIP forking feature has to impact RTCWeb client requirement or not. I believe the "Fedex IVR" case was specifically intended to surface the requirement for "non-final responses" (switching a media stream from the initial responder to a next responder). That's one form of forking ("serial fork"?) I haven't understood forking to be a requirement in any other use case. From harald@alvestrand.no Fri Oct 28 12:01: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 CE60E21F899F for ; Fri, 28 Oct 2011 12:01:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.44 X-Spam-Level: X-Spam-Status: No, score=-110.44 tagged_above=-999 required=5 tests=[AWL=0.159, 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 j+8BuqeKs4Lu for ; Fri, 28 Oct 2011 12:01:49 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id C63AA21F88B7 for ; Fri, 28 Oct 2011 12:01:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0B42539E165 for ; Fri, 28 Oct 2011 21:01: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 jQzEwx34XET6 for ; Fri, 28 Oct 2011 21:01:47 +0200 (CEST) Received: from [172.19.29.10] (216-239-45-4.google.com [216.239.45.4]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 51F6B39E048 for ; Fri, 28 Oct 2011 21:01:47 +0200 (CEST) Message-ID: <4EAAFC19.1040604@alvestrand.no> Date: Fri, 28 Oct 2011 12:01:45 -0700 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: "rtcweb@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [rtcweb] ICE/STUN support in SIP endpoints: SIPit data X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 19:01:49 -0000 Just saw this in a report from SIPit 29.... Support for various items in the 20 endpoints present: 50% ice 40% 5389stun 35% turn 15% 3489stun Of course the devices that people drag along to SIPit aren't exactly old devices, but it's still nice to see documentation that there exist at least 10 ICE-supporting SIP devices. Harald From ibc@aliax.net Fri Oct 28 12: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 4AEAB1F0C41 for ; Fri, 28 Oct 2011 12:07:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.644 X-Spam-Level: X-Spam-Status: No, score=-2.644 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DQpc5fV0KJ9t for ; Fri, 28 Oct 2011 12:07: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 B185B1F0C40 for ; Fri, 28 Oct 2011 12:07:01 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so4390644vcb.31 for ; Fri, 28 Oct 2011 12:07:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.151.129 with SMTP id c1mr580187vcw.271.1319828821175; Fri, 28 Oct 2011 12:07:01 -0700 (PDT) Received: by 10.220.159.134 with HTTP; Fri, 28 Oct 2011 12:07:01 -0700 (PDT) In-Reply-To: <4EAAFC19.1040604@alvestrand.no> References: <4EAAFC19.1040604@alvestrand.no> Date: Fri, 28 Oct 2011 21:07:01 +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] ICE/STUN support in SIP endpoints: SIPit data X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 19:07:02 -0000 2011/10/28 Harald Alvestrand : > Of course the devices that people drag along to SIPit aren't exactly old > devices, but it's still nice to see documentation that there exist at lea= st > 10 ICE-supporting SIP devices. It's also important that those SIP devices implementing ICE interoperate :) --=20 I=C3=B1aki Baz Castillo From pravindran@sonusnet.com Fri Oct 28 12: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 4C6E21F0C38 for ; Fri, 28 Oct 2011 12:16:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.691 X-Spam-Level: X-Spam-Status: No, score=-2.691 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 Sod-3KCUOIVU for ; Fri, 28 Oct 2011 12:16:16 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 55B1B1F0C34 for ; Fri, 28 Oct 2011 12:16:15 -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 p9SJGktw027188; Fri, 28 Oct 2011 15:16:46 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail05.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 28 Oct 2011 15:16:10 -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: Sat, 29 Oct 2011 00:44:03 +0530 Message-ID: <2E239D6FCD033C4BAF15F386A979BF51159D7B@sonusinmail02.sonusnet.com> In-Reply-To: <4EAAF413.8030501@alvestrand.no> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] RTCWeb Forking usecase [was RE: draft-kaplan-rtcweb-sip-interworking-requirements-00] thread-index: AcyVn0i9tpV9DtOsRCqHvzGcN/GYnQAAQMNQ References: <20111024224257.28459.65554.idtracker@ietfa.amsl.com><6EB8679A-13D5-4AD7-97F2-BC35FC0966F0@acmepacket.com><2E239D6FCD033C4BAF15F386A979BF51159C32@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF51159D7A@sonusinmail02.sonusnet.com> <4EAAF413.8030501@alvestrand.no> From: "Ravindran Parthasarathi" To: "Harald Alvestrand" X-OriginalArrivalTime: 28 Oct 2011 19:16:10.0654 (UTC) FILETIME=[0D4383E0:01CC95A6] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] RTCWeb Forking usecase [was RE: draft-kaplan-rtcweb-sip-interworking-requirements-00] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 19:16:17 -0000 SGFyYWxkLA0KDQpUaGFua3MgZm9yIHRoZSBjbGFyaWZpY2F0aW9uLiAiRmVkZXggSVZSIiB1c2Vj YXNlIGlzIHVuZGVyIGJyb3dzZXIgdG8gR1cvc2VydmVyIHNlY3Rpb24gKHNlYyA0LjMpIHdoaWNo IGlzIGEgU0lQIGJhc2VkIGZvcmtpbmcgcmVxdWlyZW1lbnQuIElmIHlvdSBsb29rIGF0IGNhcmVm dWxseSwgIkZlZGV4IElWUiBub24tZmluYWwgcmVzcG9uc2UiIHNjZW5hcmlvIGNvdWxkIGhhdmUg YmUgYWNoaWV2ZWQgY2xlYW5seSB1c2luZyB0d28gc2VwYXJhdGUgb2ZmZXIvYW5zd2VyIGV4Y2hh bmdlICYgdHdvIGZpbmFsIHJlc3BvbnNlcyAoSU5WSVRFLzIwMC9BQ0ssIFJFLUlOVklURS8yMDAv QUNLKSA6DQoNCjEpIGN1c3RvbWVyIC0gZmVkZXggSVZSIG9mZmVyL2Fuc3dlciBleGNoYW5nZQ0K MikgZmVkZXggYWdlbnQgLSBDdXN0b21lciBvZmZlci9hbnN3ZXIgZXhjaGFuZ2UNCg0KYnV0IGl0 IG1heSBiZSBhdm9pZGVkIGluIGxlZ2FjeSBmb3IgYmlsbGluZyByZWFzb25zIHdoaWNoIHNob3Vs ZCBub3QgYmUgbWFqb3IgY29uY2VybiBmb3IgUlRDV2ViLiBJbiBjYXNlIG9mIFNJUCBmb3JraW5n LCBpdCBpcyBhc3N1bWVkIHRoYXQgMm5kIGFuc3dlciBvdmVycmlkZSB0aGUgMXN0IGFuc3dlciBp biB0aGUgbWVkaWEgcGxhbmUuDQoNCkFzIEkgbWVudGlvbmVkIGVhcmxpZXIsIFNJUCAoc2VyaWFs KSBmb3JraW5nIHJlcXVpcmVtZW50IHNoYWxsIGJlIG1ldCBieSBnYXRld2F5IHNpZ25hbGluZyBh bmQgbm8gZXh0cmEgcmVxdWlyZW1lbnQgZm9yIGJyb3dzZXIuIEFsc28sIHN3aXRjaGluZyBtZWRp YSBzdHJlYW0gZnJvbSBvbmUgcmVzcG9uZGVyIHRvIG90aGVyIHJlc3BvbmRlciBpbiBGZWRleCBJ VlIgdXNlY2FzZSBpcyBub3Qgc28gZWFzeSBiZWNhdXNlIG9mIGxlZ2FjeSBtZWRpYSBoYW5kbGlu ZyAoSUNFLCBSVENQKSBkaWZmZXJlbmNlcyBhcyBtZW50aW9uZWQgaW4gZHJhZnQta2FwbGFuLXJ0 Y3dlYi1zaXAtaW50ZXJ3b3JraW5nLXJlcXVpcmVtZW50cy0wMC4NCg0KSVNUTSwgd2UgZG9uJ3Qg aGF2ZSBSVENXZWIgc3BlY2lmaWMgZm9ya2luZyB1c2VjYXNlIHRpbGwgbm93Lg0KDQpUaGFua3MN ClBhcnRoYSANCiANCj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPkZyb206IEhhcmFsZCBB bHZlc3RyYW5kIFttYWlsdG86aGFyYWxkQGFsdmVzdHJhbmQubm9dDQo+U2VudDogRnJpZGF5LCBP Y3RvYmVyIDI4LCAyMDExIDExOjU4IFBNDQo+VG86IFJhdmluZHJhbiBQYXJ0aGFzYXJhdGhpDQo+ Q2M6IEnDsWFraSBCYXogQ2FzdGlsbG87IHJ0Y3dlYkBpZXRmLm9yZzsgSGFkcmllbCBLYXBsYW4N Cj5TdWJqZWN0OiBSZTogW3J0Y3dlYl0gUlRDV2ViIEZvcmtpbmcgdXNlY2FzZSBbd2FzIFJFOiBk cmFmdC1rYXBsYW4tDQo+cnRjd2ViLXNpcC1pbnRlcndvcmtpbmctcmVxdWlyZW1lbnRzLTAwXQ0K Pg0KPk9uIDEwLzI4LzIwMTEgMTA6NTYgQU0sIFJhdmluZHJhbiBQYXJ0aGFzYXJhdGhpIHdyb3Rl Og0KPj4gQnkgbG9va2luZyBhdCBkcmFmdC1pZXRmLXJ0Y3dlYi11c2UtY2FzZXMtYW5kLXJlcXVp cmVtZW50cy0wNiwgSSBjb3VsZA0KPm5vdCBzZWUgYW55IHNwZWNpZmljIHJlcXVpcmVtZW50IGZv ciBSVENXZWIgZm9ya2luZy4gSW4gY2FzZSBTSVAgZm9ya2luZw0KPmlzIHRoZSBvbmx5IHJlcXVp cmVtZW50IGZvciBSVENXZWIgYW5kIGFsc28sIFJUQ1dlYiBkb2VzIG5vdCBoYXZlIGFueQ0KPnNw ZWNpZmljIGZvcmtpbmcgcmVxdWlyZW1lbnQsIHRoZW4gdGhlIGdhdGV3YXkgYmV0d2VlbiBSVENX ZWImICBTSVANCj5zaGFsbCB0YWtlIGNhcmUgb2YgdGhlIGZ1bmN0aW9uYWxpdHkuIEknbSBhc2tp bmcgdGhpcyBxdWVzdGlvbiB0byBnZXQNCj50aGUgY2xhcml0eSBvbiB3aGV0aGVyIFNJUCBmb3Jr aW5nIGZlYXR1cmUgaGFzIHRvIGltcGFjdCBSVENXZWIgY2xpZW50DQo+cmVxdWlyZW1lbnQgb3Ig bm90Lg0KPkkgYmVsaWV2ZSB0aGUgIkZlZGV4IElWUiIgY2FzZSB3YXMgc3BlY2lmaWNhbGx5IGlu dGVuZGVkIHRvIHN1cmZhY2UgdGhlDQo+cmVxdWlyZW1lbnQgZm9yICJub24tZmluYWwgcmVzcG9u c2VzIiAoc3dpdGNoaW5nIGEgbWVkaWEgc3RyZWFtIGZyb20gdGhlDQo+aW5pdGlhbCByZXNwb25k ZXIgdG8gYSBuZXh0IHJlc3BvbmRlcikuDQo+VGhhdCdzIG9uZSBmb3JtIG9mIGZvcmtpbmcgKCJz ZXJpYWwgZm9yayI/KQ0KPg0KPkkgaGF2ZW4ndCB1bmRlcnN0b29kIGZvcmtpbmcgdG8gYmUgYSBy ZXF1aXJlbWVudCBpbiBhbnkgb3RoZXIgdXNlIGNhc2UuDQoNCg== From roman@telurix.com Fri Oct 28 12:29: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 8F5E121F8450 for ; Fri, 28 Oct 2011 12:29:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.894 X-Spam-Level: X-Spam-Status: No, score=-2.894 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9O+seKu4C72B for ; Fri, 28 Oct 2011 12:29:22 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id ECAB011E8082 for ; Fri, 28 Oct 2011 12:29:21 -0700 (PDT) Received: by qadc10 with SMTP id c10so4993977qad.31 for ; Fri, 28 Oct 2011 12:29:21 -0700 (PDT) Received: by 10.224.17.205 with SMTP id t13mr4064992qaa.61.1319830161245; Fri, 28 Oct 2011 12:29:21 -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 bh18sm15925276qab.8.2011.10.28.12.29.20 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 28 Oct 2011 12:29:20 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so4414535vcb.31 for ; Fri, 28 Oct 2011 12:29:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.33.101 with SMTP id q5mr5634397pbi.121.1319830159611; Fri, 28 Oct 2011 12:29:19 -0700 (PDT) Received: by 10.68.62.170 with HTTP; Fri, 28 Oct 2011 12:29:19 -0700 (PDT) In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF51159D7B@sonusinmail02.sonusnet.com> References: <20111024224257.28459.65554.idtracker@ietfa.amsl.com> <6EB8679A-13D5-4AD7-97F2-BC35FC0966F0@acmepacket.com> <2E239D6FCD033C4BAF15F386A979BF51159C32@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF51159D7A@sonusinmail02.sonusnet.com> <4EAAF413.8030501@alvestrand.no> <2E239D6FCD033C4BAF15F386A979BF51159D7B@sonusinmail02.sonusnet.com> Date: Fri, 28 Oct 2011 15:29:19 -0400 Message-ID: From: Roman Shpount To: Ravindran Parthasarathi Content-Type: multipart/alternative; boundary=bcaec520ef91d3d56d04b060e70d Cc: rtcweb@ietf.org Subject: Re: [rtcweb] RTCWeb Forking usecase [was RE: draft-kaplan-rtcweb-sip-interworking-requirements-00] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 19:29:22 -0000 --bcaec520ef91d3d56d04b060e70d Content-Type: text/plain; charset=ISO-8859-1 On Fri, Oct 28, 2011 at 3:14 PM, Ravindran Parthasarathi < pravindran@sonusnet.com> wrote: > > Thanks for the clarification. "Fedex IVR" usecase is under browser to > GW/server section (sec 4.3) which is a SIP based forking requirement. If you > look at carefully, "Fedex IVR non-final response" scenario could have be > achieved cleanly using two separate offer/answer exchange & two final > responses (INVITE/200/ACK, RE-INVITE/200/ACK) : > > This is actually wrong, unless we specify that WebRTC is always using the same media stream address parameters (list of ICE candidates) within the same call. If in WebRTC this cannot be guaranteed, serial forking cannot be implemented unless multiple answers can be provided to the same offer. In other words we either get the same offer from WebRTC client so we can quietly not send it, or multiple answers need to be provided. In addition to Fedex IVR scenario, we also have find-me/follow-me scenarios where either multiple early media sources are playing at the same time (land line ring back and cell phone ring back). We also sometimes end up with situations where two people answer the same call, such as boss and a secretary answering the same call. _____________ Roman Shpount --bcaec520ef91d3d56d04b060e70d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Oct 28, 2011 at 3:14 PM, Ravindran P= arthasarathi <pravindran@sonusnet.com> wrote:

Thanks for the clarification. "Fedex IVR" usecase is under browse= r to GW/server section (sec 4.3) which is a SIP based forking requirement. = If you look at carefully, "Fedex IVR non-final response" scenario= could have be achieved cleanly using two separate offer/answer exchange &a= mp; two final responses (INVITE/200/ACK, RE-INVITE/200/ACK) :


This is actually wrong, unless we specify that W= ebRTC is always using the same media stream address parameters (list of ICE= candidates) within the same call. If in WebRTC this cannot be guaranteed, = serial forking cannot be implemented unless multiple answers can be provide= d to the same offer. In other words we either get the same offer from WebRT= C client so we can quietly not send it, or multiple answers need to be prov= ided.

In addition to Fedex IVR scenario, we also have find-me/follow-me scena= rios where either multiple early media sources are playing at the same time= (land line ring back and cell phone ring back). We also sometimes end up w= ith situations where two people answer the same call, such as boss and a se= cretary answering the same call.
_____________
Roman Shpount

--bcaec520ef91d3d56d04b060e70d-- From ibc@aliax.net Fri Oct 28 12:34:19 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CEA121F8477 for ; Fri, 28 Oct 2011 12:34:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.644 X-Spam-Level: X-Spam-Status: No, score=-2.644 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yZGprxlU8Eyv for ; Fri, 28 Oct 2011 12:34:18 -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 885F321F8476 for ; Fri, 28 Oct 2011 12:34:18 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so4419532vcb.31 for ; Fri, 28 Oct 2011 12:34:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.117.199 with SMTP id s7mr625225vcq.201.1319830456731; Fri, 28 Oct 2011 12:34:16 -0700 (PDT) Received: by 10.220.159.134 with HTTP; Fri, 28 Oct 2011 12:34:16 -0700 (PDT) In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF51159D7B@sonusinmail02.sonusnet.com> References: <20111024224257.28459.65554.idtracker@ietfa.amsl.com> <6EB8679A-13D5-4AD7-97F2-BC35FC0966F0@acmepacket.com> <2E239D6FCD033C4BAF15F386A979BF51159C32@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF51159D7A@sonusinmail02.sonusnet.com> <4EAAF413.8030501@alvestrand.no> <2E239D6FCD033C4BAF15F386A979BF51159D7B@sonusinmail02.sonusnet.com> Date: Fri, 28 Oct 2011 21:34:16 +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 Forking usecase [was RE: draft-kaplan-rtcweb-sip-interworking-requirements-00] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 19:34:19 -0000 2011/10/28 Ravindran Parthasarathi : > As I mentioned earlier, SIP (serial) forking requirement shall be met by = gateway signaling and no extra requirement for browser. Do it in your gateway if you want, but don't try to mandate it please. As I also mentioned earlier, some of us are willing to handle forking in the WebRTC client (at JavaScript level) and that is perfectly possible. Regards. --=20 I=C3=B1aki Baz Castillo From pravindran@sonusnet.com Fri Oct 28 12:44: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 1382D21F84BD for ; Fri, 28 Oct 2011 12:44:04 -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.240, 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 zC077ZwvOexb for ; Fri, 28 Oct 2011 12:44:03 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 803E821F84BB for ; Fri, 28 Oct 2011 12:44:03 -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 p9SJiZhm013351; Fri, 28 Oct 2011 15:44:35 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail04.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 28 Oct 2011 15:43: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="utf-8" Content-Transfer-Encoding: base64 Date: Sat, 29 Oct 2011 01:13:12 +0530 Message-ID: <2E239D6FCD033C4BAF15F386A979BF51159D7C@sonusinmail02.sonusnet.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] RTCWeb Forking usecase [was RE: draft-kaplan-rtcweb-sip-interworking-requirements-00] thread-index: AcyVqJpHzoIhjGncSSCQQlr4SraK2QAADa9A References: <20111024224257.28459.65554.idtracker@ietfa.amsl.com><6EB8679A-13D5-4AD7-97F2-BC35FC0966F0@acmepacket.com><2E239D6FCD033C4BAF15F386A979BF51159C32@sonusinmail02.sonusnet.com><2E239D6FCD033C4BAF15F386A979BF51159D7A@sonusinmail02.sonusnet.com><4EAAF413.8030501@alvestrand.no><2E239D6FCD033C4BAF15F386A979BF51159D7B@sonusinmail02.sonusnet.com> From: "Ravindran Parthasarathi" To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= X-OriginalArrivalTime: 28 Oct 2011 19:43:46.0838 (UTC) FILETIME=[E86D2360:01CC95A9] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] RTCWeb Forking usecase [was RE: draft-kaplan-rtcweb-sip-interworking-requirements-00] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 19:44:04 -0000 SW5ha2ksDQoNCklTVE0sIFNJUCBzcGVjaWZpYyBmdW5jdGlvbmFsaXR5IGlzIHB1c2hlZCBpbnRv IFdlYlJUQyBjbGllbnQgdW5uZWNlc3Nhcnkgd2l0aG91dCB3ZWxsLWRlZmluZWQgV2ViUlRDIHVz ZWNhc2UuIA0KDQpUaGFua3MNClBhcnRoYQ0KDQo+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cj5Gcm9tOiBJw7Fha2kgQmF6IENhc3RpbGxvIFttYWlsdG86aWJjQGFsaWF4Lm5ldF0NCj5TZW50 OiBTYXR1cmRheSwgT2N0b2JlciAyOSwgMjAxMSAxOjA0IEFNDQo+VG86IFJhdmluZHJhbiBQYXJ0 aGFzYXJhdGhpDQo+Q2M6IEhhcmFsZCBBbHZlc3RyYW5kOyBydGN3ZWJAaWV0Zi5vcmc7IEhhZHJp ZWwgS2FwbGFuDQo+U3ViamVjdDogUmU6IFtydGN3ZWJdIFJUQ1dlYiBGb3JraW5nIHVzZWNhc2Ug W3dhcyBSRTogZHJhZnQta2FwbGFuLQ0KPnJ0Y3dlYi1zaXAtaW50ZXJ3b3JraW5nLXJlcXVpcmVt ZW50cy0wMF0NCj4NCj4yMDExLzEwLzI4IFJhdmluZHJhbiBQYXJ0aGFzYXJhdGhpIDxwcmF2aW5k cmFuQHNvbnVzbmV0LmNvbT46DQo+PiBBcyBJIG1lbnRpb25lZCBlYXJsaWVyLCBTSVAgKHNlcmlh bCkgZm9ya2luZyByZXF1aXJlbWVudCBzaGFsbCBiZSBtZXQNCj5ieSBnYXRld2F5IHNpZ25hbGlu ZyBhbmQgbm8gZXh0cmEgcmVxdWlyZW1lbnQgZm9yIGJyb3dzZXIuDQo+DQo+RG8gaXQgaW4geW91 ciBnYXRld2F5IGlmIHlvdSB3YW50LCBidXQgZG9uJ3QgdHJ5IHRvIG1hbmRhdGUgaXQgcGxlYXNl Lg0KPkFzIEkgYWxzbyBtZW50aW9uZWQgZWFybGllciwgc29tZSBvZiB1cyBhcmUgd2lsbGluZyB0 byBoYW5kbGUgZm9ya2luZw0KPmluIHRoZSBXZWJSVEMgY2xpZW50IChhdCBKYXZhU2NyaXB0IGxl dmVsKSBhbmQgdGhhdCBpcyBwZXJmZWN0bHkNCj5wb3NzaWJsZS4NCj4NCj5SZWdhcmRzLg0KPg0K Pi0tDQo+ScOxYWtpIEJheiBDYXN0aWxsbw0KPjxpYmNAYWxpYXgubmV0Pg0K From christer.holmberg@ericsson.com Fri Oct 28 12:52: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 9A2E321F8573 for ; Fri, 28 Oct 2011 12:52:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.029 X-Spam-Level: X-Spam-Status: No, score=-6.029 tagged_above=-999 required=5 tests=[AWL=0.270, 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 jtNSErmmSYJb for ; Fri, 28 Oct 2011 12:52: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 C751F21F8560 for ; Fri, 28 Oct 2011 12:52:36 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-49-4eab08032349 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 60.3C.20773.3080BAE4; Fri, 28 Oct 2011 21:52:35 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Fri, 28 Oct 2011 21:52:35 +0200 From: Christer Holmberg To: Ravindran Parthasarathi , =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= Date: Fri, 28 Oct 2011 21:49:54 +0200 Thread-Topic: [rtcweb] RTCWeb Forking usecase [was RE: draft-kaplan-rtcweb-sip-interworking-requirements-00] Thread-Index: AcyVqJpHzoIhjGncSSCQQlr4SraK2QAADa9AAAB8ooI= Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852233C3B835@ESESSCMS0356.eemea.ericsson.se> References: <20111024224257.28459.65554.idtracker@ietfa.amsl.com><6EB8679A-13D5-4AD7-97F2-BC35FC0966F0@acmepacket.com><2E239D6FCD033C4BAF15F386A979BF51159C32@sonusinmail02.sonusnet.com><2E239D6FCD033C4BAF15F386A979BF51159D7A@sonusinmail02.sonusnet.com><4EAAF413.8030501@alvestrand.no><2E239D6FCD033C4BAF15F386A979BF51159D7B@sonusinmail02.sonusnet.com> , <2E239D6FCD033C4BAF15F386A979BF51159D7C@sonusinmail02.sonusnet.com> In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF51159D7C@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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] RTCWeb Forking usecase [was RE: draft-kaplan-rtcweb-sip-interworking-requirements-00] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 19:52:37 -0000 Hi, In my opinion, interworking with SIP is itself such use-case :) I think the question is whether a browser should be able to handle parallel= forking, or if serial forking is enough. In my opinion serial forking is enough, ie the JS app (or, if you want, a g= ateway) informs the browser about the currently active remote media paramet= ers. Regards, Christer ________________________________________ From: rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] On Behalf Of Ravind= ran Parthasarathi [pravindran@sonusnet.com] Sent: Friday, October 28, 2011 10:43 PM To: I=F1aki Baz Castillo Cc: rtcweb@ietf.org Subject: Re: [rtcweb] RTCWeb Forking usecase [was RE: draft-kaplan-rtcweb= -sip-interworking-requirements-00] Inaki, ISTM, SIP specific functionality is pushed into WebRTC client unnecessary w= ithout well-defined WebRTC usecase. Thanks Partha >-----Original Message----- >From: I=F1aki Baz Castillo [mailto:ibc@aliax.net] >Sent: Saturday, October 29, 2011 1:04 AM >To: Ravindran Parthasarathi >Cc: Harald Alvestrand; rtcweb@ietf.org; Hadriel Kaplan >Subject: Re: [rtcweb] RTCWeb Forking usecase [was RE: draft-kaplan- >rtcweb-sip-interworking-requirements-00] > >2011/10/28 Ravindran Parthasarathi : >> As I mentioned earlier, SIP (serial) forking requirement shall be met >by gateway signaling and no extra requirement for browser. > >Do it in your gateway if you want, but don't try to mandate it please. >As I also mentioned earlier, some of us are willing to handle forking >in the WebRTC client (at JavaScript level) and that is perfectly >possible. > >Regards. > >-- >I=F1aki Baz Castillo > _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From pravindran@sonusnet.com Fri Oct 28 12: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 2271521F8610 for ; Fri, 28 Oct 2011 12:57:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.683 X-Spam-Level: X-Spam-Status: No, score=-2.683 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 Oq-QnZlObibT for ; Fri, 28 Oct 2011 12:57:01 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 65B5C21F85B8 for ; Fri, 28 Oct 2011 12:57:01 -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 p9SJvXKe021870; Fri, 28 Oct 2011 15:57:33 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail06.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 28 Oct 2011 15:56: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_01CC95AA.8DD9235A" Date: Sat, 29 Oct 2011 01:18:24 +0530 Message-ID: <2E239D6FCD033C4BAF15F386A979BF51159D7D@sonusinmail02.sonusnet.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] RTCWeb Forking usecase [was RE: draft-kaplan-rtcweb-sip-interworking-requirements-00] thread-index: AcyVp+mWgF3/FmIFSGOI+3JkIrfKSAAAKqog References: <20111024224257.28459.65554.idtracker@ietfa.amsl.com><6EB8679A-13D5-4AD7-97F2-BC35FC0966F0@acmepacket.com><2E239D6FCD033C4BAF15F386A979BF51159C32@sonusinmail02.sonusnet.com><2E239D6FCD033C4BAF15F386A979BF51159D7A@sonusinmail02.sonusnet.com><4EAAF413.8030501@alvestrand.no><2E239D6FCD033C4BAF15F386A979BF51159D7B@sonusinmail02.sonusnet.com> From: "Ravindran Parthasarathi" To: "Roman Shpount" X-OriginalArrivalTime: 28 Oct 2011 19:56:57.0352 (UTC) FILETIME=[BF9C0080:01CC95AB] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] RTCWeb Forking usecase [was RE: draft-kaplan-rtcweb-sip-interworking-requirements-00] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 19:57:03 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC95AA.8DD9235A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Roman, =20 The point is that WebRTC browser is not required to get multiple answer for single offer in case RTCWeb-SIP interop scenario with SIP forking and it applies for "Fedex IVR" usecase. Could you please point out the exact usecase for "find-me/follow-me" in draft-ietf-rtcweb-use-cases-and-requirements-06. =20 Thanks Partha =20 From: Roman Shpount [mailto:roman@telurix.com]=20 Sent: Saturday, October 29, 2011 12:59 AM To: Ravindran Parthasarathi Cc: Harald Alvestrand; rtcweb@ietf.org Subject: Re: [rtcweb] RTCWeb Forking usecase [was RE: draft-kaplan-rtcweb-sip-interworking-requirements-00] =20 =20 On Fri, Oct 28, 2011 at 3:14 PM, Ravindran Parthasarathi wrote: Thanks for the clarification. "Fedex IVR" usecase is under browser to GW/server section (sec 4.3) which is a SIP based forking requirement. If you look at carefully, "Fedex IVR non-final response" scenario could have be achieved cleanly using two separate offer/answer exchange & two final responses (INVITE/200/ACK, RE-INVITE/200/ACK) : This is actually wrong, unless we specify that WebRTC is always using the same media stream address parameters (list of ICE candidates) within the same call. If in WebRTC this cannot be guaranteed, serial forking cannot be implemented unless multiple answers can be provided to the same offer. In other words we either get the same offer from WebRTC client so we can quietly not send it, or multiple answers need to be provided. In addition to Fedex IVR scenario, we also have find-me/follow-me scenarios where either multiple early media sources are playing at the same time (land line ring back and cell phone ring back). We also sometimes end up with situations where two people answer the same call, such as boss and a secretary answering the same call. _____________ Roman Shpount ------_=_NextPart_001_01CC95AA.8DD9235A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Roman,

 

The point is that WebRTC browser is not required to get = multiple answer for single offer in case RTCWeb-SIP interop scenario with SIP = forking and it applies for “Fedex IVR” usecase.  Could you = please point out the exact usecase for “find-me/follow-me” in = draft-ietf-rtcweb-use-cases-and-requirements-06.

 

Thanks

Partha

 

From:= Roman = Shpount [mailto:roman@telurix.com]
Sent: Saturday, October 29, 2011 12:59 AM
To: Ravindran Parthasarathi
Cc: Harald Alvestrand; rtcweb@ietf.org
Subject: Re: [rtcweb] RTCWeb Forking usecase [was RE: draft-kaplan-rtcweb-sip-interworking-requirements-00]

 

 

On Fri, Oct 28, 2011 at 3:14 PM, Ravindran = Parthasarathi <pravindran@sonusnet.com> wrote:


Thanks for the clarification. "Fedex IVR" usecase is under = browser to GW/server section (sec 4.3) which is a SIP based forking requirement. If = you look at carefully, "Fedex IVR non-final response" scenario = could have be achieved cleanly using two separate offer/answer exchange & two = final responses (INVITE/200/ACK, RE-INVITE/200/ACK) :


This is actually wrong, unless we specify that WebRTC is always using = the same media stream address parameters (list of ICE candidates) within the same = call. If in WebRTC this cannot be guaranteed, serial forking cannot be = implemented unless multiple answers can be provided to the same offer. In other = words we either get the same offer from WebRTC client so we can quietly not send = it, or multiple answers need to be provided.

In addition to Fedex IVR scenario, we also have find-me/follow-me = scenarios where either multiple early media sources are playing at the same time = (land line ring back and cell phone ring back). We also sometimes end up with situations where two people answer the same call, such as boss and a = secretary answering the same call.
_____________
Roman Shpount

------_=_NextPart_001_01CC95AA.8DD9235A-- From ibc@aliax.net Fri Oct 28 13:04: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 EBCA811E8081 for ; Fri, 28 Oct 2011 13:04:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.644 X-Spam-Level: X-Spam-Status: No, score=-2.644 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VVN2YJoDvkOI for ; Fri, 28 Oct 2011 13:04:59 -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 6389111E807F for ; Fri, 28 Oct 2011 13:04:59 -0700 (PDT) Received: by vws5 with SMTP id 5so4462238vws.31 for ; Fri, 28 Oct 2011 13:04:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.107.81 with SMTP id a17mr617178vcp.96.1319832296772; Fri, 28 Oct 2011 13:04:56 -0700 (PDT) Received: by 10.220.159.134 with HTTP; Fri, 28 Oct 2011 13:04:56 -0700 (PDT) In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF51159D7C@sonusinmail02.sonusnet.com> References: <20111024224257.28459.65554.idtracker@ietfa.amsl.com> <6EB8679A-13D5-4AD7-97F2-BC35FC0966F0@acmepacket.com> <2E239D6FCD033C4BAF15F386A979BF51159C32@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF51159D7A@sonusinmail02.sonusnet.com> <4EAAF413.8030501@alvestrand.no> <2E239D6FCD033C4BAF15F386A979BF51159D7B@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF51159D7C@sonusinmail02.sonusnet.com> Date: Fri, 28 Oct 2011 22:04:56 +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 Forking usecase [was RE: draft-kaplan-rtcweb-sip-interworking-requirements-00] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 20:05:00 -0000 2011/10/28 Ravindran Parthasarathi : > ISTM, SIP specific functionality is pushed into WebRTC client unnecessary= without well-defined WebRTC usecase. It's unnecessary for you. For me it's *necessary*. Are you propossing that the specs should prevent this use case just because it seems unnecessary for you? --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Fri Oct 28 13:11: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 50B291F0C38 for ; Fri, 28 Oct 2011 13:11:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.645 X-Spam-Level: X-Spam-Status: No, score=-2.645 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id He7GwJJQ5ocD for ; Fri, 28 Oct 2011 13:11: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 B81401F0C34 for ; Fri, 28 Oct 2011 13:11:05 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so4452152vcb.31 for ; Fri, 28 Oct 2011 13:11:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.151.129 with SMTP id c1mr610351vcw.271.1319832665260; Fri, 28 Oct 2011 13:11:05 -0700 (PDT) Received: by 10.220.159.134 with HTTP; Fri, 28 Oct 2011 13:11:05 -0700 (PDT) In-Reply-To: <4EAAFC19.1040604@alvestrand.no> References: <4EAAFC19.1040604@alvestrand.no> Date: Fri, 28 Oct 2011 22:11:05 +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] ICE/STUN support in SIP endpoints: SIPit data X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 20:11:06 -0000 2011/10/28 Harald Alvestrand : > Support for various items in the 20 endpoints present: > > =C2=A050% ice > =C2=A040% 5389stun > =C2=A035% turn > =C2=A015% 3489stun Another important information for WebRTC: > 80% of the endpoints present supported SRTP using sdes. There were no dtl= s-srtp implementations at this SIPit. --=20 I=C3=B1aki Baz Castillo From pravindran@sonusnet.com Fri Oct 28 13:13:33 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FF8611E808C for ; Fri, 28 Oct 2011 13:13:33 -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.230, 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 2xjvGNsLrzli for ; Fri, 28 Oct 2011 13:13:32 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id A9EE811E807F for ; Fri, 28 Oct 2011 13:13:32 -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 p9SKE47Y032544; Fri, 28 Oct 2011 16:14:04 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail05.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 28 Oct 2011 16:13: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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sat, 29 Oct 2011 01:43:29 +0530 Message-ID: <2E239D6FCD033C4BAF15F386A979BF51159D7F@sonusinmail02.sonusnet.com> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852233C3B835@ESESSCMS0356.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] RTCWeb Forking usecase [was RE:draft-kaplan-rtcweb-sip-interworking-requirements-00] thread-index: AcyVqJpHzoIhjGncSSCQQlr4SraK2QAADa9AAAB8ooIAACopwA== References: <20111024224257.28459.65554.idtracker@ietfa.amsl.com><6EB8679A-13D5-4AD7-97F2-BC35FC0966F0@acmepacket.com><2E239D6FCD033C4BAF15F386A979BF51159C32@sonusinmail02.sonusnet.com><2E239D6FCD033C4BAF15F386A979BF51159D7A@sonusinmail02.sonusnet.com><4EAAF413.8030501@alvestrand.no><2E239D6FCD033C4BAF15F386A979BF51159D7B@sonusinmail02.sonusnet.com>, <2E239D6FCD033C4BAF15F386A979BF51159D7C@sonusinmail02.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852233C3B835@ESESSCMS0356.eemea.ericsson.se> From: "Ravindran Parthasarathi" To: "Christer Holmberg" , =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= X-OriginalArrivalTime: 28 Oct 2011 20:13:29.0266 (UTC) FILETIME=[0ED61120:01CC95AE] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] RTCWeb Forking usecase [was RE:draft-kaplan-rtcweb-sip-interworking-requirements-00] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 20:13:33 -0000 Hi Christer, In case of SIP forking interop with WebRTC, it is possible for = WebRTC-SIP gateway to handle this scenario and not by browser. In fact, = it is my review comment to = draft-kaplan-rtcweb-sip-interworking-requirements-00 (Para 2 in = http://www.ietf.org/mail-archive/web/rtcweb/current/msg02316.html) where = this mail thread started. Even if WebRTC supports both serial & parallel forking, whether WebRTC = signaling will take up the same shape of SIP forking wherein initial = INVITE only forks and not for RE-INVITE? In case of WebRTC forking, it = is very much possible for different shape of forking. The well defined = WebRTC usecase & requirement may clarify these doubts. Thanks Partha >-----Original Message----- >From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >Sent: Saturday, October 29, 2011 1:20 AM >To: Ravindran Parthasarathi; I=F1aki Baz Castillo >Cc: rtcweb@ietf.org >Subject: RE: [rtcweb] RTCWeb Forking usecase [was RE:draft-kaplan- >rtcweb-sip-interworking-requirements-00] > > >Hi, > >In my opinion, interworking with SIP is itself such use-case :) > >I think the question is whether a browser should be able to handle >parallel forking, or if serial forking is enough. > >In my opinion serial forking is enough, ie the JS app (or, if you want, >a gateway) informs the browser about the currently active remote media >parameters. > >Regards, > >Christer > > >________________________________________ >From: rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] On Behalf Of >Ravindran Parthasarathi [pravindran@sonusnet.com] >Sent: Friday, October 28, 2011 10:43 PM >To: I=F1aki Baz Castillo >Cc: rtcweb@ietf.org >Subject: Re: [rtcweb] RTCWeb Forking usecase [was RE: draft-kaplan- >rtcweb-sip-interworking-requirements-00] > >Inaki, > >ISTM, SIP specific functionality is pushed into WebRTC client >unnecessary without well-defined WebRTC usecase. > >Thanks >Partha > >>-----Original Message----- >>From: I=F1aki Baz Castillo [mailto:ibc@aliax.net] >>Sent: Saturday, October 29, 2011 1:04 AM >>To: Ravindran Parthasarathi >>Cc: Harald Alvestrand; rtcweb@ietf.org; Hadriel Kaplan >>Subject: Re: [rtcweb] RTCWeb Forking usecase [was RE: draft-kaplan- >>rtcweb-sip-interworking-requirements-00] >> >>2011/10/28 Ravindran Parthasarathi : >>> As I mentioned earlier, SIP (serial) forking requirement shall be = met >>by gateway signaling and no extra requirement for browser. >> >>Do it in your gateway if you want, but don't try to mandate it please. >>As I also mentioned earlier, some of us are willing to handle forking >>in the WebRTC client (at JavaScript level) and that is perfectly >>possible. >> >>Regards. >> >>-- >>I=F1aki Baz Castillo >> >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb From HKaplan@acmepacket.com Fri Oct 28 13:27: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 EC0B411E8087 for ; Fri, 28 Oct 2011 13:27:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.457 X-Spam-Level: X-Spam-Status: No, score=-2.457 tagged_above=-999 required=5 tests=[AWL=0.142, 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 FF6pbZccjRTD for ; Fri, 28 Oct 2011 13:27:40 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 38BBB11E807F for ; Fri, 28 Oct 2011 13:27:40 -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, 28 Oct 2011 16:27:38 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.232]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Fri, 28 Oct 2011 16:27:38 -0400 From: Hadriel Kaplan To: Ravindran Parthasarathi Thread-Topic: [rtcweb] RTCWeb Forking usecase [was RE: draft-kaplan-rtcweb-sip-interworking-requirements-00] Thread-Index: AQHMlbAILP8rzLuLTkuw47kPYlO7nw== Date: Fri, 28 Oct 2011 20:27:37 +0000 Message-ID: <247FFE2C-DB2C-4280-A219-BE1503662F92@acmepacket.com> References: <20111024224257.28459.65554.idtracker@ietfa.amsl.com><6EB8679A-13D5-4AD7-97F2-BC35FC0966F0@acmepacket.com><2E239D6FCD033C4BAF15F386A979BF51159C32@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF51159D7A@sonusinmail02.sonusnet.com> <4EAAF413.8030501@alvestrand.no> <2E239D6FCD033C4BAF15F386A979BF51159D7B@sonusinmail02.sonusnet.com> In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF51159D7B@sonusinmail02.sonusnet.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: <025AE6A626454443A6477A5053830393@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [rtcweb] RTCWeb Forking usecase [was RE: draft-kaplan-rtcweb-sip-interworking-requirements-00] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 20:27:41 -0000 We've debated serial and parallel forking a number of times but I don't kno= w if there's been consensus. But your email is really two different questions/topics: 1) Is there a use-case for forking within WebRTC? 2) Does supporting SIP forking mean the Browser has to handle the SDP/media= behavior of it, vs. the Web-server/Interworking-function handling it? For the first question, I can certainly envision a Web-app wanting to let A= lice press a single button on her Browser and end up communicating with Bob= no matter where he may be, or letting her single button-press end up commu= nicating with Bob first and then Charlie, or letting her single button-pres= s end up communicating with Bob and Charlie at the same time. But I think = such things can be accomplished through clever Web-app code without needing= the Browser to be aware it's a forked ROAP/SDP scenario.=20 [Note: though this may depend on what W3C decides the user-consent UI model= is relative to PeerConnections, MediaStreams and ROAP] With regards to the second question, there was a long email thread on this = which started here I think: http://www.ietf.org/mail-archive/web/rtcweb/current/msg01354.html -hadriel On Oct 28, 2011, at 3:14 PM, Ravindran Parthasarathi wrote: > Harald, >=20 > Thanks for the clarification. "Fedex IVR" usecase is under browser to GW/= server section (sec 4.3) which is a SIP based forking requirement. If you l= ook at carefully, "Fedex IVR non-final response" scenario could have be ach= ieved cleanly using two separate offer/answer exchange & two final response= s (INVITE/200/ACK, RE-INVITE/200/ACK) : >=20 > 1) customer - fedex IVR offer/answer exchange > 2) fedex agent - Customer offer/answer exchange >=20 > but it may be avoided in legacy for billing reasons which should not be m= ajor concern for RTCWeb. In case of SIP forking, it is assumed that 2nd ans= wer override the 1st answer in the media plane. >=20 > As I mentioned earlier, SIP (serial) forking requirement shall be met by = gateway signaling and no extra requirement for browser. Also, switching med= ia stream from one responder to other responder in Fedex IVR usecase is not= so easy because of legacy media handling (ICE, RTCP) differences as mentio= ned in draft-kaplan-rtcweb-sip-interworking-requirements-00. >=20 > ISTM, we don't have RTCWeb specific forking usecase till now. >=20 > Thanks > Partha=20 >=20 >> -----Original Message----- >> From: Harald Alvestrand [mailto:harald@alvestrand.no] >> Sent: Friday, October 28, 2011 11:58 PM >> To: Ravindran Parthasarathi >> Cc: I=F1aki Baz Castillo; rtcweb@ietf.org; Hadriel Kaplan >> Subject: Re: [rtcweb] RTCWeb Forking usecase [was RE: draft-kaplan- >> rtcweb-sip-interworking-requirements-00] >>=20 >> On 10/28/2011 10:56 AM, Ravindran Parthasarathi wrote: >>> By looking at draft-ietf-rtcweb-use-cases-and-requirements-06, I could >> not see any specific requirement for RTCWeb forking. In case SIP forking >> is the only requirement for RTCWeb and also, RTCWeb does not have any >> specific forking requirement, then the gateway between RTCWeb& SIP >> shall take care of the functionality. I'm asking this question to get >> the clarity on whether SIP forking feature has to impact RTCWeb client >> requirement or not. >> I believe the "Fedex IVR" case was specifically intended to surface the >> requirement for "non-final responses" (switching a media stream from the >> initial responder to a next responder). >> That's one form of forking ("serial fork"?) >>=20 >> I haven't understood forking to be a requirement in any other use case. >=20 From christer.holmberg@ericsson.com Fri Oct 28 13: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 CB5A521F84F8 for ; Fri, 28 Oct 2011 13:41:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.034 X-Spam-Level: X-Spam-Status: No, score=-6.034 tagged_above=-999 required=5 tests=[AWL=0.265, 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 Kds4NElJGTmM for ; Fri, 28 Oct 2011 13:41: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 E9AFA11E8082 for ; Fri, 28 Oct 2011 13:41:26 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-81-4eab137501f3 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 11.9E.20773.5731BAE4; Fri, 28 Oct 2011 22:41:25 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Fri, 28 Oct 2011 22:41:24 +0200 From: Christer Holmberg To: Ravindran Parthasarathi , =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= Date: Fri, 28 Oct 2011 22:37:17 +0200 Thread-Topic: [rtcweb] RTCWeb Forking usecase [was RE:draft-kaplan-rtcweb-sip-interworking-requirements-00] Thread-Index: AcyVqJpHzoIhjGncSSCQQlr4SraK2QAADa9AAAB8ooIAACopwAABfX3L Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852233C3B83D@ESESSCMS0356.eemea.ericsson.se> References: <20111024224257.28459.65554.idtracker@ietfa.amsl.com><6EB8679A-13D5-4AD7-97F2-BC35FC0966F0@acmepacket.com><2E239D6FCD033C4BAF15F386A979BF51159C32@sonusinmail02.sonusnet.com><2E239D6FCD033C4BAF15F386A979BF51159D7A@sonusinmail02.sonusnet.com><4EAAF413.8030501@alvestrand.no><2E239D6FCD033C4BAF15F386A979BF51159D7B@sonusinmail02.sonusnet.com>, <2E239D6FCD033C4BAF15F386A979BF51159D7C@sonusinmail02.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852233C3B835@ESESSCMS0356.eemea.ericsson.se>, <2E239D6FCD033C4BAF15F386A979BF51159D7F@sonusinmail02.sonusnet.com> In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF51159D7F@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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] RTCWeb Forking usecase [was RE:draft-kaplan-rtcweb-sip-interworking-requirements-00] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 20:41:27 -0000 Hi, >In case of SIP forking interop with WebRTC, it is possible for WebRTC-SIP = gateway to handle this scenario and not by browser. In fact, it is my revie= w comment to=20 >draft-kaplan-rtcweb-sip-interworking-requirements-00 (Para 2 in http://www= .ietf.org/mail-archive/web/rtcweb/current/msg02316.html) where this mail th= read started. In theory, I'm sure the gateway could handle most cases. Things may look simple on a PowerPoint slide, showing a simple use-case, bu= t from my experience you may end up with very complex and "clumsy" procedur= es, depending on how complex your call establishment procedures are. >Even if WebRTC supports both serial & parallel forking, whether WebRTC sig= naling will take up the same shape of SIP forking wherein initial INVITE on= ly forks and not for RE-INVITE? In case of WebRTC=20 >forking, it is very much possible for different shape of forking. Well, we can not only say that we support forking. We do need to specify ex= actly what we mean by "forking support", and what possible restrictions we = have. Regards, Christer >-----Original Message----- >From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >Sent: Saturday, October 29, 2011 1:20 AM >To: Ravindran Parthasarathi; I=F1aki Baz Castillo >Cc: rtcweb@ietf.org >Subject: RE: [rtcweb] RTCWeb Forking usecase [was RE:draft-kaplan- >rtcweb-sip-interworking-requirements-00] > > >Hi, > >In my opinion, interworking with SIP is itself such use-case :) > >I think the question is whether a browser should be able to handle >parallel forking, or if serial forking is enough. > >In my opinion serial forking is enough, ie the JS app (or, if you want, >a gateway) informs the browser about the currently active remote media >parameters. > >Regards, > >Christer > > >________________________________________ >From: rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] On Behalf Of >Ravindran Parthasarathi [pravindran@sonusnet.com] >Sent: Friday, October 28, 2011 10:43 PM >To: I=F1aki Baz Castillo >Cc: rtcweb@ietf.org >Subject: Re: [rtcweb] RTCWeb Forking usecase [was RE: draft-kaplan- >rtcweb-sip-interworking-requirements-00] > >Inaki, > >ISTM, SIP specific functionality is pushed into WebRTC client >unnecessary without well-defined WebRTC usecase. > >Thanks >Partha > >>-----Original Message----- >>From: I=F1aki Baz Castillo [mailto:ibc@aliax.net] >>Sent: Saturday, October 29, 2011 1:04 AM >>To: Ravindran Parthasarathi >>Cc: Harald Alvestrand; rtcweb@ietf.org; Hadriel Kaplan >>Subject: Re: [rtcweb] RTCWeb Forking usecase [was RE: draft-kaplan- >>rtcweb-sip-interworking-requirements-00] >> >>2011/10/28 Ravindran Parthasarathi : >>> As I mentioned earlier, SIP (serial) forking requirement shall be met >>by gateway signaling and no extra requirement for browser. >> >>Do it in your gateway if you want, but don't try to mandate it please. >>As I also mentioned earlier, some of us are willing to handle forking >>in the WebRTC client (at JavaScript level) and that is perfectly >>possible. >> >>Regards. >> >>-- >>I=F1aki Baz Castillo >> >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb From randell-ietf@jesup.org Fri Oct 28 15: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 F164921F84C1 for ; Fri, 28 Oct 2011 15:02:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.547 X-Spam-Level: X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[AWL=0.052, 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 C7c3ceG2KcUc for ; Fri, 28 Oct 2011 15:02: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 7F22821F84BD for ; Fri, 28 Oct 2011 15:02: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 1RJuV8-0008BH-LA for rtcweb@ietf.org; Fri, 28 Oct 2011 17:02:10 -0500 Message-ID: <4EAB2657.7090609@jesup.org> Date: Fri, 28 Oct 2011 18:01:59 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <20111024224257.28459.65554.idtracker@ietfa.amsl.com><6EB8679A-13D5-4AD7-97F2-BC35FC0966F0@acmepacket.com><2E239D6FCD033C4BAF15F386A979BF51159C32@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF51159D7A@sonusinmail02.sonusnet.com> <4EAAF413.8030501@alvestrand.no> <2E239D6FCD033C4BAF15F386A979BF51159D7B@sonusinmail02.sonusnet.com> <247FFE2C-DB2C-4280-A219-BE1503662F92@acmepacket.com> In-Reply-To: <247FFE2C-DB2C-4280-A219-BE1503662F92@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 Forking usecase [was RE: draft-kaplan-rtcweb-sip-interworking-requirements-00] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 22:02:12 -0000 On 10/28/2011 4:27 PM, Hadriel Kaplan wrote: > > We've debated serial and parallel forking a number of times but I don't know if there's been consensus. > > But your email is really two different questions/topics: > 1) Is there a use-case for forking within WebRTC? As discussed, given that users will be "logged into" a service from multiple devices, and that we don't know what the application desired behavior will be, we need to support multiple ANSWER responses to a OFFER, and support allowing multiple of those answers to become active. (For example, OFFER sent to "my Team", answered by 3 members of the team.) As for implementation: probably by cloning the PeerConnection or a Factory (this has been discussed before and I haven't gone over the messages to see where it ended up). -- Randell Jesup randell-ietf@jesup.org From HKaplan@acmepacket.com Fri Oct 28 15:18:44 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D63C71F0C43 for ; Fri, 28 Oct 2011 15:18:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.464 X-Spam-Level: X-Spam-Status: No, score=-2.464 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 58qw07S7ptIB for ; Fri, 28 Oct 2011 15:18:44 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 44D051F0C38 for ; Fri, 28 Oct 2011 15:18:44 -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, 28 Oct 2011 18:18:42 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.232]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Fri, 28 Oct 2011 18:18:42 -0400 From: Hadriel Kaplan To: Randell Jesup Thread-Topic: [rtcweb] RTCWeb Forking usecase [was RE: draft-kaplan-rtcweb-sip-interworking-requirements-00] Thread-Index: AQHMlb+MtYdQSlKDHEijV6ncguiECQ== Date: Fri, 28 Oct 2011 22:18:41 +0000 Message-ID: <817D03B4-A50D-4047-A638-4BFA231543E2@acmepacket.com> References: <20111024224257.28459.65554.idtracker@ietfa.amsl.com><6EB8679A-13D5-4AD7-97F2-BC35FC0966F0@acmepacket.com><2E239D6FCD033C4BAF15F386A979BF51159C32@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF51159D7A@sonusinmail02.sonusnet.com> <4EAAF413.8030501@alvestrand.no> <2E239D6FCD033C4BAF15F386A979BF51159D7B@sonusinmail02.sonusnet.com> <247FFE2C-DB2C-4280-A219-BE1503662F92@acmepacket.com> <4EAB2657.7090609@jesup.org> In-Reply-To: <4EAB2657.7090609@jesup.org> 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: <6DA2396BF0627E4DB2EA0A41029EA16E@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [rtcweb] RTCWeb Forking usecase [was RE: draft-kaplan-rtcweb-sip-interworking-requirements-00] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 22:18:44 -0000 On Oct 28, 2011, at 6:01 PM, Randell Jesup wrote: > As discussed, given that users will be "logged into" a service from multi= ple devices, and that we don't know what the application desired behavior w= ill be, we need to support multiple ANSWER responses to a OFFER, and suppor= t allowing multiple of those answers to become active. (For example, OFFER= sent to "my Team", answered by 3 members of the team.) As for implementat= ion: probably by cloning the PeerConnection or a Factory (this has been dis= cussed before and I haven't gone over the messages to see where it ended up= ). Yes, but in theory we don't need to support ROAP forking to let you do that= , because you don't need to do it that way. For example you can write the = JS to send a "session request" message without any ROAP/SDP, and as each "s= ession response" comes back from each team member with a ROAP OFFER, the lo= cal JS creates a new PeerConnection and sends back to each team member a RO= AP ANSWER from you. So basically mimicking the offerless-INVITE model of S= IP. Or send a JS "session request" and get back a "session response" from each = team member without any ROAP, then create each PeerConnection and send a ne= w distinct "session request" with ROAP OFFER separately to each team member= . Kind of like a 3xx response model of SIP. Or send a JS query to get back a list of URLs each representing a team memb= er, and create a PeerConnection for each and send a ROAP OFFER to each URL.= Really like a 3xx response model of SIP. -hadriel From roman@telurix.com Fri Oct 28 16:00: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 EF10E1F0C43 for ; Fri, 28 Oct 2011 16:00:45 -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.078, 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 wmcj7Ui6tQPr for ; Fri, 28 Oct 2011 16:00:45 -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 574C31F0C34 for ; Fri, 28 Oct 2011 16:00:45 -0700 (PDT) Received: by ywt2 with SMTP id 2so4821457ywt.31 for ; Fri, 28 Oct 2011 16:00:45 -0700 (PDT) Received: by 10.236.175.4 with SMTP id y4mr6562374yhl.128.1319842844950; Fri, 28 Oct 2011 16:00:44 -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 z28sm14652017yhl.4.2011.10.28.16.00.38 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 28 Oct 2011 16:00:39 -0700 (PDT) Received: by gyh20 with SMTP id 20so4843523gyh.31 for ; Fri, 28 Oct 2011 16:00:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.33.101 with SMTP id q5mr6302065pbi.121.1319842838012; Fri, 28 Oct 2011 16:00:38 -0700 (PDT) Received: by 10.68.62.170 with HTTP; Fri, 28 Oct 2011 16:00:37 -0700 (PDT) In-Reply-To: <4EAB2657.7090609@jesup.org> References: <20111024224257.28459.65554.idtracker@ietfa.amsl.com> <6EB8679A-13D5-4AD7-97F2-BC35FC0966F0@acmepacket.com> <2E239D6FCD033C4BAF15F386A979BF51159C32@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF51159D7A@sonusinmail02.sonusnet.com> <4EAAF413.8030501@alvestrand.no> <2E239D6FCD033C4BAF15F386A979BF51159D7B@sonusinmail02.sonusnet.com> <247FFE2C-DB2C-4280-A219-BE1503662F92@acmepacket.com> <4EAB2657.7090609@jesup.org> Date: Fri, 28 Oct 2011 19:00:37 -0400 Message-ID: From: Roman Shpount To: Randell Jesup Content-Type: multipart/alternative; boundary=bcaec520ef9184e18e04b063db3d Cc: rtcweb@ietf.org Subject: Re: [rtcweb] RTCWeb Forking usecase [was RE: draft-kaplan-rtcweb-sip-interworking-requirements-00] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 23:00:46 -0000 --bcaec520ef9184e18e04b063db3d Content-Type: text/plain; charset=ISO-8859-1 On Fri, Oct 28, 2011 at 6:01 PM, Randell Jesup wrote: > > As discussed, given that users will be "logged into" a service from > multiple devices, and that we don't know what the application desired > behavior will be, we need to support multiple ANSWER responses to a OFFER, > and support allowing multiple of those answers to become active. (For > example, OFFER sent to "my Team", answered by 3 members of the team.) As > for implementation: probably by cloning the PeerConnection or a Factory > (this has been discussed before and I haven't gone over the messages to see > where it ended up). > I agree with this completely. I think the most encouraging response I got before on this list was that the API should always produce the same list of ICE candidates for a given Web browser session. Because of this, all the offers from the WebRTC client would be the same and simultaneous forking can be implemented by creating a new peer connection for each answer, generating and discarding the offer (since it is the same as the offer from the original peer connection in this session) and feeding a new answer to it. I am not sure this behavior is defined anywhere, but this could definitely work and would allow to implement all forking scenarios without cloning or factory API calls. I would feel a bit more comfortable if the API would actually reflect this usage (i.e. have one method that always returns an offer for this web session and peer connection only processing answers or responses to remote offers). _____________ Roman Shpount --bcaec520ef9184e18e04b063db3d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Oct 28, 2011 at 6:01 PM, Randell Jes= up <randell-= ietf@jesup.org> wrote:

As discussed, given that users will be "logged into" a service fr= om multiple devices, and that we don't know what the application desire= d behavior will be, we need to support multiple ANSWER responses to a OFFER= , and support allowing multiple of those answers to become active. =A0(For = example, OFFER sent to "my Team", answered by 3 members of the te= am.) =A0As for implementation: probably by cloning the PeerConnection or a = Factory (this has been discussed before and I haven't gone over the mes= sages to see where it ended up).

I agree with this completely.

I think the mo= st encouraging response I got before on this list was that the API should a= lways produce the same list of ICE candidates for a given Web browser sessi= on. Because of this, all the offers from the WebRTC client would be the sam= e and simultaneous forking can be implemented by creating a new peer connec= tion for each answer, generating and discarding the offer (since it is the = same as the offer from the original peer connection in this session) and fe= eding a new answer to it. I am not sure this behavior is defined anywhere, = but this could definitely work and would allow to implement all forking sce= narios without cloning or factory API calls. I would feel a bit more comfor= table if the API would actually reflect this usage (i.e. have one method th= at always returns an offer for this web session and peer connection only pr= ocessing answers or responses to remote offers).
_____________
Roman Shpount


--bcaec520ef9184e18e04b063db3d-- From roman@telurix.com Fri Oct 28 16:11: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 5626521F854D for ; Fri, 28 Oct 2011 16:11:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.901 X-Spam-Level: X-Spam-Status: No, score=-2.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] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OY2vFb94topt for ; Fri, 28 Oct 2011 16:10:59 -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 3B38C21F8532 for ; Fri, 28 Oct 2011 16:10:58 -0700 (PDT) Received: by ywt2 with SMTP id 2so4828747ywt.31 for ; Fri, 28 Oct 2011 16:10:57 -0700 (PDT) Received: by 10.68.26.168 with SMTP id m8mr6528977pbg.29.1319843457483; Fri, 28 Oct 2011 16:10:57 -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 i10sm19310131pbn.10.2011.10.28.16.10.56 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 28 Oct 2011 16:10:56 -0700 (PDT) Received: by pzk34 with SMTP id 34so11083812pzk.9 for ; Fri, 28 Oct 2011 16:10:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.12.138 with SMTP id y10mr6371889pbb.70.1319843455919; Fri, 28 Oct 2011 16:10:55 -0700 (PDT) Received: by 10.68.62.170 with HTTP; Fri, 28 Oct 2011 16:10:55 -0700 (PDT) In-Reply-To: <817D03B4-A50D-4047-A638-4BFA231543E2@acmepacket.com> References: <20111024224257.28459.65554.idtracker@ietfa.amsl.com> <6EB8679A-13D5-4AD7-97F2-BC35FC0966F0@acmepacket.com> <2E239D6FCD033C4BAF15F386A979BF51159C32@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF51159D7A@sonusinmail02.sonusnet.com> <4EAAF413.8030501@alvestrand.no> <2E239D6FCD033C4BAF15F386A979BF51159D7B@sonusinmail02.sonusnet.com> <247FFE2C-DB2C-4280-A219-BE1503662F92@acmepacket.com> <4EAB2657.7090609@jesup.org> <817D03B4-A50D-4047-A638-4BFA231543E2@acmepacket.com> Date: Fri, 28 Oct 2011 19:10:55 -0400 Message-ID: From: Roman Shpount To: Hadriel Kaplan Content-Type: multipart/alternative; boundary=bcaec51f907f59656604b0640059 Cc: Randell Jesup , "" Subject: Re: [rtcweb] RTCWeb Forking usecase [was RE: draft-kaplan-rtcweb-sip-interworking-requirements-00] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 23:11:00 -0000 --bcaec51f907f59656604b0640059 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Oct 28, 2011 at 6:18 PM, Hadriel Kaplan wrote: > Yes, but in theory we don't need to support ROAP forking to let you do > that, because you don't need to do it that way. For example you can write > the JS to send a "session request" message without any ROAP/SDP, and as each > "session response" comes back from each team member with a ROAP OFFER, the > local JS creates a new PeerConnection and sends back to each team member a > ROAP ANSWER from you. So basically mimicking the offerless-INVITE model of > SIP. > > Or send a JS "session request" and get back a "session response" from each > team member without any ROAP, then create each PeerConnection and send a new > distinct "session request" with ROAP OFFER separately to each team member. > Kind of like a 3xx response model of SIP. > > Or send a JS query to get back a list of URLs each representing a team > member, and create a PeerConnection for each and send a ROAP OFFER to each > URL. Really like a 3xx response model of SIP. > > If you do not need to inter-operate with SIP you can implement forking like functionality with signaling only. If you do, you need forking support (or a some sort of SBC or gateway solution). In general, I think it makes sense to support forking if it does not greatly complicate the WebRTC client implementation, makes API more complex or has some security implications. Forking support is a good thing, since it will allow for better interoperability and more flexible future signaling scenarios. I don't think it is hard to add support for forking in WebRTC (all you need to do is to reuse the same ICE candidates for all calls in the same browser session), and this model encourages better resource usage. It does mean that the same TURN/STUN servers should be used for all calls in the session, but other then that it does not limit any of the functionality. _____________ Roman Shpount --bcaec51f907f59656604b0640059 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Oct 28, 2011 at 6:18 P= M, Hadriel Kaplan <HKaplan@acmepacket.com> wrote:
Yes, but in theory we don't need to support ROAP fork= ing to let you do that, because you don't need to do it that way. =A0Fo= r example you can write the JS to send a "session request" messag= e without any ROAP/SDP, and as each "session response" comes back= from each team member with a ROAP OFFER, the local JS creates a new PeerCo= nnection and sends back to each team member a ROAP ANSWER from you. =A0So b= asically mimicking the offerless-INVITE model of SIP.

Or send a JS "session request" and get back a "session respo= nse" from each team member without any ROAP, then create each PeerConn= ection and send a new distinct "session request" with ROAP OFFER = separately to each team member. =A0Kind of like a 3xx response model of SIP= .

Or send a JS query to get back a list of URLs each representing a team memb= er, and create a PeerConnection for each and send a ROAP OFFER to each URL.= =A0Really like a 3xx response model of SIP.


If you do not nee= d to inter-operate with SIP you can implement forking like functionality wi= th signaling only. If you do, you need forking support (or a some sort of S= BC or gateway solution).

In general, I think it makes sense to support forking if it does not=20 greatly complicate the WebRTC client implementation, makes API more complex= or has some security implications. Forking support is a good thing, since = it will allow for better interoperability and more flexible future signaling=20 scenarios. I don't think it is hard to add support for forking in WebRT= C (all you need to do is to reuse the same ICE candidates for all calls in = the same browser session), and this model encourages better resource usage.= It does mean that the same TURN/STUN servers should be used for all calls = in the session, but other then that it does not limit any of the functional= ity.
_____________
Roman Shpount


--bcaec51f907f59656604b0640059-- From ibc@aliax.net Sat Oct 29 04:57: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 3A5DB21F8A7D for ; Sat, 29 Oct 2011 04:57:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.645 X-Spam-Level: X-Spam-Status: No, score=-2.645 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ci8JmSaGWRFp for ; Sat, 29 Oct 2011 04:57: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 8A90921F8A56 for ; Sat, 29 Oct 2011 04:57:00 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so4771881vcb.31 for ; Sat, 29 Oct 2011 04:56:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.7.12 with SMTP id b12mr1120442vcb.23.1319889419624; Sat, 29 Oct 2011 04:56:59 -0700 (PDT) Received: by 10.220.184.6 with HTTP; Sat, 29 Oct 2011 04:56:59 -0700 (PDT) In-Reply-To: References: <20111024224257.28459.65554.idtracker@ietfa.amsl.com> <6EB8679A-13D5-4AD7-97F2-BC35FC0966F0@acmepacket.com> <2E239D6FCD033C4BAF15F386A979BF51159C32@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF51159D7A@sonusinmail02.sonusnet.com> <4EAAF413.8030501@alvestrand.no> <2E239D6FCD033C4BAF15F386A979BF51159D7B@sonusinmail02.sonusnet.com> <247FFE2C-DB2C-4280-A219-BE1503662F92@acmepacket.com> <4EAB2657.7090609@jesup.org> <817D03B4-A50D-4047-A638-4BFA231543E2@acmepacket.com> Date: Sat, 29 Oct 2011 13:56:59 +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 , "" Subject: Re: [rtcweb] RTCWeb Forking usecase [was RE: draft-kaplan-rtcweb-sip-interworking-requirements-00] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Oct 2011 11:57:01 -0000 2011/10/29 Roman Shpount : > If you do not need to inter-operate with SIP you can implement forking li= ke > functionality with signaling only. If you do, you need forking support (o= r a > some sort of SBC or gateway solution). Even more, some WebRTC scenario could just not allow forking at all. Since the in-the-wire protocol is up to the developer he does not need to accomplish all the features and use cases of SIP, but just those his scenario needs. > In general, I think it makes sense to support forking if it does not grea= tly > complicate the WebRTC client implementation, makes API more complex or ha= s > some security implications. Forking support is a good thing, since it wil= l > allow for better interoperability and more flexible future signaling > scenarios. I don't think it is hard to add support for forking in WebRTC > (all you need to do is to reuse the same ICE candidates for all calls in = the > same browser session), and this model encourages better resource usage. I= t > does mean that the same TURN/STUN servers should be used for all calls in > the session, but other then that it does not limit any of the functionali= ty. I hope this is achieved as it opens the door to cool scenarios (indeed this is required in SIP, but could also be required by some future scenarios we cannot imagine right now). --=20 I=C3=B1aki Baz Castillo From harald@alvestrand.no Sat Oct 29 09:07: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 3692621F8A4E for ; Sat, 29 Oct 2011 09:07:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I2QAAZSuTWuZ for ; Sat, 29 Oct 2011 09:07:02 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 2F91F21F8A35 for ; Sat, 29 Oct 2011 09:07:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 221A439E162 for ; Sat, 29 Oct 2011 18:07:00 +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 Afg4dBHtNMhA for ; Sat, 29 Oct 2011 18:06:58 +0200 (CEST) Received: from [192.168.6.21] (unknown [24.104.44.194]) by eikenes.alvestrand.no (Postfix) with ESMTPS id E58CC39E088 for ; Sat, 29 Oct 2011 18:06:57 +0200 (CEST) Message-ID: <4EAC24A2.70401@alvestrand.no> Date: Sat, 29 Oct 2011 09:06:58 -0700 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: rtcweb@ietf.org References: <20111024224257.28459.65554.idtracker@ietfa.amsl.com> <6EB8679A-13D5-4AD7-97F2-BC35FC0966F0@acmepacket.com> <2E239D6FCD033C4BAF15F386A979BF51159C32@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF51159D7A@sonusinmail02.sonusnet.com> <4EAAF413.8030501@alvestrand.no> <2E239D6FCD033C4BAF15F386A979BF51159D7B@sonusinmail02.sonusnet.com> <247FFE2C-DB2C-4280-A219-BE1503662F92@acmepacket.com> <4EAB2657.7090609@jesup.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------030504030108080402050107" Subject: Re: [rtcweb] RTCWeb Forking usecase [was RE: draft-kaplan-rtcweb-sip-interworking-requirements-00] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Oct 2011 16:07:03 -0000 This is a multi-part message in MIME format. --------------030504030108080402050107 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 10/28/2011 04:00 PM, Roman Shpount wrote: > > On Fri, Oct 28, 2011 at 6:01 PM, Randell Jesup > wrote: > > > As discussed, given that users will be "logged into" a service > from multiple devices, and that we don't know what the application > desired behavior will be, we need to support multiple ANSWER > responses to a OFFER, and support allowing multiple of those > answers to become active. (For example, OFFER sent to "my Team", > answered by 3 members of the team.) As for implementation: > probably by cloning the PeerConnection or a Factory (this has been > discussed before and I haven't gone over the messages to see where > it ended up). > > > I agree with this completely. > > I think the most encouraging response I got before on this list was > that the API should always produce the same list of ICE candidates for > a given Web browser session. Because of this, all the offers from the > WebRTC client would be the same and simultaneous forking can be > implemented by creating a new peer connection for each answer, > generating and discarding the offer (since it is the same as the offer > from the original peer connection in this session) and feeding a new > answer to it. I considered it when we discussed this last, but I'm not sure it works. If we support SDES, the offer also contains crypto keys. Reusing crypto keys for all created connections would be a huge security vulnerability. That's why I ended up with the somewhat more complex "factory" model I proposed in an earlier mail; another method would be to have a PeerConnection constructor that takes an offer AND an answer as creation parameters. Of course we could mandate DTLS-SRTP key negotiation..... > I am not sure this behavior is defined anywhere, but this could > definitely work and would allow to implement all forking scenarios > without cloning or factory API calls. I would feel a bit more > comfortable if the API would actually reflect this usage (i.e. have > one method that always returns an offer for this web session and peer > connection only processing answers or responses to remote offers). > _____________ > Roman Shpount > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --------------030504030108080402050107 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 10/28/2011 04:00 PM, Roman Shpount wrote:

On Fri, Oct 28, 2011 at 6:01 PM, Randell Jesup <randell-ietf@jesup.org> wrote:

As discussed, given that users will be "logged into" a service from multiple devices, and that we don't know what the application desired behavior will be, we need to support multiple ANSWER responses to a OFFER, and support allowing multiple of those answers to become active.  (For example, OFFER sent to "my Team", answered by 3 members of the team.)  As for implementation: probably by cloning the PeerConnection or a Factory (this has been discussed before and I haven't gone over the messages to see where it ended up).

I agree with this completely.

I think the most encouraging response I got before on this list was that the API should always produce the same list of ICE candidates for a given Web browser session. Because of this, all the offers from the WebRTC client would be the same and simultaneous forking can be implemented by creating a new peer connection for each answer, generating and discarding the offer (since it is the same as the offer from the original peer connection in this session) and feeding a new answer to it.
I considered it when we discussed this last, but I'm not sure it works.

If we support SDES, the offer also contains crypto keys. Reusing crypto keys for all created connections would be a huge security vulnerability.

That's why I ended up with the somewhat more complex "factory" model I proposed in an earlier mail; another method would be to have a PeerConnection constructor that takes an offer AND an answer as creation parameters.

Of course we could mandate DTLS-SRTP key negotiation.....

I am not sure this behavior is defined anywhere, but this could definitely work and would allow to implement all forking scenarios without cloning or factory API calls. I would feel a bit more comfortable if the API would actually reflect this usage (i.e. have one method that always returns an offer for this web session and peer connection only processing answers or responses to remote offers).
_____________
Roman Shpount



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

--------------030504030108080402050107-- From ibc@aliax.net Sat Oct 29 09:14: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 C67BC21F84D9 for ; Sat, 29 Oct 2011 09:14:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.645 X-Spam-Level: X-Spam-Status: No, score=-2.645 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id obaW7sl+T0AJ for ; Sat, 29 Oct 2011 09:14: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 3601A21F84CD for ; Sat, 29 Oct 2011 09:14:26 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so4852152vcb.31 for ; Sat, 29 Oct 2011 09:14:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.147.198 with SMTP id m6mr1233705vcv.128.1319904865675; Sat, 29 Oct 2011 09:14:25 -0700 (PDT) Received: by 10.220.184.6 with HTTP; Sat, 29 Oct 2011 09:14:25 -0700 (PDT) In-Reply-To: <4EAC24A2.70401@alvestrand.no> References: <20111024224257.28459.65554.idtracker@ietfa.amsl.com> <6EB8679A-13D5-4AD7-97F2-BC35FC0966F0@acmepacket.com> <2E239D6FCD033C4BAF15F386A979BF51159C32@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF51159D7A@sonusinmail02.sonusnet.com> <4EAAF413.8030501@alvestrand.no> <2E239D6FCD033C4BAF15F386A979BF51159D7B@sonusinmail02.sonusnet.com> <247FFE2C-DB2C-4280-A219-BE1503662F92@acmepacket.com> <4EAB2657.7090609@jesup.org> <4EAC24A2.70401@alvestrand.no> Date: Sat, 29 Oct 2011 18:14: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] RTCWeb Forking usecase [was RE: draft-kaplan-rtcweb-sip-interworking-requirements-00] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Oct 2011 16:14:26 -0000 2011/10/29 Harald Alvestrand : > Of course we could mandate DTLS-SRTP key negotiation..... SIPit29 summary says: > 80% of the endpoints present supported SRTP using sdes. > There were no dtls-srtp implementations at this SIPit. Just a comment. Of coure the current status of SRTP implementations in SIP world should not be the only argument for WebRTC. --=20 I=C3=B1aki Baz Castillo From harald@alvestrand.no Sat Oct 29 09:18: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 342BE21F8ACA for ; Sat, 29 Oct 2011 09:18:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.449 X-Spam-Level: X-Spam-Status: No, score=-110.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2kbB-32ZynDt for ; Sat, 29 Oct 2011 09:18:52 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 9F4A421F8AC9 for ; Sat, 29 Oct 2011 09:18:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E821139E162; Sat, 29 Oct 2011 18:18:51 +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 6qne0BqL4btC; Sat, 29 Oct 2011 18:18:51 +0200 (CEST) Received: from [192.168.6.21] (unknown [24.104.44.194]) by eikenes.alvestrand.no (Postfix) with ESMTPS id CD22939E088; Sat, 29 Oct 2011 18:18:50 +0200 (CEST) Message-ID: <4EAC276B.6040309@alvestrand.no> Date: Sat, 29 Oct 2011 09:18:51 -0700 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= References: <20111024224257.28459.65554.idtracker@ietfa.amsl.com> <6EB8679A-13D5-4AD7-97F2-BC35FC0966F0@acmepacket.com> <2E239D6FCD033C4BAF15F386A979BF51159C32@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF51159D7A@sonusinmail02.sonusnet.com> <4EAAF413.8030501@alvestrand.no> <2E239D6FCD033C4BAF15F386A979BF51159D7B@sonusinmail02.sonusnet.com> <247FFE2C-DB2C-4280-A219-BE1503662F92@acmepacket.com> <4EAB2657.7090609@jesup.org> <4EAC24A2.70401@alvestrand.no> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] RTCWeb Forking usecase [was RE: draft-kaplan-rtcweb-sip-interworking-requirements-00] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Oct 2011 16:18:53 -0000 On 10/29/2011 09:14 AM, Iñaki Baz Castillo wrote: > 2011/10/29 Harald Alvestrand: >> Of course we could mandate DTLS-SRTP key negotiation..... > SIPit29 summary says: > >> 80% of the endpoints present supported SRTP using sdes. >> There were no dtls-srtp implementations at this SIPit. > Just a comment. Of coure the current status of SRTP implementations in > SIP world should not be the only argument for WebRTC. > > I was partially joking.... I wanted to point out that the argument for supporting SIP-style forking and the argument for supporting SDES or non-encrypted RTP is based in the same "legacy interop" desire. I don't think we can satisfy all desires in that area. From ibc@aliax.net Sat Oct 29 10:29: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 2420221F8AB0 for ; Sat, 29 Oct 2011 10:29:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.345 X-Spam-Level: X-Spam-Status: No, score=-2.345 tagged_above=-999 required=5 tests=[AWL=-0.268, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_34=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 AtZ7zc26Gi2T for ; Sat, 29 Oct 2011 10:29:21 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8047C21F87C2 for ; Sat, 29 Oct 2011 10:29:21 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so4875244vcb.31 for ; Sat, 29 Oct 2011 10:29:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.7.12 with SMTP id b12mr1280282vcb.23.1319909360930; Sat, 29 Oct 2011 10:29:20 -0700 (PDT) Received: by 10.220.184.6 with HTTP; Sat, 29 Oct 2011 10:29:20 -0700 (PDT) Date: Sat, 29 Oct 2011 19:29:20 +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] Media forking solution for SIP interoperability (without a media gateway) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Oct 2011 17:29:22 -0000 Hi, the next suggestion would allow media serial/parallel forking scenarios when interoperating with a SIP network. It is just a *suggestion*. Assumtions ------------------ - WebRTC specs don't allow sharing a local PeerConnection for sending and receiving media to/from more than a single remote peer. - The remote pure SIP peers implement ICE+SRTP and can interoperate with a WebRTC client in the media plane without requiring media gateways. The problem ------------------ Let's assume a WebRTC client implementing SIP at JavaScript level (although there could be a signaling gateway). - The WebRTC client makes an outgoing call which arrives to a SIP proxy and forking occurs (serial or parallel). - The WebRTC client receives more than a single SIP 183 response with different To-tags and different SDPs (so they are different remote SIP peers). - And/or the WebRTC client receives a 200 OK with a Totag and SDP different than the one received in the previous 183. In this case, given the first assumption above, the WebRTC client must choose a single remote SIP peer and can just send and receive media to the chosen peer (limitation 1). If the SIP 200 OK arriving to the WebRTC client belongs to a remote peer different than the chosen one, the WebRTC client cannot reuse the already open local PeerConnection since it was created passing it a different remote SDP (limitation 2). Solution ------------ - The WebRTC client sends the call and receives a 183 with Totag "AAAA" and SDP "SDP_A" from SIP_PEER_A. - It creates a PeerConnection passing it "SDP_A", sends like a ROAP Answer to the peer and media flow starts between client and SIP_PEER_A. - Later (or very soon) another 183 with Totag "BBBB" and SDP "SDP_B" arrives to the WebRTC client from SIP_PEER_B. - The client creates a *new* PeerConnection *without* passing it "SDP_B" and sends a SIP UPDATE with the associated ROAP Offer to SIP_PEER_B. - If SIP_PEER_B implements SIP UPDATE it will reply a 200 OK with a new "SDP_B2" (it could be the same as "SDP_B"). - The client then passes "SDP_B2" to the second PeerConnection and media flow starts between client and SIP_PEER_A. - Later a SIP 200 OK with Totag "CCCC" and SDP "SDP_C" arrives to the client from SIP_PEER_C. - The client creates a *new* PeerConnection *without* passing it "SDP_C" and sends a SIP re-INVITE with the associated ROAP Offer to SIP_PEER_C. - SIP_PEER_C will reply a 200 OK with a new "SDP_C2" (it could be the same as "SDP_C"). - The client then passes "SDP_C2" to the third PeerConnection and media flow starts between client and SIP_PEER_C. At the same time the client destroys the first and second PeerConnections. And we are done. Limitation solved. Of course if SIP_PEER_B does not implement UPDATE we have a problem, but RFC 3311 (SIP UPDATE Method) is a standard since 2002, come on! Conclusion ---------------- SIP media forking can be implemented in JavaScript without mandating special requirements in WebRTC for interoperating with "legacy" SIP (why do we call "legacy" to SIP???). And we just need tu use existing SIP mechanisms. No signaling gateway is required (of course !!) nor a media gateway (if second bullet in "Assumtions" section above is satisfied). We all are happy (but those who have in mind a market selling WebRTC-SIP gateway boxes and want that the specs satisfy their business model). --=20 I=C3=B1aki Baz Castillo From HKaplan@acmepacket.com Sat Oct 29 11:38: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 F005221F85B1 for ; Sat, 29 Oct 2011 11:38:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, J_CHICKENPOX_26=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 CP9hGcj2SVSP for ; Sat, 29 Oct 2011 11:38:01 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 5299521F85A8 for ; Sat, 29 Oct 2011 11:38: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; Sat, 29 Oct 2011 14:37:56 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.232]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Sat, 29 Oct 2011 14:37:56 -0400 From: Hadriel Kaplan To: Harald Alvestrand Thread-Topic: [rtcweb] RTCWeb Forking usecase [was RE: draft-kaplan-rtcweb-sip-interworking-requirements-00] Thread-Index: AQHMlmnfG9o+JV4aRU6fOX6sBnYc9Q== Date: Sat, 29 Oct 2011 18:37:55 +0000 Message-ID: <433A5637-35F1-4D50-84F8-3336A2CF57E2@acmepacket.com> References: <20111024224257.28459.65554.idtracker@ietfa.amsl.com> <6EB8679A-13D5-4AD7-97F2-BC35FC0966F0@acmepacket.com> <2E239D6FCD033C4BAF15F386A979BF51159C32@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF51159D7A@sonusinmail02.sonusnet.com> <4EAAF413.8030501@alvestrand.no> <2E239D6FCD033C4BAF15F386A979BF51159D7B@sonusinmail02.sonusnet.com> <247FFE2C-DB2C-4280-A219-BE1503662F92@acmepacket.com> <4EAB2657.7090609@jesup.org> <4EAC24A2.70401@alvestrand.no> In-Reply-To: <4EAC24A2.70401@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="Windows-1252" Content-ID: <7CA9957541603E4091D0EA9C685CD8E4@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [rtcweb] RTCWeb Forking usecase [was RE: draft-kaplan-rtcweb-sip-interworking-requirements-00] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Oct 2011 18:38:02 -0000 On Oct 29, 2011, at 12:06 PM, Harald Alvestrand wrote: > I considered it when we discussed this last, but I'm not sure it works. > If we support SDES, the offer also contains crypto keys. Reusing crypto k= eys for all created connections would be a huge security vulnerability. The SDES key is used in the sending direction, not the receive. That means= everyone receiving the ROAP Offer will get the key and be able to decrypt = the Offerer's transmitted media, but only the receivers of the ROAP Answer = will be able to decrypt the Answerer's media. So yes obviously if the ROAP= Offer is generated by a Browser and sent to multiple parties, all of those= parties would be able to render the media (and possibly spoof it to the ot= hers). =20 But that vulnerability exists with SDES regardless of whether we support RO= AP forking or not. Even if the WebRTC browser only allows one ROAP Answer = for any given Offer, if SDES is supported at all then we have to trust the = JS and Web server, and trust them not to send the ROAP Offer to multiple pa= rties, or we have to trust all those parties - assuming ROAP contains an SD= ES key and the Browser ends up using it. For example, even if we don't sup= port ROAP forking, a benign JS and Web-server might still send the ROAP Off= er to multiple Browsers and only send back one ROAP Answer from the first a= nswering Browser, not realizing that doing so introduced a vulnerability. My point is that supporting SDES to begin with opens up vulnerabilities, re= gardless of whether we support forking. If we want to support SDES for int= erop with SIP, which I think we do, then what we could do is mandate the Br= owsers support both SDES and DTLS-SRTP, and that if they receive a ROAP Off= er or Answer with DTLS-SRTP in the SDP they use it for that peer, ignoring = SDES. And also that in the Browser's security-info display that would othe= rwise show the DTLS-SRTP fingerprint/SAS, if SDES is used it says so and gi= ves some info about its vulnerabilities. {Note: I'm assuming Browsers will = be required to provide the DTLS-SRTP fingerprint/SAS in some display box if= the human wants to see them] Fundamentally SDES relies on trusting the Web server(s) and the clients it'= s given to. In the Web you already rely on that, for any JS-created/seen m= essage. For example Web-based mail or IM. You have to trust the JS+Server= , and trust them to not send your message to parties which shouldn't get to= see them. I'm not saying that makes using SDES ok, but just noting it, fw= iw. > Of course we could mandate DTLS-SRTP key negotiation=85.. Assume we did that. Then to interop with SIP, the Web-server or an interwo= rking device would terminate DTLS-SRTP on one side, and use SDES or plainte= xt RTP on the other, including to multiple SIP-forked parties. What have y= ou gained? The only benefit is that if the human checks the fingerprint/SA= S in the Browser's display-box, and verifies that the other side did not ha= ve the same SAS or none at all, then the human would know the media is pote= ntially not secure end-to-end. But you can display "The media is potential= ly not secure end-to-end" even if SDES were used by the Browser itself, wit= hout even needing the human to verify an SAS with the other side. -hadriel p.s. draft-wing-srtp-keying-eval-00 discussed this forking issue and recomm= ended re-keying in forking scenarios, for SIP. No one does that as far as = I know, though. From harald@alvestrand.no Sat Oct 29 11:49: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 6C3CD21F85B1 for ; Sat, 29 Oct 2011 11:49:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.458 X-Spam-Level: X-Spam-Status: No, score=-110.458 tagged_above=-999 required=5 tests=[AWL=0.141, 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 qg9xQLL17V5X for ; Sat, 29 Oct 2011 11:49:19 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 92F7B21F8564 for ; Sat, 29 Oct 2011 11:49:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9B22339E162; Sat, 29 Oct 2011 20:49:18 +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 ujGVKG1GTbaN; Sat, 29 Oct 2011 20:49:17 +0200 (CEST) Received: from [172.19.29.10] (216-239-45-4.google.com [216.239.45.4]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 3E21C39E088; Sat, 29 Oct 2011 20:49:17 +0200 (CEST) Message-ID: <4EAC4AAB.1000509@alvestrand.no> Date: Sat, 29 Oct 2011 11:49:15 -0700 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: Hadriel Kaplan References: <20111024224257.28459.65554.idtracker@ietfa.amsl.com> <6EB8679A-13D5-4AD7-97F2-BC35FC0966F0@acmepacket.com> <2E239D6FCD033C4BAF15F386A979BF51159C32@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF51159D7A@sonusinmail02.sonusnet.com> <4EAAF413.8030501@alvestrand.no> <2E239D6FCD033C4BAF15F386A979BF51159D7B@sonusinmail02.sonusnet.com> <247FFE2C-DB2C-4280-A219-BE1503662F92@acmepacket.com> <4EAB2657.7090609@jesup.org> <4EAC24A2.70401@alvestrand.no> <433A5637-35F1-4D50-84F8-3336A2CF57E2@acmepacket.com> In-Reply-To: <433A5637-35F1-4D50-84F8-3336A2CF57E2@acmepacket.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: "" Subject: Re: [rtcweb] RTCWeb Forking usecase [was RE: draft-kaplan-rtcweb-sip-interworking-requirements-00] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Oct 2011 18:49:20 -0000 On 10/29/2011 11:37 AM, Hadriel Kaplan wrote: > On Oct 29, 2011, at 12:06 PM, Harald Alvestrand wrote: > >> I considered it when we discussed this last, but I'm not sure it works. >> If we support SDES, the offer also contains crypto keys. Reusing crypto keys for all created connections would be a huge security vulnerability. > The SDES key is used in the sending direction, not the receive. That means everyone receiving the ROAP Offer will get the key and be able to decrypt the Offerer's transmitted media, but only the receivers of the ROAP Answer will be able to decrypt the Answerer's media. So yes obviously if the ROAP Offer is generated by a Browser and sent to multiple parties, all of those parties would be able to render the media (and possibly spoof it to the others). > > But that vulnerability exists with SDES regardless of whether we support ROAP forking or not. Even if the WebRTC browser only allows one ROAP Answer for any given Offer, if SDES is supported at all then we have to trust the JS and Web server, and trust them not to send the ROAP Offer to multiple parties, or we have to trust all those parties - assuming ROAP contains an SDES key and the Browser ends up using it. For example, even if we don't support ROAP forking, a benign JS and Web-server might still send the ROAP Offer to multiple Browsers and only send back one ROAP Answer from the first answering Browser, not realizing that doing so introduced a vulnerability. I don't think I expressed myself clearly.... Consider: we create PC A, and it creates an offer with key A1 we get answer B1, and give it to PC A. Media flows, encrypted with A1 from A. we get answer B2, create a new PC B. How does PC B know to use key A1 to encrypt media to B? Two possibilities: - All PCs created in this script use the same sending key. That seems like opening up vulnerabilities when creating PCs that connect to different places. - The creation of PC B gets some special initialization data to tell it to use key A1 My earlier note about sending the offer as an initialization parameter to the creation of PC B was one possibility for that. Using a factory class to hold the information about key A1 is another. .... > -hadriel > p.s. draft-wing-srtp-keying-eval-00 discussed this forking issue and recommended re-keying in forking scenarios, for SIP. No one does that as far as I know, though. Thanks for the pointer. > From harald@alvestrand.no Sat Oct 29 14:11: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 5B3EE21F84D5 for ; Sat, 29 Oct 2011 14:11:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.472 X-Spam-Level: X-Spam-Status: No, score=-110.472 tagged_above=-999 required=5 tests=[AWL=0.127, 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 W-8e1itwNdwC for ; Sat, 29 Oct 2011 14:11:19 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id BF70421F84BC for ; Sat, 29 Oct 2011 14:11:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 16BD239E162 for ; Sat, 29 Oct 2011 23:11:19 +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 pVa41wJyhLUc for ; Sat, 29 Oct 2011 23:11:18 +0200 (CEST) Received: from [172.19.29.10] (216-239-45-4.google.com [216.239.45.4]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 5BC4539E088 for ; Sat, 29 Oct 2011 23:11:18 +0200 (CEST) Message-ID: <4EAC6BF4.2000604@alvestrand.no> Date: Sat, 29 Oct 2011 14:11:16 -0700 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: "rtcweb@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [rtcweb] URI schemes for TURN and STUN X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Oct 2011 21:11:20 -0000 Hi, being in the process of scanning all the drafts with -rtcweb- in them, I came across these two: draft-nandakumar-rtcweb-stun-uri-00.txt draft-nandakumar-rtcweb-turn-uri-00.txt Just three comments: - I think it's not RTCWEB business. They should be pointed at the home group for STUN/ICE. - I do not think it's appropriate to use "turn" and "turns" for indicating transport. Polluting the URI namespace with more configuration parameters in the form of trailing "s" is a Bad Thing. - Passing passwords in URIs is generally a Bad Practice. If you really want this in this case, please explore the implications thereof fully in the Security Considerations section. Good luck with the discussion (elsewhere)! Harald From christer.holmberg@ericsson.com Sat Oct 29 14:43: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 B304021F86A6 for ; Sat, 29 Oct 2011 14:43:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.205 X-Spam-Level: X-Spam-Status: No, score=-6.205 tagged_above=-999 required=5 tests=[AWL=0.394, 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 trOZ1Lw3IRwt for ; Sat, 29 Oct 2011 14:43: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 0847921F8610 for ; Sat, 29 Oct 2011 14:43:29 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-1f-4eac73809da3 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id AA.87.20773.1837CAE4; Sat, 29 Oct 2011 23:43:29 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.2.197]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Sat, 29 Oct 2011 23:43:28 +0200 From: Christer Holmberg To: Hadriel Kaplan , Harald Alvestrand Date: Sat, 29 Oct 2011 23:43:28 +0200 Thread-Topic: SDES in browser [was: RTCWeb Forking usecase [was: draft-kaplan-rtcweb-sip-interworking-requirements-00]] Thread-Index: AQHMloPLAoM+L3n8+0Cq94atygftSg== Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852234CFC9FF@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "" Subject: [rtcweb] SDES in browser [was: RTCWeb Forking usecase [was: draft-kaplan-rtcweb-sip-interworking-requirements-00]] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Oct 2011 21:43:30 -0000 Hi, > If we want to support SDES for interop with SIP, which I think we do, the= n what we could do is mandate the Browsers support both SDES and DTLS-SRTP,= =20 I am not sure the browser itself would need to support SDES. It may be enou= gh if SDES is implemented in the JavaScript App, the API then allows the Ap= p to provide keys to the browser, and the browser would use those keys for = media encryption instead of triggering DTLS-SRPT. And, if the JavaScript App does not provide any keys to the browser, DTLS-S= RTP could be used as default. Regards, Christer= From christer.holmberg@ericsson.com Sat Oct 29 14:48: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 AAAE821F862F for ; Sat, 29 Oct 2011 14:48:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.212 X-Spam-Level: X-Spam-Status: No, score=-6.212 tagged_above=-999 required=5 tests=[AWL=0.387, 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 Y8BvNnFZ65lG for ; Sat, 29 Oct 2011 14:48: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 D93D521F85FF for ; Sat, 29 Oct 2011 14:48:43 -0700 (PDT) X-AuditID: c1b4fb3d-b7c26ae0000035b9-8e-4eac74ba6887 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 28.89.13753.AB47CAE4; Sat, 29 Oct 2011 23:48:42 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.2.197]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Sat, 29 Oct 2011 23:48:42 +0200 From: Christer Holmberg To: Hadriel Kaplan , Randell Jesup Date: Sat, 29 Oct 2011 23:44:26 +0200 Thread-Topic: [rtcweb] RTCWeb Forking usecase [was RE: draft-kaplan-rtcweb-sip-interworking-requirements-00] Thread-Index: AQHMlb+MtYdQSlKDHEijV6ncguiECZWT3FwC Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852234CFCA00@ESESSCMS0356.eemea.ericsson.se> References: <20111024224257.28459.65554.idtracker@ietfa.amsl.com><6EB8679A-13D5-4AD7-97F2-BC35FC0966F0@acmepacket.com><2E239D6FCD033C4BAF15F386A979BF51159C32@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF51159D7A@sonusinmail02.sonusnet.com> <4EAAF413.8030501@alvestrand.no> <2E239D6FCD033C4BAF15F386A979BF51159D7B@sonusinmail02.sonusnet.com> <247FFE2C-DB2C-4280-A219-BE1503662F92@acmepacket.com> <4EAB2657.7090609@jesup.org>, <817D03B4-A50D-4047-A638-4BFA231543E2@acmepacket.com> In-Reply-To: <817D03B4-A50D-4047-A638-4BFA231543E2@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] RTCWeb Forking usecase [was RE: draft-kaplan-rtcweb-sip-interworking-requirements-00] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Oct 2011 21:48:44 -0000 Hi, > Yes, but in theory we don't need to support ROAP forking to let you do th= at, because you don't need to do it that way. For example you > can write the JS to send a "session request" message without any ROAP/SDP= , and as each "session response" comes back from each team=20 > member with a ROAP OFFER, the local JS creates a new PeerConnection and s= ends back to each team member a ROAP ANSWER from you.=20 > So basically mimicking the offerless-INVITE model of SIP. That would cause issues with SIP interworking. I hope we can agree on the f= act that many (most?) SIP environments and use-cases rely on the SDP offer = being sent in the INVITE. The gateway would end up having to map SIP answer= s into ROAP offers, and vice verse, which could become very messy. And, when the gateway receveis on offerless ROAD offer, if it needs to map = it into an INVITE with an SDP offer, what information would it include in t= he SDP offer? Regards. Christer= From ibc@aliax.net Sat Oct 29 15:26: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 30F7921F854D for ; Sat, 29 Oct 2011 15:26:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.643 X-Spam-Level: X-Spam-Status: No, score=-2.643 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FX0V1a6uQVj1 for ; Sat, 29 Oct 2011 15:26: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 93AF821F8548 for ; Sat, 29 Oct 2011 15:26:33 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so4951593vcb.31 for ; Sat, 29 Oct 2011 15:26:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.150.212 with SMTP id z20mr1346077vcv.58.1319927193032; Sat, 29 Oct 2011 15:26:33 -0700 (PDT) Received: by 10.220.184.6 with HTTP; Sat, 29 Oct 2011 15:26:32 -0700 (PDT) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852234CFCA00@ESESSCMS0356.eemea.ericsson.se> References: <20111024224257.28459.65554.idtracker@ietfa.amsl.com> <6EB8679A-13D5-4AD7-97F2-BC35FC0966F0@acmepacket.com> <2E239D6FCD033C4BAF15F386A979BF51159C32@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF51159D7A@sonusinmail02.sonusnet.com> <4EAAF413.8030501@alvestrand.no> <2E239D6FCD033C4BAF15F386A979BF51159D7B@sonusinmail02.sonusnet.com> <247FFE2C-DB2C-4280-A219-BE1503662F92@acmepacket.com> <4EAB2657.7090609@jesup.org> <817D03B4-A50D-4047-A638-4BFA231543E2@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A05852234CFCA00@ESESSCMS0356.eemea.ericsson.se> Date: Sun, 30 Oct 2011 00:26:32 +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: Randell Jesup , "" Subject: Re: [rtcweb] RTCWeb Forking usecase [was RE: draft-kaplan-rtcweb-sip-interworking-requirements-00] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Oct 2011 22:26:34 -0000 2011/10/29 Christer Holmberg : > Hi, > >> Yes, but in theory we don't need to support ROAP forking to let you do t= hat, because you don't need to do it that way. =C2=A0For example you >> can write the JS to send a "session request" message without any ROAP/SD= P, and as each "session response" comes back from each team >> member with a ROAP OFFER, the local JS creates a new PeerConnection and = sends back to each team member a ROAP ANSWER from you. >> So basically mimicking the offerless-INVITE model of SIP. > > That would cause issues with SIP interworking. I hope we can agree on the= fact that many (most?) SIP environments and use-cases rely on the SDP offe= r being sent in the INVITE. The gateway would end up having to map SIP answ= ers into ROAP offers, and vice verse, which could become very messy. > > And, when the gateway receveis on offerless ROAD offer, if it needs to ma= p it into an INVITE with an SDP offer, what information would it include in= the SDP offer? Take into account that not all of us will require a protocol gateway :) --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Sat Oct 29 15:34:21 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 881F521F8593 for ; Sat, 29 Oct 2011 15:34:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.643 X-Spam-Level: X-Spam-Status: No, score=-2.643 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dEF4VVV9AEuk for ; Sat, 29 Oct 2011 15:34:21 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 083E521F8564 for ; Sat, 29 Oct 2011 15:34:20 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so4953382vcb.31 for ; Sat, 29 Oct 2011 15:34:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.7.12 with SMTP id b12mr1428397vcb.23.1319927660540; Sat, 29 Oct 2011 15:34:20 -0700 (PDT) Received: by 10.220.184.6 with HTTP; Sat, 29 Oct 2011 15:34:20 -0700 (PDT) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852234CFC9FF@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05852234CFC9FF@ESESSCMS0356.eemea.ericsson.se> Date: Sun, 30 Oct 2011 00:34:20 +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: "" Subject: Re: [rtcweb] SDES in browser [was: RTCWeb Forking usecase [was: draft-kaplan-rtcweb-sip-interworking-requirements-00]] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Oct 2011 22:34:21 -0000 2011/10/29 Christer Holmberg : >> If we want to support SDES for interop with SIP, which I think we do, th= en what we could do is mandate the Browsers support both SDES and DTLS-SRTP= , > > I am not sure the browser itself would need to support SDES. It may be en= ough if SDES is implemented in the JavaScript App, the API then allows the = App to provide keys to the browser, and the browser would use those keys fo= r media encryption instead of triggering DTLS-SRPT. > > And, if the JavaScript App does not provide any keys to the browser, DTLS= -SRTP could be used as default. Note that it would require some kind of standarized JavaScript WebRTC API callback. --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Sat Oct 29 15:36: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 5FAB421F8497 for ; Sat, 29 Oct 2011 15:36:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.644 X-Spam-Level: X-Spam-Status: No, score=-2.644 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qElX0a+LbsYu for ; Sat, 29 Oct 2011 15:36: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 CCECB21F8496 for ; Sat, 29 Oct 2011 15:36:00 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so4953755vcb.31 for ; Sat, 29 Oct 2011 15:36:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.150.81 with SMTP id x17mr1385710vcv.233.1319927760325; Sat, 29 Oct 2011 15:36:00 -0700 (PDT) Received: by 10.220.184.6 with HTTP; Sat, 29 Oct 2011 15:36:00 -0700 (PDT) In-Reply-To: <4EAC6BF4.2000604@alvestrand.no> References: <4EAC6BF4.2000604@alvestrand.no> Date: Sun, 30 Oct 2011 00:36:00 +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] URI schemes for TURN and STUN X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Oct 2011 22:36:01 -0000 2011/10/29 Harald Alvestrand : > - I do not think it's appropriate to use "turn" and "turns" for indicatin= g > transport. Polluting the URI namespace with more configuration parameters= in > the form of trailing "s" is a Bad Thing. But there should be some way to indicate that a TURN server listens in TLS, right? --=20 I=C3=B1aki Baz Castillo From petithug@acm.org Sat Oct 29 16:23: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 8563821F84D4; Sat, 29 Oct 2011 16:23:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.243 X-Spam-Level: X-Spam-Status: No, score=-102.243 tagged_above=-999 required=5 tests=[AWL=0.357, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KEct+xyomWsw; Sat, 29 Oct 2011 16:23:15 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id C4E0021F84D3; Sat, 29 Oct 2011 16:23:15 -0700 (PDT) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 5E28D2087B; Sat, 29 Oct 2011 23:14:38 +0000 (UTC) Message-ID: <4EAC8AE0.3020307@acm.org> Date: Sat, 29 Oct 2011 16:23:12 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20111010 Iceowl/1.0b2 Icedove/3.1.15 MIME-Version: 1.0 To: Harald Alvestrand References: <4EAC6BF4.2000604@alvestrand.no> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: "rtcweb@ietf.org" , Behave WG Subject: Re: [rtcweb] URI schemes for TURN and STUN X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Oct 2011 23:23:16 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/29/2011 03:36 PM, Iñaki Baz Castillo wrote: > 2011/10/29 Harald Alvestrand : >> - I do not think it's appropriate to use "turn" and "turns" for indicating >> transport. Polluting the URI namespace with more configuration parameters in >> the form of trailing "s" is a Bad Thing. > > But there should be some way to indicate that a TURN server listens in > TLS, right? > We should continue this discussion in BEHAVE, but I would like to ask the OP to send a pointer on the RFC or discussion that says that using a trailing "s" to indicate security is a bad thing. Thanks. - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk6sit4ACgkQ9RoMZyVa61dhpgCfZv+XuDhAljo3N0s33zbh6l0E aWAAmwUP2mvcZiY9BLB5BAsjoe6OULMl =yx3i -----END PGP SIGNATURE----- From ibc@aliax.net Sat Oct 29 16:26:27 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C958311E8080; Sat, 29 Oct 2011 16:26:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.644 X-Spam-Level: X-Spam-Status: No, score=-2.644 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EuZ2zQ1h8WGB; Sat, 29 Oct 2011 16:26:27 -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 296CD11E807F; Sat, 29 Oct 2011 16:26:27 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so4965523vcb.31 for ; Sat, 29 Oct 2011 16:26:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.150.81 with SMTP id x17mr1410465vcv.233.1319930785403; Sat, 29 Oct 2011 16:26:25 -0700 (PDT) Received: by 10.220.184.6 with HTTP; Sat, 29 Oct 2011 16:26:25 -0700 (PDT) In-Reply-To: <4EAC8AE0.3020307@acm.org> References: <4EAC6BF4.2000604@alvestrand.no> <4EAC8AE0.3020307@acm.org> Date: Sun, 30 Oct 2011 01:26:25 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Marc Petit-Huguenin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" , Behave WG Subject: Re: [rtcweb] URI schemes for TURN and STUN X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Oct 2011 23:26:27 -0000 2011/10/30 Marc Petit-Huguenin : > I would like to ask the OP to > send a pointer on the RFC or discussion that says that using a trailing "= s" to > indicate security is a bad thing. Well, in http (so https) it's a good idea. In SIP (using "sips" instead of "sip" schema) it's a pain nobody wants to deal with (and there are bugs in the specifications). --=20 I=C3=B1aki Baz Castillo From harald@alvestrand.no Sat Oct 29 21:41: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 1CCC411E8083; Sat, 29 Oct 2011 21:41:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.524 X-Spam-Level: X-Spam-Status: No, score=-110.524 tagged_above=-999 required=5 tests=[AWL=0.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 OmeszXy7rRcr; Sat, 29 Oct 2011 21:41:01 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 2198D11E8082; Sat, 29 Oct 2011 21:41:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3228139E162; Sun, 30 Oct 2011 05:41:00 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i6lPh-Opdjpx; Sun, 30 Oct 2011 05:40:59 +0100 (CET) Received: from [192.168.6.21] (unknown [24.104.44.194]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 05BD939E088; Sun, 30 Oct 2011 05:40:57 +0100 (CET) Message-ID: <4EACD558.1050003@alvestrand.no> Date: Sat, 29 Oct 2011 21:40:56 -0700 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: Marc Petit-Huguenin References: <4EAC6BF4.2000604@alvestrand.no> <4EAC8AE0.3020307@acm.org> In-Reply-To: <4EAC8AE0.3020307@acm.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: Keith Moore , "rtcweb@ietf.org" , Ned Freed , Behave WG Subject: Re: [rtcweb] URI schemes for TURN and STUN X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Oct 2011 04:41:02 -0000 On 10/29/2011 04:23 PM, Marc Petit-Huguenin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 10/29/2011 03:36 PM, Iñaki Baz Castillo wrote: >> 2011/10/29 Harald Alvestrand: >>> - I do not think it's appropriate to use "turn" and "turns" for indicating >>> transport. Polluting the URI namespace with more configuration parameters in >>> the form of trailing "s" is a Bad Thing. >> But there should be some way to indicate that a TURN server listens in >> TLS, right? >> > We should continue this discussion in BEHAVE, but I would like to ask the OP to > send a pointer on the RFC or discussion that says that using a trailing "s" to > indicate security is a bad thing. I'll have to forward this question to the apps ADs of a few years ago about whether there's documentation for it. It does not seem to have been captured in an RFC that I can find; discussion was in the ~2000-2005 timeframe. The short version, from memory: Doing "s" locks you into one and exactly one security scheme, and prevents you from saying anything about the requisite parameters for that scheme, while using AUTH parameters such as POP or in-band negotiation such as IMAP are much more flexible approaches. > Thanks. > > - -- > Marc Petit-Huguenin > Personal email: marc@petit-huguenin.org > Professional email: petithug@acm.org > Blog: http://blog.marc.petit-huguenin.org > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > > iEYEARECAAYFAk6sit4ACgkQ9RoMZyVa61dhpgCfZv+XuDhAljo3N0s33zbh6l0E > aWAAmwUP2mvcZiY9BLB5BAsjoe6OULMl > =yx3i > -----END PGP SIGNATURE----- > From christer.holmberg@ericsson.com Sun Oct 30 00:33: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 A4B9321F8551 for ; Sun, 30 Oct 2011 00:33:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.069 X-Spam-Level: X-Spam-Status: No, score=-6.069 tagged_above=-999 required=5 tests=[AWL=0.230, 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 fYFcYeAwtyLm for ; Sun, 30 Oct 2011 00:33: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 DBEC521F854F for ; Sun, 30 Oct 2011 00:33:32 -0700 (PDT) X-AuditID: c1b4fb3d-b7c26ae0000035b9-8d-4eacfdcbcfa6 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 99.E4.13753.BCDFCAE4; Sun, 30 Oct 2011 08:33:31 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.57]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Sun, 30 Oct 2011 08:33:31 +0100 From: Christer Holmberg To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= Date: Sun, 30 Oct 2011 08:32:22 +0100 Thread-Topic: [rtcweb] SDES in browser [was: RTCWeb Forking usecase [was: draft-kaplan-rtcweb-sip-interworking-requirements-00]] Thread-Index: AcyWiueYZCnkLjiyRpigS1M8tkSE+gASyide Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585223571738D@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05852234CFC9FF@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: "" Subject: Re: [rtcweb] SDES in browser [was: RTCWeb Forking usecase [was: draft-kaplan-rtcweb-sip-interworking-requirements-00]] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Oct 2011 07:33:33 -0000 Hi, >>> If we want to support SDES for interop with SIP, which I think we do, t= hen what we could do is mandate the Browsers support both SDES and DTLS-SRT= P, >> >> I am not sure the browser itself would need to support SDES. It may be e= nough if SDES is implemented in the JavaScript App, the API then allows the= App=20 >>to provide keys to the browser, and the browser would use those keys for = media encryption instead of triggering DTLS-SRPT. >> >> And, if the JavaScript App does not provide any keys to the browser, DTL= S-SRTP could be used as default. > > Note that it would require some kind of standarized JavaScript WebRTC API= callback. I thought API requirements are part of what we are trying to specify :) Regards, Christer From christer.holmberg@ericsson.com Sun Oct 30 00: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 AE40121F8591 for ; Sun, 30 Oct 2011 00:38:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.073 X-Spam-Level: X-Spam-Status: No, score=-6.073 tagged_above=-999 required=5 tests=[AWL=0.226, 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 jtMbGHYD5gzT for ; Sun, 30 Oct 2011 00:38: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 EBFC021F8551 for ; Sun, 30 Oct 2011 00:38:54 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-d3-4eacff0d6f11 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id A9.43.20773.D0FFCAE4; Sun, 30 Oct 2011 08:38:53 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.57]) by esessmw0184.eemea.ericsson.se ([10.2.3.53]) with mapi; Sun, 30 Oct 2011 08:38:53 +0100 From: Christer Holmberg To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= Date: Sun, 30 Oct 2011 08:36:51 +0100 Thread-Topic: [rtcweb] RTCWeb Forking usecase [was RE: draft-kaplan-rtcweb-sip-interworking-requirements-00] Thread-Index: AcyWidEQUnol4P/3RoS3CT7u8WEfOgATN+ol Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585223571738E@ESESSCMS0356.eemea.ericsson.se> References: <20111024224257.28459.65554.idtracker@ietfa.amsl.com> <6EB8679A-13D5-4AD7-97F2-BC35FC0966F0@acmepacket.com> <2E239D6FCD033C4BAF15F386A979BF51159C32@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF51159D7A@sonusinmail02.sonusnet.com> <4EAAF413.8030501@alvestrand.no> <2E239D6FCD033C4BAF15F386A979BF51159D7B@sonusinmail02.sonusnet.com> <247FFE2C-DB2C-4280-A219-BE1503662F92@acmepacket.com> <4EAB2657.7090609@jesup.org> <817D03B4-A50D-4047-A638-4BFA231543E2@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A05852234CFCA00@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: Randell Jesup , "" Subject: Re: [rtcweb] RTCWeb Forking usecase [was RE: draft-kaplan-rtcweb-sip-interworking-requirements-00] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Oct 2011 07:38:55 -0000 Hi, >>> Yes, but in theory we don't need to support ROAP forking to let you do = that, because you don't need to do it that way. For example you >>> can write the JS to send a "session request" message without any ROAP/S= DP, and as each "session response" comes back from each team >>> member with a ROAP OFFER, the local JS creates a new PeerConnection and= sends back to each team member a ROAP ANSWER from you. >>> So basically mimicking the offerless-INVITE model of SIP. >> >> That would cause issues with SIP interworking. I hope we can agree on th= e fact that many (most?) SIP environments and use-cases rely >> on the SDP offer being sent in the INVITE. The gateway would end up havi= ng to map SIP answers into ROAP offers, and vice verse, which=20 >> could become very messy. > >> And, when the gateway receveis on offerless ROAD offer, if it needs to m= ap it into an INVITE with an SDP offer, what information would it include i= n the SDP offer? > > Take into account that not all of us will require a protocol gateway :) Sure, but assuming you would still use ROAP on the JS-browser API, you woul= dl have to do similar "interworking" in your JS app. Regards, Christer From stefan.lk.hakansson@ericsson.com Sun Oct 30 03:06: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 D4D6F21F8A55 for ; Sun, 30 Oct 2011 03:06:24 -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=-0.233, BAYES_00=-2.599, J_CHICKENPOX_34=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 M0qli+HmBOln for ; Sun, 30 Oct 2011 03:06:24 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id D609B21F88B7 for ; Sun, 30 Oct 2011 03:06:23 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-35-4ead219a778c Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 94.4C.20773.A912DAE4; Sun, 30 Oct 2011 11:06:18 +0100 (CET) Received: from [127.0.0.1] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.137.0; Sun, 30 Oct 2011 11:06:18 +0100 Message-ID: <4EAD2199.6050305@ericsson.com> Date: Sun, 30 Oct 2011 11:06:17 +0100 From: =?UTF-8?B?U3RlZmFuIEjDpWthbnNzb24=?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110922 Lightning/1.0b2 Thunderbird/3.1.15 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [rtcweb] Media forking solution for SIP interoperability (without a media gateway) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Oct 2011 10:06:24 -0000 I assume that part of the solution here is that the new PeerConnection's reuse the same candidates as the first one created? Br, Stefan On 10/29/2011 07:29 PM, Iñaki Baz Castillo wrote: > Hi, the next suggestion would allow media serial/parallel forking > scenarios when interoperating with a SIP network. It is just a > *suggestion*. > > > Assumtions > ------------------ > > - WebRTC specs don't allow sharing a local PeerConnection for sending > and receiving media to/from more than a single remote peer. > > - The remote pure SIP peers implement ICE+SRTP and can interoperate > with a WebRTC client in the media plane without requiring media > gateways. > > > The problem > ------------------ > > Let's assume a WebRTC client implementing SIP at JavaScript level > (although there could be a signaling gateway). > > - The WebRTC client makes an outgoing call which arrives to a SIP > proxy and forking occurs (serial or parallel). > > - The WebRTC client receives more than a single SIP 183 response with > different To-tags and different SDPs (so they are different remote SIP > peers). > > - And/or the WebRTC client receives a 200 OK with a Totag and SDP > different than the one received in the previous 183. > > In this case, given the first assumption above, the WebRTC client must > choose a single remote SIP peer and can just send and receive media to > the chosen peer (limitation 1). > If the SIP 200 OK arriving to the WebRTC client belongs to a remote > peer different than the chosen one, the WebRTC client cannot reuse the > already open local PeerConnection since it was created passing it a > different remote SDP (limitation 2). > > > Solution > ------------ > > - The WebRTC client sends the call and receives a 183 with Totag > "AAAA" and SDP "SDP_A" from SIP_PEER_A. > > - It creates a PeerConnection passing it "SDP_A", sends like a ROAP > Answer to the peer and media flow starts between client and > SIP_PEER_A. > > - Later (or very soon) another 183 with Totag "BBBB" and SDP "SDP_B" > arrives to the WebRTC client from SIP_PEER_B. > > - The client creates a *new* PeerConnection *without* passing it > "SDP_B" and sends a SIP UPDATE with the associated ROAP Offer to > SIP_PEER_B. > > - If SIP_PEER_B implements SIP UPDATE it will reply a 200 OK with a > new "SDP_B2" (it could be the same as "SDP_B"). > > - The client then passes "SDP_B2" to the second PeerConnection and > media flow starts between client and SIP_PEER_A. > > - Later a SIP 200 OK with Totag "CCCC" and SDP "SDP_C" arrives to the > client from SIP_PEER_C. > > - The client creates a *new* PeerConnection *without* passing it > "SDP_C" and sends a SIP re-INVITE with the associated ROAP Offer to > SIP_PEER_C. > > - SIP_PEER_C will reply a 200 OK with a new "SDP_C2" (it could be the > same as "SDP_C"). > > - The client then passes "SDP_C2" to the third PeerConnection and > media flow starts between client and SIP_PEER_C. At the same time the > client destroys the first and second PeerConnections. > > And we are done. Limitation solved. Of course if SIP_PEER_B does not > implement UPDATE we have a problem, but RFC 3311 (SIP UPDATE Method) > is a standard since 2002, come on! > > > Conclusion > ---------------- > > SIP media forking can be implemented in JavaScript without mandating > special requirements in WebRTC for interoperating with "legacy" SIP > (why do we call "legacy" to SIP???). And we just need tu use existing > SIP mechanisms. > > No signaling gateway is required (of course !!) nor a media gateway > (if second bullet in "Assumtions" section above is satisfied). > > We all are happy (but those who have in mind a market selling > WebRTC-SIP gateway boxes and want that the specs satisfy their > business model). > > > From ibc@aliax.net Sun Oct 30 03:20: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 D55ED21F863E for ; Sun, 30 Oct 2011 03:20:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.644 X-Spam-Level: X-Spam-Status: No, score=-2.644 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1IbQTZPoxyn1 for ; Sun, 30 Oct 2011 03:20: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 4B36E21F84CB for ; Sun, 30 Oct 2011 03:20:01 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so5102450vcb.31 for ; Sun, 30 Oct 2011 03:20:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.7.12 with SMTP id b12mr1764013vcb.23.1319970000768; Sun, 30 Oct 2011 03:20:00 -0700 (PDT) Received: by 10.220.184.6 with HTTP; Sun, 30 Oct 2011 03:20:00 -0700 (PDT) In-Reply-To: <4EAD2199.6050305@ericsson.com> References: <4EAD2199.6050305@ericsson.com> Date: Sun, 30 Oct 2011 11:20:00 +0100 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: =?UTF-8?Q?Stefan_H=C3=A5kansson?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Media forking solution for SIP interoperability (without a media gateway) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Oct 2011 10:20:01 -0000 2011/10/30 Stefan H=C3=A5kansson : > I assume that part of the solution here is that the new PeerConnection's > reuse the same candidates as the first one created? Well, if that would be possible then my solution is not needed at all :) My solution is a "workaround" for the case in which WebRTC does not allow reusing the same local candidates. In my suggestion I create N *independent* PeerConnection instances. --=20 I=C3=B1aki Baz Castillo From ekr@rtfm.com Sun Oct 30 07:29: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 81FB921F8497; Sun, 30 Oct 2011 07:29:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.96 X-Spam-Level: X-Spam-Status: No, score=-102.96 tagged_above=-999 required=5 tests=[AWL=0.017, 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 0moZTEPPc0vH; Sun, 30 Oct 2011 07:29:38 -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 D6F7721F8495; Sun, 30 Oct 2011 07:29:37 -0700 (PDT) Received: by ggnv1 with SMTP id v1so6040520ggn.31 for ; Sun, 30 Oct 2011 07:29:37 -0700 (PDT) Received: by 10.236.77.163 with SMTP id d23mr12446161yhe.34.1319984977447; Sun, 30 Oct 2011 07:29:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.147.124.3 with HTTP; Sun, 30 Oct 2011 07:28:56 -0700 (PDT) In-Reply-To: <4EACD558.1050003@alvestrand.no> References: <4EAC6BF4.2000604@alvestrand.no> <4EAC8AE0.3020307@acm.org> <4EACD558.1050003@alvestrand.no> From: Eric Rescorla Date: Sun, 30 Oct 2011 07:28:56 -0700 Message-ID: To: Harald Alvestrand Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Keith Moore , Ned Freed , Behave WG , "rtcweb@ietf.org" Subject: Re: [rtcweb] URI schemes for TURN and STUN X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Oct 2011 14:29:38 -0000 On Sat, Oct 29, 2011 at 9:40 PM, Harald Alvestrand w= rote: > On 10/29/2011 04:23 PM, Marc Petit-Huguenin wrote: >> >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 10/29/2011 03:36 PM, I=F1aki Baz Castillo wrote: >>> >>> 2011/10/29 Harald Alvestrand: >>>> >>>> - I do not think it's appropriate to use "turn" and "turns" for >>>> indicating >>>> transport. Polluting the URI namespace with more configuration >>>> parameters in >>>> the form of trailing "s" is a Bad Thing. >>> >>> But there should be some way to indicate that a TURN server listens in >>> TLS, right? >>> >> We should continue this discussion in BEHAVE, but I would like to ask th= e >> OP to >> send a pointer on the RFC or discussion that says that using a trailing >> "s" to >> indicate security is a bad thing. > > I'll have to forward this question to the apps ADs of a few years ago abo= ut > whether there's documentation for it. It does not seem to have been captu= red > in an RFC that I can find; discussion was in the ~2000-2005 timeframe. > > The short version, from memory: Doing "s" locks you into one and exactly = one > security scheme, and prevents you from saying anything about the requisit= e > parameters for that scheme, while using AUTH parameters such as POP or > in-band negotiation such as IMAP =A0are much more flexible approaches. I haven't formed an opinion on the value of turn[s] URIs one way or another, but... What you say above is absolutely true, but there is a tradeoff here. If you= just provide a URI with no indication of the expected security mechanism, and rely on in-band negotiation, then an active attacker can force the client d= own to the weakest security mechanism (a downgrade attack). So, for instance, if the client supports both TURN and TURN over TLS, the attacker can impersonate a server which supports only TURN and force the client to accept that. By contrast, if the URI indicates a minimal security mechanism that is sufficiently strong, then this form of attack is not possible. Obviously, t= he user could configure his client to only support secure connections (via whatever mechanism) but this is less convenient. Another point in the design space is to require some specific security mech= anism that is strong enough to authenticate the server and then use that mechanis= m to support secure negotiation of the real mechanism. Unfortunately, the onl= y widely supported mechanism that meets that standard is TLS, so this isn't much of an improvement. -Ekr From christer.holmberg@ericsson.com Sun Oct 30 09:03: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 6EAE921F8B49 for ; Sun, 30 Oct 2011 09:03:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.777 X-Spam-Level: X-Spam-Status: No, score=-5.777 tagged_above=-999 required=5 tests=[AWL=-0.078, BAYES_00=-2.599, J_CHICKENPOX_34=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 l5ecnRfeY0s5 for ; Sun, 30 Oct 2011 09:03:07 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 2511921F8B43 for ; Sun, 30 Oct 2011 09:03:06 -0700 (PDT) X-AuditID: c1b4fb3d-b7c26ae0000035b9-a3-4ead75372c64 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id CD.DD.13753.7357DAE4; Sun, 30 Oct 2011 17:03:04 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.57]) by esessmw0184.eemea.ericsson.se ([10.2.3.53]) with mapi; Sun, 30 Oct 2011 17:03:03 +0100 From: Christer Holmberg To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= , "rtcweb@ietf.org" Date: Sun, 30 Oct 2011 16:58:09 +0100 Thread-Topic: [rtcweb] Media forking solution for SIP interoperability (without a media gateway) Thread-Index: AcyWYE5k7XnXBTfwTS2iFiRnk8hglwAvGn++ Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852235717390@ESESSCMS0356.eemea.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [rtcweb] Media forking solution for SIP interoperability (without a media gateway) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Oct 2011 16:03:10 -0000 Hi, I don't like the idea of having to send UPDATE/re-INVITE for every new earl= y dialog. In addition, I am not even sure it would work with ICE. Remember that ICE a= llows the UAS to send an "answer" unreliably (the unreliabe 18x is re-trans= mitted a few times), but since it's not a real answer, the UAC is not allow= ed to send an UDPATE. In my opinion a better solution is to create a new PeerConnection for every= new early dialog, which uses the *same* address/candidate parameters as th= e "parent" PeerConnection. In such case there is no need to send an UPDATE. Regards, Chrsiter ________________________________________ From: rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] On Behalf Of I=F1ak= i Baz Castillo [ibc@aliax.net] Sent: Saturday, October 29, 2011 8:29 PM To: rtcweb@ietf.org Subject: [rtcweb] Media forking solution for SIP interoperability (without = a media gateway) Hi, the next suggestion would allow media serial/parallel forking scenarios when interoperating with a SIP network. It is just a *suggestion*. Assumtions ------------------ - WebRTC specs don't allow sharing a local PeerConnection for sending and receiving media to/from more than a single remote peer. - The remote pure SIP peers implement ICE+SRTP and can interoperate with a WebRTC client in the media plane without requiring media gateways. The problem ------------------ Let's assume a WebRTC client implementing SIP at JavaScript level (although there could be a signaling gateway). - The WebRTC client makes an outgoing call which arrives to a SIP proxy and forking occurs (serial or parallel). - The WebRTC client receives more than a single SIP 183 response with different To-tags and different SDPs (so they are different remote SIP peers). - And/or the WebRTC client receives a 200 OK with a Totag and SDP different than the one received in the previous 183. In this case, given the first assumption above, the WebRTC client must choose a single remote SIP peer and can just send and receive media to the chosen peer (limitation 1). If the SIP 200 OK arriving to the WebRTC client belongs to a remote peer different than the chosen one, the WebRTC client cannot reuse the already open local PeerConnection since it was created passing it a different remote SDP (limitation 2). Solution ------------ - The WebRTC client sends the call and receives a 183 with Totag "AAAA" and SDP "SDP_A" from SIP_PEER_A. - It creates a PeerConnection passing it "SDP_A", sends like a ROAP Answer to the peer and media flow starts between client and SIP_PEER_A. - Later (or very soon) another 183 with Totag "BBBB" and SDP "SDP_B" arrives to the WebRTC client from SIP_PEER_B. - The client creates a *new* PeerConnection *without* passing it "SDP_B" and sends a SIP UPDATE with the associated ROAP Offer to SIP_PEER_B. - If SIP_PEER_B implements SIP UPDATE it will reply a 200 OK with a new "SDP_B2" (it could be the same as "SDP_B"). - The client then passes "SDP_B2" to the second PeerConnection and media flow starts between client and SIP_PEER_A. - Later a SIP 200 OK with Totag "CCCC" and SDP "SDP_C" arrives to the client from SIP_PEER_C. - The client creates a *new* PeerConnection *without* passing it "SDP_C" and sends a SIP re-INVITE with the associated ROAP Offer to SIP_PEER_C. - SIP_PEER_C will reply a 200 OK with a new "SDP_C2" (it could be the same as "SDP_C"). - The client then passes "SDP_C2" to the third PeerConnection and media flow starts between client and SIP_PEER_C. At the same time the client destroys the first and second PeerConnections. And we are done. Limitation solved. Of course if SIP_PEER_B does not implement UPDATE we have a problem, but RFC 3311 (SIP UPDATE Method) is a standard since 2002, come on! Conclusion ---------------- SIP media forking can be implemented in JavaScript without mandating special requirements in WebRTC for interoperating with "legacy" SIP (why do we call "legacy" to SIP???). And we just need tu use existing SIP mechanisms. No signaling gateway is required (of course !!) nor a media gateway (if second bullet in "Assumtions" section above is satisfied). We all are happy (but those who have in mind a market selling WebRTC-SIP gateway boxes and want that the specs satisfy their business model). -- I=F1aki Baz Castillo _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb= From ibc@aliax.net Sun Oct 30 12:12: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 7402521F8AD9 for ; Sun, 30 Oct 2011 12:12:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.645 X-Spam-Level: X-Spam-Status: No, score=-2.645 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h8zk9BXhaOEZ for ; Sun, 30 Oct 2011 12:12:23 -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 DB16D21F8AD3 for ; Sun, 30 Oct 2011 12:12:22 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so5256359vcb.31 for ; Sun, 30 Oct 2011 12:12:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.150.212 with SMTP id z20mr1911834vcv.58.1320001942347; Sun, 30 Oct 2011 12:12:22 -0700 (PDT) Received: by 10.220.184.6 with HTTP; Sun, 30 Oct 2011 12:12:22 -0700 (PDT) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852235717390@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05852235717390@ESESSCMS0356.eemea.ericsson.se> Date: Sun, 30 Oct 2011 20:12:22 +0100 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] Media forking solution for SIP interoperability (without a media gateway) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Oct 2011 19:12:23 -0000 2011/10/30 Christer Holmberg : > I don't like the idea of having to send UPDATE/re-INVITE for every new ea= rly dialog. Hi Christer, it was just a suggestion, I'm not traying to mandating or standarizing nothing :) > In addition, I am not even sure it would work with ICE. Remember that ICE= allows the UAS to send an "answer" unreliably (the unreliabe 18x is re-tra= nsmitted a few times), but since it's not a real answer, the UAC is not all= owed to send an UDPATE. I don't agree. If the UAC receives a 180 it means that the 180 has been received (regardless it was unreliable), so UPDATE is possible. > In my opinion a better solution is to create a new PeerConnection for eve= ry new early dialog, which uses the *same* address/candidate parameters as = the "parent" PeerConnection. In such case there is no need to send an UPDAT= E. Sure! but my suggestion was based on the assumption that WebRTC won't allow reusing the same local address/candidates in two different PeerConnection's. Regards. --=20 I=C3=B1aki Baz Castillo From christer.holmberg@ericsson.com Sun Oct 30 12:24:20 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B35C321F8B17 for ; Sun, 30 Oct 2011 12:24:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.075 X-Spam-Level: X-Spam-Status: No, score=-6.075 tagged_above=-999 required=5 tests=[AWL=0.224, 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 pm-FCcFKK67U for ; Sun, 30 Oct 2011 12:24:20 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id EF45E21F8B0E for ; Sun, 30 Oct 2011 12:24:19 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-6f-4eada4627593 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id E1.43.20773.264ADAE4; Sun, 30 Oct 2011 20:24:19 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.57]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Sun, 30 Oct 2011 20:24:18 +0100 From: Christer Holmberg To: =?iso-8859-1?Q?=27I=F1aki_Baz_Castillo=27?= Date: Sun, 30 Oct 2011 20:24:17 +0100 Thread-Topic: [rtcweb] Media forking solution for SIP interoperability (without a media gateway) Thread-Index: AcyXN9rzK5XILIp7Q4mcOSLH9iwWsgAAO1SA Message-ID: <7F2072F1E0DE894DA4B517B93C6A058522357895FA@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05852235717390@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] Media forking solution for SIP interoperability (without a media gateway) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Oct 2011 19:24:20 -0000 Hi,=20 >> I don't like the idea of having to send UPDATE/re-INVITE for every new e= arly dialog. > > Hi Christer, it was just a suggestion, I'm not traying to mandating or st= andarizing nothing :) And I didn't like the suggestion :) >> In addition, I am not even sure it would work with ICE. Remember that IC= E allows the UAS to send=20 >> an "answer" unreliably (the unreliabe 18x is re-transmitted a few times)= , but since it's not a real=20 >> answer, the UAC is not allowed to send an UDPATE. > > I don't agree. If the UAC receives a 180 it means that the 180 has been r= eceived (regardless it was=20 > unreliable), so UPDATE is possible. Ok, small correction: you are not allowed to send a new offer before you ha= ve received the previous answer in a reliably sent response :) Regards, Christer >> In my opinion a better solution is to create a new PeerConnection for ev= ery new early dialog, which uses the=20 >> *same* address/candidate parameters as the "parent" PeerConnection. In s= uch case there is no need to send an UPDATE. > > Sure! but my suggestion was based on the assumption that WebRTC won't all= ow reusing the same local address/candidates in two different PeerConnectio= n's. Regards. -- I=F1aki Baz Castillo From ibc@aliax.net Sun Oct 30 12:41: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 BB37D21F8B16 for ; Sun, 30 Oct 2011 12:41:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.645 X-Spam-Level: X-Spam-Status: No, score=-2.645 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LoFxX95WELPD for ; Sun, 30 Oct 2011 12:41:32 -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 DB13221F8B09 for ; Sun, 30 Oct 2011 12:41:31 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so5264921vcb.31 for ; Sun, 30 Oct 2011 12:41:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.1.196 with SMTP id 4mr1633580vcg.268.1320003691258; Sun, 30 Oct 2011 12:41:31 -0700 (PDT) Received: by 10.220.184.6 with HTTP; Sun, 30 Oct 2011 12:41:31 -0700 (PDT) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A058522357895FA@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05852235717390@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A058522357895FA@ESESSCMS0356.eemea.ericsson.se> Date: Sun, 30 Oct 2011 20:41:31 +0100 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] Media forking solution for SIP interoperability (without a media gateway) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Oct 2011 19:41:32 -0000 2011/10/30 Christer Holmberg : >> I don't agree. If the UAC receives a 180 it means that the 180 has been = received (regardless it was >> unreliable), so UPDATE is possible. > > Ok, small correction: you are not allowed to send a new offer before you = have received the previous answer in a reliably sent response :) Ok, PRACK (RFC 3262) dates from 2002, so just add "Require: 100rel" in the INVITE and you are done. Of course, if the remote SIP peer does not implement PRACK I am sure it won't implement ICE and SRTP, so interoperability with a WebRTC client is not possible anyway. Anyhow, let's remember that the purpose of WebRTC is not the interoperability with old SIP phones which implement nothing but plain SIP and plain RTP. So I don't expect that WebRTC will allow reusing the same local candidates in a new PeerConnection just to allow SIP media forking. Regards. --=20 I=C3=B1aki Baz Castillo From christer.holmberg@ericsson.com Sun Oct 30 13: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 354AC21F8B5D for ; Sun, 30 Oct 2011 13:11:22 -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.220, 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 flG1GxFXMjwT for ; Sun, 30 Oct 2011 13:11:21 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 3CB2821F8B63 for ; Sun, 30 Oct 2011 13:11:20 -0700 (PDT) X-AuditID: c1b4fb3d-b7c26ae0000035b9-a6-4eadaf66812a Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 48.86.13753.66FADAE4; Sun, 30 Oct 2011 21:11:19 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.57]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Sun, 30 Oct 2011 21:11:18 +0100 From: Christer Holmberg To: =?iso-8859-1?Q?=27I=F1aki_Baz_Castillo=27?= Date: Sun, 30 Oct 2011 21:11:18 +0100 Thread-Topic: [rtcweb] Media forking solution for SIP interoperability (without a media gateway) Thread-Index: AcyXO+1qLdSLgC+6Qf26jvyVTfz0bwAAnGPg Message-ID: <7F2072F1E0DE894DA4B517B93C6A058522357895FC@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05852235717390@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A058522357895FA@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] Media forking solution for SIP interoperability (without a media gateway) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Oct 2011 20:11:22 -0000 Hi,=20 >>> I don't agree. If the UAC receives a 180 it means that the 180 has=20 >>> been received (regardless it was unreliable), so UPDATE is possible. >> >> Ok, small correction: you are not allowed to send a new offer before=20 >> you have received the previous answer in a reliably sent response :) > > Ok, PRACK (RFC 3262) dates from 2002, so just add "Require: 100rel" in th= e INVITE and you are done. Of course, if=20 > the remote SIP peer does not implement PRACK I am sure it won't implement= ICE and SRTP, so interoperability with a WebRTC client is not possible any= way. Dude, where were you when they wrote RFC 5245? The reason they specified th= e re-transmission of un-reliable 18x responses was so that ICE entities wou= ld NOT have to support PRACK :) Having said that, *today* PRACK support may be more common (75%, according = to the SIPit report) than back in those days, and if in addition SRTP manda= tes PRACK support there might not be a real-life problem. > Anyhow, let's remember that the purpose of WebRTC is not the interoperabi= lity with old SIP phones which=20 > implement nothing but plain SIP and plain RTP.=20 I agreed. And, my main concern is not whether endpoints will support PRACK, but havin= g to send new offers just because of forking.=20 Of course, nobody prevents you from doing that, if you want :) > So I don't expect that WebRTC will allow reusing the same local candidate= s in a new PeerConnection just to allow SIP media forking. Well, that's what we have to figure out. And, just for the record: based on what do you make that assumption? Regards, Christer From ibc@aliax.net Sun Oct 30 13:32: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 30DC421F8B78 for ; Sun, 30 Oct 2011 13:32:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.645 X-Spam-Level: X-Spam-Status: No, score=-2.645 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yui3uP5ywuj1 for ; Sun, 30 Oct 2011 13:32: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 7EC8421F8B73 for ; Sun, 30 Oct 2011 13:32:44 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so5279218vcb.31 for ; Sun, 30 Oct 2011 13:32:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.7.12 with SMTP id b12mr2060058vcb.23.1320006763891; Sun, 30 Oct 2011 13:32:43 -0700 (PDT) Received: by 10.220.184.6 with HTTP; Sun, 30 Oct 2011 13:32:43 -0700 (PDT) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A058522357895FC@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05852235717390@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A058522357895FA@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A058522357895FC@ESESSCMS0356.eemea.ericsson.se> Date: Sun, 30 Oct 2011 21:32:43 +0100 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] Media forking solution for SIP interoperability (without a media gateway) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Oct 2011 20:32:45 -0000 2011/10/30 Christer Holmberg : >>> Ok, small correction: you are not allowed to send a new offer before >>> you have received the previous answer in a reliably sent response :) >> >> Ok, PRACK (RFC 3262) dates from 2002, so just add "Require: 100rel" in t= he INVITE and you are done. Of course, if >> the remote SIP peer does not implement PRACK I am sure it won't implemen= t ICE and SRTP, so interoperability with a WebRTC client is not possible an= yway. > > Dude, where were you when they wrote RFC 5245? The reason they specified = the re-transmission of un-reliable 18x responses was so that ICE entities w= ould NOT have to support PRACK :) Sure, but WebRTC is not SIP and must not be designed just in order to interoperate with SIP. > Having said that, *today* PRACK support may be more common (75%, accordin= g to the SIPit report) than back in those days, and if in addition SRTP man= dates PRACK support there might not be a real-life problem. Oh, I didn't know that SRTP mandates PRACK, then we are done :) >> Anyhow, let's remember that the purpose of WebRTC is not the interoperab= ility with old SIP phones which >> implement nothing but plain SIP and plain RTP. > > I agreed. > > And, my main concern is not whether endpoints will support PRACK, but hav= ing to send new offers just because of forking. Of course I prefer not having to use that but, should WebRTC modify PeerConnection specs just for allowing SIP media forking? >> So I don't expect that WebRTC will allow reusing the same local candidat= es in a new PeerConnection just to allow SIP media forking. > > Well, that's what we have to figure out. I would also like to know what non-SIP folks think about this. > And, just for the record: based on what do you make that assumption? Ok: in order to allow SIP media forking, WebRTC should allow reusing the same local candidates in a new PeerConnection (or making a single PeerConnection capable of sending and receiving RTP to/from more than a single remote peer). Remember that WebRTC does not mandate a protocol in-the-wire, so a developer could make a new/custom protocol in which for each "early response containing media" it creates a new PeerConnection. However that does not fit well with SIP. But this is just a SIP issue, not a WebRTC issue. Should PeerConnection become more complex just for those willing to implement SIP (or something that can be mapped to SIP) in WebRTC and interoperate with SIP? I insist: this limitation *just* affects to SIP (due to SIP nature in which a UAC MUST be able to send/receive RTP to different peers using the same local address). Any other protocol implemented on top of WebRTC could avoid this limitation with a proper design. So should WebRTC be conditionated by SIP protocol requirements? I don't think so, regardless the number of SIP folks participating in this WG (I still think WebRTC is something for the Web). So this is the reason of my assumption. Regards. --=20 I=C3=B1aki Baz Castillo From prvs=27757133b=tterriberry@mozilla.com Sun Oct 30 14:00: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 1C6D521F8AC3 for ; Sun, 30 Oct 2011 14:00:12 -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 JYlPr4SBVomu for ; Sun, 30 Oct 2011 14:00:11 -0700 (PDT) Received: from mxip0i.isis.unc.edu (mxip0i.isis.unc.edu [152.2.0.72]) by ietfa.amsl.com (Postfix) with ESMTP id 32BE221F8A4B for ; Sun, 30 Oct 2011 14:00:06 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EANm5rU6sGgRS/2dsb2JhbABDqEeBfoFyAQEEAThAAQULCyEWDwkDAgECAUUTAQcCF4dnsiCJAgSIBpEiE4xS X-IronPort-AV: E=Sophos;i="4.69,426,1315195200"; d="scan'208";a="287645518" Received: from mr1a.isis.unc.edu (HELO smtp.unc.edu) ([172.26.4.82]) by mxip0o.isis.unc.edu with ESMTP; 30 Oct 2011 17:00:06 -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 p9UL03T1008973 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sun, 30 Oct 2011 17:00:05 -0400 (EDT) Message-ID: <4EADBAD3.5020804@mozilla.com> Date: Sun, 30 Oct 2011 14:00: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: <20111024224257.28459.65554.idtracker@ietfa.amsl.com> <6EB8679A-13D5-4AD7-97F2-BC35FC0966F0@acmepacket.com> <2E239D6FCD033C4BAF15F386A979BF51159C32@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF51159D7A@sonusinmail02.sonusnet.com> <4EAAF413.8030501@alvestrand.no> <2E239D6FCD033C4BAF15F386A979BF51159D7B@sonusinmail02.sonusnet.com> <247FFE2C-DB2C-4280-A219-BE1503662F92@acmepacket.com> <4EAB2657.7090609@jesup.org> <4EAC24A2.70401@alvestrand.no> In-Reply-To: <4EAC24A2.70401@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] RTCWeb Forking usecase [was RE: draft-kaplan-rtcweb-sip-interworking-requirements-00] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Oct 2011 21:00:12 -0000 >> I think the most encouraging response I got before on this list was >> that the API should always produce the same list of ICE candidates for >> a given Web browser session. Because of this, all the offers from the I don't think this is possible, depending on what you mean by "web browser session". People's web browsers move around, change which networking device they're using, etc., at any time. At a minimum, you need some interface to raise an error and deal with the fallout when you require this behavior and it can't be provided. The PeerConnection factory/cloning solution could potentially give you that (it could simply fail if it can't use the same ICE candidates anymore). >> WebRTC client would be the same and simultaneous forking can be >> implemented by creating a new peer connection for each answer, >> generating and discarding the offer (since it is the same as the offer >> from the original peer connection in this session) and feeding a new >> answer to it. > I considered it when we discussed this last, but I'm not sure it works. I'm confident it doesn't. Again, external cameras can be plugged in and unplugged, etc., by the user at any time, and these can change the capabilities exposed in the offer. This is also something you have to deal with, if you really rely on "same offer" behavior. > If we support SDES, the offer also contains crypto keys. Reusing crypto > keys for all created connections would be a huge security vulnerability. I'm starting to come to the opinion that we shouldn't support SDES. If we're doing it just for interop with legacy, we'd get better interop with fewer headaches by supporting plain RTP. We'd have a distinction between the two that I could actually explain to users, and less chance of (unnoticed) downgrade attacks. From christer.holmberg@ericsson.com Sun Oct 30 14:39: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 14C2421F8663 for ; Sun, 30 Oct 2011 14:39:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.083 X-Spam-Level: X-Spam-Status: No, score=-6.083 tagged_above=-999 required=5 tests=[AWL=0.216, 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 BcSKqrex0qRK for ; Sun, 30 Oct 2011 14:39:27 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 475B221F85B9 for ; Sun, 30 Oct 2011 14:39:27 -0700 (PDT) X-AuditID: c1b4fb3d-b7c26ae0000035b9-2c-4eadc40d471a Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 31.B9.13753.D04CDAE4; Sun, 30 Oct 2011 22:39:26 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.57]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Sun, 30 Oct 2011 22:39:25 +0100 From: Christer Holmberg To: =?iso-8859-1?Q?=27I=F1aki_Baz_Castillo=27?= Date: Sun, 30 Oct 2011 22:39:24 +0100 Thread-Topic: [rtcweb] Media forking solution for SIP interoperability (without a media gateway) Thread-Index: AcyXQxT4MPLpdNE8T36g3pNqLg6+0wABtXDQ Message-ID: <7F2072F1E0DE894DA4B517B93C6A058522357895FE@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05852235717390@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A058522357895FA@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A058522357895FC@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] Media forking solution for SIP interoperability (without a media gateway) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Oct 2011 21:39:28 -0000 Hi,=20 >> Having said that, *today* PRACK support may be more common (75%, accordi= ng to the SIPit report) than back in those=20 >> days, and if in addition SRTP mandates PRACK support there might not be = a real-life problem. > > Oh, I didn't know that SRTP mandates PRACK, then we are done :) I don't think SRTP as such mandates PRACK. But, whatever media negotiations= , that require reliably sent SDP, you want to do during the early dialog re= quire PRACK. >>> Anyhow, let's remember that the purpose of WebRTC is not the=20 >>> interoperability with old SIP phones which implement nothing but plain = SIP and plain RTP. >> >> I agreed. >> >> And, my main concern is not whether endpoints will support PRACK, but ha= ving to send new offers just because of forking. > > Of course I prefer not having to use that but, should WebRTC modify PeerC= onnection specs just for allowing SIP media forking? WebRTC is not going to modify anything. AFAIK, we will ask W3C to do it, ba= sed on our wishes and requirements. However, it would only be needed if we decide to support parallel forking. = If we choose to only require support of serial forking, you may not have to= create new PeerConnections - if you can modify the remote media parameters= of the existing one. As I've said before, I am personally fine with supporting serial forking, b= ut if we can get parallel forking "for free" that's of course good. >>>> So I don't expect that WebRTC will allow reusing the same local candid= ates in a new PeerConnection just to allow SIP media forking. >>> >>> Well, that's what we have to figure out. >> >> I would also like to know what non-SIP folks think about this. First I think the SIP folks shall agree on what THEY want. Then we'll see w= hether/how it's possible to achieve, and what others think. Regards, Christer From fluffy@cisco.com Sun Oct 30 17:05:17 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22A5C21F8BFB for ; Sun, 30 Oct 2011 17:05:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.343 X-Spam-Level: X-Spam-Status: No, score=-106.343 tagged_above=-999 required=5 tests=[AWL=0.212, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, 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 Y9UND-BUhPwQ for ; Sun, 30 Oct 2011 17:05:16 -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 B4B6521F8BF6 for ; Sun, 30 Oct 2011 17:05:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=553; q=dns/txt; s=iport; t=1320019514; x=1321229114; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=mLbmDc9VcqyQlTwlk8uNx2QUSJmml2AF2xZltKboTG0=; b=XRU7ptwk1ArxFZP+Tph5cYvyD545JvyRGZKpES5AB610H08zZ+89yOPJ S0v57jgTu+CrQ6pry74IRzaT4xcX6NC3amlbUkXuzRT5uDwUhuefcAip9 h6NTLzoyzcp4aFR2KUcbbeMOuNuCfXp9yjlZXejuJT99aRhNXbesmGxHF k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak0GAN7krU6rRDoG/2dsb2JhbABDJqkagQWBcgEBAQECARIBZgULC0ZXBi4Hh2CVSAGdG4ghYQSIBowIkX4 X-IronPort-AV: E=Sophos;i="4.69,428,1315180800"; d="scan'208";a="10119568" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 31 Oct 2011 00:05:14 +0000 Received: from sjc-vpn2-1232.cisco.com (sjc-vpn2-1232.cisco.com [10.21.116.208]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p9V05Ds1024727; Mon, 31 Oct 2011 00:05:14 GMT Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Cullen Jennings In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852235717390@ESESSCMS0356.eemea.ericsson.se> Date: Sun, 30 Oct 2011 12:41:24 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <3BBCA56E-CA6E-4585-8EBB-ED6EDFED789F@cisco.com> References: <7F2072F1E0DE894DA4B517B93C6A05852235717390@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1251.1) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Media forking solution for SIP interoperability (without a media gateway) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 00:05:17 -0000 On Oct 30, 2011, at 9:58 , Christer Holmberg wrote: > In my opinion a better solution is to create a new PeerConnection for = every new early dialog, which uses the *same* address/candidate = parameters as the "parent" PeerConnection.=20 Hmm we should talk about this - I have a hard time seeing how that is = going to work. I was working on the assumption that PeerConnection = could deal with more than one offer/answer pair at a time. Given the = current WebRTC API and something like ROAP - it seems like that should = just work.=20 From fluffy@cisco.com Sun Oct 30 17:05:17 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FEC621F8BF6 for ; Sun, 30 Oct 2011 17:05:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.198 X-Spam-Level: X-Spam-Status: No, score=-106.198 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, 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 JSgEpnKVNkqY for ; Sun, 30 Oct 2011 17:05:17 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 929B321F8BEC for ; Sun, 30 Oct 2011 17:05:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=653; q=dns/txt; s=iport; t=1320019516; x=1321229116; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=ZPckN53NGylVUwUK/EbcBCij2T5zh4aquW/FpFdbR6U=; b=DaNw7uhajxP0rrEUSC5/q/9lpM7mIVfykXLOOFgca8cBLYyhC0pXWZIb n4Eby9goaePl7iT5+QGC/8rlOFCpfZ3eB6FFIADnt83B8sh6WEyQQ9++M FrqPTVi++q9BD9DJqlmH419B1mC6qPJY8gUt5kfwk9pqRoCB3rB5vuxq+ c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak0GANHlrU6rRDoG/2dsb2JhbABDJqkagQWBcgEBAQECARIBZhALRlcGNYdglU8BnRuIIWEEiAaMCJF+ X-IronPort-AV: E=Sophos;i="4.69,428,1315180800"; d="scan'208";a="11262269" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 31 Oct 2011 00:05:16 +0000 Received: from sjc-vpn2-1232.cisco.com (sjc-vpn2-1232.cisco.com [10.21.116.208]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p9V05Ds4024727; Mon, 31 Oct 2011 00:05:16 GMT Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Cullen Jennings In-Reply-To: Date: Sun, 30 Oct 2011 14:46:47 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <5DC01631-24B5-43F3-96E3-9DDBACB7783C@cisco.com> References: <4EA9A899.4020804@alvestrand.no> To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= X-Mailer: Apple Mail (2.1251.1) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] draft-sipdoc-rtcweb-open-wire-protocol-00 (Open In-The-Wire Protocol for RTC-Web) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 00:05:17 -0000 On Oct 27, 2011, at 13:13 , I=F1aki Baz Castillo wrote: >=20 > Sorry, our fault. I didn't aware about the draft naming conventions. No worry - it's more of a guideline than a rule. If you submit a new = version with the a name like=20 draft-castillo-rtcweb-open-wire-protocol-00=20 and send me an email reminding me, the chairs will get the new draft = marked as replacing draft-sipdoc-rtcweb-open-wire-protocol-00. = Unfortunately you will need to wait till Nov 13 before you will be able = to submit as it will be a -00 draft. =20 In the meantime, people can just use the existing draft.=20 Cullen =20= From fluffy@cisco.com Sun Oct 30 17:05:18 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C526511E8091 for ; Sun, 30 Oct 2011 17:05:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.35 X-Spam-Level: X-Spam-Status: No, score=-106.35 tagged_above=-999 required=5 tests=[AWL=0.205, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, 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 LvlPUkHpbPwB for ; Sun, 30 Oct 2011 17:05:18 -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 12BF921F8BF9 for ; Sun, 30 Oct 2011 17:05:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=3139; q=dns/txt; s=iport; t=1320019517; x=1321229117; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=MNxPW1IPN9QRDrsq+/gnHyCZmLTbPa/MnbzVOEIakBw=; b=XCGyJGL2r+p4c2GbnH1j6rKMeM7EqPxpClc6Xd6mgdC7mkUgCKOdzxOM 7yTmxE78722j/UdNXgIBOG6/dvtviAzw3wpoecnUqdoBh1ggfq0kzCXVu da0pNNPoizpWkBbVSh3PJ1J+MTuUgaY/2VMXPFobnHAIar5R+Bu3mIHXe M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak4GANHlrU6rRDoG/2dsb2JhbABDJqkagQWBcgEBAQECAQEBAQ8BJzQLEAsOCi4nMAYTIodgCJVHAZ0XBIghYQSIBowIkX4 X-IronPort-AV: E=Sophos;i="4.69,428,1315180800"; d="scan'208";a="11296201" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 31 Oct 2011 00:05:16 +0000 Received: from sjc-vpn2-1232.cisco.com (sjc-vpn2-1232.cisco.com [10.21.116.208]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p9V05Ds5024727; Mon, 31 Oct 2011 00:05:16 GMT Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: Date: Sun, 30 Oct 2011 14:51:05 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4EA5EA46.1010803@jesup.org> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1251.1) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] draft-jesup-rtcweb-data-00 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: Mon, 31 Oct 2011 00:05:18 -0000 +1=20 On Oct 25, 2011, at 9:31 , Hadriel Kaplan wrote: >=20 > On Oct 25, 2011, at 10:20 AM, Eric Rescorla wrote: >=20 >> On Tue, Oct 25, 2011 at 1:02 AM, Hadriel Kaplan = wrote: >>>=20 >>> Req. 8: The data stream transport protocol MUST NOT encode IP = addresses inside its protocol fields; doing so reveals potentially = private information, and leads to failure if the address is depended = upon. >>=20 >> I don't really understand what this means. In general, the peer has >> access to your IP address >> information from ICE. >=20 > =46rom a privacy perspective: if a person uses a Web-site designed = with privacy/anonymity in mind (e.g., battered-spouse forum), then the = site would relay your media-plane stuff through a type of TURN server = that does ICE itself both ways. But if the SCTP layer on top of UDP = encodes your local IP using one of the optional SCTP fields in RFC 4960 = or 5061, then you lose that anonymity. Since the SCTP layer is built = into the Browser and not under control of the Javascript, a site can't = prevent it from revealing that info. >=20 > =46rom a failure perspective: if the SCTP layer on top of UDP encodes = local or remote IP addresses using an SCTP field, presumably it does so = for some purpose. Since history has shown that relying on embedded IP = Addresses for anything is prone to failure due to the proliferation of = NATs, double-NATs, v4-v6 NATs, etc., then we shouldn't want SCTP to rely = on such being useful. The best way to make sure it can't rely on them, = is not to use any to begin with. :) >=20 >=20 >>> Req. 10: The data stream packet format/encoding MUST be such that it = is impossible for a malicious Javascript to generate an application = message crafted such that it could be interpreted as a native protocol = over UDP - such as UPnP, RTP, SNMP, STUN, etc. >>=20 >> I'm not sure this is really an issue the way you raise it. It's clear >> that you shouldn't be able to >> generate messages that appear to be STUN or RTP but that's necessary >> for demux to work >> right. >=20 > Yes I didn't mean to imply it would be hard to satisfy the = requirement, or not necessary for other reasons. I suggested it because = some people wanted to do raw UDP a while ago and this requirement's = there to show we can't do raw UDP. >=20 >=20 >> However, given that the other side has consented, I don't see >> that confusion with >> other protocols being an issue. The kind of intercepting proxies that >> we found for >> HTTP don't seem to be a feature of the UDP environment. >=20 >=20 > I don't know that intercepting middleboxes don't exist for any/all = random UDP-based protocol. I wouldn't be surprised to find there are = for DNS, for example. But you're talking about for ever, not just now. = I don't have a crystal ball. Regardless, I would expect this = requirement to be achieved easily, no? >=20 > -hadriel >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From fluffy@cisco.com Sun Oct 30 17:05: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 4EAD511E8091 for ; Sun, 30 Oct 2011 17:05:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.227 X-Spam-Level: X-Spam-Status: No, score=-106.227 tagged_above=-999 required=5 tests=[AWL=0.072, 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 QhA5f7M2uDlk for ; Sun, 30 Oct 2011 17:05:18 -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 B90F711E8090 for ; Sun, 30 Oct 2011 17:05:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=1917; q=dns/txt; s=iport; t=1320019518; x=1321229118; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=v7s0FALE3XPE2tcWIPn/ccvxpxiNdo/CcVsld/oBfks=; b=XtICo+CSY6EBKdises1SLm2pn7sKZOX5KvvoM1KBSvRODMomWq0Yyzwl CvYQ4Vv6NpOjgrQOzt3MjqIxFK1Ai7SzR0eOYKiuk+UcMqiMe5Jc3RfbE nJZHnWeJCOUv4bo+PkoHUtxu4pV8/nJOgBjkHcWwyJZ40RL8l+jFqTbXD Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAN7krU6rRDoG/2dsb2JhbABDqUCBBYFyAQEBAQIBAQEBDwFbCwULC0YnMAYTIodgCJVAAZ0XBIghYQSIBowIkX4 X-IronPort-AV: E=Sophos;i="4.69,428,1315180800"; d="scan'208";a="10119579" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 31 Oct 2011 00:05:18 +0000 Received: from sjc-vpn2-1232.cisco.com (sjc-vpn2-1232.cisco.com [10.21.116.208]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p9V05Ds8024727; Mon, 31 Oct 2011 00:05:18 GMT Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Cullen Jennings In-Reply-To: Date: Sun, 30 Oct 2011 15:06:39 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= X-Mailer: Apple Mail (2.1251.1) Cc: "" Subject: Re: [rtcweb] Does ROAP mandate the on-the-wire format? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 00:05:19 -0000 Let's say the RTCWeb API passed JSON objects like the ones in ROAP in = and out of the PeerConnection object. (I will be arguing that is one = thing we should consider). At that oping you could write the SIP over = webesockets in JS in the browsers. You might even find some useful info = on how to do the mapping in draft-jennings-rtcweb-signaling-gateway-01 I think there has been a lot of talking past each other on this. In some = cases ROAP over webesockets might be a protocol used to speak directly = to a ROAP to SIP signaling GW. So I view ROAP over a well defined = transport to be a on the wire protocol but certainly not the only on the = wire protocol. Just one that some systems could use.=20 On the other hand, if one does SIP in JS (or the browser), that works = too.=20 Hope that helps clarify.=20 On Oct 21, 2011, at 10:43 , I=F1aki Baz Castillo wrote: > 2011/10/21 Hadriel Kaplan : >> Well since the Browser will never know whether ROAP is really to = another Browser vs. the Javascript, then yes it could be used that way. = (it will probably be painful, but possible) >=20 > The question comes because my wire signaling implementation (SIP over > WebSocket) is that: SIP. So the JS sends and receives pure SIP > messages (with SDP) over the wire. >=20 > If ROAP includes a real SDP (as the draft currently states) then I'm > done as I just need to create a ROAP object (in JavaScript) and pass > it the received SDP string (and also set some session status > variables, which can be easily mapped from the received SIP > request/response). >=20 > Hope I'm right and I don't have to drop the work of long months. >=20 > Regards. >=20 > --=20 > I=F1aki Baz Castillo > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From fluffy@cisco.com Sun Oct 30 17: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 8F6BD11E8099 for ; Sun, 30 Oct 2011 17:05:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.379 X-Spam-Level: X-Spam-Status: No, score=-106.379 tagged_above=-999 required=5 tests=[AWL=0.220, 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 XKBaSp0r9QaD for ; Sun, 30 Oct 2011 17:05:54 -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 171771F0C49 for ; Sun, 30 Oct 2011 17:05:54 -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=1320019554; x=1321229154; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=FMyeobc+W244jWTZOoeyaSZfX+70Q+d6tGG8/BLrtgU=; b=iEiC+PCyjxX3d77CkJIA6b7oqMRgZaR2VEfkj4RXiQEUb2G/fqj2DaKQ mcRG0VCMKuZpuHzL2QBXoOvh35wdvVQbaXv4jL2hpqJNApKkkSW+nSNRU zqz0Zs9XpxsiMXlqzMKxSl3U4xTHm+FIPBIP6X7b4ljdmZh6NYTo3TRVm c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAEnmrU6rRDoG/2dsb2JhbABDqUCBBYFyAQEBAQIBAQEBDwEnNAsFCwtGJzAGEyKHYAiVQAGdFwSIIWEEiAaMCJF/ X-IronPort-AV: E=Sophos;i="4.69,428,1315180800"; d="scan'208";a="11283009" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 31 Oct 2011 00:05:53 +0000 Received: from sjc-vpn2-1232.cisco.com (sjc-vpn2-1232.cisco.com [10.21.116.208]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p9V05Ds9024727; Mon, 31 Oct 2011 00:05:52 GMT Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <4EAC6BF4.2000604@alvestrand.no> Date: Sun, 30 Oct 2011 17:05:52 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4EAC6BF4.2000604@alvestrand.no> To: Harald Alvestrand X-Mailer: Apple Mail (2.1251.1) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] URI schemes for TURN and STUN X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 00:05:54 -0000 On Oct 29, 2011, at 15:11 , Harald Alvestrand wrote: > Hi, > being in the process of scanning all the drafts with -rtcweb- in them, = I came across these two: >=20 > draft-nandakumar-rtcweb-stun-uri-00.txt > draft-nandakumar-rtcweb-turn-uri-00.txt >=20 > Just three comments: >=20 > - I think it's not RTCWEB business. They should be pointed at the home = group for STUN/ICE. I suspect the point of putting rtcweb in the name was so this group of = people would find them. I doubt you would have noticed them had they = been named behave. That said, I did ask the authors to send emails about = them to the behave WG. So I get your point, but I think they were meant = for this group to read. I know I would not have noticed them had they = been in behave.=20 > - I do not think it's appropriate to use "turn" and "turns" for = indicating transport. Polluting the URI namespace with more = configuration parameters in the form of trailing "s" is a Bad Thing. It's a bit more complicated than that - some time this is the right = thing, sometimes not. I have no idea of the case here but just saying = HTTPS was a Bad Thing seems a bit over simplistic. Anyways - I'd have to = think about what we need to accomplish, what the use cases are and try = to sort this out. I'm not arguing for or against turns - I'd want to see = a bit more info before getting into that.=20 > - Passing passwords in URIs is generally a Bad Practice. If you really = want this in this case, please explore the implications thereof fully in = the Security Considerations section. Agree it is not good. Questions is, is it any worse than passing them JS = downloaded over HTTP or HTTPS? I note that is is what another document I = am co-author of is suggesting so I'm a bit sensitive about how that = conversation goes. I don't have real strong feeling about if it should = be in the TURN URI or not but I have pretty strong feelings that it is = either going to be in the URI or sitting in the same HTTP doc right = beside the URI with all the same "Bad Practice" issues either way.=20 >=20 > Good luck with the discussion (elsewhere)! >=20 > Harald >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From fluffy@cisco.com Sun Oct 30 17: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 535FF11E8094 for ; Sun, 30 Oct 2011 17:06:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.384 X-Spam-Level: X-Spam-Status: No, score=-106.384 tagged_above=-999 required=5 tests=[AWL=0.215, 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 lLs+KeDvoGcb for ; Sun, 30 Oct 2011 17:06:02 -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 E95C311E808F for ; Sun, 30 Oct 2011 17:06:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=824; q=dns/txt; s=iport; t=1320019563; x=1321229163; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=QPudcDRhfAaAOdGbruHXp4qckl256lX4ZpQNuyV9Ju4=; b=BhqmnppVrSHsLvCijHwXmrqgtA2GrRxDquauFLyNIC52mSO2nEgOLDOp gt37a3PJLfM0sfOwd4RFfTuEu9UQpNaGdmzgIDJjLPmrjP9ehBlZJwAaF okZoQ9Z9npSCj7syQnaDWcehLUYqySqQFFK0b1CLD8rJ0XMdkza1O4XoS E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EANHlrU6rRDoG/2dsb2JhbABDqUCBBYFyAQEBAQIBEgFmBQsLDjhXBjWHYJVPAZ0biCFhBIgGjAiRfw X-IronPort-AV: E=Sophos;i="4.69,428,1315180800"; d="scan'208";a="11262337" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 31 Oct 2011 00:06:02 +0000 Received: from sjc-vpn2-1232.cisco.com (sjc-vpn2-1232.cisco.com [10.21.116.208]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p9V05DsA024727; Mon, 31 Oct 2011 00:06:02 GMT Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=windows-1252 From: Cullen Jennings In-Reply-To: <715A5714-B44A-4E1D-AC2F-7CC2EAD42D0F@acmepacket.com> Date: Sun, 30 Oct 2011 17:06:02 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <76E0CAF7-E66C-467D-A518-59143A663E31@cisco.com> References: <715A5714-B44A-4E1D-AC2F-7CC2EAD42D0F@acmepacket.com> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1251.1) Cc: "" Subject: Re: [rtcweb] draft-sipdoc-rtcweb-open-wire-protocol-00 (Open In-The-Wire Protocol for RTC-Web) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 00:06:03 -0000 On Oct 27, 2011, at 11:09 , Hadriel Kaplan wrote: > One process-based concern about making requirement 4 a WG requirement: = you can't actually do SIP over Websocket with a "pure SIP network" until = we get Websocket into a SIP-extending RFC as a new transport type. I = wouldn't want to hold up WebRTC docs becoming RFCs, waiting for the = DISPATCH and probable SIPCORE process to make a websocket SIP transport = into a RFC. I *want* to add Websocket as a SIP transport type, but it's = not actually as trivial as one would think. One random idea =85 say that websockets was a protocol you could use to = connect to a TURN server and then the TURN sever could send UPD or TCP = SIP. That might be easier to deploy =85 not sure this is a good idea =85 = just a random idea I thought I would mention.=20 From harald@alvestrand.no Sun Oct 30 18:08: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 D479A1F0C54 for ; Sun, 30 Oct 2011 18:08:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.561 X-Spam-Level: X-Spam-Status: No, score=-110.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 i4V6yZo2trkO for ; Sun, 30 Oct 2011 18:08:36 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 33EB31F0C3E for ; Sun, 30 Oct 2011 18:08:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 43FC639E088; Mon, 31 Oct 2011 02:08:34 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2e2bXAC0+AOW; Mon, 31 Oct 2011 02:08:33 +0100 (CET) Received: from [192.168.6.21] (unknown [24.104.44.194]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 2969239E038; Mon, 31 Oct 2011 02:08:32 +0100 (CET) Message-ID: <4EADF511.2040403@alvestrand.no> Date: Sun, 30 Oct 2011 18:08:33 -0700 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: Cullen Jennings References: <7F2072F1E0DE894DA4B517B93C6A05852235717390@ESESSCMS0356.eemea.ericsson.se> <3BBCA56E-CA6E-4585-8EBB-ED6EDFED789F@cisco.com> In-Reply-To: <3BBCA56E-CA6E-4585-8EBB-ED6EDFED789F@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Media forking solution for SIP interoperability (without a media gateway) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 01:08:36 -0000 On 10/30/2011 11:41 AM, Cullen Jennings wrote: > On Oct 30, 2011, at 9:58 , Christer Holmberg wrote: > >> In my opinion a better solution is to create a new PeerConnection for every new early dialog, which uses the *same* address/candidate parameters as the "parent" PeerConnection. > Hmm we should talk about this - I have a hard time seeing how that is going to work. I was working on the assumption that PeerConnection could deal with more than one offer/answer pair at a time. Given the current WebRTC API and something like ROAP - it seems like that should just work. I think having a single PeerConnection object send media to multiple peers at the same time breaks the model we've been working from. It may be reasonable to give a PeerConnection the ability to switch from one remote peer to another remote peer (to support 180-like things), but I don't think it's reasonable to have it connected to multiple remote peers. So if we support real forking, we'll have to create multiple PeerConnections to do that. From duerst@it.aoyama.ac.jp Sun Oct 30 20: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 1F7EA11E80B1 for ; Sun, 30 Oct 2011 20:27:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.43 X-Spam-Level: X-Spam-Status: No, score=-99.43 tagged_above=-999 required=5 tests=[AWL=0.360, 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 eg9IQ+WU5ySF for ; Sun, 30 Oct 2011 20:27:16 -0700 (PDT) Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id 29AFE11E80AF for ; Sun, 30 Oct 2011 20:27:16 -0700 (PDT) Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id p9V3R25V023465 for ; Mon, 31 Oct 2011 12:27:02 +0900 Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 7395_16c4_33018c7a_0370_11e1_8351_001d096c566a; Mon, 31 Oct 2011 12:27:02 +0900 Received: from [IPv6:::1] ([133.2.210.1]:50548) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Mon, 31 Oct 2011 12:27:02 +0900 Message-ID: <4EAE157F.5020901@it.aoyama.ac.jp> Date: Mon, 31 Oct 2011 12:26:55 +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: Harald Alvestrand References: <4EAC6BF4.2000604@alvestrand.no> <4EAC8AE0.3020307@acm.org> <4EACD558.1050003@alvestrand.no> In-Reply-To: <4EACD558.1050003@alvestrand.no> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: Keith Moore , Ned Freed , Behave WG , "rtcweb@ietf.org" Subject: Re: [rtcweb] URI schemes for TURN and STUN X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 03:27:17 -0000 For the http vs. https case, there is a very good answer from Roy Fielding at http://lists.w3.org/Archives/Public/www-tag/2006Mar/0040.html In essence, not distinguishing the two schemes would mean either additional roundtrips (assuming http is the more frequent one) or exposition of data on the network that was supposed to be private. Regards, Martin. On 2011/10/30 13:40, Harald Alvestrand wrote: > On 10/29/2011 04:23 PM, Marc Petit-Huguenin wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 10/29/2011 03:36 PM, Iñaki Baz Castillo wrote: >>> 2011/10/29 Harald Alvestrand: >>>> - I do not think it's appropriate to use "turn" and "turns" for >>>> indicating >>>> transport. Polluting the URI namespace with more configuration >>>> parameters in >>>> the form of trailing "s" is a Bad Thing. >>> But there should be some way to indicate that a TURN server listens in >>> TLS, right? >>> >> We should continue this discussion in BEHAVE, but I would like to ask >> the OP to >> send a pointer on the RFC or discussion that says that using a >> trailing "s" to >> indicate security is a bad thing. > I'll have to forward this question to the apps ADs of a few years ago > about whether there's documentation for it. It does not seem to have > been captured in an RFC that I can find; discussion was in the > ~2000-2005 timeframe. > > The short version, from memory: Doing "s" locks you into one and exactly > one security scheme, and prevents you from saying anything about the > requisite parameters for that scheme, while using AUTH parameters such > as POP or in-band negotiation such as IMAP are much more flexible > approaches. > > >> Thanks. >> >> - -- Marc Petit-Huguenin >> Personal email: marc@petit-huguenin.org >> Professional email: petithug@acm.org >> Blog: http://blog.marc.petit-huguenin.org >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.11 (GNU/Linux) >> >> iEYEARECAAYFAk6sit4ACgkQ9RoMZyVa61dhpgCfZv+XuDhAljo3N0s33zbh6l0E >> aWAAmwUP2mvcZiY9BLB5BAsjoe6OULMl >> =yx3i >> -----END PGP SIGNATURE----- >> > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From duerst@it.aoyama.ac.jp Sun Oct 30 20:30: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 C16FF11E80AD for ; Sun, 30 Oct 2011 20:30:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.475 X-Spam-Level: X-Spam-Status: No, score=-99.475 tagged_above=-999 required=5 tests=[AWL=0.315, 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 cEvQljSYqqMp for ; Sun, 30 Oct 2011 20:30:12 -0700 (PDT) Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id 25E5711E8085 for ; Sun, 30 Oct 2011 20:30:12 -0700 (PDT) Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id p9V3UBBW025897 for ; Mon, 31 Oct 2011 12:30:11 +0900 Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 7395_16ea_a3accd4a_0370_11e1_8351_001d096c566a; Mon, 31 Oct 2011 12:30:11 +0900 Received: from [IPv6:::1] ([133.2.210.1]:42781) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Mon, 31 Oct 2011 12:30:12 +0900 Message-ID: <4EAE163C.4070603@it.aoyama.ac.jp> Date: Mon, 31 Oct 2011 12:30:04 +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: Harald Alvestrand References: <4EAC6BF4.2000604@alvestrand.no> In-Reply-To: <4EAC6BF4.2000604@alvestrand.no> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] URI schemes for TURN and STUN X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 03:30:12 -0000 On 2011/10/30 6:11, Harald Alvestrand wrote: > Hi, > being in the process of scanning all the drafts with -rtcweb- in them, I > came across these two: > > draft-nandakumar-rtcweb-stun-uri-00.txt > draft-nandakumar-rtcweb-turn-uri-00.txt > > Just three comments: > > - I think it's not RTCWEB business. They should be pointed at the home > group for STUN/ICE. For TURN, there's already http://tools.ietf.org/html/draft-petithuguenin-behave-turn-uri-bis-04. Regards, Martin. > - I do not think it's appropriate to use "turn" and "turns" for > indicating transport. Polluting the URI namespace with more > configuration parameters in the form of trailing "s" is a Bad Thing. > - Passing passwords in URIs is generally a Bad Practice. If you really > want this in this case, please explore the implications thereof fully in > the Security Considerations section. > > Good luck with the discussion (elsewhere)! > > Harald > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From roman@telurix.com Sun Oct 30 20:30: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 C8B7C1F0C68 for ; Sun, 30 Oct 2011 20:30:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.905 X-Spam-Level: X-Spam-Status: No, score=-2.905 tagged_above=-999 required=5 tests=[AWL=0.071, 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 3jQHLmphhVWe for ; Sun, 30 Oct 2011 20:30: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 416FE1F0C63 for ; Sun, 30 Oct 2011 20:30:46 -0700 (PDT) Received: by ywt2 with SMTP id 2so6555084ywt.31 for ; Sun, 30 Oct 2011 20:30:45 -0700 (PDT) Received: by 10.236.145.37 with SMTP id o25mr6612853yhj.31.1320031845903; Sun, 30 Oct 2011 20:30:45 -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 i50sm15690997yhk.11.2011.10.30.20.30.45 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 30 Oct 2011 20:30:45 -0700 (PDT) Received: by ywt2 with SMTP id 2so6555060ywt.31 for ; Sun, 30 Oct 2011 20:30:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.62.136 with SMTP id y8mr20249887pbr.87.1320031844386; Sun, 30 Oct 2011 20:30:44 -0700 (PDT) Received: by 10.68.62.170 with HTTP; Sun, 30 Oct 2011 20:30:44 -0700 (PDT) In-Reply-To: <76E0CAF7-E66C-467D-A518-59143A663E31@cisco.com> References: <715A5714-B44A-4E1D-AC2F-7CC2EAD42D0F@acmepacket.com> <76E0CAF7-E66C-467D-A518-59143A663E31@cisco.com> Date: Sun, 30 Oct 2011 23:30:44 -0400 Message-ID: From: Roman Shpount To: Cullen Jennings Content-Type: multipart/alternative; boundary=bcaec53961a22d48da04b08fddea Cc: "" Subject: Re: [rtcweb] draft-sipdoc-rtcweb-open-wire-protocol-00 (Open In-The-Wire Protocol for RTC-Web) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 03:30:46 -0000 --bcaec53961a22d48da04b08fddea Content-Type: text/plain; charset=ISO-8859-1 On Sun, Oct 30, 2011 at 8:06 PM, Cullen Jennings wrote: > > On Oct 27, 2011, at 11:09 , Hadriel Kaplan wrote: > > > One process-based concern about making requirement 4 a WG requirement: > you can't actually do SIP over Websocket with a "pure SIP network" until we > get Websocket into a SIP-extending RFC as a new transport type. I wouldn't > want to hold up WebRTC docs becoming RFCs, waiting for the DISPATCH and > probable SIPCORE process to make a websocket SIP transport into a RFC. I > *want* to add Websocket as a SIP transport type, but it's not actually as > trivial as one would think. > > I think a better idea would be to create a new type of server which works as a proxy between websocket and arbitrary TCP/UDP type connection. This way we don't need to break TURN servers to implement this. Proposing something like this obviously outside of scope of WebRTC, and it also has some interesting security issues (how do we proxy websocket to TLS socket for SIPS?). _____________ Roman Shpount --bcaec53961a22d48da04b08fddea Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sun, Oct 30, 2011 at 8:06 P= M, Cullen Jennings <fluffy@cisco.com> wrote:

On Oct 27, 2011, at 11:09 , Hadriel Kaplan wrote:

> One process-based concern about making requirement 4 a WG requirement:= you can't actually do SIP over Websocket with a "pure SIP network= " until we get Websocket into a SIP-extending RFC as a new transport t= ype. =A0I wouldn't want to hold up WebRTC docs becoming RFCs, waiting f= or the DISPATCH and probable SIPCORE process to make a websocket SIP transp= ort into a RFC. =A0I *want* to add Websocket as a SIP transport type, but i= t's not actually as trivial as one would think.


I think a better idea would be to create a new t= ype of server which works as a proxy between websocket and arbitrary TCP/UD= P type connection. This way we don't need to break TURN servers to impl= ement this. Proposing something like this obviously outside of scope of Web= RTC, and it also has some interesting security issues (how do we proxy webs= ocket to TLS socket for SIPS?).
_____________
Roman Shpount

--bcaec53961a22d48da04b08fddea-- From internet-drafts@ietf.org Sun Oct 30 21:56: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 EF0C521F8BB1; Sun, 30 Oct 2011 21:56:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.564 X-Spam-Level: X-Spam-Status: No, score=-102.564 tagged_above=-999 required=5 tests=[AWL=0.035, 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 6kRBdo7moVY7; Sun, 30 Oct 2011 21:56:47 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7395621F8BA4; Sun, 30 Oct 2011 21:56:47 -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.62 Message-ID: <20111031045647.29130.54659.idtracker@ietfa.amsl.com> Date: Sun, 30 Oct 2011 21:56:47 -0700 Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-security-01.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 04:56:48 -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-01.txt Pages : 36 Date : 2011-10-30 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-01.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-01.txt From ekr@rtfm.com Sun Oct 30 21: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 74D2F21F8C79 for ; Sun, 30 Oct 2011 21:57:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.961 X-Spam-Level: X-Spam-Status: No, score=-102.961 tagged_above=-999 required=5 tests=[AWL=0.016, 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 LohmnaMTOYbc for ; Sun, 30 Oct 2011 21:57:47 -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 E2D6721F8C73 for ; Sun, 30 Oct 2011 21:57:46 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so5433823vcb.31 for ; Sun, 30 Oct 2011 21:57:46 -0700 (PDT) Received: by 10.220.147.134 with SMTP id l6mr2215004vcv.21.1320037066286; Sun, 30 Oct 2011 21:57:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.118.132 with HTTP; Sun, 30 Oct 2011 21:57:05 -0700 (PDT) From: Eric Rescorla Date: Sun, 30 Oct 2011 21:57:05 -0700 Message-ID: To: rtcweb@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [rtcweb] System security draft X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 04:57:47 -0000 Per the chairs request for submissions, I've prepared a proposed system security draft. For convenience, I've added it as an appendix to the threat model document, which has been somewhat updated but is largely unchanged. The proposal itself is clearly separated in Appendix A. There are definitely still some serious rough edges here and a bunch of pieces that are flat-out incomplete, but I hope it's clear the direction I'm trying to go. -Ekr From bernard_aboba@hotmail.com Sun Oct 30 22:26: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 6728221F8C67 for ; Sun, 30 Oct 2011 22:26:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.431 X-Spam-Level: X-Spam-Status: No, score=-102.431 tagged_above=-999 required=5 tests=[AWL=0.167, 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 ZH+JnsWr31P7 for ; Sun, 30 Oct 2011 22:26:36 -0700 (PDT) Received: from blu0-omc1-s14.blu0.hotmail.com (blu0-omc1-s14.blu0.hotmail.com [65.55.116.25]) by ietfa.amsl.com (Postfix) with ESMTP id 6E32421F8C84 for ; Sun, 30 Oct 2011 22:26:36 -0700 (PDT) Received: from BLU152-W48 ([65.55.116.8]) by blu0-omc1-s14.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 30 Oct 2011 22:26:31 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_99b025ff-76a3-490d-bf1f-4e53728348cc_" X-Originating-IP: [24.17.217.162] From: Bernard Aboba To: Date: Sun, 30 Oct 2011 22:26:30 -0700 Importance: Normal In-Reply-To: <4EAE163C.4070603@it.aoyama.ac.jp> References: <4EAC6BF4.2000604@alvestrand.no>, <4EAE163C.4070603@it.aoyama.ac.jp> MIME-Version: 1.0 X-OriginalArrivalTime: 31 Oct 2011 05:26:31.0740 (UTC) FILETIME=[A5F547C0:01CC978D] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] URI schemes for TURN and STUN X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 05:26:38 -0000 --_99b025ff-76a3-490d-bf1f-4e53728348cc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [BA] Agree with Harald here. These items are (at best) tangential and bet= ter handled (or discarded) elsewhere.=20 > - I do not think it's appropriate to use "turn" and "turns" for > indicating transport. Polluting the URI namespace with more > configuration parameters in the form of trailing "s" is a Bad Thing. > - Passing passwords in URIs is generally a Bad Practice. If you really > want this in this case=2C please explore the implications thereof fully i= n > the Security Considerations section. > > Good luck with the discussion (elsewhere)! > > Harald = --_99b025ff-76a3-490d-bf1f-4e53728348cc_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
[BA] Agree with Harald here. =3B =3B These items are (at best) tang= ential and better handled (or discarded) elsewhere.

>=3B - I= do not think it's appropriate to use "turn" and "turns" for
>=3B indi= cating transport. Polluting the URI namespace with more
>=3B configura= tion parameters in the form of trailing "s" is a Bad Thing.
>=3B - Pas= sing passwords in URIs is generally a Bad Practice. If you really
>=3B= want this in this case=2C please explore the implications thereof fully in=
>=3B the Security Considerations section.
>=3B
>=3B Good lu= ck with the discussion (elsewhere)!
>=3B
>=3B Harald

= --_99b025ff-76a3-490d-bf1f-4e53728348cc_-- From bernard_aboba@hotmail.com Sun Oct 30 23:38: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 3405421F8CC0 for ; Sun, 30 Oct 2011 23:38:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.441 X-Spam-Level: X-Spam-Status: No, score=-102.441 tagged_above=-999 required=5 tests=[AWL=0.157, 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 R82xGL5XKjiU for ; Sun, 30 Oct 2011 23:38:00 -0700 (PDT) Received: from blu0-omc3-s13.blu0.hotmail.com (blu0-omc3-s13.blu0.hotmail.com [65.55.116.88]) by ietfa.amsl.com (Postfix) with ESMTP id C496F21F8CBC for ; Sun, 30 Oct 2011 23:37:59 -0700 (PDT) Received: from BLU152-W11 ([65.55.116.73]) by blu0-omc3-s13.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 30 Oct 2011 23:37:55 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_d26c6e6b-f312-4cef-be01-318f0f5a4c1c_" X-Originating-IP: [24.17.217.162] From: Bernard Aboba To: Date: Sun, 30 Oct 2011 23:37:54 -0700 Importance: Normal In-Reply-To: <20111031045647.29130.54659.idtracker@ietfa.amsl.com> References: <20111031045647.29130.54659.idtracker@ietfa.amsl.com> MIME-Version: 1.0 X-OriginalArrivalTime: 31 Oct 2011 06:37:55.0522 (UTC) FILETIME=[9F4A8A20:01CC9797] Subject: [rtcweb] Review of draft-ietf-rtcweb-security-01.txt (part I) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 06:38:01 -0000 --_d26c6e6b-f312-4cef-be01-318f0f5a4c1c_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Section 1 [BA] In addition to introducing the threat model=2C I would suggest that th= is section reference the Use Case and Overview documents=2C as well as prov= iding an overview of the rest of the document. =20 Section 4.1 In order for the user to make an intelligent decision about whether to allow a call (and hence his camera and microphone input to be routed somewhere)=2C he must understand either who is requesting access=2C where the media is going=2C or both. So=2C for instance=2C one might imagine that at the t= ime access to camera and microphone is requested=2C the user is shown a dialog that says "site X has requested access to camera and microphone=2C yes or no" (though note that this type of in-flow interface violates one of the guidelines in Section 3). The user's decision will of course be based on his opinion of Site X. However=2C as discussed below=2C this is a complicated concept. [BA] I would suggest that this paragraph needs to be restructured. =20 The question of "camera and microphone input" is a device access question= =2C that relates to "who is requesting access"=2C whereas "allowing a call... t= o be routed somewhere" is relevant to "where the media is going."=20 While the last two sentences of the paragraph relate to the device access q= uestion=2C the media question is not introduced in this section. While this question = is (partially) addressed in Sections 4.1.1.1=2C 4.1.1.2 and 4.1.1.3=2C I would like to see some basic d= iscussion of the=20 problem in Section 4.1.=20 For example=2C the nature of the "where the media is going" problem could b= e introduced=2C talking about identification mechanisms and the trust relationships that they might= depend on. Without this=2C it is somewhat hard to place Sections 4.1.1.1=2C 4.1.1.2 and 4.1.1.= 3 in context.=20 Section 4.1.1.1 A key aspect of this scenario is that the user is designating the callee=2C= not the site. While the application might or might not be carrying out the user's wishes or doing something nefarious=2C the calle= r at least has an expectation of what should happen.=20 For example=2C if the caller asks the service to call his or her mother and= someone else answers the phone=2C there is some probability that the caller will recognize this=2C whereas if the service decides who s= hould be called=2C then no such expectations are in place. Section 4.1.1.2 the user's expectation is that they are calling the site they're actually v= isiting. [BA] Rather than just talking about the device access issue=2C I'd suggest = that the "media routing" issue also be addressed here.=20 This can be quite a complex issue to deal with=2C particularly in a situati= on where the destination is an E.164 number. =20 In such a situation=2C the best that might be achievable is to provide the = user with an assertion of the destination or provider=2C as well as information on the trustworthiness of that assertion. For examp= le=2C a site whose identity has been verified by HTTPS might assert that a given E.164 number is being called=3B or the = identity of the media endpoint might be cryptographically verified (e.g. a service-provider SBC) so that the user might not know who = is being called=2C but they might know that the call is being handled by a particular service-provider.=20 Personally=2C it seems that independently verifying the media destination a= nd device access and explaining this to the user may be=20 futile in many cases=2C in that the user will be presented with unrelated a= nd (possibly irrelevant) information on which to make a judgment. Ultimately=2C simplicity may be the best guide=2C and if we're= looking for "one throat to choke" that throat is most likely to be the site delivering the web page.=20 Section 4.1.2 While this is primarily a question not for IETF=2C it should be clear that there is no really good answer. In general=2C if you cannot trust the site which you have authorized for calling not to bug you then your security situation is not really ideal. It is RECOMMENDED that browsers have explicit (and obvious) indicators that they are in a call in order to mitigate this risk. [BA] This is a very important section=2C since the usage scenario presented= is very challenging -- the user could be potentially=20 mislead not only as to the entity that is providing the code (e.g. third pa= rty vs. first party)=2C but also the media endpoint. =20 This potentially takes the worst aspects of today's third party "tracking" = scenarios to a new level --=20 audio/video surveillance by unknown third parties. =20 I'd like to see more potential solutions explored here. For example=2C if = the site isn't trustworthy=2C it may be useful to explore the potential use of trusted third parties. =20 > From: internet-drafts@ietf.org > To: i-d-announce@ietf.org > Date: Sun=2C 30 Oct 2011 21:56:47 -0700 > CC: rtcweb@ietf.org > Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-security-01.txt >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. This draft is a work item of the Real-Time Communication in WEB-brow= sers Working Group of the IETF. >=20 > Title : Security Considerations for RTC-Web > Author(s) : Eric Rescorla > Filename : draft-ietf-rtcweb-security-01.txt > Pages : 36 > Date : 2011-10-30 >=20 > 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=2C Web conferencing=2C and direct d= ata > transfer. Unlike most conventional real-time systems (e.g.=2C SIP- > based soft phones) RTC-Web communications are directly controlled by > some Web server=2C which poses new security challenges. For instance= =2C > 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 "=3Bbug"=3B a user'=3Bs co= mputer=2C 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. >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-rtcweb-security-01.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-rtcweb-security-01.txt > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb = --_d26c6e6b-f312-4cef-be01-318f0f5a4c1c_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Section 1

[BA] In addition to introducing the threat model=2C I = would suggest that this section reference the Use Case and Overview documen= ts=2C as well as providing an overview of the rest of the document. =3B=  =3B

Section 4.1
   In order for the user
   to make an intelligent decision about whether to allow a call (and
   hence his camera and microphone input to be routed somewhere)=2C he
   must understand either who is requesting access=2C where the media is
   going=2C or both.  So=2C for instance=2C one might imagine that at the t=
ime
   access to camera and microphone is requested=2C the user is shown a
   dialog that says "site X has requested access to camera and
   microphone=2C yes or no" (though note that this type of in-flow
   interface violates one of the guidelines in Section 3).  The user's
   decision will of course be based on his opinion of Site X. However=2C
   as discussed below=2C this is a complicated concept.

[BA] I would=
 suggest that this paragraph needs to be restructured.  

The questio=
n of "camera and microphone input" is a device access question=2C
that r=
elates to "who is requesting access"=2C whereas "allowing a call... to be r=
outed somewhere"
is relevant to "where the media is going." 

Whil=
e the last two sentences of the paragraph relate to the device access quest=
ion=2C
the media question is not introduced in this section.  While this=
 question is (partially) addressed in
Sections 4.1.1.1=2C 4.1.1.2 and 4.=
1.1.3=2C I would like to see some basic discussion of the 
problem in Se=
ction 4.1. 

For example=2C the nature of the "where the media is goi=
ng" problem could be introduced=2C talking
about identification mechanis=
ms and the trust relationships that they might depend on.  Without
this=
=2C it is somewhat hard to place Sections 4.1.1.1=2C 4.1.1.2 and 4.1.1.3 in=
 context. 

Section 4.1.1.1

A key aspect of this scenario is t=
hat the user is designating the callee=2C not the site.  While the applicat=
ion might or might not
be carrying out the user's wishes or doing someth=
ing nefarious=2C the caller at least has an expectation of what should happ=
en. 
For example=2C if the caller asks the service to call his or her mo=
ther and someone else answers the phone=2C there is some probability
tha=
t the caller will recognize this=2C whereas if the service decides who shou=
ld be called=2C then no such expectations are in place.

Section 4.1.=
1.2

the user's expectation is that they are calling the site they're=
 actually visiting.

[BA] Rather than just talking about the device a=
ccess issue=2C I'd suggest that the "media routing" issue also be addressed=
 here. 

This can be quite a complex issue to deal with=2C particular=
ly in a situation where the destination is an E.164 number.   
In such a=
 situation=2C the best that might be achievable is to provide the user with=
 an assertion of the destination or provider=2C
as well as information o=
n the trustworthiness of that assertion.  For example=2C a site whose ident=
ity has been verified
by HTTPS might assert that a given E.164 number is=
 being called=3B  or the identity of the media endpoint might be cryptograp=
hically
verified (e.g. a service-provider SBC) so that the user might no=
t know who is being called=2C but they might know
that the call is being=
 handled by a particular service-provider. 

Personally=2C it seems t=
hat independently verifying the media destination and device access and exp=
laining this to the user may be 
futile in many cases=2C in that the use=
r will be presented with unrelated and (possibly irrelevant) information on=
 which to make
a judgment.  Ultimately=2C simplicity may be the best gui=
de=2C and if we're looking for "one throat to choke" that throat is mostlikely to be the site delivering the web page. 

Section 4.1.2

   While this is primarily a question not for IETF=2C it should be cl=
ear
   that there is no really good answer.  In general=2C if you cannot trust
   the site which you have authorized for calling not to bug you then
   your security situation is not really ideal.  It is RECOMMENDED that
   browsers have explicit (and obvious) indicators that they are in a
   call in order to mitigate this risk.

[BA] This is a very importan=
t section=2C since the usage scenario presented is very challenging -- the =
user could be potentially 
mislead not only as to the entity that is pro=
viding the code (e.g. third party vs. first party)=2C but also the media en=
dpoint.  
This potentially takes the worst aspects of today's third part=
y "tracking" scenarios to a new level -- 
audio/video surveillance by un=
known third parties.  

I'd like to see more potential solutions explored here.  For example=2C if =
the site isn't trustworthy=2C it may be useful to explore
the potential =
use of trusted third parties.












>=3B From: internet-drafts@ietf.org
>=3B To: = i-d-announce@ietf.org
>=3B Date: Sun=2C 30 Oct 2011 21:56:47 -0700
= >=3B CC: rtcweb@ietf.org
>=3B Subject: [rtcweb] I-D Action: draft-ie= tf-rtcweb-security-01.txt
>=3B
>=3B A New Internet-Draft is avai= lable from the on-line Internet-Drafts directories. This draft is a work it= em of the Real-Time Communication in WEB-browsers Working Group of the IETF= .
>=3B
>=3B Title : Security Considerations for RTC-W= eb
>=3B Author(s) : Eric Rescorla
>=3B Filename : = draft-ietf-rtcweb-security-01.txt
>=3B Pages : 36
>=3B= Date : 2011-10-30
>=3B
>=3B The Real-Time Commun= ications on the Web (RTC-Web) working group is
>=3B tasked with sta= ndardizing protocols for real-time communications
>=3B between Web = browsers. The major use cases for RTC-Web technology are
>=3B real= -time audio and/or video calls=2C Web conferencing=2C and direct data
&g= t=3B transfer. Unlike most conventional real-time systems (e.g.=2C SIP-=
>=3B based soft phones) RTC-Web communications are directly contro= lled by
>=3B some Web server=2C which poses new security challenges= . For instance=2C
>=3B a Web browser might expose a JavaScript API= which allows a server to
>=3B place a video call. Unrestricted ac= cess to such an API would allow
>=3B any site which a user visited = to &=3Bquot=3Bbug&=3Bquot=3B a user&=3B#39=3Bs computer=2C capturi= ng
>=3B any activity which passed in front of their camera. This d= ocument
>=3B defines the RTC-Web threat model and defines an archit= ecture which
>=3B provides security within that threat model.
&g= t=3B
>=3B
>=3B A URL for this Internet-Draft is:
>=3B http= ://www.ietf.org/internet-drafts/draft-ietf-rtcweb-security-01.txt
>=3B=
>=3B Internet-Drafts are also available by anonymous FTP at:
>= =3B ftp://ftp.ietf.org/internet-drafts/
>=3B
>=3B This Internet-= Draft can be retrieved at:
>=3B ftp://ftp.ietf.org/internet-drafts/dra= ft-ietf-rtcweb-security-01.txt
>=3B __________________________________= _____________
>=3B rtcweb mailing list
>=3B rtcweb@ietf.org
&g= t=3B https://www.ietf.org/mailman/listinfo/rtcweb
= --_d26c6e6b-f312-4cef-be01-318f0f5a4c1c_-- From ibc@aliax.net Mon Oct 31 01:58: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 8C8A721F8D2F for ; Mon, 31 Oct 2011 01:58:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.645 X-Spam-Level: X-Spam-Status: No, score=-2.645 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y1h4WFNDiA1p for ; Mon, 31 Oct 2011 01:58: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 EEFF821F8D2C for ; Mon, 31 Oct 2011 01:58:30 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so5530668vcb.31 for ; Mon, 31 Oct 2011 01:58:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.7.12 with SMTP id b12mr2423060vcb.23.1320051510137; Mon, 31 Oct 2011 01:58:30 -0700 (PDT) Received: by 10.220.184.6 with HTTP; Mon, 31 Oct 2011 01:58:30 -0700 (PDT) In-Reply-To: <5DC01631-24B5-43F3-96E3-9DDBACB7783C@cisco.com> References: <4EA9A899.4020804@alvestrand.no> <5DC01631-24B5-43F3-96E3-9DDBACB7783C@cisco.com> Date: Mon, 31 Oct 2011 09:58:30 +0100 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] draft-sipdoc-rtcweb-open-wire-protocol-00 (Open In-The-Wire Protocol for RTC-Web) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 08:58:31 -0000 2011/10/30 Cullen Jennings : > On Oct 27, 2011, at 13:13 , I=C3=B1aki Baz Castillo wrote: > >> >> Sorry, our fault. I didn't aware about the draft naming conventions. > > No worry - it's more of a guideline than a rule. If you submit a new vers= ion with the a name like > > draft-castillo-rtcweb-open-wire-protocol-00 > > and send me an email reminding me, the chairs will get the new draft mark= ed as replacing draft-sipdoc-rtcweb-open-wire-protocol-00. Unfortunately yo= u will need to wait till Nov 13 before you will be able to submit =C2=A0as = it will be a -00 draft. > > In the meantime, people can just use the existing draft. Thanks a lot Cullen. However we are proposing right now the draft in SIPCORE so we'll wait a bit. Regards. --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Mon Oct 31 02:03: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 BB1E421F8A71 for ; Mon, 31 Oct 2011 02:03:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.646 X-Spam-Level: X-Spam-Status: No, score=-2.646 tagged_above=-999 required=5 tests=[AWL=0.031, 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 ieWtWYsE6gsT for ; Mon, 31 Oct 2011 02:03:25 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id CA13521F891D for ; Mon, 31 Oct 2011 02:03:24 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so5533287vcb.31 for ; Mon, 31 Oct 2011 02:03:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.150.81 with SMTP id x17mr2362036vcv.233.1320051804348; Mon, 31 Oct 2011 02:03:24 -0700 (PDT) Received: by 10.220.184.6 with HTTP; Mon, 31 Oct 2011 02:03:24 -0700 (PDT) In-Reply-To: <76E0CAF7-E66C-467D-A518-59143A663E31@cisco.com> References: <715A5714-B44A-4E1D-AC2F-7CC2EAD42D0F@acmepacket.com> <76E0CAF7-E66C-467D-A518-59143A663E31@cisco.com> Date: Mon, 31 Oct 2011 10:03:24 +0100 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: "" Subject: Re: [rtcweb] draft-sipdoc-rtcweb-open-wire-protocol-00 (Open In-The-Wire Protocol for RTC-Web) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 09:03:27 -0000 2011/10/31 Cullen Jennings : > One random idea =E2=80=A6 say that websockets was a protocol you could us= e to connect to a TURN server and then the TURN sever could send UPD or TCP= SIP. That might be easier to deploy =E2=80=A6 not sure this is a good idea= =E2=80=A6 just a random idea I thought I would mention. There are two problems with this: - If the websocket2tcp gateway is not SIP aware it would convert any TCP packet into a WebSocket message. This means that such WebSocket message could contain an incomplete SIP message or more than a single SIP message, and that would require stream parsing in the WebSocket client (JvaScript) becoming much more complex. In fact, our draft mandates that a WebSocket message MUST contain a single and complete SIP message (in the same way that SIP over UDP or SCTP). The draft "XMPP over WebSocket" mandates the same. - The SIP stack in JavaScript should set "TCP" in the Via transport, or may be "TLS", or "UDP" (depending on the SIP transport used after the websocket2tcp/udp/tls gateway. So I strongly prefer to add WebSocket as a real SIP transport in a SIP proxy (even more when I already have it deployed) :) Regards. --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Mon Oct 31 02: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 01E1821F8D37 for ; Mon, 31 Oct 2011 02:10:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.646 X-Spam-Level: X-Spam-Status: No, score=-2.646 tagged_above=-999 required=5 tests=[AWL=0.031, 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 itTA2-WOuRN0 for ; Mon, 31 Oct 2011 02:10: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 3A1B521F8D36 for ; Mon, 31 Oct 2011 02:10:43 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so5536942vcb.31 for ; Mon, 31 Oct 2011 02:10:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.151.81 with SMTP id b17mr2282909vcw.198.1320052225429; Mon, 31 Oct 2011 02:10:25 -0700 (PDT) Received: by 10.220.184.6 with HTTP; Mon, 31 Oct 2011 02:10:25 -0700 (PDT) In-Reply-To: References: <4EA9A899.4020804@alvestrand.no> <5DC01631-24B5-43F3-96E3-9DDBACB7783C@cisco.com> Date: Mon, 31 Oct 2011 10:10:25 +0100 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] draft-sipdoc-rtcweb-open-wire-protocol-00 (Open In-The-Wire Protocol for RTC-Web) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 09:10:44 -0000 2011/10/31 I=C3=B1aki Baz Castillo : >> No worry - it's more of a guideline than a rule. If you submit a new ver= sion with the a name like >> >> draft-castillo-rtcweb-open-wire-protocol-00 >> >> and send me an email reminding me, the chairs will get the new draft mar= ked as replacing draft-sipdoc-rtcweb-open-wire-protocol-00. Unfortunately y= ou will need to wait till Nov 13 before you will be able to submit =C2=A0as= it will be a -00 draft. >> >> In the meantime, people can just use the existing draft. > > Thanks a lot Cullen. However we are proposing right now the draft in > SIPCORE so we'll wait a bit. Sorry Cullen, please forget previous mail, I need a coffee. I thought we were speaking about my other draft "sip-websocket". Ok, I will submit the draft with a new name. BTW, is it possible to use my initials ("ibc") rather than my surname? Thanks a lot. --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Mon Oct 31 02:21: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 2110121F8D4A for ; Mon, 31 Oct 2011 02:21:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.346 X-Spam-Level: X-Spam-Status: No, score=-2.346 tagged_above=-999 required=5 tests=[AWL=-0.269, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_34=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 ggok7CPSvqDc for ; Mon, 31 Oct 2011 02:21: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 6596721F8D47 for ; Mon, 31 Oct 2011 02:21:31 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so5542523vcb.31 for ; Mon, 31 Oct 2011 02:21:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.150.212 with SMTP id z20mr2301931vcv.58.1320052890820; Mon, 31 Oct 2011 02:21:30 -0700 (PDT) Received: by 10.220.184.6 with HTTP; Mon, 31 Oct 2011 02:21:30 -0700 (PDT) In-Reply-To: <4EADF511.2040403@alvestrand.no> References: <7F2072F1E0DE894DA4B517B93C6A05852235717390@ESESSCMS0356.eemea.ericsson.se> <3BBCA56E-CA6E-4585-8EBB-ED6EDFED789F@cisco.com> <4EADF511.2040403@alvestrand.no> Date: Mon, 31 Oct 2011 10:21:30 +0100 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] Media forking solution for SIP interoperability (without a media gateway) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 09:21:32 -0000 2011/10/31 Harald Alvestrand : > I think having a single PeerConnection object send media to multiple peer= s > at the same time breaks the model we've been working from. > > It may be reasonable to give a PeerConnection the ability to switch from = one > remote peer to another remote peer (to support 180-like things), but I do= n't > think it's reasonable to have it connected to multiple remote peers. > > So if we support real forking, we'll have to create multiple PeerConnecti= ons > to do that. AFAIK there are three alternatives here: 1) PeerConnection can just communicate with a single peer. 2) PeerConnection can just communicate with a single peer but the per can be replaced later (so still we reuse the same local candidates, but ICE+SRTP must be "restarted". This solves serial forking. 3) PeerConnection can communicate with multiple peers at the same time. This solves serial and parallel forking. In my opinion: - Option 1) is very limited. - Option 2) is a MUST. - Option 3) would be great but it introduces some complexity. Imagine there is parallel forking and the WebRTC client recives 3 SDP's from 3 different peers, and passes all of them to the same PeerConnection. At same point a remote peer stops sending media so we get a callback "peerStopsSendingMedia()" in out PeerConnection. Does it mean that we can close the PeerConnection? not, because we must check whether there are other active peers yet (and there are in this case). So this introduces complexity at JavaScript level. The question is: is this complexity not so hard? can it be limited by some parameter when creating a PeerConnection? I imagine soemthing like: new PeerConnection( capabilities=3D[], allow_multiple_peers=3Dfalse/true= ) --=20 I=C3=B1aki Baz Castillo From christer.holmberg@ericsson.com Mon Oct 31 02: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 BAA6421F8D16 for ; Mon, 31 Oct 2011 02:40:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.236 X-Spam-Level: X-Spam-Status: No, score=-6.236 tagged_above=-999 required=5 tests=[AWL=0.363, 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 yZvC5oSTiaFN for ; Mon, 31 Oct 2011 02:40: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 F2FE021F8CE8 for ; Mon, 31 Oct 2011 02:40:22 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-39-4eae6d05e380 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id B4.54.20773.50D6EAE4; Mon, 31 Oct 2011 10:40:21 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.57]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Mon, 31 Oct 2011 10:40:20 +0100 From: Christer Holmberg To: Harald Alvestrand , Cullen Jennings Date: Mon, 31 Oct 2011 10:40:19 +0100 Thread-Topic: [rtcweb] Media forking solution for SIP interoperability (without a media gateway) Thread-Index: AcyXaZ0TkBWm83iSQyO2572tFvubmwARt3Qg Message-ID: <7F2072F1E0DE894DA4B517B93C6A058522356F23DD@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05852235717390@ESESSCMS0356.eemea.ericsson.se> <3BBCA56E-CA6E-4585-8EBB-ED6EDFED789F@cisco.com> <4EADF511.2040403@alvestrand.no> In-Reply-To: <4EADF511.2040403@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] Media forking solution for SIP interoperability (without a media gateway) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 09:40:23 -0000 Hi,=20 >>> In my opinion a better solution is to create a new=20 >>> PeerConnection for every new early dialog, which uses the=20 >>> *same* address/candidate parameters as the "parent" PeerConnection. >> Hmm we should talk about this - I have a hard time seeing=20 >> how that is going to work. I was working on the assumption=20 >> that PeerConnection could deal with more than one=20 >> offer/answer pair at a time. Given the current WebRTC API and=20 >> something like ROAP - it seems like that should just work. > > I think having a single PeerConnection object send media to=20 > multiple peers at the same time breaks the model we've been=20 > working from. > > It may be reasonable to give a PeerConnection the ability to=20 > switch from one remote peer to another remote peer (to=20 > support 180-like things), but I don't think it's reasonable=20 > to have it connected to multiple remote peers. > > So if we support real forking, we'll have to create multiple=20 > PeerConnections to do that. We could create new PeerConnections objects for every early dialog, but the= idea was that the new object could use the same local parameter (IP addres= s:port, candidates etc) as the "parent" object, so that one does not need t= o send a new offer. However, for serial forking we would only need a single PeerConnection obje= ct, assuming we could switch the remote parameter. So, again, I think we should first agree on WHAT we want, and then we can s= tart thinking on HOW to get it. Regards, Christer From ibc@aliax.net Mon Oct 31 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 24ADC21F8C80 for ; Mon, 31 Oct 2011 02:44:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.644 X-Spam-Level: X-Spam-Status: No, score=-2.644 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fEiW5QThM3BM for ; Mon, 31 Oct 2011 02:44: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 9FBE721F8C63 for ; Mon, 31 Oct 2011 02:44:56 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so5554546vcb.31 for ; Mon, 31 Oct 2011 02:44:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.150.81 with SMTP id x17mr2381884vcv.233.1320054296083; Mon, 31 Oct 2011 02:44:56 -0700 (PDT) Received: by 10.220.184.6 with HTTP; Mon, 31 Oct 2011 02:44:56 -0700 (PDT) In-Reply-To: References: Date: Mon, 31 Oct 2011 10:44:56 +0100 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: "" Subject: Re: [rtcweb] Does ROAP mandate the on-the-wire format? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 09:44:57 -0000 2011/10/30 Cullen Jennings : > Let's say the RTCWeb API passed JSON objects like the ones in ROAP in and= out of the PeerConnection object. (I will be arguing that is one thing we = should consider). =C2=A0At that oping you could write the SIP over webesock= ets in JS in the browsers. You might even find some useful info on how to d= o the mapping in draft-jennings-rtcweb-signaling-gateway-01 > > I think there has been a lot of talking past each other on this. In some = cases ROAP over webesockets might be a protocol used to speak directly to a= ROAP to SIP signaling GW. So I view ROAP over a well defined transport to = be a on the wire protocol but certainly not the only on the wire protocol. = Just one that some systems could use. > > On the other hand, if one does SIP in JS (or the browser), that works too= . > > Hope that helps clarify. Sure, thanks a lot. --=20 I=C3=B1aki Baz Castillo From christer.holmberg@ericsson.com Mon Oct 31 03:01: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 206CC21F8D72 for ; Mon, 31 Oct 2011 03:01:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.792 X-Spam-Level: X-Spam-Status: No, score=-5.792 tagged_above=-999 required=5 tests=[AWL=-0.093, BAYES_00=-2.599, J_CHICKENPOX_34=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 nzklnUcSu9M0 for ; Mon, 31 Oct 2011 03:01: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 55DD421F8D61 for ; Mon, 31 Oct 2011 03:01:42 -0700 (PDT) X-AuditID: c1b4fb3d-b7c26ae0000035b9-51-4eae72046ec7 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id A9.AB.13753.4027EAE4; Mon, 31 Oct 2011 11:01:41 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.57]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Mon, 31 Oct 2011 11:01:40 +0100 From: Christer Holmberg To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= , Harald Alvestrand Date: Mon, 31 Oct 2011 11:01:39 +0100 Thread-Topic: [rtcweb] Media forking solution for SIP interoperability (without a media gateway) Thread-Index: AcyXrn0axVjItdgbQBC2TlCVdzREjwAA9LlA Message-ID: <7F2072F1E0DE894DA4B517B93C6A058522356F2414@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05852235717390@ESESSCMS0356.eemea.ericsson.se> <3BBCA56E-CA6E-4585-8EBB-ED6EDFED789F@cisco.com> <4EADF511.2040403@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] Media forking solution for SIP interoperability (without a media gateway) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 10:01:43 -0000 Hi,=20 >> I think having a single PeerConnection object send media to=20 >> multiple peers at the same time breaks the model we've been working from= . >> >> It may be reasonable to give a PeerConnection the ability to switch=20 >> from one remote peer to another remote peer (to support 180-like=20 >> things), but I don't think it's reasonable to have it=20 >> connected to multiple remote peers. >> >> So if we support real forking, we'll have to create multiple=20 >> PeerConnections to do that. >=20 > AFAIK there are three alternatives here: >=20 >=20 > 1) PeerConnection can just communicate with a single peer. >=20 > 2) PeerConnection can just communicate with a single peer but=20 > the per can be replaced later (so still we reuse the same=20 > local candidates, but ICE+SRTP must be "restarted". This=20 > solves serial forking. >=20 > 3) PeerConnection can communicate with multiple peers at the=20 > same time. This solves serial and parallel forking. >=20 >=20 > In my opinion: >=20 > - Option 1) is very limited. >=20 > - Option 2) is a MUST. >=20 > - Option 3) would be great but it introduces some complexity.=20 > Imagine there is parallel forking and the WebRTC client=20 > recives 3 SDP's from 3 different peers, and passes all of=20 > them to the same PeerConnection. At same point a remote peer=20 > stops sending media so we get a callback=20 > "peerStopsSendingMedia()" in out PeerConnection. Does it mean=20 > that we can close the PeerConnection? not, because we must=20 > check whether there are other active peers yet (and there are=20 > in this case). So this introduces complexity at JavaScript=20 > level. The question is: is this complexity not so hard? can=20 > it be limited by some parameter when creating a=20 > PeerConnection? I imagine soemthing like: >=20 > new PeerConnection( capabilities=3D[],=20 > allow_multiple_peers=3Dfalse/true) I am not sure whether option 3) uses a single PeerConnection, but one alter= native is that we use multiple PC objects, but they all share the local par= ameters and candidates. Personally I think option 2) would be ok for most cases, and enough to supp= ort in "phase 1". And, IF someone really wants to support parallel forking, there is always t= he possibility to create new PC objects, send offers associated with them e= tc. Regards, Christer From ibc@aliax.net Mon Oct 31 03: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 E52C121F8C1A for ; Mon, 31 Oct 2011 03:24:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.344 X-Spam-Level: X-Spam-Status: No, score=-2.344 tagged_above=-999 required=5 tests=[AWL=-0.267, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_34=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 YdIoEIGRfIfZ for ; Mon, 31 Oct 2011 03:24:32 -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 84C2A21F8B87 for ; Mon, 31 Oct 2011 03:24:32 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so5576469vcb.31 for ; Mon, 31 Oct 2011 03:24:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.147.198 with SMTP id m6mr2455571vcv.128.1320056671973; Mon, 31 Oct 2011 03:24:31 -0700 (PDT) Received: by 10.220.184.6 with HTTP; Mon, 31 Oct 2011 03:24:31 -0700 (PDT) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A058522356F2414@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05852235717390@ESESSCMS0356.eemea.ericsson.se> <3BBCA56E-CA6E-4585-8EBB-ED6EDFED789F@cisco.com> <4EADF511.2040403@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A058522356F2414@ESESSCMS0356.eemea.ericsson.se> Date: Mon, 31 Oct 2011 11:24:31 +0100 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] Media forking solution for SIP interoperability (without a media gateway) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 10:24:34 -0000 2011/10/31 Christer Holmberg : >> AFAIK there are three alternatives here: >> >> >> 1) PeerConnection can just communicate with a single peer. >> >> 2) PeerConnection can just communicate with a single peer but >> the per can be replaced later (so still we reuse the same >> local candidates, but ICE+SRTP must be "restarted". This >> solves serial forking. >> >> 3) PeerConnection can communicate with multiple peers at the >> same time. This solves serial and parallel forking. >> >> >> In my opinion: >> >> - Option 1) is very limited. >> >> - Option 2) is a MUST. >> >> - Option 3) would be great but it introduces some complexity. >> Imagine there is parallel forking and the WebRTC client >> recives 3 SDP's from 3 different peers, and passes all of >> them to the same PeerConnection. At same point a remote peer >> stops sending media so we get a callback >> "peerStopsSendingMedia()" in out PeerConnection. Does it mean >> that we can close the PeerConnection? not, because we must >> check whether there are other active peers yet (and there are >> in this case). So this introduces complexity at JavaScript >> level. The question is: is this complexity not so hard? can >> it be limited by some parameter when creating a >> PeerConnection? I imagine soemthing like: >> >> =C2=A0 =C2=A0new PeerConnection( capabilities=3D[], >> allow_multiple_peers=3Dfalse/true) > > I am not sure whether option 3) uses a single PeerConnection, but one alt= ernative is that we use multiple PC objects, but they all share the local p= arameters and candidates. Maybe I'm wrong, but AFAIK the local candidates are generated when creating a PeerConnection object. This is: you create a PC object and internally it gets the candidates, so you cannot create a second PC and use the same local candidates. Am I wrong? > Personally I think option 2) would be ok for most cases, and enough to su= pport in "phase 1". I also agree. Also, many SIP phones just render a single media stream even when media parallel forking occurs, and switch to the definitive SDP when the 200 arrives, so IMHO this is not a great limitation for WebRTC. > And, IF someone really wants to support parallel forking, there is always= the possibility to create new PC objects, send offers associated with them= etc. Right. --=20 I=C3=B1aki Baz Castillo From pravindran@sonusnet.com Mon Oct 31 05:21: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 26BAD21F8DAF for ; Mon, 31 Oct 2011 05:21:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.674 X-Spam-Level: X-Spam-Status: No, score=-2.674 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 rpyg0OXZJlFt for ; Mon, 31 Oct 2011 05:21:12 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 6456121F8DAE for ; Mon, 31 Oct 2011 05:21:10 -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 p9VCLg5N012398; Mon, 31 Oct 2011 08:21:42 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail04.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 31 Oct 2011 08:21:06 -0400 Received: from INBA-HUB01.sonusnet.com ([10.70.51.86]) by sonusinmail02.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 31 Oct 2011 17:51:09 +0530 Received: from INBA-HUB02.sonusnet.com (10.70.51.87) by inba-hub01.sonusnet.com (10.70.51.86) with Microsoft SMTP Server (TLS) id 14.1.339.1; Mon, 31 Oct 2011 17:51:08 +0530 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub02.sonusnet.com ([fe80::80b9:dc60:caf7:7dfc%11]) with mapi id 14.01.0339.001; Mon, 31 Oct 2011 17:51:08 +0530 From: Ravindran Parthasarathi To: Harald Alvestrand , Cullen Jennings Thread-Topic: [rtcweb] Media forking solution for SIP interoperability (without a media gateway) Thread-Index: AQHMl2DMJAhpsnUL9kK3CsrGujQNm5WVSEKAgAEIExA= Date: Mon, 31 Oct 2011 12:21:08 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6CB8C4@inba-mail01.sonusnet.com> References: <7F2072F1E0DE894DA4B517B93C6A05852235717390@ESESSCMS0356.eemea.ericsson.se> <3BBCA56E-CA6E-4585-8EBB-ED6EDFED789F@cisco.com> <4EADF511.2040403@alvestrand.no> In-Reply-To: <4EADF511.2040403@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.54.32] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 31 Oct 2011 12:21:09.0447 (UTC) FILETIME=[923A1D70:01CC97C7] Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Media forking solution for SIP interoperability (without a media gateway) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 12:21:13 -0000 Harald, As per F11 & F12 of draft-ietf-rtcweb-use-cases-and-requirements-06 ,=20 "F11 The browser MUST be able to transmit streams to several peers concurrently. F12 The browser MUST be able to receive streams from multiple peers concurrently." The above browser requirement makes me to guess that it is possible to supp= ort SIP parallel forking sort of services in case proper JS APIs are provid= ed (May be current form of peerconnection does not). Please let me know you= r opinion on this. Thanks Partha >-----Original Message----- >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf >Of Harald Alvestrand >Sent: Monday, October 31, 2011 6:39 AM >To: Cullen Jennings >Cc: rtcweb@ietf.org >Subject: Re: [rtcweb] Media forking solution for SIP interoperability >(without a media gateway) > >On 10/30/2011 11:41 AM, Cullen Jennings wrote: >> On Oct 30, 2011, at 9:58 , Christer Holmberg wrote: >> >>> In my opinion a better solution is to create a new PeerConnection for >every new early dialog, which uses the *same* address/candidate >parameters as the "parent" PeerConnection. >> Hmm we should talk about this - I have a hard time seeing how that is >going to work. I was working on the assumption that PeerConnection >could deal with more than one offer/answer pair at a time. Given the >current WebRTC API and something like ROAP - it seems like that should >just work. >I think having a single PeerConnection object send media to multiple >peers at the same time breaks the model we've been working from. > >It may be reasonable to give a PeerConnection the ability to switch from >one remote peer to another remote peer (to support 180-like things), but >I don't think it's reasonable to have it connected to multiple remote >peers. > >So if we support real forking, we'll have to create multiple >PeerConnections to do that. > > >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb From ibc@aliax.net Mon Oct 31 05:25: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 59BF721F8C68 for ; Mon, 31 Oct 2011 05:25:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.643 X-Spam-Level: X-Spam-Status: No, score=-2.643 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mmVEWL05Zsns for ; Mon, 31 Oct 2011 05:25:53 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id D57B921F8C36 for ; Mon, 31 Oct 2011 05:25:52 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so5671015vcb.31 for ; Mon, 31 Oct 2011 05:25:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.7.12 with SMTP id b12mr2499843vcb.23.1320063952284; Mon, 31 Oct 2011 05:25:52 -0700 (PDT) Received: by 10.220.184.6 with HTTP; Mon, 31 Oct 2011 05:25:52 -0700 (PDT) In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6CB8C4@inba-mail01.sonusnet.com> References: <7F2072F1E0DE894DA4B517B93C6A05852235717390@ESESSCMS0356.eemea.ericsson.se> <3BBCA56E-CA6E-4585-8EBB-ED6EDFED789F@cisco.com> <4EADF511.2040403@alvestrand.no> <387F9047F55E8C42850AD6B3A7A03C6CB8C4@inba-mail01.sonusnet.com> Date: Mon, 31 Oct 2011 13:25:52 +0100 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Ravindran Parthasarathi Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Media forking solution for SIP interoperability (without a media gateway) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 12:25:53 -0000 2011/10/31 Ravindran Parthasarathi : > Harald, > > As per F11 & F12 of draft-ietf-rtcweb-use-cases-and-requirements-06 , > > =C2=A0 "F11 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The browser MUST be= able to transmit streams to > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 several pe= ers concurrently. > > =C2=A0 F12 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The browser MUST be = able to receive streams from > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 multiple p= eers concurrently." > > The above browser requirement makes me to guess that it is possible to su= pport SIP parallel forking sort of services in case proper JS APIs are prov= ided (May be current form of peerconnection does not). Please let me know y= our opinion on this. The above requirements don't say that a *single* PeerConnection MUST be able to send and receive streams to/from several peers concurrently. It just says that the *browser* MUST be able, and a way to achieve that is by creating multiple concurrent PeerConnection objects. --=20 I=C3=B1aki Baz Castillo From christer.holmberg@ericsson.com Mon Oct 31 05:38: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 9543F21F8DB8 for ; Mon, 31 Oct 2011 05:38:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.09 X-Spam-Level: X-Spam-Status: No, score=-6.09 tagged_above=-999 required=5 tests=[AWL=0.209, 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 yU7Vm1VSM0zD for ; Mon, 31 Oct 2011 05:38: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 CE68E21F8D70 for ; Mon, 31 Oct 2011 05:38:00 -0700 (PDT) X-AuditID: c1b4fb3d-b7c26ae0000035b9-5e-4eae96a77d09 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id F4.5B.13753.7A69EAE4; Mon, 31 Oct 2011 13:37:59 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.57]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Mon, 31 Oct 2011 13:37:59 +0100 From: Christer Holmberg To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= , Ravindran Parthasarathi Date: Mon, 31 Oct 2011 13:37:58 +0100 Thread-Topic: [rtcweb] Media forking solution for SIP interoperability (without a media gateway) Thread-Index: AcyXyD8m80QqCTY/TGOqOKNs5zlCKAAAQMoQ Message-ID: <7F2072F1E0DE894DA4B517B93C6A058522356F25B3@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05852235717390@ESESSCMS0356.eemea.ericsson.se> <3BBCA56E-CA6E-4585-8EBB-ED6EDFED789F@cisco.com> <4EADF511.2040403@alvestrand.no> <387F9047F55E8C42850AD6B3A7A03C6CB8C4@inba-mail01.sonusnet.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Media forking solution for SIP interoperability (without a media gateway) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 12:38:01 -0000 Hi, I would suggest that, instead of talking about a single PeerConnection, we = talk about using the same local IP parameters and candicates for multiple r= emote endpoints. It could be a single PC, or it could be multiple "cloned" = PCs. Again, let's first decide whether we need it - then we can start thinking o= f how to get it :) Regards, Christer > -----Original Message----- > From: rtcweb-bounces@ietf.org=20 > [mailto:rtcweb-bounces@ietf.org] On Behalf Of I=F1aki Baz Castillo > Sent: 31. lokakuuta 2011 14:26 > To: Ravindran Parthasarathi > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] Media forking solution for SIP=20 > interoperability (without a media gateway) >=20 > 2011/10/31 Ravindran Parthasarathi : > > Harald, > > > > As per F11 & F12 of=20 > draft-ietf-rtcweb-use-cases-and-requirements-06 , > > > > =A0 "F11 =A0 =A0 =A0 =A0 =A0 =A0 The browser MUST be able to transmit s= treams to > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 several peers concurrently. > > > > =A0 F12 =A0 =A0 =A0 =A0 =A0 =A0 The browser MUST be able to receive str= eams from > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 multiple peers concurrently." > > > > The above browser requirement makes me to guess that it is=20 > possible to support SIP parallel forking sort of services in=20 > case proper JS APIs are provided (May be current form of=20 > peerconnection does not). Please let me know your opinion on this. >=20 > The above requirements don't say that a *single*=20 > PeerConnection MUST be able to send and receive streams=20 > to/from several peers concurrently. It just says that the=20 > *browser* MUST be able, and a way to achieve that is by=20 > creating multiple concurrent PeerConnection objects. >=20 >=20 >=20 >=20 > -- > I=F1aki Baz Castillo > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > = From pravindran@sonusnet.com Mon Oct 31 05:51: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 3788921F8D5B for ; Mon, 31 Oct 2011 05:51:26 -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.223, 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 vvH5I5w0FGey for ; Mon, 31 Oct 2011 05:51:25 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 8FF6321F8D3F for ; Mon, 31 Oct 2011 05:51:25 -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 p9VCpv1K032255; Mon, 31 Oct 2011 08:51:57 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail07.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 31 Oct 2011 08:51:21 -0400 Received: from INBA-HUB01.sonusnet.com ([10.70.51.86]) by sonusinmail02.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 31 Oct 2011 18:21:24 +0530 Received: from INBA-HUB02.sonusnet.com (10.70.51.87) by inba-hub01.sonusnet.com (10.70.51.86) with Microsoft SMTP Server (TLS) id 14.1.339.1; Mon, 31 Oct 2011 18:21:23 +0530 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub02.sonusnet.com ([fe80::80b9:dc60:caf7:7dfc%11]) with mapi id 14.01.0339.001; Mon, 31 Oct 2011 18:21:23 +0530 From: Ravindran Parthasarathi To: Christer Holmberg , =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= Thread-Topic: [rtcweb] Media forking solution for SIP interoperability (without a media gateway) Thread-Index: AQHMl8hDWxKjfg17L0K1sVMHltxMmJWWCBIAgABc26A= Date: Mon, 31 Oct 2011 12:51:22 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6CB914@inba-mail01.sonusnet.com> References: <7F2072F1E0DE894DA4B517B93C6A05852235717390@ESESSCMS0356.eemea.ericsson.se> <3BBCA56E-CA6E-4585-8EBB-ED6EDFED789F@cisco.com> <4EADF511.2040403@alvestrand.no> <387F9047F55E8C42850AD6B3A7A03C6CB8C4@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A058522356F25B3@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A058522356F25B3@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.54.32] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 31 Oct 2011 12:51:24.0525 (UTC) FILETIME=[CC1909D0:01CC97CB] Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Media forking solution for SIP interoperability (without a media gateway) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 12:51:27 -0000 Hi Christer, I agree with you. By reading ROAP draft, I got the feel that it is possible= to connect to multiple peer from single local offer and also, it is possib= le to update multiple peers during each offer/answer exchange. It is sligh= tly upper version of SIP parallel forking wherein multiple dialogs are crea= ted in terms of SIP due to forking and update each dialogs using RE-INVITE = for media change. I like this usecase as this infrastructure helps for buil= ding complex media services in browser. Thanks Partha >-----Original Message----- >From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >Sent: Monday, October 31, 2011 6:08 PM >To: I=F1aki Baz Castillo; Ravindran Parthasarathi >Cc: rtcweb@ietf.org >Subject: RE: [rtcweb] Media forking solution for SIP interoperability >(without a media gateway) > > >Hi, > >I would suggest that, instead of talking about a single PeerConnection, >we talk about using the same local IP parameters and candicates for >multiple remote endpoints. It could be a single PC, or it could be >multiple "cloned" PCs. > >Again, let's first decide whether we need it - then we can start >thinking of how to get it :) > >Regards, > >Christer > > >> -----Original Message----- >> From: rtcweb-bounces@ietf.org >> [mailto:rtcweb-bounces@ietf.org] On Behalf Of I=F1aki Baz Castillo >> Sent: 31. lokakuuta 2011 14:26 >> To: Ravindran Parthasarathi >> Cc: rtcweb@ietf.org >> Subject: Re: [rtcweb] Media forking solution for SIP >> interoperability (without a media gateway) >> >> 2011/10/31 Ravindran Parthasarathi : >> > Harald, >> > >> > As per F11 & F12 of >> draft-ietf-rtcweb-use-cases-and-requirements-06 , >> > >> > =A0 "F11 =A0 =A0 =A0 =A0 =A0 =A0 The browser MUST be able to transmit = streams to >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 several peers concurrently. >> > >> > =A0 F12 =A0 =A0 =A0 =A0 =A0 =A0 The browser MUST be able to receive st= reams from >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 multiple peers concurrently." >> > >> > The above browser requirement makes me to guess that it is >> possible to support SIP parallel forking sort of services in >> case proper JS APIs are provided (May be current form of >> peerconnection does not). Please let me know your opinion on this. >> >> The above requirements don't say that a *single* >> PeerConnection MUST be able to send and receive streams >> to/from several peers concurrently. It just says that the >> *browser* MUST be able, and a way to achieve that is by >> creating multiple concurrent PeerConnection objects. >> >> >> >> >> -- >> I=F1aki Baz Castillo >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> From bernard_aboba@hotmail.com Mon Oct 31 05:58: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 1495621F8D80 for ; Mon, 31 Oct 2011 05:58:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.451 X-Spam-Level: X-Spam-Status: No, score=-102.451 tagged_above=-999 required=5 tests=[AWL=0.147, 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 hoPnqKoVtKLy for ; Mon, 31 Oct 2011 05:58:03 -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 3379C21F8D7E for ; Mon, 31 Oct 2011 05:58:03 -0700 (PDT) Received: from BLU152-W55 ([65.55.111.135]) by blu0-omc4-s9.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 31 Oct 2011 05:58:00 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_aefff3c6-8ee8-481f-a17c-758361045978_" X-Originating-IP: [24.17.217.162] From: Bernard Aboba To: , Date: Mon, 31 Oct 2011 05:57:59 -0700 Importance: Normal In-Reply-To: <3BBCA56E-CA6E-4585-8EBB-ED6EDFED789F@cisco.com> References: , <7F2072F1E0DE894DA4B517B93C6A05852235717390@ESESSCMS0356.eemea.ericsson.se>, <3BBCA56E-CA6E-4585-8EBB-ED6EDFED789F@cisco.com> MIME-Version: 1.0 X-OriginalArrivalTime: 31 Oct 2011 12:58:00.0177 (UTC) FILETIME=[B7ECBE10:01CC97CC] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Media forking solution for SIP interoperability (without a media gateway) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 12:58:04 -0000 --_aefff3c6-8ee8-481f-a17c-758361045978_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cullen said: > Hmm we should talk about this - I have a hard time seeing how that is goi= ng to work. I was working on the assumption that PeerConnection=20 >could deal with more than one offer/answer pair at a time. Given the curre= nt WebRTC API and something like ROAP - it seems like that should just work= .=20 [BA] We have an issue with the API spec if that it is possible for people t= o come to very different conclusions about whether this and other things "should just work". BTW=2C this was *not* my reading of the spec -- it se= ems to me that there are inherent assumptions about the state machines=2C ICE and other aspects that would restrict a PeerConnection to one offer/ans= wer pair at a time. =20 = --_aefff3c6-8ee8-481f-a17c-758361045978_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Cullen said:


>=3B Hmm we should talk about this - I have = a hard time seeing how that is going to work. I was working on the assumpti= on that PeerConnection
>=3Bcould deal with more than one offer/answe= r pair at a time. Given the current WebRTC API and something like ROAP - it= seems like that should just work.


[BA] We have an issue with t= he API spec if that it is possible for people to come to very different con= clusions about whether this and other things
"should just work". =3B=  =3B BTW=2C this was *not* my reading of the spec -- it seems to me tha= t there are inherent assumptions about the state machines=2C
ICE and oth= er aspects that would restrict a PeerConnection to one offer/answer pair at= a time. =3B
= --_aefff3c6-8ee8-481f-a17c-758361045978_-- From bernard_aboba@hotmail.com Mon Oct 31 06:22: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 D696121F8B1A for ; Mon, 31 Oct 2011 06:22:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.459 X-Spam-Level: X-Spam-Status: No, score=-102.459 tagged_above=-999 required=5 tests=[AWL=0.139, 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 meiivhdjiC9o for ; Mon, 31 Oct 2011 06:22:42 -0700 (PDT) Received: from blu0-omc2-s33.blu0.hotmail.com (blu0-omc2-s33.blu0.hotmail.com [65.55.111.108]) by ietfa.amsl.com (Postfix) with ESMTP id 38A5121F85AA for ; Mon, 31 Oct 2011 06:22:42 -0700 (PDT) Received: from BLU152-W43 ([65.55.111.71]) by blu0-omc2-s33.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 31 Oct 2011 06:22:41 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_0aa02d3f-db23-43dd-9fc8-5bbc9418f4cc_" X-Originating-IP: [24.17.217.162] From: Bernard Aboba To: Date: Mon, 31 Oct 2011 06:22:40 -0700 Importance: Normal In-Reply-To: <2308DE02-0E63-4CCF-8889-F2E79204C7AF@acmepacket.com> References: <3FACD0E9-449A-4897-8997-F76B5A41A34E@acmepacket.com>, <4EAA7B02.4010400@ericsson.com>, <2308DE02-0E63-4CCF-8889-F2E79204C7AF@acmepacket.com> MIME-Version: 1.0 X-OriginalArrivalTime: 31 Oct 2011 13:22:41.0925 (UTC) FILETIME=[2B1D8B50:01CC97D0] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Security issue: consent refresh X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 13:22:43 -0000 --_0aa02d3f-db23-43dd-9fc8-5bbc9418f4cc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > And the reason you are not needing the SHA-1 stuff is that you see no > need for this consent refresh to continue to verify that the one sending > the answers echoing the transaction IDs is a node which you provided > with the credentials? Or which the "evil" webservice has provisioned > with the credentials from the signalling exchange? >=20 > Correct. Let's assume ICE is used for initial consent. If you're past t= he initial consent stage=2C then some far-end accepted your communication.= =20 > > At that point we're at the same stage as if the JS had simply=20 initiated an HTTP connection to another site and it was approved with=20 CORS. What keeps such an HTTP connection going is simply TCP=20 "consent-refresh" using ACKs and not getting RST/FIN... and we don't=20 need to be stronger than TCP. Arguably the STUN keepalive would=20 actually be stronger than TCP even without SHA-1=2C because the STUN=20 96-bit Transaction-ID is harder to spoof-guess than two 16-bit TCP=20 sequence number fields. >=20 > If there is a MitM physically=20 on the path between the Browser and the peer=2C such a MitM can keep the=20 RTP flowing even if we used RTCP=2C=20 >because it could fake RTCP. (and such a MitM can keep TCP and SCTP going too=2C fwiw) [BA] Agree with Hadriel that forcing an IWF to "manufacture" RTCP is a bad = idea=2C and that the focus should be on an off-path attacker.=20 Also agree that we need "continuing consent" and can't rely on a "source qu= ench" approach which has proven unworkable in other contexts. There are situations where a receiver might have "gone away" for = one reason or another=2C or where the receiver is being=20 overwhelmed=2C where it might not have the ability or context to tell the s= ender to stop. For example=2C if key state has been lost=2C=20 putting out a secured "Bye" may not be possible.=20 = --_0aa02d3f-db23-43dd-9fc8-5bbc9418f4cc_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
>=3B And the reason you are not needing the SHA-1 stuff is that you see n= o
>=3B need for this consent refresh to continue to verify that t= he one sending
>=3B the answers echoing the transaction IDs is a node = which you provided
>=3B with the credentials? Or which the "evil" webs= ervice has provisioned
>=3B with the credentials from the signalling e= xchange?
>=3B
>=3B Correct. Let's assume ICE is used for initia= l consent. If you're past the initial consent stage=2C then some far-end a= ccepted your communication.
>=3B
>=3B At that point we're at the= same stage as if the JS had simply=20 initiated an HTTP connection to another site and it was approved with=20 CORS. What keeps such an HTTP connection going is simply TCP=20 "consent-refresh" using ACKs and not getting RST/FIN... and we don't=20 need to be stronger than TCP. Arguably the STUN keepalive would=20 actually be stronger than TCP even without SHA-1=2C because the STUN=20 96-bit Transaction-ID is harder to spoof-guess than two 16-bit TCP=20 sequence number fields.
>=3B
>=3B If there is a MitM physically= =20 on the path between the Browser and the peer=2C such a MitM can keep the=20 RTP flowing even if we used RTCP=2C
>=3Bbecause it could fake RTCP. (= and such a MitM can keep TCP and SCTP going too=2C fwiw)


[BA] Agree with H= adriel that forcing an IWF to "manufacture" RTCP is a bad idea=2C and that = the focus should be on an off-path attacker.

Also agree that we nee= d "continuing consent" and can't rely on a "source quench" approach which h= as proven unworkable in other
contexts. There are situations where a rec= eiver might have "gone away" for one reason or another=2C or where the rece= iver is being
overwhelmed=2C where it might not have the ability or con= text to tell the sender to stop. =3B For example=2C if key state has be= en lost=2C
putting out a secured "Bye" may not be possible.

= --_0aa02d3f-db23-43dd-9fc8-5bbc9418f4cc_-- From pravindran@sonusnet.com Mon Oct 31 06:24: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 A93D321F8BFE for ; Mon, 31 Oct 2011 06:23:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.667 X-Spam-Level: X-Spam-Status: No, score=-2.667 tagged_above=-999 required=5 tests=[AWL=-0.068, 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 DkBwnlluNeBk for ; Mon, 31 Oct 2011 06:23:59 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 3CFEC21F8B8E for ; Mon, 31 Oct 2011 06:23: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 p9VDOTEZ020779; Mon, 31 Oct 2011 09:24:29 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail07.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 31 Oct 2011 09:23:53 -0400 Received: from INBA-HUB01.sonusnet.com ([10.70.51.86]) by sonusinmail02.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 31 Oct 2011 18:53:56 +0530 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub01.sonusnet.com ([fe80::5cbc:2823:f6cc:9ce7%11]) with mapi id 14.01.0339.001; Mon, 31 Oct 2011 18:53:56 +0530 From: Ravindran Parthasarathi To: Hadriel Kaplan , "" Thread-Topic: New usecase & requirement for media forking in browser Thread-Index: AQHMl9BWsWD0kT8xzE+tFIa2IMhSLA== Date: Mon, 31 Oct 2011 13:23:55 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6CB953@inba-mail01.sonusnet.com> References: <20111024224257.28459.65554.idtracker@ietfa.amsl.com><6EB8679A-13D5-4AD7-97F2-BC35FC0966F0@acmepacket.com><2E239D6FCD033C4BAF15F386A979BF51159C32@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF51159D7A@sonusinmail02.sonusnet.com> <4EAAF413.8030501@alvestrand.no> <2E239D6FCD033C4BAF15F386A979BF51159D7B@sonusinmail02.sonusnet.com> <247FFE2C-DB2C-4280-A219-BE1503662F92@acmepacket.com> In-Reply-To: <247FFE2C-DB2C-4280-A219-BE1503662F92@acmepacket.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.54.32] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 31 Oct 2011 13:23:56.0462 (UTC) FILETIME=[578AFCE0:01CC97D0] Subject: [rtcweb] New usecase & requirement for media forking in browser X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 13:24:00 -0000 Usecase: Media forking in browser Description: User forks local stream/stream components to multiple peers si= multaneously and able to receive multiple streams from multiple peers.=20 Functional requirement: F11, F12, (any new requirement has to be added ?) API requirement: The Web API MUST provide means for the web application t= o initiate sending/receiving of stream/stream components to a multiple peer= simultaneously and relate each of these streams individually by web applic= ation. Having said that, I'm not very sure whether this usecase falls under the ca= tegory of remote-recording by John. Hadriel, Thanks for the clarification on the current status and practical usecases. Thanks Partha >-----Original Message----- >From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] >Sent: Saturday, October 29, 2011 1:58 AM >To: Ravindran Parthasarathi >Cc: Harald Alvestrand; I=F1aki Baz Castillo; >Subject: Re: [rtcweb] RTCWeb Forking usecase [was RE:draft-kaplan- >rtcweb-sip-interworking-requirements-00] > > >We've debated serial and parallel forking a number of times but I don't >know if there's been consensus. > >But your email is really two different questions/topics: >1) Is there a use-case for forking within WebRTC? >2) Does supporting SIP forking mean the Browser has to handle the >SDP/media behavior of it, vs. the Web-server/Interworking-function >handling it? > >For the first question, I can certainly envision a Web-app wanting to >let Alice press a single button on her Browser and end up communicating >with Bob no matter where he may be, or letting her single button-press >end up communicating with Bob first and then Charlie, or letting her >single button-press end up communicating with Bob and Charlie at the >same time. But I think such things can be accomplished through clever >Web-app code without needing the Browser to be aware it's a forked >ROAP/SDP scenario. >[Note: though this may depend on what W3C decides the user-consent UI >model is relative to PeerConnections, MediaStreams and ROAP] > >With regards to the second question, there was a long email thread on >this which started here I think: >http://www.ietf.org/mail-archive/web/rtcweb/current/msg01354.html > >-hadriel > > >On Oct 28, 2011, at 3:14 PM, Ravindran Parthasarathi wrote: > >> Harald, >> >> Thanks for the clarification. "Fedex IVR" usecase is under browser to >GW/server section (sec 4.3) which is a SIP based forking requirement. If >you look at carefully, "Fedex IVR non-final response" scenario could >have be achieved cleanly using two separate offer/answer exchange & two >final responses (INVITE/200/ACK, RE-INVITE/200/ACK) : >> >> 1) customer - fedex IVR offer/answer exchange >> 2) fedex agent - Customer offer/answer exchange >> >> but it may be avoided in legacy for billing reasons which should not >be major concern for RTCWeb. In case of SIP forking, it is assumed that >2nd answer override the 1st answer in the media plane. >> >> As I mentioned earlier, SIP (serial) forking requirement shall be met >by gateway signaling and no extra requirement for browser. Also, >switching media stream from one responder to other responder in Fedex >IVR usecase is not so easy because of legacy media handling (ICE, RTCP) >differences as mentioned in draft-kaplan-rtcweb-sip-interworking- >requirements-00. >> >> ISTM, we don't have RTCWeb specific forking usecase till now. >> >> Thanks >> Partha >> >>> -----Original Message----- >>> From: Harald Alvestrand [mailto:harald@alvestrand.no] >>> Sent: Friday, October 28, 2011 11:58 PM >>> To: Ravindran Parthasarathi >>> Cc: I=F1aki Baz Castillo; rtcweb@ietf.org; Hadriel Kaplan >>> Subject: Re: [rtcweb] RTCWeb Forking usecase [was RE: draft-kaplan- >>> rtcweb-sip-interworking-requirements-00] >>> >>> On 10/28/2011 10:56 AM, Ravindran Parthasarathi wrote: >>>> By looking at draft-ietf-rtcweb-use-cases-and-requirements-06, I >could >>> not see any specific requirement for RTCWeb forking. In case SIP >forking >>> is the only requirement for RTCWeb and also, RTCWeb does not have any >>> specific forking requirement, then the gateway between RTCWeb& SIP >>> shall take care of the functionality. I'm asking this question to get >>> the clarity on whether SIP forking feature has to impact RTCWeb >client >>> requirement or not. >>> I believe the "Fedex IVR" case was specifically intended to surface >the >>> requirement for "non-final responses" (switching a media stream from >the >>> initial responder to a next responder). >>> That's one form of forking ("serial fork"?) >>> >>> I haven't understood forking to be a requirement in any other use >case. >> From stefan.lk.hakansson@ericsson.com Mon Oct 31 06:45: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 1347B21F8C1E for ; Mon, 31 Oct 2011 06:45:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.209 X-Spam-Level: X-Spam-Status: No, score=-6.209 tagged_above=-999 required=5 tests=[AWL=0.090, 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 MkVL-gS6XUJd for ; Mon, 31 Oct 2011 06:45:30 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 1C4DF21F8B7A for ; Mon, 31 Oct 2011 06:45:29 -0700 (PDT) X-AuditID: c1b4fb3d-b7c26ae0000035b9-a3-4eaea6794490 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 7A.96.13753.976AEAE4; Mon, 31 Oct 2011 14:45:29 +0100 (CET) Received: from [127.0.0.1] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.137.0; Mon, 31 Oct 2011 14:45:28 +0100 Message-ID: <4EAEA670.7000403@ericsson.com> Date: Mon, 31 Oct 2011 14:45:20 +0100 From: =?ISO-8859-1?Q?Stefan_H=E5kansson?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110922 Lightning/1.0b2 Thunderbird/3.1.15 MIME-Version: 1.0 To: rtcweb@ietf.org References: <20111024224257.28459.65554.idtracker@ietfa.amsl.com> <6EB8679A-13D5-4AD7-97F2-BC35FC0966F0@acmepacket.com> <2E239D6FCD033C4BAF15F386A979BF51159C32@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF51159D7A@sonusinmail02.sonusnet.com> <4EAAF413.8030501@alvestrand.no> <2E239D6FCD033C4BAF15F386A979BF51159D7B@sonusinmail02.sonusnet.com> <247FFE2C-DB2C-4280-A219-BE1503662F92@acmepacket.com> <4EAB2657.7090609@jesup.org> <4EAC24A2.70401@alvestrand.no> <4EADBAD3.5020804@mozilla.com> In-Reply-To: <4EADBAD3.5020804@mozilla.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [rtcweb] RTCWeb Forking usecase [was RE: draft-kaplan-rtcweb-sip-interworking-requirements-00] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 13:45:31 -0000 On 10/30/2011 10:00 PM, Timothy B. Terriberry wrote: >>> I think the most encouraging response I got before on this list was >>> that the API should always produce the same list of ICE candidates for >>> a given Web browser session. Because of this, all the offers from the > > I don't think this is possible, depending on what you mean by "web > browser session". People's web browsers move around, change which > networking device they're using, etc., at any time. At a minimum, you > need some interface to raise an error and deal with the fallout when you > require this behavior and it can't be provided. The PeerConnection > factory/cloning solution could potentially give you that (it could > simply fail if it can't use the same ICE candidates anymore). > >>> WebRTC client would be the same and simultaneous forking can be >>> implemented by creating a new peer connection for each answer, >>> generating and discarding the offer (since it is the same as the offer >>> from the original peer connection in this session) and feeding a new >>> answer to it. >> I considered it when we discussed this last, but I'm not sure it works. > > I'm confident it doesn't. Again, external cameras can be plugged in and > unplugged, etc., by the user at any time, and these can change the > capabilities exposed in the offer. This is also something you have to > deal with, if you really rely on "same offer" behavior. I have some faith in that it should work. Remember that we're dealing with candidates for one local port only (regardless of the MediaStream(s) added), so it should be possible to re-use that part. The application must of course make sure that it adds the right MediaStreams before the browsers enters a stable state. A bit complicated for the web developer maybe, but SIP-compatible forking in itself is a corner case from a webrtc perspective so I think that would be OK. > >> If we support SDES, the offer also contains crypto keys. Reusing crypto >> keys for all created connections would be a huge security vulnerability. > > I'm starting to come to the opinion that we shouldn't support SDES. If > we're doing it just for interop with legacy, we'd get better interop > with fewer headaches by supporting plain RTP. We'd have a distinction > between the two that I could actually explain to users, and less chance > of (unnoticed) downgrade attacks. > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From ibc@aliax.net Mon Oct 31 07:03: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 06D0221F8D84 for ; Mon, 31 Oct 2011 07:03:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.643 X-Spam-Level: X-Spam-Status: No, score=-2.643 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AnONpzkh71WB for ; Mon, 31 Oct 2011 07:03: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 6F27321F8D77 for ; Mon, 31 Oct 2011 07:03:16 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so5780182vcb.31 for ; Mon, 31 Oct 2011 07:03:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.27.241 with SMTP id w17mr4354314vdg.90.1320069795877; Mon, 31 Oct 2011 07:03:15 -0700 (PDT) Received: by 10.220.184.6 with HTTP; Mon, 31 Oct 2011 07:03:15 -0700 (PDT) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A058522356F25B3@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05852235717390@ESESSCMS0356.eemea.ericsson.se> <3BBCA56E-CA6E-4585-8EBB-ED6EDFED789F@cisco.com> <4EADF511.2040403@alvestrand.no> <387F9047F55E8C42850AD6B3A7A03C6CB8C4@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A058522356F25B3@ESESSCMS0356.eemea.ericsson.se> Date: Mon, 31 Oct 2011 15:03:15 +0100 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] Media forking solution for SIP interoperability (without a media gateway) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 14:03:17 -0000 2011/10/31 Christer Holmberg : > I would suggest that, instead of talking about a single PeerConnection, w= e talk about using the same local IP parameters and candicates for multiple= remote endpoints. It could be a single PC, or it could be multiple "cloned= " PCs. Hi Christer, as I replied you in other mail this needs to be clarified: When are local candidates generated? when creating a new PeerConnection object? or when creating a new ROAP Offer/Answer object? In the first case case you cannot reuse the same local candidates in a new PeerConnection. In the second case you can do it (if we assume that first we create a ROAP Offer, it creates local candidates and we pass the ROAP object to a new PeerConnection) then it would be possible just if the API allows that. > Again, let's first decide whether we need it - then we can start thinking= of how to get it :) Assuming the second case above I vote for the API to allow passing an already used local candidates into a new PeerConnection so we cover all the media forking cases. --=20 I=C3=B1aki Baz Castillo From roman@telurix.com Mon Oct 31 07:26: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 01D1521F8BF4 for ; Mon, 31 Oct 2011 07:26:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.908 X-Spam-Level: X-Spam-Status: No, score=-2.908 tagged_above=-999 required=5 tests=[AWL=0.068, 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 GNYknNHRBgXG for ; Mon, 31 Oct 2011 07:26: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 406C421F8B0D for ; Mon, 31 Oct 2011 07:26:06 -0700 (PDT) Received: by ywt2 with SMTP id 2so7137741ywt.31 for ; Mon, 31 Oct 2011 07:26:05 -0700 (PDT) Received: by 10.150.212.15 with SMTP id k15mr11270899ybg.56.1320071165680; Mon, 31 Oct 2011 07:26:05 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by mx.google.com with ESMTPS id r9sm52279387anh.8.2011.10.31.07.26.02 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 31 Oct 2011 07:26:04 -0700 (PDT) Received: by qyk34 with SMTP id 34so3685224qyk.10 for ; Mon, 31 Oct 2011 07:26:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.12.138 with SMTP id y10mr23527649pbb.70.1320071161570; Mon, 31 Oct 2011 07:26:01 -0700 (PDT) Received: by 10.68.62.170 with HTTP; Mon, 31 Oct 2011 07:26:01 -0700 (PDT) In-Reply-To: <4EAEA670.7000403@ericsson.com> References: <20111024224257.28459.65554.idtracker@ietfa.amsl.com> <6EB8679A-13D5-4AD7-97F2-BC35FC0966F0@acmepacket.com> <2E239D6FCD033C4BAF15F386A979BF51159C32@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF51159D7A@sonusinmail02.sonusnet.com> <4EAAF413.8030501@alvestrand.no> <2E239D6FCD033C4BAF15F386A979BF51159D7B@sonusinmail02.sonusnet.com> <247FFE2C-DB2C-4280-A219-BE1503662F92@acmepacket.com> <4EAB2657.7090609@jesup.org> <4EAC24A2.70401@alvestrand.no> <4EADBAD3.5020804@mozilla.com> <4EAEA670.7000403@ericsson.com> Date: Mon, 31 Oct 2011 10:26:01 -0400 Message-ID: From: Roman Shpount To: rtcweb@ietf.org Content-Type: multipart/alternative; boundary=bcaec51f907fa9e63404b099042b Subject: Re: [rtcweb] RTCWeb Forking usecase [was RE: draft-kaplan-rtcweb-sip-interworking-requirements-00] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 14:26:07 -0000 --bcaec51f907fa9e63404b099042b Content-Type: text/plain; charset=ISO-8859-1 As a lot of people pointed out here there are two issues here: 1. Use Case for Parallel Forking It is obviously needed for SIP interop. There are ways around it by using different signaling scenarios, or there are way to cheat this for some use cases (serial forking), but in the end of the day, to work with the widest possible set of end points parallel forking is highly desirable. Once again, a lot of people here raised the concern that parallel forking is only needed for SIP interop and nothing else. In some sense this is true, but in general, ability to do parallel forking should save a round trip and some complexity during call setup. Imagine a scenario where a call is answered by a single peer most of the times and by multiple peers in few cases. This can be the case when some of the peers are either groups or "shared lines" in PSTN speak. If we have parallel forking, WebRTC client will send an offer with media description. If the client gets a single answer it will setup a call as soon as this answer is available. If the client gets multiple answers, it will clone the PeerConnection and process each of those answers independently. Now, if we do not have parallel forking, WebRTC client will need to start a call without an offer, get offers from all the potential call destinations, and then create a PeerConnection for each and send an answer. Extra round trip and more code, even when the call is setup to one destination only (since the client does not know in advance if the destination it is calling is a single person or a group). So, yes, everything can be implemented without parallel forking, but will be a bit more complex. 2. Complexity this will introduce to the API: I think all we need is a single clone method on the PeerConnection. If you do not need parallel forking, you never call the clone method and no additional complexity is introduced. If you need parallel forking, it is available to you. _____________ Roman Shpount --bcaec51f907fa9e63404b099042b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable As a lot of people pointed out here there are two issues here:

1. Us= e Case for Parallel Forking

It is obviously needed for SIP interop. = There are ways around it by using different signaling scenarios, or there a= re way to cheat this for some use cases (serial forking), but in the end of= the day, to work with the widest possible set of end points parallel forki= ng is highly desirable.

Once again, a lot of people here raised the concern that parallel forki= ng is only needed for SIP interop and nothing else. In some sense this is t= rue, but in general, ability to do parallel forking should save a round tri= p and some complexity during call setup. Imagine a scenario where a call is= answered by a single peer most of the times and by multiple peers in few c= ases. This can be the case when some of the peers are either groups or &quo= t;shared lines" in PSTN speak. If we have parallel forking, WebRTC cli= ent will send an offer with media description. If the client gets a single = answer it will setup a call as soon as this answer is available. If the cli= ent gets multiple answers,=A0 it will clone the PeerConnection and process = each of those answers independently. Now, if we do not have parallel forkin= g, WebRTC client will need to start a call without an offer, get offers fro= m all the potential call destinations, and then create a PeerConnection for= each and send an answer. Extra round trip and more code, even when the cal= l is setup to one destination only (since the client does not know in advan= ce if the destination it is calling is a single person or a group). So, yes= , everything can be implemented without parallel forking, but will be a bit= more complex.

2. Complexity this will introduce to the API: I think all we need is a = single clone method on the PeerConnection. If you do not need parallel fork= ing, you never call the clone method and no additional complexity is introd= uced. If you need parallel forking, it is available to you.
_____________
Roman Shpount

--bcaec51f907fa9e63404b099042b-- From ibc@aliax.net Mon Oct 31 07: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 93DAF21F8B74 for ; Mon, 31 Oct 2011 07:35:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.643 X-Spam-Level: X-Spam-Status: No, score=-2.643 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cPUllCZOnkzG for ; Mon, 31 Oct 2011 07:35:25 -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 EDE1421F8B5D for ; Mon, 31 Oct 2011 07:35:24 -0700 (PDT) Received: by vws5 with SMTP id 5so5837462vws.31 for ; Mon, 31 Oct 2011 07:35:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.240.145 with SMTP id wa17mr4432394vdc.118.1320071724205; Mon, 31 Oct 2011 07:35:24 -0700 (PDT) Received: by 10.220.184.6 with HTTP; Mon, 31 Oct 2011 07:35:24 -0700 (PDT) In-Reply-To: References: <20111024224257.28459.65554.idtracker@ietfa.amsl.com> <6EB8679A-13D5-4AD7-97F2-BC35FC0966F0@acmepacket.com> <2E239D6FCD033C4BAF15F386A979BF51159C32@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF51159D7A@sonusinmail02.sonusnet.com> <4EAAF413.8030501@alvestrand.no> <2E239D6FCD033C4BAF15F386A979BF51159D7B@sonusinmail02.sonusnet.com> <247FFE2C-DB2C-4280-A219-BE1503662F92@acmepacket.com> <4EAB2657.7090609@jesup.org> <4EAC24A2.70401@alvestrand.no> <4EADBAD3.5020804@mozilla.com> <4EAEA670.7000403@ericsson.com> Date: Mon, 31 Oct 2011 15:35:24 +0100 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Roman Shpount Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] RTCWeb Forking usecase [was RE: draft-kaplan-rtcweb-sip-interworking-requirements-00] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 14:35:25 -0000 2011/10/31 Roman Shpount : > 1. Use Case for Parallel Forking > > It is obviously needed for SIP interop. There are ways around it by using > different signaling scenarios, or there are way to cheat this for some us= e > cases (serial forking), but in the end of the day, to work with the wides= t > possible set of end points parallel forking is highly desirable. > > Once again, a lot of people here raised the concern that parallel forking= is > only needed for SIP interop and nothing else. In some sense this is true, > but in general, ability to do parallel forking should save a round trip a= nd > some complexity during call setup. Imagine a scenario where a call is > answered by a single peer most of the times and by multiple peers in few > cases. This can be the case when some of the peers are either groups or > "shared lines" in PSTN speak. If we have parallel forking, WebRTC client > will send an offer with media description. If the client gets a single > answer it will setup a call as soon as this answer is available. If the > client gets multiple answers,=C2=A0 it will clone the PeerConnection and = process > each of those answers independently. Now, if we do not have parallel > forking, WebRTC client will need to start a call without an offer, get > offers from all the potential call destinations, and then create a > PeerConnection for each and send an answer. Extra round trip and more cod= e, > even when the call is setup to one destination only (since the client doe= s > not know in advance if the destination it is calling is a single person o= r a > group). So, yes, everything can be implemented without parallel forking, = but > will be a bit more complex. > > 2. Complexity this will introduce to the API: I think all we need is a > single clone method on the PeerConnection. If you do not need parallel > forking, you never call the clone method and no additional complexity is > introduced. If you need parallel forking, it is available to you. Ok so, if we all agree here (since it seems not to add too much complexity to the API), can we ask for the API to support this need? --=20 I=C3=B1aki Baz Castillo From petithug@acm.org Mon Oct 31 07:57:52 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3CE421F8D9D; Mon, 31 Oct 2011 07:57:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.45 X-Spam-Level: X-Spam-Status: No, score=-102.45 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KVuj4IR0MLpK; Mon, 31 Oct 2011 07:57:52 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 1E03521F8CF4; Mon, 31 Oct 2011 07:57:52 -0700 (PDT) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id B07D22025C; Mon, 31 Oct 2011 14:49:07 +0000 (UTC) Message-ID: <4EAEB76B.9090304@acm.org> Date: Mon, 31 Oct 2011 07:57:47 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20111010 Iceowl/1.0b2 Icedove/3.1.15 MIME-Version: 1.0 To: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= References: <4EAC6BF4.2000604@alvestrand.no> <4EAC8AE0.3020307@acm.org> <4EACD558.1050003@alvestrand.no> <4EAE157F.5020901@it.aoyama.ac.jp> In-Reply-To: <4EAE157F.5020901@it.aoyama.ac.jp> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: Keith Moore , Ned Freed , Behave WG , "rtcweb@ietf.org" Subject: Re: [rtcweb] URI schemes for TURN and STUN X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 14:57:53 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Martin, So I understand Roy's email as saying in fact the opposite of what Harald said, i.e. that using an "s" suffix to signify security is a good thing. What is your opinion on defining a generic scheme suffix (i.e. "+s" or "+sec") that would indicate a well defined set of security properties that could apply to any scheme, (vs the current "s" suffix where security properties has to be defined scheme by scheme)? Also, what would be the best place to discuss this? Thanks. On 10/30/2011 08:26 PM, "Martin J. Dürst" wrote: > For the http vs. https case, there is a very good answer from Roy Fielding at > http://lists.w3.org/Archives/Public/www-tag/2006Mar/0040.html > > In essence, not distinguishing the two schemes would mean either additional > roundtrips (assuming http is the more frequent one) or exposition of data on the > network that was supposed to be private. > > Regards, Martin. > > On 2011/10/30 13:40, Harald Alvestrand wrote: >> On 10/29/2011 04:23 PM, Marc Petit-Huguenin wrote: > On 10/29/2011 03:36 PM, Iñaki Baz Castillo wrote: >>>>> 2011/10/29 Harald Alvestrand: >>>>>> - I do not think it's appropriate to use "turn" and "turns" for >>>>>> indicating >>>>>> transport. Polluting the URI namespace with more configuration >>>>>> parameters in >>>>>> the form of trailing "s" is a Bad Thing. >>>>> But there should be some way to indicate that a TURN server listens in >>>>> TLS, right? >>>>> > We should continue this discussion in BEHAVE, but I would like to ask > the OP to > send a pointer on the RFC or discussion that says that using a > trailing "s" to > indicate security is a bad thing. >>> I'll have to forward this question to the apps ADs of a few years ago >>> about whether there's documentation for it. It does not seem to have >>> been captured in an RFC that I can find; discussion was in the >>> ~2000-2005 timeframe. >>> >>> The short version, from memory: Doing "s" locks you into one and exactly >>> one security scheme, and prevents you from saying anything about the >>> requisite parameters for that scheme, while using AUTH parameters such >>> as POP or in-band negotiation such as IMAP are much more flexible >>> approaches. >>> - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk6ut2kACgkQ9RoMZyVa61c3WQCeJVI5ov93J+RUp9xQvcggz8uf J8gAoJ2I4kAA1lGIOij6GTJmsbe4WEpg =n4RK -----END PGP SIGNATURE----- From wolfgang.beck01@googlemail.com Mon Oct 31 08:34: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 DE8CC21F8CF4 for ; Mon, 31 Oct 2011 08:34:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.802 X-Spam-Level: X-Spam-Status: No, score=-2.802 tagged_above=-999 required=5 tests=[AWL=-0.125, 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 TmTcSa4fn6XO for ; Mon, 31 Oct 2011 08:34:03 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 47EF621F8CE8 for ; Mon, 31 Oct 2011 08:34:03 -0700 (PDT) Received: by qadc10 with SMTP id c10so6456442qad.31 for ; Mon, 31 Oct 2011 08:34:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=KdmM0GV6fFCg7sW43E8MifAkvNuRbwBqLWEwoR2qzWU=; b=Uz73oxwDifENlWrGGuKylkglZIFJ79QeLnKUVUsKJwwKdEuq/jkQHDdNvhHsoaG1lW DhMLf6RIm/r6PmJgehhiOKilkbJJau53tLYGQd1wQJzcpqUb1ija3ciylNV92y28lfbw enncaeYgSZzQ3Whwmzs/VNqrnGqUn6OKrx5vI= MIME-Version: 1.0 Received: by 10.68.52.134 with SMTP id t6mr24094434pbo.96.1320075242578; Mon, 31 Oct 2011 08:34:02 -0700 (PDT) Received: by 10.68.64.66 with HTTP; Mon, 31 Oct 2011 08:34:02 -0700 (PDT) In-Reply-To: References: Date: Mon, 31 Oct 2011 16:34:02 +0100 Message-ID: From: Wolfgang Beck To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "" Subject: Re: [rtcweb] Does ROAP mandate the on-the-wire format? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 15:34:04 -0000 It's the question whether we see 'SDP' as browser-to-browser or as browser-to-server communication. If it was strictly browser-to-browser, W3C could define a blob format that just needs some transport, like ROAP. If we have interconnection, we have to do protocol translation and know the blob's format on some server. In this case, SDP is a good choice as we can avoid translating this format most of the time. Let's hope your implementation will not choke on SDPs like this one: http://osdir.com/ml/ietf.mmusic/2006-05/msg00045.html On Mon, Oct 31, 2011 at 10:44 AM, I=F1aki Baz Castillo wrot= e: > 2011/10/30 Cullen Jennings : >> Let's say the RTCWeb API passed JSON objects like the ones in ROAP in an= d out of the PeerConnection object. (I will be arguing that is one thing we= should consider). =A0At that oping you could write the SIP over webesocket= s in JS in the browsers. You might even find some useful info on how to do = the mapping in draft-jennings-rtcweb-signaling-gateway-01 >> >> I think there has been a lot of talking past each other on this. In some= cases ROAP over webesockets might be a protocol used to speak directly to = a ROAP to SIP signaling GW. So I view ROAP over a well defined transport to= be a on the wire protocol but certainly not the only on the wire protocol.= Just one that some systems could use. >> >> On the other hand, if one does SIP in JS (or the browser), that works to= o. >> >> Hope that helps clarify. > > Sure, thanks a lot. > > -- > I=F1aki Baz Castillo > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From harald@alvestrand.no Mon Oct 31 09:00: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 C8B5D11E80CA for ; Mon, 31 Oct 2011 09:00:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CKwECSPE4-9k for ; Mon, 31 Oct 2011 09:00:13 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 6D9ED21F8E31 for ; Mon, 31 Oct 2011 09:00:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7040B39E13F; Mon, 31 Oct 2011 17:00:09 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ck8qJaJkvJSH; Mon, 31 Oct 2011 17:00:08 +0100 (CET) Received: from [172.20.78.134] (63-145-238-4.dia.static.qwest.net [63.145.238.4]) by eikenes.alvestrand.no (Postfix) with ESMTPS id BD51D39E13B; Mon, 31 Oct 2011 17:00:07 +0100 (CET) Message-ID: <4EAEC609.1040707@alvestrand.no> Date: Mon, 31 Oct 2011 09:00:09 -0700 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: Ravindran Parthasarathi References: <20111024224257.28459.65554.idtracker@ietfa.amsl.com><6EB8679A-13D5-4AD7-97F2-BC35FC0966F0@acmepacket.com><2E239D6FCD033C4BAF15F386A979BF51159C32@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF51159D7A@sonusinmail02.sonusnet.com> <4EAAF413.8030501@alvestrand.no> <2E239D6FCD033C4BAF15F386A979BF51159D7B@sonusinmail02.sonusnet.com> <247FFE2C-DB2C-4280-A219-BE1503662F92@acmepacket.com> <387F9047F55E8C42850AD6B3A7A03C6CB953@inba-mail01.sonusnet.com> In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6CB953@inba-mail01.sonusnet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "" Subject: Re: [rtcweb] New usecase & requirement for media forking in browser X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 16:00:15 -0000 On 10/31/2011 06:23 AM, Ravindran Parthasarathi wrote: > Usecase: Media forking in browser > > Description: User forks local stream/stream components to multiple peers simultaneously and able to receive multiple streams from multiple peers. Ravindran, I see this as an implementation description, and not an use case. Could you rephrase this in terms that make it clear what the user will be trying to do, and that this technology (forking) is the appropriate solution for that problem? That will also help uncover more requirements that the use case will imply. For instance, if the idea is that the user talks to multiple persons simultaneously, and they are able to hear each other without a direct connection to each other, there is an added requirement that the user be able to mix audio from local and remote sources. Thank you! Harald Alvestrand > Functional requirement: F11, F12, (any new requirement has to be added ?) > > API requirement: The Web API MUST provide means for the web application to initiate sending/receiving of stream/stream components to a multiple peer simultaneously and relate each of these streams individually by web application. > > Having said that, I'm not very sure whether this usecase falls under the category of remote-recording by John. > > Hadriel, > > Thanks for the clarification on the current status and practical usecases. > > Thanks > Partha > > >> -----Original Message----- >> From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] >> Sent: Saturday, October 29, 2011 1:58 AM >> To: Ravindran Parthasarathi >> Cc: Harald Alvestrand; Iaki Baz Castillo; >> Subject: Re: [rtcweb] RTCWeb Forking usecase [was RE:draft-kaplan- >> rtcweb-sip-interworking-requirements-00] >> >> >> We've debated serial and parallel forking a number of times but I don't >> know if there's been consensus. >> >> But your email is really two different questions/topics: >> 1) Is there a use-case for forking within WebRTC? >> 2) Does supporting SIP forking mean the Browser has to handle the >> SDP/media behavior of it, vs. the Web-server/Interworking-function >> handling it? >> >> For the first question, I can certainly envision a Web-app wanting to >> let Alice press a single button on her Browser and end up communicating >> with Bob no matter where he may be, or letting her single button-press >> end up communicating with Bob first and then Charlie, or letting her >> single button-press end up communicating with Bob and Charlie at the >> same time. But I think such things can be accomplished through clever >> Web-app code without needing the Browser to be aware it's a forked >> ROAP/SDP scenario. >> [Note: though this may depend on what W3C decides the user-consent UI >> model is relative to PeerConnections, MediaStreams and ROAP] >> >> With regards to the second question, there was a long email thread on >> this which started here I think: >> http://www.ietf.org/mail-archive/web/rtcweb/current/msg01354.html >> >> -hadriel >> >> >> On Oct 28, 2011, at 3:14 PM, Ravindran Parthasarathi wrote: >> >>> Harald, >>> >>> Thanks for the clarification. "Fedex IVR" usecase is under browser to >> GW/server section (sec 4.3) which is a SIP based forking requirement. If >> you look at carefully, "Fedex IVR non-final response" scenario could >> have be achieved cleanly using two separate offer/answer exchange& two >> final responses (INVITE/200/ACK, RE-INVITE/200/ACK) : >>> 1) customer - fedex IVR offer/answer exchange >>> 2) fedex agent - Customer offer/answer exchange >>> >>> but it may be avoided in legacy for billing reasons which should not >> be major concern for RTCWeb. In case of SIP forking, it is assumed that >> 2nd answer override the 1st answer in the media plane. >>> As I mentioned earlier, SIP (serial) forking requirement shall be met >> by gateway signaling and no extra requirement for browser. Also, >> switching media stream from one responder to other responder in Fedex >> IVR usecase is not so easy because of legacy media handling (ICE, RTCP) >> differences as mentioned in draft-kaplan-rtcweb-sip-interworking- >> requirements-00. >>> ISTM, we don't have RTCWeb specific forking usecase till now. >>> >>> Thanks >>> Partha >>> >>>> -----Original Message----- >>>> From: Harald Alvestrand [mailto:harald@alvestrand.no] >>>> Sent: Friday, October 28, 2011 11:58 PM >>>> To: Ravindran Parthasarathi >>>> Cc: Iaki Baz Castillo; rtcweb@ietf.org; Hadriel Kaplan >>>> Subject: Re: [rtcweb] RTCWeb Forking usecase [was RE: draft-kaplan- >>>> rtcweb-sip-interworking-requirements-00] >>>> >>>> On 10/28/2011 10:56 AM, Ravindran Parthasarathi wrote: >>>>> By looking at draft-ietf-rtcweb-use-cases-and-requirements-06, I >> could >>>> not see any specific requirement for RTCWeb forking. In case SIP >> forking >>>> is the only requirement for RTCWeb and also, RTCWeb does not have any >>>> specific forking requirement, then the gateway between RTCWeb& SIP >>>> shall take care of the functionality. I'm asking this question to get >>>> the clarity on whether SIP forking feature has to impact RTCWeb >> client >>>> requirement or not. >>>> I believe the "Fedex IVR" case was specifically intended to surface >> the >>>> requirement for "non-final responses" (switching a media stream from >> the >>>> initial responder to a next responder). >>>> That's one form of forking ("serial fork"?) >>>> >>>> I haven't understood forking to be a requirement in any other use >> case. > From HKaplan@acmepacket.com Mon Oct 31 10:11: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 568A511E8187 for ; Mon, 31 Oct 2011 10:11:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.016 X-Spam-Level: X-Spam-Status: No, score=-2.016 tagged_above=-999 required=5 tests=[AWL=-0.317, BAYES_00=-2.599, J_CHICKENPOX_26=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 B5XV3kZu9T29 for ; Mon, 31 Oct 2011 10:11:09 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id A3FB211E8186 for ; Mon, 31 Oct 2011 10:11:09 -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, 31 Oct 2011 13:10:57 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.232]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Mon, 31 Oct 2011 13:10:57 -0400 From: Hadriel Kaplan To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= Thread-Topic: [rtcweb] Media forking solution for SIP interoperability (without a media gateway) Thread-Index: AQHMl/ANF66yIAkQ3keuKIcRRYYGfw== Date: Mon, 31 Oct 2011 17:10:56 +0000 Message-ID: <362C36E9-3C44-4CA1-9D87-58BD3356462D@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: [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: "" Subject: Re: [rtcweb] Media forking solution for SIP interoperability (without a media gateway) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 17:11:10 -0000 On Oct 29, 2011, at 1:29 PM, I=F1aki Baz Castillo wrote: [snipped example implementation scenario] > Conclusion > ---------------- >=20 > SIP media forking can be implemented in JavaScript without mandating > special requirements in WebRTC for interoperating with "legacy" SIP > (why do we call "legacy" to SIP???). And we just need tu use existing > SIP mechanisms. Right, as I said before, we don't actually have to implement ROAP forking i= n the browser, because the JS+Server code can be clever enough to do it, ev= en to SIP. The question is if we should implement it in the browser anyway, to make th= ings work better for the scenarios where they do go to SIP. We know that even an interworking-function can "hide" the forking, because = they do that right now for SIP-H.323; but we also know that doing so is err= or-prone and causes media-clipping. So if it's not too difficult/complicated to implement, handling it natively= in the browser is likely to yield the best user experience. And the nice = thing is that if the browsers get it wrong, or the WebApp doesn't want to d= o it, the JS+Server can still fix it or make it not happen. > No signaling gateway is required (of course !!) nor a media gateway > (if second bullet in "Assumtions" section above is satisfied). >=20 > We all are happy (but those who have in mind a market selling > WebRTC-SIP gateway boxes and want that the specs satisfy their > business model). I hope you don't think I'm arguing for things for the purpose of selling We= bRTC-SIP gateways. I'm trying very hard to list all the things a WebRTC do= main must do if it wants to *avoid* gateways. =20 [Not because my company doesn't plan on selling WebRTC-SIP gateways - but b= ecause people should use gateways/SBCs when they need to for security/contr= ol/etc., but not simply to interoperate.] -hadriel From ibc@aliax.net Mon Oct 31 10:27: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 78D5211E80B6 for ; Mon, 31 Oct 2011 10:27:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.344 X-Spam-Level: X-Spam-Status: No, score=-2.344 tagged_above=-999 required=5 tests=[AWL=-0.267, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_26=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 5zkFCfHb1Len for ; Mon, 31 Oct 2011 10:27:21 -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 988BA11E8095 for ; Mon, 31 Oct 2011 10:27:21 -0700 (PDT) Received: by vws5 with SMTP id 5so6036036vws.31 for ; Mon, 31 Oct 2011 10:27:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.27.241 with SMTP id w17mr5192856vdg.90.1320082041150; Mon, 31 Oct 2011 10:27:21 -0700 (PDT) Received: by 10.220.184.6 with HTTP; Mon, 31 Oct 2011 10:27:21 -0700 (PDT) In-Reply-To: <362C36E9-3C44-4CA1-9D87-58BD3356462D@acmepacket.com> References: <362C36E9-3C44-4CA1-9D87-58BD3356462D@acmepacket.com> Date: Mon, 31 Oct 2011 18:27:21 +0100 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] Media forking solution for SIP interoperability (without a media gateway) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 17:27:22 -0000 2011/10/31 Hadriel Kaplan : >> SIP media forking can be implemented in JavaScript without mandating >> special requirements in WebRTC for interoperating with "legacy" SIP >> (why do we call "legacy" to SIP???). And we just need =C2=A0tu use exist= ing >> SIP mechanisms. > > Right, as I said before, we don't actually have to implement ROAP forking= in the browser, because the JS+Server code can be clever enough to do it, = even to SIP. > > The question is if we should implement it in the browser anyway, to make = things work better for the scenarios where they do go to SIP. > > We know that even an interworking-function can "hide" the forking, becaus= e they do that right now for SIP-H.323; but we also know that doing so is e= rror-prone and causes media-clipping. > > So if it's not too difficult/complicated to implement, handling it native= ly in the browser is likely to yield the best user experience. =C2=A0And th= e nice thing is that if the browsers get it wrong, or the WebApp doesn't wa= nt to do it, the JS+Server can still fix it or make it not happen. I agree. In case it does not add a great complexity at API level it would be great if we can reuse same local candidates in more than a single PeerConnection. >> No signaling gateway is required (of course !!) nor a media gateway >> (if second bullet in "Assumtions" section above is satisfied). >> >> We all are happy (but those who have in mind a market selling >> WebRTC-SIP gateway boxes and want that the specs satisfy their >> business model). > > I hope you don't think I'm arguing for things for the purpose of selling = WebRTC-SIP gateways. Not at all, of course. You try to make WebRTC design open so any developer can implement whatever he wants without being constrained to specific and mandatory in-the-wire protocol or message format. >=C2=A0I'm trying very hard to list all the things a WebRTC domain must do = if it wants to *avoid* gateways. Yes, it's clear in the draft ;) > [Not because my company doesn't plan on selling WebRTC-SIP gateways - but= because people should use gateways/SBCs when they need to for security/con= trol/etc., but not simply to interoperate.] Agreed. --=20 I=C3=B1aki Baz Castillo From internet-drafts@ietf.org Mon Oct 31 15: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 10A121F0D1A; Mon, 31 Oct 2011 15:24:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 zAqdKiFOXPtU; Mon, 31 Oct 2011 15:24:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 581D31F0D05; Mon, 31 Oct 2011 15:24:43 -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.62 Message-ID: <20111031222443.4893.89089.idtracker@ietfa.amsl.com> Date: Mon, 31 Oct 2011 15:24:43 -0700 Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-rtp-usage-01.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 22:24:44 -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 (WebRTC): Media Transport an= d Use of RTP Author(s) : Colin Perkins Magnus Westerlund Joerg Ott Filename : draft-ietf-rtcweb-rtp-usage-01.txt Pages : 28 Date : 2011-10-31 The Web Real-Time Communication (WebRTC) framework aims to provide support for direct interactive rich communication using audio, video, collaboration, games, etc. between two peers' web-browsers. This memo describes the media transport aspects of the WebRTC framework. It specifies how the Real-time Transport Protocol (RTP) is used in the WebRTC context, and gives requirements for which RTP features, profiles, and extensions need to be supported. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rtcweb-rtp-usage-01.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-01.txt From csp@csperkins.org Mon Oct 31 16:12: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 D6D0B11E8371 for ; Mon, 31 Oct 2011 16:12:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=1.150, 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 2KDQ8qssF-bb for ; Mon, 31 Oct 2011 16:12:41 -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 1A5F511E836E for ; Mon, 31 Oct 2011 16:12:41 -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 1RL11z-0005Lv-Yb for rtcweb@ietf.org; Mon, 31 Oct 2011 23:12:39 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1251.1) From: Colin Perkins In-Reply-To: <20111031222443.4893.89089.idtracker@ietfa.amsl.com> Date: Mon, 31 Oct 2011 23:12:37 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <0AAEA389-AA57-4212-BE69-4A56122F57F4@csperkins.org> References: <20111031222443.4893.89089.idtracker@ietfa.amsl.com> To: rtcweb@ietf.org X-Mailer: Apple Mail (2.1251.1) Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-rtp-usage-01.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 23:12:42 -0000 On 31 Oct 2011, at 22:24, 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 : Web Real-Time Communication (WebRTC): Media = Transport and Use of RTP > Author(s) : Colin Perkins > Magnus Westerlund > Joerg Ott > Filename : draft-ietf-rtcweb-rtp-usage-01.txt > Pages : 28 > Date : 2011-10-31 >=20 > The Web Real-Time Communication (WebRTC) framework aims to provide > support for direct interactive rich communication using audio, = video, > collaboration, games, etc. between two peers' web-browsers. = This > memo describes the media transport aspects of the WebRTC framework. > It specifies how the Real-time Transport Protocol (RTP) is used in > the WebRTC context, and gives requirements for which RTP features, > profiles, and extensions need to be supported. >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-rtcweb-rtp-usage-01.txt We've updated our draft on RTP Requirements for RTC-Web, and renamed it = to better reflect the content. Changes in this version include: - Update title, rewrite Abstract and Introduction, and restructure the = draft - Update section on Rate Control and Media Adaptation - Update section on Use of RTP: Core Protocols - Add some initial discussion of multiplexing several RTP sessions onto = a single lower-layer transport, primarily referencing other drafts for = the content. - Address comments by Harald Alvestrand from the mailing list (29 August = 2011) - Update Security Considerations The main technical changes are in Section 8, and focus on the = requirements for Rate Control and Media Adaptation, the limitations of = RTCP when used for this purpose without RTP/AVPF, and interoperability = with legacy systems. There are also smaller technical changes, and = numerious editorial fixes, throughout. --=20 Colin Perkins http://csperkins.org/ From HKaplan@acmepacket.com Mon Oct 31 17:04: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 4347E11E841B for ; Mon, 31 Oct 2011 17:04:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.464 X-Spam-Level: X-Spam-Status: No, score=-2.464 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9s3kbDWr1nPv for ; Mon, 31 Oct 2011 17:04:12 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id A0FF521F8E28 for ; Mon, 31 Oct 2011 17:04:12 -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, 31 Oct 2011 20:04:11 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.232]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Mon, 31 Oct 2011 20:04:11 -0400 From: Hadriel Kaplan To: "rtcweb@ietf.org" Thread-Topic: Updated: draft-kaplan-rtcweb-sip-interworking-requirements-01.txt Thread-Index: AQHMmCnHGzx2Z/Uickm/hmIKlsrmbg== Date: Tue, 1 Nov 2011 00:04:10 +0000 Message-ID: <88AC506B-8DD5-4877-BC92-3BF48C89206C@acmepacket.com> References: <20111031234158.3511.34645.idtracker@ietfa.amsl.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="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Subject: [rtcweb] Updated: draft-kaplan-rtcweb-sip-interworking-requirements-01.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 00:04:13 -0000 Hello WebRTC Witches and Wizards, This is neither a trick nor a treat, but as scary as interworking with the = ghost of SIP may seem, I've conjured-up a new incantation of sip-interworki= ng-requirements draft with the following changes: 1) Replaced all "RTCWeb" with "WebRTC". 2) Added a section about, and requirement for, being able to detect whether= interworking is needed or not, on a per session basis. 3) Cast a spell over the draft to lull you to sleep if you read it. The new draft can be found here: http://tools.ietf.org/html/draft-kaplan-rtcweb-sip-interworking-requirement= s-01 Happy Halloween! -hadriel Begin forwarded message: > From: > Subject: I-D Action: draft-kaplan-rtcweb-sip-interworking-requirements-01= .txt > Date: October 31, 2011 7:41:58 PM EDT > To: > Reply-To: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. >=20 > Title : Requirements for Interworking WebRTC with Current SIP = Deployments > Author(s) : Hadriel Kaplan > Filename : draft-kaplan-rtcweb-sip-interworking-requirements-01.t= xt > Pages : 22 > Date : 2011-10-31 >=20 > The IETF RTCWEB WG has been discussing how to interwork WebRTC with > deployed SIP equipment and domains. Doing so may require an > Interworking Function middlebox in the media-plane. This document > lists some WebRTC-to-SIP use-cases, the WebRTC requirements to > support such, and the complexity involved in interworking if the > requirements cannot be met. >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-kaplan-rtcweb-sip-interworking-= requirements-01.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-kaplan-rtcweb-sip-interworking-r= equirements-01.txt > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From HKaplan@acmepacket.com Mon Oct 31 17:35: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 827E11F0DB9 for ; Mon, 31 Oct 2011 17:35:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.351 X-Spam-Level: X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, 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 SpSU2wNcKTtd for ; Mon, 31 Oct 2011 17:35:50 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id DF0611F0DB8 for ; Mon, 31 Oct 2011 17:35: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; Mon, 31 Oct 2011 20:35:45 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.232]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Mon, 31 Oct 2011 20:35:44 -0400 From: Hadriel Kaplan To: "rtcweb@ietf.org" Thread-Topic: I-D Action: draft-kaplan-rtcweb-api-reqs-01.txt Thread-Index: AQHMmC4wcxjbNKNDLU+ouuWfze9X7Q== Date: Tue, 1 Nov 2011 00:35:44 +0000 Message-ID: <8ADA4EB6-9ED1-4D08-8754-B265B749D3D1@acmepacket.com> References: <20111031234209.5019.49381.idtracker@ietfa.amsl.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="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Subject: [rtcweb] I-D Action: draft-kaplan-rtcweb-api-reqs-01.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 00:35:50 -0000 Although some were spooked by the previous version, I've updated draft-kapl= an-rtcweb-api-reqs-01 with the following changes: 1) Replaced all "RTCWeb" with "WebRTC". 2) Added the benefits of using a higher-layer API for testing and cross-bro= wser compatibility. 3) Used the Scourgify charm to clean some other nits. The purpose of resurrecting this ghoulish draft was for posterity, so that = Web search-engine zombies record a more accurate version, and the draft can= now be buried properly. I can't speak for the other co-authors, but I don= 't plan to update the draft again; like Linus and The Great Pumpkin, while = true believers wait we may miss the free candy. Happy All Hallow's Eve! -hadriel Begin forwarded message: > From: > Subject: I-D Action: draft-kaplan-rtcweb-api-reqs-01.txt > Date: October 31, 2011 7:42:09 PM EDT > To: > Reply-To: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. >=20 > Title : API Requirements for WebRTC-enabled Browsers > Author(s) : Hadriel Kaplan > Dan Burnett > Neil Stratford > Tim Panton > Filename : draft-kaplan-rtcweb-api-reqs-01.txt > Pages : 13 > Date : 2011-10-31 >=20 > This document discusses the advantages and disadvantages of several > proposed approaches to what type of API and architectural model > WebRTC Browsers should expose and use. The document then defines > the requirements for an API that treats the Browser as a library and > interface as opposed to a self-contained application agent. >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-kaplan-rtcweb-api-reqs-01.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-kaplan-rtcweb-api-reqs-01.txt > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From randell-ietf@jesup.org Mon Oct 31 20:18:41 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 186B411E8097 for ; Mon, 31 Oct 2011 20:18: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.050, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IveLVzYSlmde for ; Mon, 31 Oct 2011 20:18:40 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 2043E11E8082 for ; Mon, 31 Oct 2011 20:18:39 -0700 (PDT) Received: from pool-173-49-135-74.phlapa.fios.verizon.net ([173.49.135.74] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RL4s2-0008GO-85; Mon, 31 Oct 2011 22:18:38 -0500 Message-ID: <4EAF64FF.8020101@jesup.org> Date: Mon, 31 Oct 2011 23:18:23 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "rtcweb@ietf.org" References: <20111031211134.8188.49554.idtracker@ietfa.amsl.com> In-Reply-To: <20111031211134.8188.49554.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20111031211134.8188.49554.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Source: X-Source-Args: X-Source-Dir: Cc: Michael Tuexen Subject: [rtcweb] New Version Notification for draft-jesup-rtcweb-data-01.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 03:18:41 -0000 A new version of I-D, draft-jesup-rtcweb-data-01.txt has been successfully submitted by Randell Jesup and posted to the IETF repository. Filename: draft-jesup-rtcweb-data Revision: 01 Title: RTCWeb Datagram Connection Creation date: 2011-10-31 WG ID: Individual Submission Number of pages: 16 Abstract: This document investigates the possibilities for designing a generic transport service that allows Web Browser to exchange generic data in a peer to peer way. Several, already standardized by IETF, transport protocols and their properties are investigated in order to identify the most appropriate one. http://www.ietf.org/id/draft-jesup-rtcweb-data-01.txt Changes include: - small typos correction - tried to clarify in the Abstract that we are investigating the usage of IETF standardized protocols for the WebRTC data service - added some more text to Section 4.1 describing the different standardized DCCP CC - added the Justin contribution (now in Sections 4.3.1 and 4.4) - added the Cullen contribution in Section 5.1 - added in section 4.2 the fact that SCTP supports PPID feature (as suggested by Randal Stewart) - include the result of the list discussion related to Requirements - summarize the discussion on DTLS/SCTP vs SCTP/DTLS and include ICE in the stack picture Not yet incorporated in the draft: - Text about congestion control options and how that interacts with SCTP's changeable congestion mechanisms. From duerst@it.aoyama.ac.jp Mon Oct 31 23:37: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 DF1F911E8163 for ; Mon, 31 Oct 2011 23:37:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.89 X-Spam-Level: X-Spam-Status: No, score=-98.89 tagged_above=-999 required=5 tests=[AWL=-0.340, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, 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 KEZBp2dmDyHw for ; Mon, 31 Oct 2011 23:37:36 -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 938B211E808E for ; Mon, 31 Oct 2011 23:37:29 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id pA16bD0o015541 for ; Tue, 1 Nov 2011 15:37:17 +0900 Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 1e1f_16bc_ef0b0728_0453_11e1_abe7_001d096c5782; Tue, 01 Nov 2011 15:37:13 +0900 Received: from [IPv6:::1] ([133.2.210.1]:60382) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 1 Nov 2011 15:37:17 +0900 Message-ID: <4EAF9391.5040209@it.aoyama.ac.jp> Date: Tue, 01 Nov 2011 15:37:05 +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: Keith Moore References: <4EAC6BF4.2000604@alvestrand.no> <4EAC8AE0.3020307@acm.org> <4EACD558.1050003@alvestrand.no> <4EAE157F.5020901@it.aoyama.ac.jp> <4EAEB76B.9090304@acm.org> <8B0C4061-D362-4DFE-9677-7E64515A6E1C@network-heretics.com> In-Reply-To: <8B0C4061-D362-4DFE-9677-7E64515A6E1C@network-heretics.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Ned Freed , "rtcweb@ietf.org" , Keith Moore , Behave WG Subject: Re: [rtcweb] URI schemes for TURN and STUN X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 06:37:37 -0000 On 2011/11/01 0:33, Keith Moore wrote: > > On Oct 31, 2011, at 10:57 AM, Marc Petit-Huguenin wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Hi Martin, >> >> So I understand Roy's email as saying in fact the opposite of what Harald said, >> i.e. that using an "s" suffix to signify security is a good thing. >> >> What is your opinion on defining a generic scheme suffix (i.e. "+s" or "+sec") >> that would indicate a well defined set of security properties that could apply >> to any scheme, (vs the current "s" suffix where security properties has to be >> defined scheme by scheme)? > > > There is no "well defined set of security properties that could apply to any scheme". Security properties necessarily vary depending on the way a resource is used, the threat model, and so forth. Here I agree with Keith. > Also, the idea that there should be a "secure" bit in a URI scheme, to distinguish it from the "insecure" form of a URL, doesn't make much sense. You always want to use the best security that's available. You always want the best security you're willing to pay for. > You don't want that to depend on the URI scheme. Ideally not, but in actual operation, it made a lot of sense for HTTP as Roy has explained. > The "s" convention was a hack to distinguish "x over SSL" from "x" for all of the URIs that existed before SSL was well-established, because those protocols didn't (then) have a way to negotiate security in-band. It made sense as a short term hack, Yes. It also makes sense in current-day operation. > but not as an architectural feature. It's not something that we want to propagate to new URI types, neither in the form of an "s" suffix, nor as any other syntactic convention. In most cases probably not. But there may be cases similar to HTTP/S where it makes sense. Each case has to be analyzed independently. Regards, Martin. > Keith > >