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

[Wolfgang Beck <[e-mail]>]

On Mon, Nov 7, 2011 at 6:35 PM, Randell Jesup <[e-mail]> wrote:
> 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]
[..]
> 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.

Is forking really essential or is it just a way to optimize call setup
time under certain conditions?
Has forking still an advantage if you want to do multiple early media?

[suppressing a remark how overlap dialing could speed up call setup
times in some interop scenarios, too]


Wolfgang Beck