Merge pull request #228152 from enricohuang/patch-3

Update known-issues.md

Author: prmerger-automator[bot]

articles/communication-services/concepts/known-issues.md

@@ -29,7 +29,7 @@ Firefox desktop browser support is now available in public preview. Known issues
 
 
 ### iOS 16 introduced bugs when putting browser in the background during a call
-The iOS 16 release has introduced a bug that can stop the ACS audio\video call when using Safari mobile browser. Apple is aware of this issue and are looking for a fix on their side. The impact could be that an ACS call might stop working during a call and the only resolution to get it working again is to have the end customer restart their phone. 
+The iOS 16 release has introduced a bug that can stop the ACS audio\video call when using Safari mobile browser. Apple is aware of this issue and is looking for a fix on their side. The impact could be that an ACS call might stop working during a call and the only resolution to get it working again is to have the end customer restart their phone. 
 
 To reproduce this bug:
 -	Have a user using an iPhone running iOS 16
@@ -42,17 +42,38 @@ Results:
 
 ### Chrome M98 - regression 
 
-Chrome version 98 introduced a regression with anormal generation of video keyframes that impacts resolution of a sent video stream negatively for majority (70%+) of users.
+Chrome version 98 introduced a regression with abnormal generation of video keyframes that impacts resolution of a sent video stream negatively for majority (70%+) of users.
 - This is a known regression introduced on [Chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=1295815)
 
+### No incoming audio during a call
+
+Occasionally, a user in an ACS call may not be able to hear the audio from remote participants.
+There is a related [Chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=1402250) bug which causes this issue, the issue can be mitigated by reconnecting the PeerConnection. We've added this workaround since SDK 1.9.1 (stable) and SDK 1.10.0 (beta)
+
+On Android Chrome, if a user joins ACS call several times, the incoming audio can also disappear. The user will not be able to hear the audio from other participants until the page is refreshed. We've fixed this issue in SDK 1.10.1-beta.1, and improved the audio resource usage.
+
 ### Some Android devices failing call scenarios except for group calls.
 
 A number of specific Android devices fail to start, accept calls, and meetings. The devices that run into this issue, won't recover and will fail on every attempt. These are mostly Samsung model A devices, particularly models A326U, A125U and A215U.
 - This is a known regression introduced on [Chromium](https://bugs.chromium.org/p/webrtc/issues/detail?id=13223).
 
+### Android Chrome mutes the call after browser goes to background for one minute
+
+On Android Chrome, if a user is on an ACS call and puts the browser into background for one minute. The microphone will lose access and the other participants in the call won't hear the audio from the user. Once the user brings the browser to foreground, microphone will be available again. Related chromium bugs [here](https://bugs.chromium.org/p/chromium/issues/detail?id=1027446) and [here](https://bugs.chromium.org/p/webrtc/issues/detail?id=10940)
+
+### The user has dropped the call but is still on the participant list.
+
+The problem can occur if a mobile user leaves the ACS group call without properly hang up. When a user closes the browser or refreshes the webpage without hang up, other participants in the group call will still see the user on the participant list for about 2 minutes.
+
+### iOS Safari refreshes the page if the user goes to another app and returns back to the browser
+
+The problem can occur if a user in an ACS call with iOS Safari, and switches to other app for a while. After the user returns back to the browser, 
+the browser page may refresh. This is because OS kills the browser. One way to mitigate this issue is to keep some states and recover after page refreshes.
+
+
 ### iOS 15.1 users joining group calls or Microsoft Teams meetings.
 
-* Sometimes when incoming PSTN is received the tab with the call or meeting will hang. Related webkit bugs [here](https://bugs.webkit.org/show_bug.cgi?id=233707) and [here](https://bugs.webkit.org/show_bug.cgi?id=233708#c0).
+* Sometimes when incoming PSTN is received the tab with the call or meeting will hang. Related WebKit bugs [here](https://bugs.webkit.org/show_bug.cgi?id=233707) and [here](https://bugs.webkit.org/show_bug.cgi?id=233708#c0).
 
 ### Local microphone/camera mutes when certain interruptions occur on iOS Safari and Android Chrome.
 
@@ -62,9 +83,9 @@ This problem can occur if another application or the operating system takes over
 - A user plays a YouTube video, for example, or starts a FaceTime call. Switching to another native application can capture access to the microphone or camera.
 - A user enables Siri, which will capture access to the microphone.
 
-On iOS for example, while on an ACS call, if a PSTN call comes in, then a microphoneMutedUnexepectedly bad UFD will be raised and audio will stop flowing in the ACS call and the call will be marked as muted. Once the PSTN call is over, the user will have to go and unmute the ACS call for audio to start flowing again in the ACS call. In the case of Android Chrome when a PSTN call comes in, audio will stop flowing in the ACS call and the ACS call will not be marked as muted. Once the PSTN call is finished, android chrome will regain audio automatically and audio will start flowing normally again in the ACS call.
+On iOS for example, while on an ACS call, if a PSTN call comes in, then a microphoneMutedUnexepectedly bad UFD will be raised and audio will stop flowing in the ACS call and the call will be marked as muted. Once the PSTN call is over, the user will have to go and unmute the ACS call for audio to start flowing again in the ACS call. In the case of Android Chrome when a PSTN call comes in, audio will stop flowing in the ACS call and the ACS call will not be marked as muted. In this case, there is no microphoneMutedUnexepectedly UFD event. Once the PSTN call is finished, Android Chrome will regain audio automatically and audio will start flowing normally again in the ACS call.
 
-In case camera is on and an interruption occurs, ACS call may or may not loose the camera. If lost then camera will be marked as off and user will have to go turn it back on after the interruption has released the camera.
+In case camera is on and an interruption occurs, ACS call may or may not lose the camera. If lost then camera will be marked as off and user will have to go turn it back on after the interruption has released the camera.
 
 Occasionally, microphone or camera devices won't be released on time, and that can cause issues with the original call. For example, if the user tries to unmute while watching a YouTube video, or if a PSTN call is active simultaneously.