Connectivity Preconditions for Session Description Protocol (SDP) Media Streams
Extracted elements (22)
The answerer in an ICE-based exchange never needs to request confirmation of a connectivity precondition from the offerer because the answerer can determine precondition status locally via ICE checks. Confirmation requests are only needed for lite ICE implementations that lack full bidirectional verification capability.
The connectivity precondition delays alerting the called party until media stream connectivity has been verified end-to-end. This addresses the real-world failure mode where SDP offer-answer negotiation succeeds but actual media cannot flow due to NATs or firewalls in the media path.
When using a connection-oriented transport in passive mode, the offerer cannot know which SIP dialog originated an incoming connection request, making dialog-to-stream correlation difficult. Having the offerer take the active role avoids this ambiguity.
Connectivity preconditions can and should be combined with other precondition types: the "qos" precondition (RFC 3312) for Quality of Service requirements and the "sec" precondition (RFC 5027) for security parameter negotiation, as connectivity alone may not fully satisfy all media stream requirements.
During re-INVITEs or UPDATEs with connectivity preconditions, both user agents SHOULD continue using old session parameters until all mandatory preconditions are met, at which point they can begin using the new parameters.
In the absence of a mechanism for correlating a dialog to a media stream (e.g., ICE), a UAS MUST NOT require the offerer to confirm a connectivity precondition, because the offerer cannot determine which dialog had its connectivity verified.
It is RECOMMENDED that ICE be supported by entities that support connectivity preconditions, as it works for all media streams (not just RTP), facilitates NAT/firewall traversal, and provides a common baseline for probe-traffic-based connectivity verification.
Packets exchanged on media streams during connectivity verification SHOULD be limited to those necessary to verify connectivity; the underlying media stream SHOULD NOT be cut through. ICE connectivity checks and TCP handshake packets are cited as examples.
The connectivity precondition type MUST be used with the end-to-end status type; use of the segmented status type is undefined.
When a mandatory connectivity precondition is offered and the answerer cannot satisfy it (e.g., no parameters enable connectivity verification without media cut-through), the offer MUST be rejected as per RFC 3312.
When a media stream involves multiple destination addresses (e.g., FEC streams), connectivity to all of them MUST be verified. For RTP streams that use RTCP, connectivity MUST be verified for both RTP and RTCP, and RTCP transmission interval rules MUST still be adhered to.
When an optional connectivity precondition is offered, the answerer MUST generate its answer SDP as soon as possible. If the answerer wants to delay session progress until connectivity is verified, it MUST upgrade the strength to "mandatory" in the answer.
A lite ICE implementation ascertains both "send" and "recv" connectivity when the controlling agent has informed it of the nominated pair for all components of the media stream. A lite implementation can only act as a controlled agent.
Direction tags for the connectivity precondition: "send" means the generating party's packets have been received by the other party; "recv" means the other party's packets have been received by the generating party; "sendrecv" requires both conditions to hold simultaneously.
For connection-oriented transports (TCP, SCTP), a successful three-way handshake satisfies both "send" and "recv" connectivity preconditions implicitly, regardless of whether they were explicitly requested. SCTP connections SHOULD be treated the same as TCP in this regard.
For full ICE implementations acting as STUN client: "send" and "recv" connectivity are ascertained when a STUN Binding Request produces a successful check for all media stream components. For any ICE implementation acting as STUN server: "recv" connectivity is ascertained upon receiving a STUN Binding Request that results in a successful response.
The connectivity precondition type is identified by the string "conn" and is added to the SDP precondition-type grammar alongside "sec" and "qos". It is used to delay session establishment or modification until media stream connectivity has been verified.
IANA has registered a new precondition type "conn" (Connectivity precondition) under the Precondition Types used with SIP subregistry, located within the Session Initiation Protocol (SIP) Parameters registry.
An attacker blocking connectivity checks (e.g., ICE STUN Binding Requests) can prevent session establishment entirely when connectivity preconditions are in use. Without preconditions, only the individual stream is affected; with them, the entire session setup is disrupted. No mitigation is provided against attackers able to block all traffic between endpoints.
An attacker generating forged connectivity checks can cause endpoints to believe connectivity exists when it does not, resulting in session establishment without working media, or can trick endpoints into sending media to the wrong destination (connection hijacking). It is RECOMMENDED that connectivity verification mechanisms use message authentication and integrity protection (e.g., ICE's STUN message integrity per RFC 5245 Section 2.5).
It is strongly RECOMMENDED that S/MIME integrity protection be applied to SDP session descriptions carrying connectivity preconditions. The SIP identity mechanism (RFC 4474) is an alternative when the user agent provides identity services rather than a proxy server.
Connectivity verification follows a priority-ordered rule set: (1) if an explicit mechanism (e.g., ICE) is negotiated, precondition is met when that mechanism succeeds; (2) else if connection-oriented transport is negotiated, precondition is met when connection is established; (3) else if transport provides implicit verification, met when that succeeds; (4) else connectivity cannot be verified and precondition will never be satisfied.