204682 2019-11-28 07:34:12 -0800 PeerConnection: Remote audio is muted if user receives phone call (even if phone call dismissed) 2020-03-23 10:09:02 -0700 1 1 1 Unclassified WebKit WebRTC Safari 13 iPhone / iPad iOS 13 RESOLVED FIXED InRadar P2 Normal --- 1 daginge webkit-unassigned gabor webkit-bug-importer youennf oldest_to_newest 1594040 0 daginge 2019-11-28 07:34:12 -0800 Summary: If a user is in a WebRTC call and receives an incoming phone call, dismisses it, and comes back to Safari, the remote audio is muted. Steps to reproduce: 1. Go to https://webrtc.github.io/samples/src/content/peerconnection/pc1/ on an iPhone running iOS 13.2.3 2. Start a peer connection 3. Verify that you hear the other side 4. Receive incoming phone call and dismiss it 5. Observe that you are taken back to Safari, and that the remote audio is now gone. 6. Hang up the call 7. Click "Call" again 8. Observe that you can now hear the other side again Expected behaviour: The video call is muted while the phone call is in progress, but that audio is resumed once the phone call has been ended/dismissed. Actual behaviour: The video call remote end is muted until the peer connection is restarted (does not seem like iceRestart does anything, has to be a new peer connection, possibly just a new video element). Impact: All sites using WebRTC on Safari for iOS, where the user might get a call in the middle of the video call. Workaround: Seems like restarting the peer connection or refreshing the page helps. You can somewhat detect this issue by doing audio analysis using WebAudio to check the output data of the remote stream. This appears to be 0. I have found no other workaround as of yet, but suspect killing the video DOM element and adding a new one should fix things. 1630267 1 webkit-bug-importer 2020-03-16 01:32:46 -0700 <rdar://problem/60486776> 1632748 2 youennf 2020-03-23 01:11:17 -0700 I believe https://bugs.webkit.org/show_bug.cgi?id=209411 and https://bugs.webkit.org/show_bug.cgi?id=209412 will fix this. 1632896 3 youennf 2020-03-23 10:09:02 -0700 Closing as both bugs are fixed.