Bug 240651 – Incoming and outgoing audio do not recover for WebRTC call after PSTN call when User has an active PSTN call and only then joins WebRTC call

• Status: RESOLVED
• Resolution: DUPLICATE
• Component: WebRTC

[Madara Freimane]

Created attachment 459587 [details]
Skype_sysdiagnose_2022.05.19_16-27-22+0300_iPhone-OS_iPhone_19F77.tar.gz

Summary:
Audio does not recover for WebRTC call after the PSTN call

Tested devices:
Bug is reproducible on:
*iPhone 11 | iOS 15.3.1
*iPhone 13  | iOS 15.4
*iPhone XR | iOS 15.5
*iPhone 11 Pro Max | iOS 15.5


Scenario:
Precondition:
Safari browser is killed
User has an active PSTN call

Steps:
1. User launches Safari and receives an incoming WebRTC call, and accepts the call
2. User ends the PSTN call
3. User tries to communicate with Users using WebRTC call

Actual result:
Audio does not recover for WebRTC call after the PSTN call

Expected result:
Audio recovers for WebRTC call after the PSTN call.

Reproducibility:
100%

[Sam Sneddon [:gsnedders]]

Comment on attachment 459587 [details]
Skype_sysdiagnose_2022.05.19_16-27-22+0300_iPhone-OS_iPhone_19F77.tar.gz

