Bug 213853 – Mic input is not returned to the mediaStream after a GSM call

• Status: NEW
• Component: WebRTC

[Francesco Durighetto (kekkokk)]

Test environment:
- Device A, iPhone Xr iOS: 13.6 beta 3, Safari mobile browser
- Device B, whatever desktop/mobile browser

Use case:
User A and B are in a webrtc audio/video call (the audio getusermedia is done with the constraint echoCancellation: true, bu I don't think it matters).
User A receive a GSM call, answer to it.

What do you expect?
When user A join the GSM call, the audio mediaStreamTrack emit a muted event since the GSM call "steal" the input of the mic and when the user A dial out the call and goes back to the webrtc call in safari the microphone input came back active (as works for the camera input, which is handled correctly).

What happens instead?
The user A receives a stream muted event and the microphone input "stops", but when he dial out the GSM call the ownership of the microphone never goes back to Safari. In this case I would at least expect an ended event from the audio mediaStreamTrack to be able to manually do a getusermedia again, but this does not happen.
So it's impossible to programmatically know when the user microphone "blacks out".


This caused lots of complaints about clients whose have encountered audio problems after receiving normal GSM calls.

[Radar WebKit Bug Importer]

<rdar://problem/65058300>

[Dag-Inge Aas]

Can confirm this is a problem. The underlying issue is that the microphone track goes to "muted" (by the OS) when you receive an incoming call, but it never goes back to "unmuted". 

The only fix I have been able to find is to add a button the user can click that there is a problem with the microphone, which is automatically removed should the audio track go back to "unmuted". If it doesn't, the user will see it, click the button, and we can restart the track and apply the new track to all the active PCs.

Note: None of the "visibilitychange" or similar browser events are fired upon returning from a call if you simply dismissed it. So I have not found a way to automatically detect that the user is back to automatically fix this yet. A user interaction is therefore needed.