I am facing an issue with a WebRTC softphone implemented using SIPml5 and Asterisk, specifically related to Chrome’s WebRTC media lifecycle.
Scenario
-
The application uses WebRTC (SIP over WebSocket).
-
Calls are originated by the backend (Asterisk originate).
-
The browser receives an incoming call and either:
-
Automatically accepts it, or
-
The user explicitly accepts the call.
-
-
The microphone permission is granted by the user.
Problem
Even when the user allows microphone access, the following behavior occurs:
-
The first call works correctly, with audio flowing normally.
-
After the call ends, all subsequent calls fail.
-
SIP signaling remains normal and calls are established.
-
No audio is transmitted or received.
-
Chrome does not ask for microphone permission again.
-
The WebRTC session appears connected, but media is not established.
-
The only way to recover is:
-
Reloading the page, or
-
Resetting site permissions in Chrome.
-
This behavior occurs regardless of whether the call is accepted automatically or via explicit user interaction.
Observations
-
SIP registration remains active.
-
SIP signaling is successful for every call.
-
Media works only once per page load.
-
After the first call termination, the media subsystem seems to be in an invalid or locked state.
-
No explicit errors are reported by SIPml5 or the browser console.
-
The issue is reproducible and Chrome-specific.
Question
Is this an expected behavior of Chrome’s WebRTC implementation?
Specifically:
-
Does Chrome restrict WebRTC media usage to a single call per page lifecycle?
-
Is there a known limitation where
getUserMedia()or media tracks cannot be reused after a call ends? -
Could this be related to Chrome’s autoplay or media permission policies rather than SIP or Asterisk?
Any insight into Chrome’s WebRTC media lifecycle and permission handling would be appreciated.