Troubleshooting Timeout Errors When Rendering Screen-Sharing Streams from an Electron App to Web Browsers Using the Azure Communication Services Calling SDK

Question

Troubleshooting Timeout Errors When Rendering Screen-Sharing Streams from an Electron App to Web Browsers Using the Azure Communication Services Calling SDK

Nguyen Van Tung 0

On our Electron App, we handle screen sharing as follows: When the screen-sharing session starts, all users who are already present in the Room on Web Browsers receive the shared screen stream normally. The stream is rendered and displayed correctly using the VideoStreamRenderer API.

However, when a new user joins the Room or an existing user reloads the page, a timeout error occurs while rendering the screen-sharing stream. It appears that the Azure Communication Services (ACS) Calling SDK does not deliver the screen-sharing stream to these users in such cases.

We would like to ask the ACS development team for clarification on the root cause and recommended solutions or workarounds for this issue.

          const inputSources = await desktopCapturer.getSources({ types: ['screen'] });
          const constraints: any = {
            audio: false,
            video: {
              mandatory: {
                chromeMediaSource: 'desktop',
                chromeMediaSourceId: inputSources[0].id,
              }
            }
          };
          const stream = await navigator.mediaDevices.getUserMedia(constraints);
          this.call.startScreenSharing(new LocalVideoStream(stream));

/**Version SDK:
    "@azure/communication-calling": "^1.38.1",
    "@azure/communication-calling-effects": "^1.1.4",
    "@azure/communication-common": "^2.4.0",
    "@azure/communication-identity": "^1.3.1",
**/

Praneeth Maddali 2,355 Reputation points Microsoft External Staff Moderator

2025-11-13T04:35:57.6333333+00:00
Hi @Nguyen Van Tung

Thank you for providing the details. The issue happens because the GA versions of the ACS Web Calling SDK no longer allow passing a custom LocalVideoStream to startScreenSharing(). If a stream is injected using desktopCapturer and getUserMedia, late joiners get an “available” signal before any frames are received, which leads to createView timeouts (error 408).

Recommended Solution

Electron: Implement ACS-managed capture for improved results.

await call.startScreenSharing(); // No LocalVideoStream argument

For source selection, handle getDisplayMedia() via session.setDisplayMediaRequestHandler.

Web: Render only when stream.isAvailable and retry on timeout:

async function showScreen(stream) { for (let i = 0; i < 3; i++) { try { const view = await new VideoStreamRenderer(stream).createView(); document.getElementById('remote-screen').appendChild(view.target); return; } catch (err) { if (err.code === 408 && i < 2) await new Promise(r => setTimeout(r, 2000)); } } }

After these changes, late participants consistently render the shared screen. Tip: Upgrade to @azure/communication-calling ≥ 1.39.x for improved screen‑sharing behavior.

Reference :
https://learn.microsoft.com/en-us/azure/communication-services/how-tos/calling-sdk/manage-video?pivots=platform-web

https://learn.microsoft.com/en-us/azure/communication-services/resources/troubleshooting/voice-video-calling/video-issues/create-view-timeout

https://learn.microsoft.com/en-us/azure/communication-services/how-tos/calling-sdk/manage-video?pivots=platform-web#start-and-stop-screen-sharing-while-on-a-call

https://learn.microsoft.com/en-us/azure/communication-services/tutorials/migrating-to-azure-communication-services-calling?tabs=java&pivots=platform-web#starting-and-stopping-video

Kindly let us know if the above helps or you need further assistance on this issue.

Nguyen Van Tung 0

We have followed all of your recommended instructions, but the issue is still not resolved. Here are the steps we have implemented:

Upgraded the Calling SDK to the latest version

    "@azure/communication-calling": "^1.40.1",

Implemented setDisplayMediaRequestHandler for our Electron app:

    electron.session.defaultSession.setDisplayMediaRequestHandler((request, callback) => {
      desktopCapturer.getSources({ types: ['screen'] }).then((sources) => {
        callback({ video: sources[0] });
      });
    });

