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

[Paul Kyzivat <[e-mail]>]

On 8/12/11 1:41 PM, Randell Jesup wrote:
> 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.

Note that this matters if the extra signaling happens after the callee 
answers. If it happens *before* the answer, then it just extends the 
"ring time" but doesn't cause clipping.

>> (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.

Again, if the extra round trip happens during "alerting" it may not be 
objectionable.

Also, if the first m-line is audio, it can get going sooner, with the 
video to follow with a slight lag.

But I agree this isn't the nicest of solutions. I'm just putting out 
some candidates to consider.

	Thanks,
	Paul