Quality of Service (QoS) Mechanism Selection in the Session Description Protocol (SDP)
Extracted elements (14)
The mechanism negotiates which QoS mechanism to use at the endpoint level but explicitly does not address whether the network supports that mechanism; discovering network-layer QoS support is out of scope. This scoping keeps the protocol focused on endpoint agreement and debugging misconfiguration.
The 'qos-mech-send' and 'qos-mech-recv' attributes are independent of QoS preconditions (RFC 3312); preconditions handle direction negotiation while this mechanism handles which QoS protocol to use. Parameters for a chosen mechanism (e.g., bandwidth) must be negotiated separately.
After an offer/answer exchange, both offerer and answerer SHOULD attempt to use the highest-priority common QoS mechanism first, falling back to lower-priority ones if the preferred mechanism fails.
If a subsequent offer omits the 'qos-mech-send' or 'qos-mech-recv' attribute for a direction already negotiated, endpoints SHOULD continue using the previously agreed QoS mechanism for that direction.
If an endpoint fails all common QoS mechanisms for a given direction, it MAY attempt to use additional QoS mechanisms not supported by the remote endpoint, since network intermediaries (e.g., an RSVP proxy) may make them work.
Integrity and authenticity protection is strongly RECOMMENDED for SDP session descriptions carrying 'qos-mech-send' and 'qos-mech-recv' attributes to prevent tampering. For SIP, S/MIME is the natural choice.
Offerers MUST include 'qos-mech-send' with tokens for QoS mechanisms supported in the send direction (in order of preference) and 'qos-mech-recv' for the receive direction.
The answerer intersects the offerer's 'qos-mech-send' tokens with its own receive-direction capabilities and returns the result in 'qos-mech-recv', and vice versa. If no common mechanism exists, empty attributes are returned.
The 'qos-mech-recv' SDP attribute lists QoS mechanisms (in order of preference) supported by the entity for traffic it receives. It is independent of 'qos-mech-send' and may be used without it.
The 'qos-mech-send' SDP attribute lists QoS mechanisms (in order of preference) supported by the entity for traffic it sends. It is defined at both session and media levels and takes IANA-registered tokens as values.
RFC 5432 creates a new IANA subregistry 'QoS Mechanism Tokens' under SDP Parameters, with initial values 'rsvp' and 'nsis'. New registrations require 'Specification Required' per RFC 5226.
RFC 5432 registers the SDP attribute 'qos-mech-recv' under the SDP Parameters registry, for session and media levels, listing QoS mechanisms supported in the receive direction.
An attacker may add, modify, or remove 'qos-mech-send'/'qos-mech-recv' attributes, potentially preventing endpoints from finding a common QoS mechanism. End-to-end integrity protection (e.g., S/MIME for SIP) is strongly recommended.
Both attributes follow ABNF syntax: 'qos-mech-send' or 'qos-mech-recv' followed by a colon and an optional space-separated list of tokens. Each token is either 'rsvp', 'nsis', or an extension-mech (any token value).