We are experiencing an artificial delay in our call setup when using SIP.js with an Asterisk backend over a WebSockets transport.
We recently noticed that when configuring a high iceGatheringTimeout value (e.g., 5000 ms), SIP.js holds back the SIP signaling (INVITE / 200 OK) for exactly that duration, even if the underlying browser engine has already finished gathering all viable ICE candidates within milliseconds.
The Behavior We See (From chrome://webrtc-internals):
When analyzing our WebRTC dumps, we see a clean, immediate gathering process from the browser, but an exact 5-second stall before the SIP layer reacts:
14:09:58.621 – Gathering starts (iceTransportPolicy: "all").
14:09:58.709 – The browser finishes gathering local and STUN candidates. The state transitions to iceGatheringState: "complete" (taking only ~88ms total).
The Stall – The browser sits idle, waiting.
14:10:03.621 – Exactly 5000ms after gathering started, the session description handler flushes.
14:10:03.714 – The SIP message goes out, and the connection transitions to connected instantly.
If we lower iceGatheringTimeout to 1000, the call delays for exactly 1000ms. If we set it to 750, it delays for exactly 750ms.
Based on standard WebRTC behavior, the iceGatheringTimeout should act as an upper ceiling (maximum timeout) to abort a stalled gathering process. If the browser fires an explicit iceGatheringState === 'complete' event before the timeout expires, the application should theoretically resolve the SDP and proceed immediately.
Instead, it appears that SIP.js is treating iceGatheringTimeout as a mandatory, blocking setTimeout window.
Is this expected? Is there a work-around for this, configuration etc.?
We are experiencing an artificial delay in our call setup when using SIP.js with an Asterisk backend over a WebSockets transport.
We recently noticed that when configuring a high iceGatheringTimeout value (e.g., 5000 ms), SIP.js holds back the SIP signaling (INVITE / 200 OK) for exactly that duration, even if the underlying browser engine has already finished gathering all viable ICE candidates within milliseconds.
The Behavior We See (From chrome://webrtc-internals):
When analyzing our WebRTC dumps, we see a clean, immediate gathering process from the browser, but an exact 5-second stall before the SIP layer reacts:
14:09:58.621 – Gathering starts (iceTransportPolicy: "all").
14:09:58.709 – The browser finishes gathering local and STUN candidates. The state transitions to iceGatheringState: "complete" (taking only ~88ms total).
The Stall – The browser sits idle, waiting.
14:10:03.621 – Exactly 5000ms after gathering started, the session description handler flushes.
14:10:03.714 – The SIP message goes out, and the connection transitions to connected instantly.
If we lower iceGatheringTimeout to 1000, the call delays for exactly 1000ms. If we set it to 750, it delays for exactly 750ms.
Based on standard WebRTC behavior, the iceGatheringTimeout should act as an upper ceiling (maximum timeout) to abort a stalled gathering process. If the browser fires an explicit iceGatheringState === 'complete' event before the timeout expires, the application should theoretically resolve the SDP and proceed immediately.
Instead, it appears that SIP.js is treating iceGatheringTimeout as a mandatory, blocking setTimeout window.
Is this expected? Is there a work-around for this, configuration etc.?