WebRTC standards map¶
This page connects AutoMobile’s WebRTC implementation choices to the public standards that define the interoperable wire protocol. It is intended as a reading guide, not as a replacement for the specifications.
Scope and reading order¶
The standards below govern the WebRTC session, signalling, secure media, and
RTP payloads. Android capture (video-server / screenrecord), iOS capture
(ScreenCaptureKit helper / FFmpeg), the local Unix-socket control protocol, and
request-size or timeout limits are AutoMobile or platform implementation
choices; they are not WebRTC standards.
For a first pass, read the W3C WebRTC API, JSEP (RFC 9429), WHIP (RFC 9725), and ICE (RFC 8445). Then use the row for the feature being investigated.
Implementation-to-spec map¶
| AutoMobile functionality | Implementation choice and boundary | Standards basis |
|---|---|---|
| Peer connection and media directions | WebRtcPublisher creates a WebRTC peer connection with sendonly H.264 video and optional sendonly PCMU audio. The peer-connection state is the lifecycle signal; AutoMobile does not invent a separate media-session protocol. |
W3C WebRTC: RTCPeerConnection and transceivers, JSEP (RFC 9429), and SDP offer/answer (RFC 3264). |
| Offer/answer validation | Before accepting an answer, AutoMobile checks the expected media sections, negotiated codecs, and directions. A malformed or partially compatible answer fails the session rather than being treated as a working stream. | SDP (RFC 8866) defines SDP syntax; RFC 3264 defines matching media sections and format intersection; WHIP section 4.4 adds WHIP-specific media constraints. |
| WHIP ingest and teardown | WhipClient POSTs an application/sdp offer, accepts the server SDP answer and Location resource URL, and DELETEs that URL on stop or failed startup. Retaining and deleting the resource avoids leaking server-side sessions. |
WHIP sections 4.2 and 4.6 (RFC 9725). |
| WHIP bearer token | When configured, whipToken is sent as an HTTP Authorization: Bearer credential on WHIP requests. Supplying the token and protecting it are deployment responsibilities; AutoMobile only applies the configured request authentication. |
WHIP authentication and bearer-token rules (RFC 9725 section 4.7) and OAuth 2.0 bearer-token usage (RFC 6750). |
| WHEP viewing | MediaMTX (the supported fanout) accepts a viewer’s WHEP offer, returns an answer, and forwards the publisher’s RTP to that viewer; AutoMobile only publishes over WHIP. WHEP is still an Internet-Draft, so its behavior is an interoperability target rather than an RFC guarantee. | WebRTC-HTTP Egress Protocol (WHEP) Internet-Draft. |
| ICE candidate gathering and STUN/TURN | By default AutoMobile waits for ICE gathering before its WHIP POST. iceServers can supply STUN or TURN servers. This conservative non-trickle default favors simple WHIP interoperability; it is not a different ICE protocol. |
ICE (RFC 8445), STUN (RFC 8489), and TURN (RFC 8656). |
| Opt-in trickle ICE | With trickleIce: true, AutoMobile sends the initial offer and PATCHes later candidates as application/trickle-ice-sdpfrag. The ingest server must advertise/support this extension. |
Trickle ICE (RFC 8838), SDP fragments (RFC 8840), and WHIP section 4.3 (RFC 9725). |
| Secure media readiness | Capture packets are only sent after the peer connection reaches a connected state. That is AutoMobile’s lifecycle guard around the standard ICE + DTLS-SRTP establishment performed by werift; it prevents an old source from sending into a failed session. | W3C connection state, ICE (RFC 8445), and DTLS-SRTP (RFC 5764). |
| H.264 Annex-B to RTP packetization | VideoServerStreamParser accepts arbitrary input chunks, reconstructs Annex-B NAL units/access units, and packetizes them as single-NAL or FU-A RTP payloads. The RTP marker marks the final packet of an access unit. Chunk tolerance is an AutoMobile transport boundary; the payload layout is standards-defined. |
RTP (RFC 3550) and H.264 RTP payload format, especially sections 5.1, 5.2, 5.6, and 5.8 (RFC 6184). |
| Late WHEP viewers and decoder configuration | MediaMTX caches recent parameter sets and a keyframe and replays them to a newly-arrived viewer so it can start decoding without waiting for the next IDR. On the AutoMobile side, the publisher re-injects cached SPS/PPS before every IDR (RFC 6184 §8.4) so each keyframe is a self-contained decoder-initialization point. | RFC 6184 parameter sets and payload parameters and the public ITU-T H.264 recommendation. |
| Keyframe requests (PLI) | A WHEP viewer’s Picture Loss Indication is relayed by MediaMTX to the publisher, which asks the capture source for a fresh IDR: the persistent encoder via a socket command (MediaCodec PARAMETER_KEY_REQUEST_SYNC_FRAME), screenrecord via a segment rotation, and iOS via an ffmpeg encoder restart (throttled), with the periodic bounded GOP as a fallback. |
RTCP PLI (RFC 4585 section 6.3.1) and RFC 5104. |
| Optional PCMU audio | AutoMobile encodes 8 kHz mono PCM16 as G.711 mu-law (PCMU) and offers it as RTP payload type 0. Audio capture availability is platform-specific; the codec clock rate and payload mapping are interoperable RTP choices. | RTP A/V Profile: PCMU and static payload type 0 (RFC 3551). |
| Reconnect, stop, and consent loss | On connection failure, AutoMobile tears down the old WHIP resource, backs off, and creates a fresh publisher session while retaining the prepared capture source. It replays cached codec configuration and requests a new keyframe; only a capture failure recreates the source. The retry schedule and source policy are implementation choices, while deleting a WHIP resource and ceasing media when peer consent is lost are protocol-aligned. | WHIP session termination (RFC 9725 section 4.6) and ICE consent freshness (RFC 7675). |
| BUNDLE and RTCP multiplexing | AutoMobile delegates SDP generation and transport details to werift. It does not add custom BUNDLE or RTCP-mux rules; those are negotiated as part of the WebRTC/WHIP session. | WHIP section 4.4 (RFC 9725), JSEP (RFC 9429), and W3C WebRTC. |
Deliberately non-standardized choices¶
- Capture source selection and encoder lifecycle: selecting Android
video-serverversusscreenrecord, or iOS ScreenCaptureKit plus FFmpeg, is a platform integration choice. Their output contract is H.264 Annex-B, which is consumed at the RFC 6184 boundary. - Stream IDs and the Unix socket: reserving IDs before asynchronous start, cancellation during source resolution, and bounded local framing prevent daemon races and denial-of-service conditions. They do not appear on the WebRTC wire.
- Safety limits and retries: publisher-side timeouts and reconnect backoff keep AutoMobile’s WHIP session predictable. They must preserve the negotiated WebRTC session semantics but are not required parameter values in a WebRTC specification.
- Keyframe replay policy: MediaMTX replays cached parameter sets + a keyframe for fast late-viewer startup; AutoMobile’s publisher re-injects SPS/PPS before every IDR so each keyframe is self-contained. RTCP PLI is relayed end to end (viewer → MediaMTX → publisher → capture source) rather than deferred.
For the architecture and operational configuration, see WebRTC Screen Streaming. For a CI-worker walkthrough, see Streaming a device’s screen from a CI worker.