(To note, you almost certainly don't want to publicly share sysdiagnose, like attaching them to bugs here, given they contain personal information.)

[Sam Sneddon [:gsnedders]]

This sounds identical to bug 230537, which was apparently fixed in iOS 15.2?

[Radar WebKit Bug Importer]

<rdar://problem/93970270>

[youenn fablet]

(In reply to Sam Sneddon [:gsnedders] from comment #2)
> This sounds identical to bug 230537, which was apparently fixed in iOS 15.2?

Not really, here the PSTN call is happening and the web page starts to capture audio.
In that case, audio capture will fail as the PSTN call has higher priority.
Audio capture can succeed through getUserMedia once the PSTN call is finished.

An improvement would be to mute the audio capture until the PSTN call is finished, at which point we could potentially unmute the audio capture.
This would require us to be notified when the PSTN call ends.

[Madara Freimane]

Bug is still reproducible with latest iOS versions
Reproduced on:

- iPhone 11 | iOS 15.6
 and Safari
- iPhone 11 Pro Max | iOS 16 Beta 4 (20A5328h) and Safari

Steps how to reproduce a bug:

1. Kill the Safari browser

2. Receive/make PSTN call (User has an active PSTN call)

3. Open Safari browser and join WebRTC call

4. End the PSTN call 

=> Audio does not recover for WebRTC call (User have to mute and unmute the call to be able get back audio)

Android Chrome has not this problem.

When making a webrtc call, and receive a PSTN call in Android Chrome, audioTrack readyState will not be ended. After PSTN call finished, audioTrack will recover automatically

[youenn fablet]

This still reproduces according bug originator in iOS 16.1.

[Madara Freimane]

Bug is still reproducible with the following use case:
1. Kill the Safari browser

2. Receive/make PSTN call (User has an active PSTN call)

3. Open Safari browser and join WebRTC call

4. End the PSTN call

Tested devices:
- iPhone 12 Mini (iOS 16.1.1, build: 20B101)
- iPhone 11 Pro Max (iOS 16.2 Beta 2, build: 20C5043e)

A new sysdiagnostics file added:
https://drive.google.com/file/d/1GHwagm5nY0scYeq9Ktz3_7yi0rt-xPlG/view?usp=share_link
Bug reproduced on 11.11.2022. at 23:35 (EET time zone).

[youenn fablet]

(In reply to Madara Freimane from comment #8)
> Bug is still reproducible with the following use case:
> 1. Kill the Safari browser

> 2. Receive/make PSTN call (User has an active PSTN call)
> 
3. Open Safari browser and join WebRTC call

> 4. End the PSTN call
> 
> Tested devices:
> - iPhone 12 Mini (iOS 16.1.1, build: 20B101)
> - iPhone 11 Pro Max (iOS 16.2 Beta 2, build: 20C5043e)
> 
> A new sysdiagnostics file added:
> https://drive.google.com/file/d/1GHwagm5nY0scYeq9Ktz3_7yi0rt-xPlG/
> view?usp=share_link
> Bug reproduced on 11.11.2022. at 23:35 (EET time zone).

@Madara, in that case, I would assume that the audio starts muted in Safari.
In which case the user currently needs to unmute using Safari UI.
Is that correct?

[Joyce Ma]

@youenn On iOS 16.2, the bug is still reproducible following these steps:

1. Join WebRTC call with video/audio
2. iOS receive a PSTN call
3. iOS rejects PSTN call from pop-up
4. iOS Returns to tab with WebRTC call - This will result in the return of Audio and Video
5. Repeat steps 2, 3, and 4
6. iOS Returns to tab with WebRTC call - This will result in loss of incoming/outgoing audio.

Therefore, one does not need to actually accept the PSTN call in order for this to occur.

[youenn fablet]

(In reply to Joyce Ma from comment #10)
> @youenn On iOS 16.2, the bug is still reproducible following these steps:
> 
> 1. Join WebRTC call with video/audio
> 2. iOS receive a PSTN call
> 3. iOS rejects PSTN call from pop-up
> 4. iOS Returns to tab with WebRTC call - This will result in the return of
> Audio and Video
> 5. Repeat steps 2, 3, and 4
> 6. iOS Returns to tab with WebRTC call - This will result in loss of
> incoming/outgoing audio.
> 
> Therefore, one does not need to actually accept the PSTN call in order for
> this to occur.

I just tried these steps with iOS16.4 beta and https://webrtc.github.io/samples/src/content/peerconnection/pc1/.
I was not able to reproduce the issue.
Can you have a try?
If you can reproduce there, can you send me a sysdiagnose ([e-mail]).

[youenn fablet]

> I just tried these steps with iOS16.4 beta and
> https://webrtc.github.io/samples/src/content/peerconnection/pc1/.

I tried like 10 times rejecting the PSTN call.

[Joyce Ma]

(In reply to youenn fablet from comment #12)
> > I just tried these steps with iOS16.4 beta and
> > https://webrtc.github.io/samples/src/content/peerconnection/pc1/.
> 
> I tried like 10 times rejecting the PSTN call.

@youenn I can't reproduce it via the peerconnection example but it was reproducible with using Google Meets. 

In order to do this, I had to request Desktop version so it doesn't redirect me to download the app. 

Within the Google Meet application, I repeated the below steps to repro. 

--------
Go to settings > Safari > Request Desktop Website 
--------
1. Join WebRTC call with video/audio
2. iOS receive a PSTN call
3. iOS rejects PSTN call from pop-up
4. iOS Returns to tab with WebRTC call - This will result in the return of Audio and Video
5. Repeat steps 2, 3, and 4
6. iOS Returns to tab with WebRTC call - This will result in loss of incoming/outgoing audio.

With regards to the sysdiagnose, I'll see if I can get one out to you soon!

[youenn fablet]

Thanks Joyce,

I was able to reproduce, I looked also at the sysdiagnose and it aligns with what I saw:
1. WebContent and WebKit.GPU are interrupted due to the phone call
2. WebContent asks to activate the audio session, this might be web application specific
3. WebKit.GPU does not get the end of interruption signal probably due to step 2.

Probably step 2 does not happen in https://webrtc.github.io/samples/src/content/peerconnection/pc1/, hence why it does not reproduce there.

In that case, user has to manually resume capture through Safari UI, while it should be automatically happening.

[Joyce Ma]

(In reply to youenn fablet from comment #14)
> Thanks Joyce,
> 
> I was able to reproduce, I looked also at the sysdiagnose and it aligns with
> what I saw:
> 1. WebContent and WebKit.GPU are interrupted due to the phone call
> 2. WebContent asks to activate the audio session, this might be web
> application specific
> 3. WebKit.GPU does not get the end of interruption signal probably due to
> step 2.
> 
> Probably step 2 does not happen in
> https://webrtc.github.io/samples/src/content/peerconnection/pc1/, hence why
> it does not reproduce there.
> 
> In that case, user has to manually resume capture through Safari UI, while
> it should be automatically happening.

@youenn Thanks for taking the time to look into this more! 

Would we expect this to be fixed eventually? 

We have this marked as a known issue for some time now, so we have suggested folks to work around this by simply recapturing the audio via application side. But it seems to be a regression that may be related to this:
https://bugs.webkit.org/show_bug.cgi?id=230537

[youenn fablet]

This is the same underlying issue as bug 247993, let's dupe it for now.

*** This bug has been marked as a duplicate of bug 247993 ***

[Madara Freimane]

This bug is still reproducible with the following use case:
1. Safari browser killed
2. User is in PSTN call
3. User launches Safari browser and joins WebRTC call
4. User ends PSTN call and returns to WebRTC call
=> no incoming/outgoing audio for iOS User in WebRTC call, video works.

Reproduced a bug on:
- iPhone 14 Pro (iOS 16.3.1) and Safari
- iPhone 13 (iOS 16.4.1) and Safari
- iPhone 11 Pro Max (iOS 16.5 Beta) and Safari

Uploaded a new sysdiagnostics file (recorded on iOS 16.5 Beta at 17:03 EET, 19.04.23.):
https://drive.google.com/file/d/1C8wPkv_2nhY1vRGyw5HbFfgDeY4pLiRl/view?usp=share_link