Started screen sharing without passing any LocalVideoStream argument

      this.call.startScreenSharing();

Added retry logic for rendering the screen-sharing stream using VideoStreamRenderer

 private async renderVideo(stream: RemoteVideoStream, retry = 0) {
    const containerElm = this.elRef.nativeElement.querySelector('.video-container');

    if (this._processing || !containerElm) return;

    try {
      this._processing = true;
      this._videoRenderer = new VideoStreamRenderer(stream);

      const videoContainer = await this._videoRenderer.createView({ scalingMode: 'Fit', isMirrored: false });
      this._view = videoContainer as VideoStreamRendererView;

      containerElm.innerHTML = '';
      containerElm.appendChild(videoContainer.target);
    } catch (error) {
      console.error('ACS stream setup error:', error);
      await this.cleanupCurrentStream();
      if (retry < 3) {
        this._processing = false;
        await new Promise((r) => setTimeout(r, 2000));
        await this.renderVideo(stream, retry + 1);
      }
    } finally {
      this._processing = false;
    }
  }

Despite upgrading the SDK, implementing the Electron display media handler, starting screen sharing without arguments, and adding render retry logic, the issue still persists.

This problem is now seriously affecting our project schedule, and we urgently need a definitive and complete solution from the ACS engineering team.

We kindly request that the ACS team provide a thorough fix or guidance to fully resolve this issue.

Praneeth Maddali 2,355 Reputation points Microsoft External Staff Moderator

2025-11-17T17:37:09.2366667+00:00
Hi @Nguyen Van Tung

Thanks for the detailed follow‑up and sorry this is still blocking your timeline. Based on the behavior you described (timeouts when new participants join or the page reloads), the most reliable mitigation is to render only after actual frames are flowing, not just when the stream is signaled as present.

this happensLate joiners often receive a “stream available” signal before any frames arrive, so VideoStreamRenderer.createView() times out with 408/43203. This is a known condition when signaling and media delivery are slightly out of sync.

Reference:

https://learn.microsoft.com/en-us/azure/communication-services/resources/troubleshooting/voice-video-calling/video-issues/create-view-timeout

What to change

On Electron (sharer): use ACS‑managed capture and a robust display‑media handler

Start sharing with await call.startScreenSharing() (no custom LocalVideoStream). GA behavior change doc: https://learn.microsoft.com/en-us/azure/communication-services/how-tos/calling-sdk/manage-video?pivots=platform-web#start-and-stop-screen-sharing-while-on-a-call and migration notes: https://learn.microsoft.com/en-us/azure/communication-services/tutorials/migrating-to-azure-communication-services-calling?pivots=platform-web#starting-and-stopping-video.

Bind setDisplayMediaRequestHandler to the same session as your calling window and ensure you call callback() exactly once and never throw. (Electron can stall getDisplayMedia() on exceptions/cancellation, which results in no frames downstream.)
// Main process function wireScreenShareHandlerFor(win: BrowserWindow) { const sess = win.webContents.session; sess.setDisplayMediaRequestHandler(async (_req, callback) => { try { const sources = await desktopCapturer.getSources({ types: ['screen'] }); const source = sources[0]; callback(source ? { video: source } : {}); // deny cleanly if none } catch { callback({}); // never throw out of handler } }); }

On web receivers: gate on isReceiving, then render; add retries and a raw‑media fallback

Wait for RemoteVideoStream.isReceiving === true (frames are actually arriving), not only isAvailable. API semantics: https://learn.microsoft.com/en-us/javascript/api/azure-communication-services/%40azure/communication-calling/remotevideostream?view=azure-communication-services-js.

Retry createView() on 408; dispose renderer between attempts.

