Re: [MMUSIC] Updating the pacing of ICE connectivity checks

[Emil Ivov <[e-mail]>]

Well for one, we hadn't even noticed that there was different pacing for
non-RTP traffic, so when we added support for Pseudo TCP to ice4j.org,
we just let it use the default timers. It really didn't cross our
collective minds that the same stack in the same application would have
the right of going down to 20ms if it used the magic word (and RTP
header) but then go back up to 500 ms if it didn't. It's almost as if it
were punished for having bad non-RTP thoughts ;)

Anyways, I think that, had we known about the "MUST NOT drop below 500
ms" limitation, we would have simply ignored it: these are user
perceptible delays after all, and no one would like to wayt 10+ seconds
for a file to start transferring.

Cheers,
Emil

On 15.02.13, 17:47, Gonzalo Camarillo wrote:
> Hi,
> 
> to add to what Magnus said, it is important that we understand what
> implementations have been doing so far (regardless of what the RFC says)
> and that we come up with recommendations implementers will actually
> follow. Keep in mind we are here to write specifications, not fiction ;-)
> 
> Thanks,
> 
> Gonzalo
> 
> 
> On 14/02/2013 5:51 PM, Magnus Westerlund wrote:
>> Thus I would be careful with speeding up Ta for RTP to much, and I think
>> someone needs to fine empiric data that it would work.
>>
>> For the the 500 ms that can likely be significantly lowered without any
>> issues. But some considerations around the wider usage needs to be taken
>> into account.
> 
> 

-- 
https://jitsi.org