Update to the Session Initiation Protocol (SIP) Preconditions Framework
updates
- rfc-3312 — Integration of Resource Management and Session Initiation Protocol (SIP)
Extracted elements (22)
Moving an existing media stream to a new transport address is treated as equivalent to establishing a new stream from the preconditions perspective. This justifies setting all current status values to 'No' and restarting precondition negotiation from scratch, regardless of prior negotiated state.
RFC 3312 disallowed downgrading current status values in answers, but this is insufficient for session mobility scenarios such as 3pcc-driven transfers. When a 3pcc controller moves a session from B to C, the answer must be able to reset the current status to 'No' because no resource reservation exists between A and C. This document lifts that prohibition for the mobility case.
The prohibition on sending media during session suspension (no RTP/RTCP) is explicitly scoped to QoS preconditions only. Connection-setup control messages for connection-oriented transports (e.g., TCP SYNs) are not affected by this rule; UAs follow standard SDP 'setup' attribute rules regardless of QoS preconditions.
UASs do not typically send offer/answer exchanges to inform the UAC that all preconditions are met; instead, they simply send a 180 Ringing response. This asymmetry is by design: resuming session establishment does not require a separate signaling round-trip.
For streams using segmented status, a local address change may or may not affect the remote segment's precondition status. The specification mandates treating the move as a full reset (all current status to 'No') regardless, to ensure consistent behavior across implementations.
This document updates RFC 3312 Table 3 to permit answerers to downgrade current status values when moving a stream to a new address. Implementations conforming to RFC 3312 alone will not permit such downgrades and may mishandle session-mobility scenarios.
An answerer MUST downgrade the current status values received in the offer if it has local information about them or if the media stream is being moved to a new transport address.
Each precondition type MUST define any extra actions UAs should perform or refrain from performing when session establishment is suspended, including specifying whether media streams may send and receive packets during suspension. The QoS-specific rule prohibiting RTP/RTCP during suspension applies only to QoS preconditions, not universally.
It is strongly RECOMMENDED that integrity protection be applied to SDP session descriptions carrying preconditions. S/MIME is identified as the natural choice for end-to-end integrity protection, as described in RFC 3261.
New precondition types MUST also describe the behavior of UAs upon reception of a re-INVITE or an UPDATE with preconditions for an ongoing session.
New precondition types MUST have an associated precondition type tag (e.g., 'qos' for QoS preconditions). Authors MUST register new precondition types and their tags with IANA by following the instructions in Section 15 of RFC 3312.
Specifications defining new precondition types MUST describe whether optional preconditions are applicable and, if so, what behavior a UA should exhibit upon reception of optional preconditions.
Specifications defining new precondition types MUST indicate which status type (end-to-end, segmented, or both) applies to the new precondition. New preconditions may use one or both status types.
When a stream is being moved to a new transport address, the offerer MUST set all current status values about which it does not have local information to 'No', treating the move as equivalent to establishing a new stream.
A separate table governs offerer behavior when receiving an answer that updates or downgrades local status: no/no stays no; yes/yes stays yes; transac yes with local no yields yes; transac no with local yes yields no.
Desired status may be renegotiated when a stream moves to a new transport address. A UA may upgrade desired status (optional to mandatory) in an offer or answer, but may only downgrade (mandatory to optional) in an offer, not in an answer.
Precondition strength: mandatory or optional. Mandatory preconditions must be met before session establishment resumes; optional ones allow more flexibility. Specs must describe whether optional strength is applicable and the expected UA behavior.
Precondition type tag: a short string identifier (e.g., 'qos') that labels a precondition type. Required for every new precondition type and must be registered with IANA.
Status types defined in RFC 3312 are end-to-end and segmented. New precondition specifications must declare which applies. For segmented status, an address change at one segment may or may not affect precondition status at the remote segment.
The updated transaction/local status table (replacing Table 3 of RFC 3312) governs answerer behavior: if both transac and local status are 'no', new values are no/no; if both are 'yes', new values are yes/yes; mixed cases depend on local information. Answerers may now downgrade current status values, which RFC 3312 previously disallowed.
IANA registration requirements for the preconditions framework remain as defined in RFC 3312 Section 15. Any new precondition types introduced by future documents must follow those registration procedures.
An attacker adding preconditions to, or modifying existing preconditions within, a session description could prevent session establishment. An attacker removing preconditions could force sessions to be established without mandatory preconditions being met. Integrity protection via S/MIME is strongly recommended to counter these threats.