Frequently Asked Questions
Delay in Starting a Stream – WebRTC
It takes a few seconds from the time that I initiate a connection, to the time that I can see the video. Is there a way for me to improve on this?
Unfortunately, that delay is due to the nature of WebRTC and the security parameters (ICE) it runs.
Every time a client is preparing to set-up an ICE connection it needs to gather candidate addresses. In addition to addresses that appear on the local interfaces, this also includes acquiring STUN bindings, Jingle Nodes and TURN allocations or executing UPnP or PCP queries.
Once the above are completed, the client would take all the resulting candidates and send them to the remote party where the exact same process would start.
Additionally, many of these have to be executed through all the interfaces on the client endpoint. There are many ways for this process to run into speed bumps and delay the establishment of a connection:
- A VPN interface with no Internet connectivity. This would mean that VoIP clients will try to get in touch with STUN and TURN servers through it but never get a response. Their transactions would have to timeout before the client proceeds
- A wireless interface that appears “up” but is otherwise not connected (e.g. because it attached to a hotspot with a captive portal)
- A STUN/TURN server that went down for some reasons and is not even returning “port unreachable” ICMP errors.