Re: [rtcweb] draft-alvestrand-one-rtp-00.txt ICE usage

[Randell Jesup <[e-mail]>]

On 8/12/2011 11:57 AM, Paul Kyzivat wrote:

> Trimming, and changing subject
> On 8/12/11 11:20 AM, Harald Alvestrand wrote:
>> There are 2 possible things to do for the offerer:
>> - Start ICE procedure on all ports when sending the offer
>> - Wait until the answer comes back, and either start ICE procedure on
>> one port (if the responder understood TOGETHER), or start the ICE
>> procedure on all ports (if the responder did not understand TOGETHER)
>> The first alternative is a number of milliseconds faster, but others
>> should chime in on whether that's significant or not.
1/2 RTT is significant especially on slower/longer-distance connections,
since I think all the other setup stuff we're talking about adds up.
We have to make sure that we don't have the "...lo?" problem when
answering an incoming connection.  (Setup delay of more than a couple
hundred ms causes first syllables to be lost.)  It might even be worse on a
computer if the person has a headset on or answers in speakerphone mode with
a button press - you don't have the natural delay of bringing a receiver to
face.

> (I don't know much about ICE, so just call me on it if I say something
> stupid)
> IIUC, there are some aspects of ICE that MUST be done before sending the
> offer. Specifically that involved gathering the candidate list, which
> may involve assignment of multiple local ports, interactions with a TURN
> server, etc. I don't think everything can be deferred until the answer
> is received.
Right; one assumes you've done them.

> (I suppose one approach would be for the initial offer to set the port
> to zero in all but the first m-line. Then, once the first answer is
> received, indicating whether TOGETHER is supported, another offer can be
> generated, using appropriate ICE based on whether using TOGETHER or not.
> But that does start to get complex.)
That forces a full extra RTT plus overhead...  Ouch.

-- 
Randell Jesup
[e-mail]