WebRTC captures and transports live audio and video. The application layer manages rooms, language pairs, speech recognition, translation and shared captions. A production design monitors the media plane and caption data plane separately, publishes one authoritative caption stream and provides ICE/STUN/TURN and reconnection strategies for real networks.
The four paths inside one call
| Path | Responsibility | State to observe |
|---|---|---|
| Media plane | Camera, microphone and remote tracks | Permission, device, loss, bitrate, ICE |
| Signaling plane | Room, participant, publish and subscribe | Connection, user and stream IDs |
| Caption data plane | ASR, translation, revisions and delivery | Languages, segment version, latency |
| Business layer | Identity, invitation, policy and configuration | Host, guest and language pair |
Why HTTPS and media permission come first
Browsers request cameras and microphones through getUserMedia(). MDN documents that it is available only in a secure context and requires user permission. An enterprise embedded browser, blocked operating-system permission, missing HTTPS or unavailable device can therefore load the page while failing to capture media. The interface should distinguish denied, missing and active devices.
What ICE, STUN and TURN solve
The W3C WebRTC Recommendation defines browser real-time media and ICE connectivity. In business use, devices sit behind NAT, firewalls and restricted Wi-Fi. STUN helps discover viable addresses; TURN relays media when direct connectivity fails. Acceptance testing should cover office networks, guest Wi-Fi, hotels, mobile hotspots and restrictive firewalls.
A reachable web page proves HTTPS access. A joined room proves signaling. Only a remote media track receiving continuing frames proves the audio/video path is established.
How shared captions remain consistent
If every client independently recognises and translates the same audio, timing, model routing and segmentation differences create competing versions. A controlled caption producer can consume the agreed audio source, issue stable segment IDs and revisions, then broadcast one version to the room. Updates replace the same segment instead of appending duplicates.
How to configure language direction
When languages are known, specify who speaks which language and what each side reads. Automatic language identification works best with a limited candidate set and sufficient speech; it should not be described as unconditional recognition of any language. Names, brands, model numbers and domain terms should be prepared for sales, support and remote acceptance calls.
A practical fault map
| Symptom | Check first | Do not confuse with |
|---|---|---|
| No local preview | Browser/OS permission and device ID | Remote network failure |
| Joined, no remote video | Publish, subscribe, ICE and TURN | Page loading |
| Frozen video, captions continue | Loss and video track state | Whole-room outage |
| Repeated captions | Segment ID, revision replacement, producer | Translation quality alone |
| Echo | Speaker pickup, headset, echo cancellation | Caption engine latency |
Pre-launch acceptance checklist
- Test permission on the production HTTPS domain
- Cover camera, microphone and device switching
- Call across carriers and enterprise networks
- Verify TURN relay and reconnect behaviour
- Keep stable IDs for participants, tracks and caption segments
- Show media and caption status separately
- Test language changes, terminology and numbers
- Define recording and transcript retention scope
Frequently asked questions
Does a browser call always require an installed client?
No. A compatible browser can join by link, but enterprise policy, permissions and complex networks still require testing. Windows or Android clients suit fixed workstations and tighter device control.
Does WebRTC automatically mean end-to-end encryption?
WebRTC media transport uses encryption, but whether a system meets an end-to-end definition depends on media servers, relays, recording and application architecture. The term should not be promised from WebRTC alone.
Method note: this guide combines public web standards with WALI's current call workflow. Network reachability, language coverage and device compatibility remain subject to project testing and the current product configuration.