[jitsi-dev] Sometimes sluggish ice connection time when using audio mixing


#1

Spent the last couple days trying to track down occasional slow ice
connection times for clients. I was seeing ice connection times fall into
one of two categories basically:

- Very fast (entire flow finishes in 1-2 seconds)
- Sluggish (entire flow takes 6+ seconds to complete)

I was finally able to track this down to the rtp manager for the mixer
taking a while to start up (I didn't dig in to specifically why).

Some context:
- IceUdpTransportManager establishes the ice connection and then calls
onIceConnected to notify all the channels that it's connected.
- DtlsPacketTransformer will not accept any incoming dtls packets until the
dtlsTransport is set.
- dtlsTransport gets set when the channel starts its streams

The twist here is that: since audio is typically the first media block in
the sdp, it gets called first in the loop to notify onIceConnected. Since
with the mixer enabled audio can be slow to start up, it takes a while to
set the connector and have DtlsPacketTransformer start listening. This
gets doubly-punished because chrome does an exponential backoff when it
sends client hellos...so if the first one is missed it waits a second, then
2 seconds, then 4, etc. Audio channel startup taking 5+ seconds means
we'll not only miss the first couple hellos, but the subsequent one (once
we are ready) will take even longer.

Not sure if there is a real fix here...it doesn't happen every time, so
there may be something in the fmj rtpManager initialization code that can
be fixed to prevent it from taking too long. I may do something like tweak
the order of the channel onIceConnected notifications to prefer video
first. Anyway, just a heads up in case anyone else is being hit by this.


#2

Have you tried Videobridge as the DTLS client instead of Chrome?
That's done through the setup attribute as defined by
https://xmpp.org/extensions/xep-0320.html and
https://tools.ietf.org/html/rfc5763. Then Videobridge will send the
DTLS ClientHello as soon as it's ready and I expect Chrome's
exponential back-off will not matter.

ยทยทยท

On Thu, Sep 8, 2016 at 11:29 PM, Brian Baldino <brian@highfive.com> wrote:

This gets
doubly-punished because chrome does an exponential backoff when it sends
client hellos...so if the first one is missed it waits a second, then 2
seconds, then 4, etc. Audio channel startup taking 5+ seconds means we'll
not only miss the first couple hellos, but the subsequent one (once we are
ready) will take even longer.