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
Summary: Incoming and outgoing audio do not recover for WebRTC call after PSTN call wh...
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebRTC (show other bugs)
Version: Safari 15
Hardware: iPhone / iPad iOS 15
: P2 Normal
Assignee: Nobody
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2022-05-19 07:59 PDT by Madara Freimane
Modified: 2023-02-02 15:38 PST (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Madara Freimane 2022-05-19 07:59:15 PDT
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%
Comment 1 Sam Sneddon [:gsnedders] 2022-05-19 08:50:04 PDT
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.)
Comment 2 Sam Sneddon [:gsnedders] 2022-05-19 08:51:20 PDT
This sounds identical to bug 230537, which was apparently fixed in iOS 15.2?
Comment 3 Radar WebKit Bug Importer 2022-05-26 08:00:15 PDT
<rdar://problem/93970270>
Comment 4 youenn fablet 2022-05-30 06:08:17 PDT
(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.
Comment 5 Madara Freimane 2022-08-02 06:44:32 PDT
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)
Comment 6 rychouwei 2022-08-17 02:31:52 PDT
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
Comment 7 youenn fablet 2022-10-25 08:21:07 PDT
This still reproduces according bug originator in iOS 16.1.
Comment 8 Madara Freimane 2022-11-11 13:52:06 PST
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).
Comment 9 youenn fablet 2023-01-23 07:40:09 PST
(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?
Comment 10 Joyce Ma 2023-01-25 17:03:17 PST
@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.
Comment 11 youenn fablet 2023-01-26 03:51:18 PST
(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 (youenn@apple.com).
Comment 12 youenn fablet 2023-01-26 03:51:49 PST
> 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.
Comment 13 Joyce Ma 2023-02-01 13:45:47 PST
(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!
Comment 14 youenn fablet 2023-02-02 04:50:30 PST
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.
Comment 15 Joyce Ma 2023-02-02 15:38:28 PST
(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