14 Realtime Protocols: WebRTC and WebSocket Operations

14.1 Start With the Decision

WebRTC carries media while WebSocket carries an ordered byte stream. Mixing their roles can hide relay cost, jitter, and recovery work.

14.2 Route Overview

This is part 2 of 3. Review Realtime Protocols: Messaging Foundations for the preceding evidence.

14.3 Learning Objectives

• Compare WebRTC and WebSocket transport behavior.
• Budget latency, jitter, loss, and relay fallback.

14.4 Chapter Roadmap

• WebRTC and WebSocket Are Different
• Latency, Jitter, and Loss Review
• Security Review
• Worked Review: Door Station With Live View
• Realtime Selection Workflow
• Learning Route
• Knowledge Check: Real-Time Protocol Workflows
• Quiz: Media or Signaling?
• Match the Realtime Role
• Order the Realtime Review
• Quiz: WebRTC or WebSocket?
• Common Pitfalls
• Pitfall 1: Calling Every Fast Update Realtime
• Pitfall 2: Sending Media Through the Notification Channel
• Pitfall 3: Ignoring Jitter
• Pitfall 4: Treating Relay Fallback as Policy-Free

14.5 WebRTC and WebSocket Are Different

Browser support can make WebRTC and WebSocket look interchangeable, but their payload and timing contracts differ. Use Figure 14.1 to compare the paths before assigning either one to a camera or control surface.

Both names often appear in browser-based IoT systems, but they solve different problems. Inspect Figure 14.1 first as two paths with different payload contracts.

In Figure 14.1, trace WebRTC through negotiation and secure timed media, then trace WebSocket through one persistent application channel. The WebRTC side owns media-specific concerns such as codecs and changing network routes; the WebSocket side carries ordered messages such as status and commands. A product may use both, but the diagram keeps their roles from collapsing into “live browser traffic.”

Use WebRTC when the browser needs a secure media session or peer connection behavior. Use WebSocket when the browser needs a persistent bidirectional application channel for events, commands, and state updates. A browser dashboard may use both: WebRTC for live camera/audio and WebSocket for device status, alarms, and operator commands.

14.6 Latency, Jitter, and Loss Review

Average latency alone cannot prove a usable media session. Inspect Figure 14.2 in sequence—end-to-end delay, variation between arrivals, loss handling, and evidence—so each symptom leads to a measurable control.

RTP does not guarantee timely delivery or network quality by itself. Inspect Figure 14.2 for the sequence numbers and timestamps receivers can use and the thresholds the system must still supply.

Read Figure 14.2 from sender to receiver. First allocate the delay budget across capture, network, buffering, decoding, and playback. Next examine arrival variation and the receiver buffer: more buffering can hide jitter but consumes latency budget. Then connect packet loss and audio-video synchronization to RTCP, browser statistics, or gateway logs. Those measurements turn “the call felt bad” into thresholds the running design review can test under load and path changes.

Review the path in terms of:

• Capture and encode: time before packets are available.
• Packetization: frame size, audio interval, and payload format.
• Network delay: one-way delay, routing changes, wireless contention, and gateway queues.
• Jitter: variation in packet arrival that the receiver must smooth.
• Loss and reordering: missing or late packets that affect media continuity.
• Receiver buffer: delay added to make playback stable.
• Reports: RTCP, gateway logs, browser stats, or application telemetry that shows path quality.

For voice or video media, the packet stack is part of the timing budget. Codec frames may be wrapped in RTP, UDP, IP, and link-layer headers before they reach the radio or wire, so small payloads can lose useful goodput to overhead and fragmentation. Robust Header Compression, or ROHC, can reduce repeated IP/UDP/RTP header fields to a few bytes on suitable links, but the evidence record should prove the compressor context, loss behavior, round-trip assumptions, and recovery after silence or reordering rather than quoting a best-case header size. The receiver should also name the synchronization window, not only the average delay: a video stream that trails audio by a small amount can still feel natural, while video that leads audio is noticed much sooner. A review note might therefore set asymmetric bounds, such as keeping video no more than about 80 ms behind audio and no more than about 140 ms ahead of audio. Treat those limits as product evidence beside the RTP sequence numbers, timestamps, jitter buffer, and RTCP quality reports.

14.7 Security Review

Realtime IoT traffic can carry private audio, video, and operational state. Security review must cover signaling, media, identity, authorization, and storage boundaries.

Use Figure 14.3 to follow one session across its trust boundaries before approving its performance design.

In Figure 14.3, begin with the identities allowed to create or join the session. Then verify signaling protection and media protection separately, because encrypting one does not secure the other. Continue through authorization and replay control to relay and fallback paths, and finish at logs and recording storage. The result connects the earlier role split to an end-to-end policy rather than a list of protocol acronyms.

Check:

• Identity: device, gateway, service, browser user, and operator identities.
• Signaling protection: session setup should be protected against interception and tampering.
• Media protection: use protected media transport for sensitive audio or video.
• Authorization: restrict who can start, join, view, record, or control a session.
• Replay control: stale media or commands should not be accepted as current action.
• Fallback: relay paths and degraded modes should preserve policy and logging.
• Recording boundary: live stream rules may differ from stored clip rules.

14.8 Worked Review: Door Station With Live View

A building door station needs a visitor button, live video, two-way audio, status updates, and recorded clips for review. The team wants realtime media without losing reliable notifications.

Inspect Figure 14.4 to apply the chapter’s role split to one running system. Follow the visitor event first, then the live session, and finally the recorded evidence path.

Read Figure 14.4 from the door station outward. A reliable notification wakes the application, session signaling negotiates who may join, and protected timed transport carries audio and video while a separate state channel updates the dashboard. After the interaction, the clip follows a reliable upload into controlled storage. The evidence records alongside those branches—delivery, latency, loss, authorization, and retention—show how the abstract review becomes an acceptance test.

14.9 Realtime Selection Workflow

Use this workflow before choosing a realtime protocol.

14.10 Learning Route

Use this chapter after the application-protocol overview and before worked examples that combine several protocol roles.

Use Figure 14.5 as a deliberate pass through the chapter rather than a list of related pages. Start with the application flow, then add protocol roles, timing evidence, and security proof in that order.

Follow Figure 14.5 from flow selection through the SIP/RTP role split and the WebRTC/WebSocket browser paths. The next stop adds latency, jitter, loss, and synchronization limits; the security stop then tests identity, protected signaling and media, relay, and recording boundaries. Finish with integration practice, where those separate observations become one evidence record. This route preserves the running narrative from need to proof.

14.11 Knowledge Check: Real-Time Protocol Workflows

14.12 Common Pitfalls

14.13 Continue to the Next Part

Carry this evidence into Realtime Protocols: Transport Selection, which begins with Deep Dive: How “Live” Rides On (and Escapes) HTTP.