Summary: The browser page is refreshed or iOS User is disconnected from the call if iOS User receives a PSTN/FaceTime call and waits at least 1 min in the middle of WebRTC call Tested devices: The bug is reproducible on: - iPhone 11 Pro Max (iOS 17 Public Beta 4, build: 21A5312c) and Safari - iPhone 13 (iOS 17 Public Beta 4, build: 21A5312c) and Safari The bug is not reproducible on: - iPhone 13 (iOS 16.6) and Safari Scenario: Preconditions: Browser opened on iOS 17 device The User is in an active WebRTC call with audio/video ON Steps: 1. iOS 17 User receives PSTN/FaceTime call in the middle of the WebRTC call 2. iOS 17 User spends at least 1min in a PSTN/FaceTime call 3. iOS 17 User or another User ends the PSTN/FaceTime call 4. iOS 17 User sees that browser page refreshes OR iOS User is disconnected from the call Actual result: The browser page is refreshed if iOS User receives a PSTN/FaceTime call and waits at least 1 min in the middle of WebRTC call OR iOS User is disconnected from the call Expected result: The browser page is not refreshed and iOS User can continue to use WebRTC call if iOS User receives a PSTN/FaceTime call and waits at least 1 min in the middle of WebRTC call Reproducibility: 100% Additional information: Observed that higher reproducibility (100%) is when User has only audio call and video is disabled.
<rdar://problem/114196339>
I am not able to reproduce by doing the following: - Load in Safari https://webrtc.github.io/samples/src/content/peerconnection/audio/ - Receive a FT call, wait 1 minute - Go back to Safari and check the stats. I see the page is not refreshed and packets are still being sent. It might be that the process is killed (memory maybe) or suspended for long enough that the connection gets disconnected.
We would probably need a sysdiagnose since I cannot reproduce. It is not unexpected that a page got disconnected since the process might be suspended if the user is in a phone call. Please reopen if you can still reproduce and can provide a sysdiagnose.