Re: [rtcweb] Let's define the purpose of WebRTC

Randell Jesup <randell-ietf@jesup.org> Tue, 08 November 2011 16:42 UTC

Return-Path: <randell-ietf@jesup.org>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 492E321F8B62 for <rtcweb@ietfa.amsl.com>; Tue, 8 Nov 2011 08:42:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.559
X-Spam-Level:
X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eBiZ8j2iQjMi for <rtcweb@ietfa.amsl.com>; Tue, 8 Nov 2011 08:42:43 -0800 (PST)
Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id B7DBD21F8B4A for <rtcweb@ietf.org>; Tue, 8 Nov 2011 08:42:43 -0800 (PST)
Received: from pool-173-49-135-74.phlapa.fios.verizon.net ([173.49.135.74] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <randell-ietf@jesup.org>) id 1RNol0-00064C-Sk for rtcweb@ietf.org; Tue, 08 Nov 2011 10:42:42 -0600
Message-ID: <4EB95BE1.5060706@jesup.org>
Date: Tue, 08 Nov 2011 11:42:09 -0500
From: Randell Jesup <randell-ietf@jesup.org>
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: <CALiegfkVNVAs_MyU_-4koA4zRwSn1-FwLjY9g_oZVkhi9rSK5Q@mail.gmail.com> <CAD5OKxt=k_Mon_GMs1w-bGMgpk12h6ZQ=FkoRVsTp4271iMSLA@mail.gmail.com> <CABcZeBNMTgwH-R_jd-AiEJ8tELTeFMNm-bAJohRg2RxD5e+kZQ@mail.gmail.com> <CAD6AjGRBmrAqB3CEWxtaXnryPA5App13S2jJPAt+7HwWZsQFzA@mail.gmail.com> <CABcZeBNtoizuRymVMxF4CdiLu1Nju63C0xkWJHjoarpxeLXjyA@mail.gmail.com> <CALiegfk=oJJ20GhKQBKA7aspHhUyQ-s+DR-qSi4XV455Nj718w@mail.gmail.com> <9C4C8AE2-4AFF-4553-9D19-556F12AC066E@phonefromhere.com> <9B907E0E-7FE7-4302-BDFA-CEEC12734B8C@edvina.net> <7BF02133-2A7E-48ED-982F-90B7868F9FB9@phonefromhere.com> <4EB74D06.8000006@jesup.org> <CAAJUQMihjTRgpO8hjgiYz5iLbWTncdXFO8nnRE9VDRND36-b2w@mail.gmail.com> <4EB7FAED.4070104@jesup.org> <4EB806F7.2090603@alvestrand.no> <CAAJUQMjcoR+epj03GWyAmZbdLPt87KHACEGH7oQubaGm7CTZUQ@mail.gmail.com> <4EB816D1.1040708@jesup.org> <CAAJUQMjEErTx-kinq+j06q8Us+nvZcwpXiDnO7_6=Z9DUV4+ng@mail.gmail.com>
In-Reply-To: <CAAJUQMjEErTx-kinq+j06q8Us+nvZcwpXiDnO7_6=Z9DUV4+ng@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jesup.org
X-Source:
X-Source-Args:
X-Source-Dir:
Subject: Re: [rtcweb] Let's define the purpose of WebRTC
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Nov 2011 16:42:44 -0000

On 11/8/2011 4:43 AM, Wolfgang Beck wrote:
> On Mon, Nov 7, 2011 at 6:35 PM, Randell Jesup<randell-ietf@jesup.org>  wrote:
>> On 11/7/2011 11:53 AM, Wolfgang Beck wrote:
>>>
>>> On Mon, Nov 7, 2011 at 5:27 PM, Harald Alvestrand<harald@alvestrand.no>
>>>   wrote:
>>> [on SIP-style forking]
> [..]
>> And I disagree with Harald here; telling the clients they should open
>> connections to the "caller" is exactly what parallel forking by the server
>> does.  It tells them "here's the offer and ICE candidates, open a connection
>> to the "caller" and complete negotiation."  It'd be silly not to include the
>> OFFER in the message to the "callee's", since we have to send them the ICE
>> candidates anyways - plus, the "callee's" may need that info for alerting,
>> etc, and not providing it would add more round-trips.  Never forget that
>> even half-round-trips can be PAINFUL to some applications!  And don't forget
>> that this might get used on links that bounce off a satellite (or two!), or
>> transit low-bandwidth wireless networks or mesh networks, etc.  Now there's
>> RTT... ;-)
>>
> If you are on satellite links, the signaling round trip time is not
> your most pressing problem.

Yes, but people do talk over them, and may do other "real-time" things 
over them.  Sometimes that's simply the only option.  Even my Uncle in 
Virginia "horse country" (= $$$$$) can't get anything better than 
dial-up or satellite internet, because houses are so far apart and far 
from telco office.  And then there are people/soldiers/etc in 3rd-world 
countries or disaster relief efforts, etc.

>
> Is forking really essential or is it just a way to optimize call setup
> time under certain conditions?

I think in most cases you can set up the calls with other methods of 
varying complexity and delays.  Hard to be sure that all uses would be 
covered by that, and some might involve extra consents be generated to 
the user, or some method of tying the OFFERs together, and I'm not sure 
that can easily be done if we don't trust the JS code.  (though it might 
not be a real concern - we haven't looked at this re: security/privacy yet).

> Has forking still an advantage if you want to do multiple early media?

I suspect forking is an advantage here, but haven't analyzed it.


-- 
Randell Jesup
randell-ietf@jesup.org