A Framework for Session Description Protocol (SDP) Attributes When Multiplexing
Extracted elements (29)
Attributes for SDP Capability Negotiation (pcfg, acfg, acap, tcap from RFC 5939) use the SPECIAL or INHERIT category because they encapsulate other attributes whose multiplexing categories vary. Section 14 provides detailed procedures: configurations must be coherent under multiplexing, and payload type numbers and latent configurations require special handling to avoid conflicts when bundling.
The categorizations assigned in this specification are normative, not informative. Although attributes can be semantically grouped (media content, transport characteristics, metadata, relationships), the multiplexing categories are defined independently of those informal groupings, because multiplexing compatibility is a distinct axis from semantic purpose.
The multiplexing framework was created because attributes that make sense on independent "m=" lines may not make sense when those lines share a single 5-tuple. For example, each "m=" line may independently specify "ice-ufrag", but when multiplexed over the same ICE component the meaning becomes muddled. SRTP setup, ICE, and DTLS procedures motivate conservation of NAT port bindings.
Attributes from RFC 7195 for circuit-switched PSTN bearers (cs-correlation variants) are TBD because RFC 8843 requires the c= line nettype to be "IN", while RFC 7195 defines a "PSTN" nettype. A future specification defining PSTN multiplexing would be needed before assigning categories.
Attributes from RTSP RFCs (RFC 2326 and RFC 7826) — range, control, mtag, etag — are CAUTION because RFC 8843 mandates the offer/answer usage of SDP, whereas these RTSP SDP attributes are defined only for declarative SDP usage. RTSP is not supported for RTP stream multiplexing.
ICE credential attributes (ice-pwd, ice-ufrag) and candidate/remote-candidates are categorized TRANSPORT: when multiple "m=" lines are multiplexed, only the credentials and candidates from the "m=" line chosen for transport setup are used. The other lines' ICE attributes are ignored for transport purposes.
Precondition attributes des, conf, curr (RFC 3312) are CAUTION because a mismatched set of preconditions across media descriptions results in session establishment failures due to inability to meet the requested resource reservations.
QoS mechanism attributes qos-mech-send and qos-mech-recv (RFC 5432) are TRANSPORT: when multiple "m=" lines are multiplexed, the QoS mechanism from the chosen transport "m=" line applies to the entire multiplexed session.
The ccap attribute (RFC 7006, connection data capability) is IDENTICAL because the connection address type MUST be identical across all multiplexed "m=" lines. The bcap attribute (bandwidth capability) is INHERIT, inheriting the SUM category applicable to the b= attribute.
The crypto attribute (RFC 4568 SDES) is TRANSPORT: when multiple "m=" lines are bundled, the crypto attribute from the "m=" line corresponding to the first MID in the BUNDLE group is used for transport setup, and other lines' crypto attributes are ignored.
The DCCP-based attributes dccp-service-code (RFC 5762) and dccp-port (RFC 6773) are categorized CAUTION because DCCP is connection-oriented and does not allow multiple connections on the same 5-tuple, making multiplexing of DCCP-based media descriptions over a single transport inadvisable.
The extmap attribute (RFC 5285/RFC 8285) is SPECIAL: the specification defining each specific RTP header extension must be consulted to determine the multiplexing implications, since different extensions may have different constraints.
The fingerprint attribute (RFC 4572/RFC 8122) is TRANSPORT: when multiple DTLS-based "m=" lines are bundled, the fingerprint value from the "m=" line chosen for transport setup is used. This is consistent with DTLS operating at the transport layer rather than per-media-stream.
The key-mgmt and mikey attributes (RFC 4567) are IDENTICAL: the key management protocol must be identical across all "m=" lines in a multiplexed group, since all media sharing a transport must use a consistent keying mechanism.
The rtcp-mux attribute (RFC 5761) is IDENTICAL: RTP/RTCP multiplexing affects the entire RTP session, so all "m=" lines sharing a 5-tuple must consistently enable or disable it. Similarly, rtcp-rsize (RFC 5506) and rtcp-unicast (RFC 5760) are IDENTICAL.
The sescap attribute (RFC 6871) is CAUTION for multiplexing because it requires unique configuration numbers across the entire SDP, whereas RFC 5939 scopes them within a single media description. Using identical configuration numbers across bundled media descriptions is the standard way to indicate compatible configurations in a bundle.
Attributes in the IDENTICAL category MUST be repeated across all media descriptions under multiplexing. For example, rtcp-mux MUST be enabled for all "m=" lines transported over a single 5-tuple because RTCP reporting is per RTP session.
Attributes in the IDENTICAL-PER-PT category MUST have identical values across all media descriptions for a given RTP payload type when repeated. Payload-type-specific attributes (rtpmap, fmtp, ptime, maxptime, framerate, rtcp-fb) fall into this category.
Attributes in the TBD category have not been analyzed under the multiplexing framework and SHOULD NOT be multiplexed. Once specifications defining multiplexing/demultiplexing procedures for those protocols (e.g., MSRP, BFCP) become available, their category assignments may be revisited.
For attributes in the SUM category, software MUST apply the sum of all attribute values being multiplexed instead of trying to use them independently. This applies to bandwidth (b=AS) and other rate-limiting attributes so the aggregate value is used for the shared transport.
For RFC 5939 SDP Capability Negotiation used under multiplexing, potential configurations (pcfg) MUST only include attribute capabilities whose multiplexing categories are compatible; a configuration inherits the MUST-level constraints of each constituent encapsulated attribute.
For RFC 6871 media capabilities negotiation under multiplexing, when dealing with payload type numbers, each payload type MUST have identical rmcap and mfcap values across all multiplexed "m=" lines, because payload type assignments must be consistent within a single RTP session.
For TRANSPORT category attributes, the software MUST pick the value associated with the "m=" line whose information is used for setting up the underlying transport (per RFC 8843, the first MID in the BUNDLE group line). Attributes in this category include ice-pwd, ice-ufrag, candidate, fingerprint, crypto, setup, connection, and zrtp-hash.
If SSRCs are repeated across "m=" lines being multiplexed, they MUST all represent the same underlying RTP source. This constraint applies to the ssrc attribute defined in RFC 5576.
INHERIT category attributes encapsulate other SDP attributes and inherit their multiplexing category from the encapsulated attribute. The inherited attributes MUST be coherent in order to form a valid configuration from a multiplexing point of view.
RFC 8859 defines nine normative multiplexing categories for SDP attributes: NORMAL (independently specified, unaffected), CAUTION (not advisable to multiplex), IDENTICAL (must repeat identical values), SUM (aggregate values for transport), TRANSPORT (use value from chosen m= line), INHERIT (inherits category from encapsulated attribute), IDENTICAL-PER-PT (must be identical per RTP payload type), SPECIAL (consult defining specification), and TBD (not yet analyzed, should not be multiplexed).
RFC 8859 adds a "Mux Category" column to fifteen existing IANA SDP-related subregistries, including: SDP bwtype, attribute-name, content SDP Parameters, group semantics, rtcp-fb attribute values, ack/nack attribute values, depend SDP attribute values, cs-correlation attribute values, ssrc-group semantics, SDP/RTSP key management protocol identifiers, codec control messages, QoS mechanism tokens, SDP capability negotiation option tags, timestamp reference clock source parameters, and media clock source parameters.
RFC 8859 creates a new "Multiplexing Categories" subregistry under the "Session Description Protocols (SDP) Parameters" registry. The registry contains the nine category values (NORMAL, CAUTION, IDENTICAL, SUM, TRANSPORT, INHERIT, IDENTICAL-PER-PT, SPECIAL, TBD) and their definitions. New entries require Standards Action.
This document does not define a new protocol and introduces no new security considerations beyond those applicable to SDP and its existing attributes. The framework itself is an analytical tool; security properties of multiplexed sessions depend on the security mechanisms (DTLS-SRTP, SDES, ZRTP) used, whose attributes are categorized TRANSPORT — meaning transport-security configuration is taken from the elected bundle m= line and applied to the entire multiplexed session.