|
| 1 | +--- |
| 2 | +title: Azure Communication Services - known issues - all browsers |
| 3 | +description: Learn more about known issues on Azure Communication Service calling when using all browsers |
| 4 | +author: sloanster |
| 5 | +services: azure-communication-services |
| 6 | + |
| 7 | +ms.author: micahvivion |
| 8 | +ms.date: 02/23/2024 |
| 9 | +ms.topic: include |
| 10 | +ms.service: azure-communication-services |
| 11 | +ms.subservice: calling |
| 12 | +ms.custom: template-how-to |
| 13 | +--- |
| 14 | + |
| 15 | +## All Desktop browsers |
| 16 | + |
| 17 | + |
| 18 | +### It isn't possible to render multiple previews from multiple devices on web |
| 19 | +**Browser version:** All.<br> |
| 20 | +**Azure Communication Service calling SDK version:** All.<br> |
| 21 | +**Description:** It isn't possible to render multiple previews from multiple devices on web. This issue is a known limitation.<br> |
| 22 | +**Known issue reference:** For more information, see [Calling SDK overview](../../../voice-video-calling/calling-sdk-features.md).<br> |
| 23 | + |
| 24 | + |
| 25 | +### Repeatedly switching video devices might cause video streaming to stop temporarily |
| 26 | +**Browser version:** All.<br> |
| 27 | +**Azure Communication Service calling SDK version:** All.<br> |
| 28 | +**Description:** Switching between video devices might cause your video stream to pause while the stream is acquired from the selected device. Switching between devices frequently can cause performance degradation.<br> |
| 29 | +**Recommended workaround:** Developers should ensure to stop the stream from one device before starting another to mitigate performance degradation when switching between video devices.<br> |
| 30 | + |
| 31 | + |
| 32 | +### Video signal problem when the call is in connecting state |
| 33 | +**Browser version:** All. <br> |
| 34 | +**Azure Communication Service calling SDK version:** All.<br> |
| 35 | +**Description:** If a user turns video on and off quickly while the call is in the *Connecting* state, this action might lead to a problem with the stream acquired for the call. It's best for developers to build their apps in a way that doesn't require video to be turned on and off while the call is in the *Connecting* state. Degraded video performance might occur in the following scenarios: |
| 36 | +- If the user starts with audio, and then starts and stops video, while the call is in the *Connecting* state. |
| 37 | +- If the user starts with audio, and then starts and stops video, while the call is in the *Lobby* state. |
| 38 | +<br> |
| 39 | + |
| 40 | +### Delay in rendering remote participant videos |
| 41 | +**Browser version:** All.<br> |
| 42 | +**Azure Communication Service calling SDK version:** All.<br> |
| 43 | +**Description:** During an ongoing group call, suppose that *User A* sends video, and then *User B* joins the call. Sometimes, User B doesn't see video from User A, or User A's video begins rendering after a long delay. A network environment configuration problem might cause this delay.<br> |
| 44 | +**Known issue reference:** For more information [Network recommendations](../../../voice-video-calling/network-requirements.md).<br> |
| 45 | + |
| 46 | +### Excessive use of certain APIs like mute/unmute results in throttling on Azure Communication Services infrastructure |
| 47 | +**Browser version:** All.<br> |
| 48 | +**Azure Communication Service calling SDK version:** All.<br> |
| 49 | +**Description:** As a result of the mute/unmute API call, Azure Communication Services infrastructure informs other participants in the call about the state of audio of a local participant who invoked mute/unmute, so that participants in the call know who is muted/unmuted. |
| 50 | + |
| 51 | +Excessive use of mute/unmute is blocked in Azure Communication Services infrastructure. Throttling happens if the participant (or application on behalf of participant) attempts to mute/unmute continuously, every second, more than 15 times in a 30-second rolling window. |
| 52 | +<br> |
| 53 | + |
| 54 | +## All mobile browser |
| 55 | + |
| 56 | + |
| 57 | +### It isn't possible to render multiple previews from multiple devices on web |
| 58 | +**Browser version:** All.<br> |
| 59 | +**Azure Communication Service calling SDK version:** All.<br> |
| 60 | +**Description:** It isn't possible to render multiple previews from multiple devices on web. This issue is a known limitation.<br> |
| 61 | +**Known issue reference:** For more information, see [Calling SDK overview](../../../voice-video-calling/calling-sdk-features.md).<br> |
| 62 | + |
| 63 | +### Repeatedly switching video devices might cause video streaming to stop temporarily |
| 64 | +**Browser version:** All.<br> |
| 65 | +**Azure Communication Service calling SDK version:** All.<br> |
| 66 | +**Description:** Switching between video devices might cause your video stream to pause while the stream is acquired from the selected device. Switching between devices frequently can cause performance degradation.<br> |
| 67 | +**Recommended workaround:** Developers should ensure to stop the stream from one device before starting another to mitigate performance degradation when switching between video devices.<br> |
| 68 | + |
| 69 | +### Video signal problem when the call is in connecting state |
| 70 | +**Browser version:** All.<br> |
| 71 | +**Azure Communication Service calling SDK version:** All.<br> |
| 72 | +**Description:** If a user turns video on and off quickly while the call is in the *Connecting* state, this action might lead to a problem with the stream acquired for the call. It's best for developers to build their apps in a way that doesn't require video to be turned on and off while the call is in the *Connecting* state. Degraded video performance might occur in the following scenarios: |
| 73 | + - If the user starts with audio, and then starts and stops video, while the call is in the *Connecting* state. |
| 74 | + - If the user starts with audio, and then starts and stops video, while the call is in the *Lobby* state. |
| 75 | + |
| 76 | + |
| 77 | + ### Delay in rendering remote participant videos |
| 78 | +**Browser version:** All.<br> |
| 79 | +**Azure Communication Service calling SDK version:** All.<br> |
| 80 | +**Description:** During an ongoing group call, suppose that *User A* sends video, and then *User B* joins the call. Sometimes, User B doesn't see video from User A, or User A's video begins rendering after a long delay. A network environment configuration problem might cause this delay.<br> |
| 81 | +**Known issue reference:** For more information [Network recommendations](../../../voice-video-calling/network-requirements.md). <br> |
| 82 | + |
| 83 | + ### Excessive use of certain APIs like mute/unmute results in throttling on Azure Communication Services infrastructure |
| 84 | +**Browser version:** All.<br> |
| 85 | +**Azure Communication Service calling SDK version:** All<br> |
| 86 | +**Description:** As a result of the mute/unmute API call, Azure Communication Services infrastructure informs other participants in the call about the state of audio of a local participant who invoked mute/unmute, so that participants in the call know who is muted/unmuted.<br> |
| 87 | + |
| 88 | +Excessive use of mute/unmute is blocked in Azure Communication Services infrastructure. Throttling happens if the participant (or application on behalf of participant) attempts to mute/unmute continuously, every second, more than 15 times in a 30-second rolling window. |
| 89 | + |
| 90 | +### Refreshing a page doesn't immediately remove the user from their call |
| 91 | +**Browser version:** All.<br> |
| 92 | +**Azure Communication Service calling SDK version:** All.<br> |
| 93 | +**Description:** If a user is in a call and decides to refresh the page, the Communication Services media service doesn't remove this user immediately from the call. It waits for the user to rejoin. The user is removed from the call after the media service times out. |
| 94 | + |
| 95 | + If a user is in a call and decides to refresh the page, the Communication Services media service doesn't remove this user immediately from the call. It waits for the user to rejoin. The user is removed from the call after the media service times out. |
| 96 | + |
| 97 | + It's best to build user experiences that don't require end users to refresh the page of your application while in a call. If a user refreshes the page, reuse the same Communication Services user ID after that user returns back to the application. By rejoining with the same user ID, the user is represented as the same, existing object in the `remoteParticipants` collection. From the perspective of other participants in the call, the user remains in the call during the time it takes to refresh the page, up to a minute or two. |
| 98 | + |
| 99 | + If the user was sending video before refreshing, the `videoStreams` collection keeps the previous stream information until the service times out and removes it. In this scenario, the application might decide to observe any new streams added to the collection, and render one with the highest `id`. |
0 commit comments