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

Randell Jesup <randell-ietf@jesup.org> Mon, 07 November 2011 15:36 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 2175521F85A4 for <rtcweb@ietfa.amsl.com>; Mon, 7 Nov 2011 07:36:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.554
X-Spam-Level:
X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KvQ2VeVT1zMA for <rtcweb@ietfa.amsl.com>; Mon, 7 Nov 2011 07:36:46 -0800 (PST)
Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 79C1A21F8512 for <rtcweb@ietf.org>; Mon, 7 Nov 2011 07:36:46 -0800 (PST)
Received: from pool-173-49-135-74.phlapa.fios.verizon.net ([173.49.135.74] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <randell-ietf@jesup.org>) id 1RNRFd-0000vP-K4 for rtcweb@ietf.org; Mon, 07 Nov 2011 09:36:45 -0600
Message-ID: <4EB7FAED.4070104@jesup.org>
Date: Mon, 07 Nov 2011 10:36:13 -0500
From: Randell Jesup <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>
In-Reply-To: <CAAJUQMihjTRgpO8hjgiYz5iLbWTncdXFO8nnRE9VDRND36-b2w@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: Mon, 07 Nov 2011 15:36:47 -0000

On 11/7/2011 7:20 AM, Wolfgang Beck wrote:
> On Mon, Nov 7, 2011 at 4:14 AM, Randell Jesup<randell-ietf@jesup.org>  wrote:
>> On 11/6/2011 9:01 AM, Tim Panton wrote:
>>> [..]
>>
>> For example, you mention forking and glare.  Well, I've given very
>> non-interop cases of where forking would be useful: contacting someone who
>> has 2 desktops, a notebook, a tablet, and a phone all logged into the
>> service, or some of the game scenarios, or a very non-standard-SIP-like mesh
>> conference using forked invites.

> Do you really need forking to achieve this? Couldn't you just return
> references to those devices back to the caller
> which can then decide how to call them? A redirect server instead of a
> forking proxy?

So I assume instead of letting the server fork, you'd have the server 
return "you should really call these N specific sub-addresses", and have 
the client redo the call with those sub-addresses (which BTW complicates 
the security and camera/mic access model, I think).  It would then 
generate N parallel OFFERs via the server.

This generates several unwanted side-effects:

a) possible more complex security/user-agreement issues

b) at a minimum an extra round-trip for call setup if "forking" is 
needed, before any client is informed there's an incoming call.  In 
practice this may be much worse, since N parallel OFFERs will mean N ICE 
candidate harvestings in order to send out the OFFERs.

c) when one candidate is ACCEPTed, the client will be responsible for 
cancelling the OFFERs to the others (assuming it only wanted one 
conversation), or more ongoing resources used, if it wants to leave the 
option for other 'forked' destinations to answer.

d) higher bandwidth and resource use, both by the client and the server. 
  While this may seem minor, the extra energy used (and extra network 
traffic for ICE, cancelling OFFERs, etc) could actually matter for 
mobile clients, which is where all of this will likely be moving to.

There's also a timing hole opened (small) where the list returned may no 
longer be correct when the multiple OFFERs are sent - I think this, 
while real, doesn't really matter in practice.

> Forking is a good example how interop -- with SIP or with different
> RTCWEB apps -- complicates things significantly.

I think letting the server fork it (parallel forking) actually is less 
complication in practice.

>> And glare: Cullen's classic example of glare is two people talking, browser to browser, and one saying "lets add
>> video", and both turning it on.  No interop or SIP required for that to
>> cause glare.
> If your service requires this function, yes, you're right. It has
> nothing to do with SIP and interop.
>
> The question is: does a JS client have to deal with glare handling if
> it can exclude conflicting offers by other means. My 'click here to
> speak to a human' application might never need this at all.

If there's any way both the client and the person at the other end could 
cause a re-OFFER (say if your local IP address changes??), then glare is 
always possible.  Best to simply design for it so the application 
doesn't need to, especially since most app developers will have no 
concept what glare is or why it might happen.


-- 
Randell Jesup
randell-ietf@jesup.org