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

[Randell Jesup <[e-mail]>]

On 11/7/2011 11:53 AM, Wolfgang Beck wrote:
> On Mon, Nov 7, 2011 at 5:27 PM, Harald Alvestrand<[e-mail]>  wrote:
> [on SIP-style forking]
>> If we were doing a greenfield application, I'd let the server tell all the
>> possible endpoints that they should set up a connection to the original
>> caller, and forget about the caller calling anyone.
>>
>> The difference between caller and callee is a question of your level of
>> abstraction.....
>
> That's the kind of innovative thinking I thought RTCWEB was all about.
>
> And this forking discussion is a good example how the requirement to
> have interop between different RTCWEB apps and/or SIP is holding us
> back. Ditch the trapezoid and do greenfield.

This has nothing to do with trapezoids.  This is something I believe we 
need even if there was an absolute block on SIP interop.

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... ;-)

Now, the "caller" may have taken the first ACCEPT, or it might run them 
parallel until a final accept on one, or it might keep all the options 
open for the entire "call" (which doesn't map super-well to SIP, note, 
though it can be emulated in SIP).  So the "caller" may decline the 
ANSWERs or final ANSWERS (ACCEPTs) from any of the forked "callees". 
That's entirely up to the app.


-- 
Randell Jesup
[e-mail]