Intermittent remote video render failure (code 408 / subCode 43203) — audio OK, correlated with Firefox on the sender side

Question

Intermittent remote video render failure (code 408 / subCode 43203) — audio OK, correlated with Firefox on the sender side

Bastien Lafont 0

Problem summary

We integrate the Azure Communication Services Calling SDK for video calls in our web application. On some connections, client A is unable to display the video stream of a remote participant B, while audio from the same participant works normally. The video render fails after several retries with the following error:

Failed to render video stream, rendering timed out while waiting for video frames. Please try again, if issue persists, contact Azure Communication Services support. (code=408, subCode=43203) Failed to render stream <streamId> after 3 retries.

The issue is not systematic. We observe that it occurs noticeably more often when participant B (the stream sender) is on Firefox. The receiver's browser (client A) does not appear to matter — the problem reproduces regardless of A's browser — which points to a cause on the sending/encoding side rather than the rendering side.

To determine whether the issue came from our configuration or our SDK integration, we followed the official documentation (Get started with video calling) and built a minimal standalone HTML/CSS/JS app, independent of our application. We reproduce the issue with this minimal setup as well, which tends to rule out a cause related to our application-level integration. Here is the repository for the demo like app https://github.com/foodytaing/visio-acs

Environment

SDK: @azure/communication-calling and @azure/communication-commonversion latest
Client A browser (receiver): not relevant — reproduced across multiple browsers
Client B browser (sender): Firefox (observed correlation)
OS: Mac & Windows

Expected vs. observed behavior

Expected: B's remote video stream renders on A's side.
Observed: B's audio is received and works correctly; only the video render times out while waiting for frames and never displays.

Affected call references

We can give some exemple of Call Id and Stream Id when error occurs if needed

The call reaches Connected and the remote participant is Connected; the failure is isolated to rendering the remote video stream.

Aditya N 2,985 Microsoft External Staff Moderator

Hello @Bastien Lafont

Thank you for reaching out Microsoft Q&A.

This 408/43203 error ("Failed to render video stream, rendering timed out while waiting for video frames") happens when the SDK subscribes to a remote video stream but doesn't receive actual frames within its timeout window, even though signaling reports the stream as available.

Audio works because it follows a separate path, but video frame delivery can lag slightly behind signaling — especially when the sender is on Firefox (which is still in Public Preview for ACS video calling). Common triggers include the sender's tab being backgrounded, minor network hiccups during initial keyframe delivery, or timing differences in Firefox's WebRTC encoding.

Recommendation:

The most effective mitigation is to wait for is Receiving before calling createView() and add light retry logic for this specific error. Here's a clean pattern based on the official guidance:

JavaScript

remoteVideoStream.on('isAvailableChanged', async () => {

if (remoteVideoStream.isAvailable) {

// Optional: also wait for isReceiving

if (!remoteVideoStream.isReceiving) {

  await new Promise((resolve) => {

    const handler = () => { 

      if (remoteVideoStream.isReceiving) {

        remoteVideoStream.off('isReceivingChanged', handler);

        resolve();

      }

    };

    remoteVideoStream.on('isReceivingChanged', handler);

    // Safety timeout

    setTimeout(resolve, 3000);

  });

}



const renderer = new VideoStreamRenderer(remoteVideoStream);

try {

  const view = await renderer.createView({ scalingMode: 'Fit' });

  // Attach view.target to your UI

} catch (err) {

  if (err.code === 408 && err.subCode === 43203) {

    console.warn('Render timeout - retrying once...');

    // Retry once after short delay, or dispose & retry

    await new Promise(r => setTimeout(r, 800));

    // ... retry createView

  }

}
```  }

});

 

Try the pattern above in your minimal app first.

If the issue continues, share a couple of affected Call IDs + console logs from both sides (especially the Firefox sender). We can dig deeper.

Keep the sender tab active/foreground during testing. 

Reference: [Manage video during calls - An Azure Communication Services article | Microsoft Learn](https://learn.microsoft.com/en-us/azure/communication-services/how-tos/calling-sdk/manage-video?pivots=platform-web#render-remote-participant-videoscreensharing-streams%22https://learn.microsoft.com/en-us/azure/communication-services/how-tos/calling-sdk/manage-video?pivots=platform-web#render-remote-participant-videoscreensharing-streams%22) 

[Video issues - CreateView timeout - Azure Communication Services - Troubleshooting Guide | Microsof…](https://learn.microsoft.com/en-us/azure/communication-services/resources/troubleshooting/voice-video-calling/video-issues/create-view-timeout%22https://learn.microsoft.com/en-us/azure/communication-services/resources/troubleshooting/voice-video-calling/video-issues/create-view-timeout%22)

Share via

Intermittent remote video render failure (code 408 / subCode 43203) — audio OK, correlated with Firefox on the sender side

Your answer