If retries still fail, fall back to stream.getMediaStream() and attach to a <video> element.
// Typescript (receiver) async function renderScreen(stream: RemoteVideoStream) { // Wait up to ~5s for frames if (!stream.isReceiving) { await new Promise<void>(resolve => { const h = () => { if (stream.isReceiving) { stream.off('isReceivingChanged', h); resolve(); } }; stream.on('isReceivingChanged', h); setTimeout(() => { stream.off('isReceivingChanged', h); resolve(); }, 5000); }); } for (let attempt = 1; attempt <= 3; attempt++) { try { const renderer = new VideoStreamRenderer(stream); const view = await renderer.createView({ scalingMode: 'Fit', isMirrored: false }); mount(view.target); return; } catch (err: any) { if (err?.code === 408 && attempt < 3) await delay(2000); } } // Fallback: raw MediaStream try { const media = await stream.getMediaStream(); const video = document.getElementById('remote-screen') as HTMLVideoElement; video.autoplay = true; video.playsInline = true; video.srcObject = media; await video.play(); } catch (fallbackErr) { console.error('Fallback failed', fallbackErr); } }

Version note Stay on @azure/communication-calling ≥ 1.39.x (you’re on 1.40.1, good). These releases include improvements to screen‑sharing behavior and signaling for late joiners. Reference:
https://github.com/Azure/Communication/blob/master/releasenotes/acs-javascript-calling-library-release-notes.md
https://www.npmjs.com/package/@azure/communication-calling

Reference below documents for more info :

https://learn.microsoft.com/en-us/azure/communication-services/how-tos/calling-sdk/manage-video?pivots=platform-web#start-and-stop-screen-sharing-while-on-a-call

https://learn.microsoft.com/en-us/javascript/api/azure-communication-services/%40azure/communication-calling/remotevideostream?view=azure-communication-services-js

Switching to ACS‑managed screen capture on Electron and rendering only after isReceiving (with retry + fallback) is what typically resolves late‑joiner timeouts in practice. If this still reproduces, please share an affected call.id and timestamps of isAvailable/isReceiving transitions

Kindly let us know if the above helps or you need further assistance on this issue.
Praneeth Maddali 2,355 Reputation points Microsoft External Staff Moderator

2025-11-18T22:43:35.91+00:00

Hi @Nguyen Van Tung

I'm just reaching out to see if your issue has been resolved or if you've had a chance to review my previous comment?
Nguyen Van Tung 0 Reputation points

2025-11-19T02:05:54.6166667+00:00

@Praneeth Maddali
Thank you, we have received your response and are currently testing based on your guidance. We will get back to you once we have the results.
Nguyen Van Tung 0 Reputation points

2025-11-19T04:23:25.6+00:00

Hi @Praneeth Maddali ,

Call ID: e42f6ecc-0740-4317-a34b-a3ad26e4f625,

Stream ID: 212,

Participant: 8:acs:94e9141f-c0ec-4585-b8f6-1773f5a49703_0000002b-3a27-e708-41e4-6f8ded7c6cfd

Timestamp: 2025-11-19T04:04:23.561Z
=> We have retested the scenario following your latest guidance, but the issue still persists. We have listed the detailed error information above for your review.

Based on our investigation, we believe the root cause is not in our implementation but rather an issue on the Azure Communication Services (ACS) server side. It appears that the ACS server does not deliver screen-sharing video frames to users who newly join or rejoin the room when the screen is being shared from our Electron application.

As a temporary workaround, we have implemented the following logic:

Detect when a user newly joins or rejoins the room.

When this case occurs, automatically call stopScreenSharing() and then startScreenSharing() again to restart the screen-sharing stream.

However, this is only a temporary solution. We still require an official fix, and we hope that your development team can address this issue in upcoming SDK releases.
Praneeth Maddali 2,355 Reputation points Microsoft External Staff Moderator

2025-11-24T07:06:20.9433333+00:00

Hi @Nguyen Van Tung

Thank you for sending the updated logs and for retesting the scenario. We reviewed the timestamps and diagnostic information, and we did not identify any issues on the ACS service side. From the log patterns, signaling for the screen-sharing stream is received correctly, but video frames are not yet available at the time your application attempts to render the stream. This results in the observed createViewtimeout, which aligns with a known client-side timing condition.

