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