Architecting Advanced WebRTC Screen Sharing for Remote Tech Support Workflows

How-To-Articles
1

Architecting Advanced WebRTC Screen Sharing for Remote Tech Support Workflows

What This Guide Covers

This masterclass details the implementation of WebRTC-based Screen Sharing for advanced technical support scenarios. By the end of this guide, you will be able to architect a seamless transition from a Voice or Chat session to a full screen-sharing experience. You will learn how to handle complex network topologies (STUN/TURN), implement “Read-Only” vs. “Remote Control” permissions, and ensure the session remains stable across high-latency satellite or mobile connections.

Prerequisites, Roles & Licensing

WebRTC Screen Sharing requires modern browser support and specific platform configuration.

  • Licensing: Genesys Cloud CX 1, 2, or 3.
  • Permissions:
    • Screen Share > Session > View/Add
    • Security > Policy > View/Edit
  • OAuth Scopes: screenshare, conversations.
  • Infrastructure: The Genesys Cloud WebRTC SDK installed on your web application.

The Implementation Deep-Dive

1. The Screen Sharing Handshake

Unlike Co-browse (which mirrors the DOM), Screen Sharing transmits an actual video stream of the user’s desktop or a specific application window. This is achieved via the getDisplayMedia() browser API.

Implementation Pattern:

  1. The Invitation: The agent clicks the “Screen Share” button in their workspace, which generates a unique Session Key.
  2. The Connection: The customer enters the key on your support page, or the key is automatically passed via a WebSocket message if a chat session is already active.
  3. The Stream: The browser prompts the user to select which screen/window to share. Once selected, a secure Peer-to-Peer (P2P) WebRTC connection is established between the customer and the agent.

2. Navigating NAT and Firewalls (STUN/TURN)

WebRTC relies on direct P2P connections, which are often blocked by corporate firewalls.

Architectural Reasoning:
To ensure a 100% connection success rate, you must configure TURN (Traversal Using Relays around NAT) servers.

  • STUN: Used to discover the public IP of the customer.
  • TURN: Used as a fallback “Relay” if a direct P2P connection cannot be established.
    Genesys Cloud provides globally distributed TURN servers, but you must ensure your customers’ internal networks allow outbound UDP traffic on ports 16384-32768.

3. Implementing “Selective” Redaction

Because screen sharing is a video stream, you cannot use CSS classes to mask fields (unlike Co-browse).

The Implementation Pattern:

  1. Application-Specific Sharing: Instruct the customer to share only the Target Application rather than their “Entire Screen.” This prevents the agent from seeing background notifications (e.g., private emails or Slack messages).
  2. Overlay Logic: Implement a “Privacy Overlay” on your web app. When screen sharing is active, your app can detect the session state and hide sensitive UI elements (like credit card inputs) using high-contrast black boxes that are “burned” into the video stream before it is sent to the agent.

4. Handling High-Latency and Low-Bandwidth

A 1080p screen share can consume 2-5 Mbps, which can choke an agent’s connection if they are handling multiple interactions.

Implementation Step:
Configure Bandwidth Constraints in the Screen Share SDK.

  • Max Bitrate: Cap the stream at 1.5 Mbps for support scenarios where high-frame-rate video isn’t required.
  • Frame Rate: Reduce the FPS from 30 to 5 or 10. For tech support (viewing log files or settings), a lower frame rate is perfectly acceptable and significantly improves stability.

Validation, Edge Cases & Troubleshooting

Edge Case 1: Browser “Permission Denied” Errors

  • The failure condition: The customer clicks “Share” but nothing happens, and a console error shows NotAllowedError.
  • The root cause: The getDisplayMedia() API can only be triggered by a “User Gesture” (e.g., a button click). It cannot be launched automatically by the website.
  • The solution: Ensure the screen sharing session is launched only after an explicit click event from the customer.

Edge Case 2: Multi-Monitor Confusion

  • The failure condition: The agent sees a blank screen or the wrong monitor.
  • The root cause: The customer has multiple monitors and selected the wrong one in the browser picker.
  • The solution: Implement a “Stream Preview” window on the customer’s side. This shows them exactly what the agent is seeing, allowing them to quickly stop and restart the share if the wrong screen was selected.

Official References