Since the service is operating normally, the next step will be to adjust your internal implementation around frame availability (isReceiving), render retries, and Electron’s display-media handler as previously recommended. These changes typically resolve late-join rendering failures.

Kindly let us know if the above helps or you need further assistance on this issue.
Praneeth Maddali 2,355 Reputation points Microsoft External Staff Moderator

2025-12-01T09:45:46.08+00:00

Hi @Nguyen Van Tung

I'm just reaching out to see if your issue has been resolved or if you've had a chance to review my previous comment?
Nguyen Van Tung 0 Reputation points

2025-12-01T10:19:28.4433333+00:00

Hi @Praneeth Maddali
Thank you. Up to this point, we have tried all the solutions your team suggested, but unfortunately none of them are working. We currently have to use a temporary workaround by restarting the screen sharing whenever a new user joins or rejoins the call. If your team can demonstrate that this feature works correctly on Electron, please provide us with an example project on GitHub so we can verify it.

2 answers

Your answer

Nguyen Van Tung 0 Reputation points

2025-11-14T08:36:45.7133333+00:00

We have followed all of your recommended instructions, but the issue is still not resolved. Here are the steps we have implemented:

Upgraded the Calling SDK to the latest version

"@azure/communication-calling": "^1.40.1",

Implemented setDisplayMediaRequestHandler for our Electron app:

electron.session.defaultSession.setDisplayMediaRequestHandler((request, callback) => { desktopCapturer.getSources({ types: ['screen'] }).then((sources) => { callback({ video: sources[0] }); }); });

Started screen sharing without passing any LocalVideoStream argument

this.call.startScreenSharing();

Added retry logic for rendering the screen-sharing stream using VideoStreamRenderer

private async renderVideo(stream: RemoteVideoStream, retry = 0) { const containerElm = this.elRef.nativeElement.querySelector('.video-container'); if (this._processing || !containerElm) return; try { this._processing = true; this._videoRenderer = new VideoStreamRenderer(stream); const videoContainer = await this._videoRenderer.createView({ scalingMode: 'Fit', isMirrored: false }); this._view = videoContainer as VideoStreamRendererView; containerElm.innerHTML = ''; containerElm.appendChild(videoContainer.target); } catch (error) { console.error('ACS stream setup error:', error); await this.cleanupCurrentStream(); if (retry < 3) { this._processing = false; await new Promise((r) => setTimeout(r, 2000)); await this.renderVideo(stream, retry + 1); } } finally { this._processing = false; } }

Despite upgrading the SDK, implementing the Electron display media handler, starting screen sharing without arguments, and adding render retry logic, the issue still persists.

This problem is now seriously affecting our project schedule, and we urgently need a definitive and complete solution from the ACS engineering team.

We kindly request that the ACS team provide a thorough fix or guidance to fully resolve this issue.
Praneeth Maddali 2,355 Reputation points Microsoft External Staff Moderator

2025-11-18T22:43:35.91+00:00

Hi @Nguyen Van Tung

I'm just reaching out to see if your issue has been resolved or if you've had a chance to review my previous comment?
Nguyen Van Tung 0 Reputation points

2025-11-19T02:05:54.6166667+00:00

@Praneeth Maddali
Thank you, we have received your response and are currently testing based on your guidance. We will get back to you once we have the results.
Nguyen Van Tung 0 Reputation points

2025-11-19T04:23:25.6+00:00

Hi @Praneeth Maddali ,

Call ID: e42f6ecc-0740-4317-a34b-a3ad26e4f625,

Stream ID: 212,

Participant: 8:acs:94e9141f-c0ec-4585-b8f6-1773f5a49703_0000002b-3a27-e708-41e4-6f8ded7c6cfd

Timestamp: 2025-11-19T04:04:23.561Z
=> We have retested the scenario following your latest guidance, but the issue still persists. We have listed the detailed error information above for your review.

