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

[Randell Jesup <[e-mail]>]

On 11/7/2011 7:20 AM, Wolfgang Beck wrote:
> On Mon, Nov 7, 2011 at 4:14 AM, Randell Jesup<[e-mail]>  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
[e-mail]