Expand description
RTP capability matching between producers, routers, and consumers.
Separates negotiation into two distinct stages to keep producer codecs decoupled from consumer capabilities:
- Ingress Normalization: Producer formats are matched against router capabilities
to produce a standardized
Consumablestream. - Egress Selection: Consumer capabilities are intersected with the
Consumablestream to determine supported formats, RTCP feedback, and congestion control modes.
Producer Stream Router Capabilities
\ /
v v
+-------------------------------------------------------+
| Stage 1: Ingress Normalization |
| - Match primary codecs & assign router payload types |
| - Remap RTX `apt` to negotiated primary payload types |
| - Intersect supported header extensions |
+-------------------------------------------------------+
|
v
Consumable MediaStream
|
+--------------------+
| |
v v
Consumer 1 Capabilities Consumer 2 Capabilities
| |
v v
+-----------------------+ +-----------------------+
| Stage 2: Egress Match | | Stage 2: Egress Match |
| - Codec intersection | | - Codec intersection |
| - RTCP feedback match | | - RTCP feedback match |
| - BWE policy (TWCC) | | - BWE policy (REMB) |
+-----------------------+ +-----------------------+
| |
v v
Consumer 1 Egress Stream Consumer 2 Egress StreamThis module operates purely on the typed domain model (MediaStream, MediaFormat,
HeaderExtension, StreamBinding). Rules that depend on raw SDP session structure
(m-line ordering, rejected m-sections, BUNDLE extmap consistency) are outside this module
and belong at the signaling edge.
EnumsΒ§
- BweFeedback
Policy π - RtpNegotiation
Error - Failure raised while deriving or negotiating RTP parameters.
FunctionsΒ§
- apply_
bwe_ πfeedback_ policy - Negotiation may leave both transport-cc and goog-remb present in the raw RTCP feedback intersection. We filter here so downstream sender logic sees one coherent bandwidth-estimation mode instead of multiple competing ones.
- bwe_
feedback_ πpolicy - Selects a local forwarding policy for mutually exclusive bandwidth-estimation feedback families.
- can_
consume - Check whether a consumer capability set can negotiate at least one media codec.
- codec_
match_ πignoring_ payload_ type - Returns whether two formats describe the same codec configuration, ignoring PT
- critical_
codec_ πsettings_ match - Only settings that actually affect wire compatibility are treated as hard negotiation keys here.
- derive_
consumable_ rtp_ parameters - Derives the router-consumable media stream from producer parameters.
- effective_
vp9_ πprofile_ id - find_
matching_ πconsumer_ rtx_ capability - Consumer-side RTX matching works against the already-consumable stream.
At this point the streamβs
aptmust refer to a primary PT that survived consumer negotiation, otherwise forwarding RTX would create an orphan repair stream with no valid primary target - find_
matching_ πmedia_ capability - Media capability matching ignores payload type. PT is negotiated output state, not an identity key for codec compatibility.
- find_
matching_ πrtx_ capability - RTX matching has one extra constraint beyond ordinary codec matching:
- format_
with_ πoverrides - Rebuild the format from the source while applying negotiated overrides.
- formats_
contain_ πpayload_ type - formats_
contain_ πprimary_ payload_ type - h264_
critical_ πsettings_ match packetization-modeis a hard compatibility key. Different packetization modes describe different RTP packetization behaviour, so mismatches are not just preferences- h264_
packetization_ πmode - has_
generic_ πnack - intersect_
feedback π - RTCP feedback is negotiated by common support, not by union. Advertising feedback that only one side supports would let later code assume a control signal is usable when the peer never negotiated it. https://www.rfc-editor.org/rfc/rfc4585.html#section-4.2
- negotiate_
consumer_ rtp_ parameters - Negotiates the consumer-facing stream from a consumable stream.
- negotiate_
header_ πextensions - This is a URI-level capability intersection only.
- negotiated_
payload_ πtype - Payload-type policy:
- normalize_
nack_ πrtx - normalized_
channels π - Channel count is only part of codec identity for audio. Video formats do not use RTP channel count semantics in this model, so we normalize all video channel counts away to avoid spurious mismatches.
- parse_
rtx_ πassociated_ payload aptis not optional metadata for RTX. It is the linkage that says which primary payload type this repair stream protects. Without it, the RTX format is structurally invalid for negotiation.- vp9_
critical_ πsettings_ match