Based on our investigation, we believe the root cause is not in our implementation but rather an issue on the Azure Communication Services (ACS) server side. It appears that the ACS server does not deliver screen-sharing video frames to users who newly join or rejoin the room when the screen is being shared from our Electron application.

As a temporary workaround, we have implemented the following logic:

Detect when a user newly joins or rejoins the room.

When this case occurs, automatically call stopScreenSharing() and then startScreenSharing() again to restart the screen-sharing stream.

However, this is only a temporary solution. We still require an official fix, and we hope that your development team can address this issue in upcoming SDK releases.
Praneeth Maddali 2,355 Reputation points Microsoft External Staff Moderator

2025-11-24T07:06:20.9433333+00:00

Hi @Nguyen Van Tung

Thank you for sending the updated logs and for retesting the scenario. We reviewed the timestamps and diagnostic information, and we did not identify any issues on the ACS service side. From the log patterns, signaling for the screen-sharing stream is received correctly, but video frames are not yet available at the time your application attempts to render the stream. This results in the observed createViewtimeout, which aligns with a known client-side timing condition.

Since the service is operating normally, the next step will be to adjust your internal implementation around frame availability (isReceiving), render retries, and Electron’s display-media handler as previously recommended. These changes typically resolve late-join rendering failures.

Kindly let us know if the above helps or you need further assistance on this issue.
Praneeth Maddali 2,355 Reputation points Microsoft External Staff Moderator

2025-12-01T09:45:46.08+00:00

Hi @Nguyen Van Tung

I'm just reaching out to see if your issue has been resolved or if you've had a chance to review my previous comment?
Nguyen Van Tung 0 Reputation points

2025-12-01T10:19:28.4433333+00:00

Hi @Praneeth Maddali
Thank you. Up to this point, we have tried all the solutions your team suggested, but unfortunately none of them are working. We currently have to use a temporary workaround by restarting the screen sharing whenever a new user joins or rejoins the call. If your team can demonstrate that this feature works correctly on Electron, please provide us with an example project on GitHub so we can verify it.

Answer 1

When a new user joins the room or an existing user reloads the page, the timeout error while rendering the screen-sharing stream may be related to the createView timeout failures in the Azure Communication Services (ACS) Calling SDK. Here are some potential causes and recommended workarounds:

Network Issues: If the video sender (the user sharing the screen) has network issues, it could lead to a failure in the video subscription for new users. Ensure that the sender has a stable network connection.
Video Sender Dropped from Call: If the video sender unexpectedly drops from the call, other participants may not receive the video frames, leading to a timeout error. This can happen if the sender terminates the browser process instead of hanging up. Ensure that the sender properly ends the call.
Retry Mechanism: Implement a retry mechanism for invoking the createView API. If a timeout occurs, continuously retry until it succeeds. This can help in scenarios where there are temporary network issues.
User Interface Notifications: Consider implementing a mechanism to notify users when the sender's browser goes to the background or when there are network issues. This can help manage expectations and improve the user experience.
Monitor Network Quality: Monitor the network quality and media status. If the network performance degrades, you might want to automatically turn off incoming video streams to maintain call quality.

These strategies should help mitigate the timeout errors when rendering screen-sharing streams in your Electron app using the ACS Calling SDK.

References:

Nguyen Van Tung 0 Reputation points

2025-11-12T08:28:39.8633333+00:00

We would like to know if there are any specific solutions or workarounds for this issue. The problem only occurs when the screen is shared from the Electron App to Web Browser users. When the screen is shared from Web Browsers, it works correctly without any errors.

Answer 2

Nguyen Van Tung 0

We would like to know if there are any specific solutions or workarounds for this issue. The problem only occurs when the screen is shared from the Electron App to Web Browser users. When the screen is shared from Web Browsers, it works correctly without any errors.

Share via

Troubleshooting Timeout Errors When Rendering Screen-Sharing Streams from an Electron App to Web Browsers Using the Azure Communication Services Calling SDK

2 answers

Your answer