Integration of Resource Management and Session Initiation Protocol (SIP)
updated by
Extracted elements (33)
A UA that supports QoS but does not intend to use it still includes desired-status lines with the 'none' strength-tag. This allows the answerer to upgrade the precondition to 'optional' or 'mandatory' without requiring a new offer/answer exchange.
Precondition attributes are placed in SDP rather than SIP headers because preconditions are stream-specific; SDP naturally carries per-stream parameters, while SIP headers are session-wide.
When both direction strength-tags are identical, a single 'sendrecv' desired-status line is required rather than two separate lines, to achieve a more compact encoding while preserving equivalent semantics.
SIP provides no mechanism to refuse an offer arriving in a 1xx or 2xx response to an INVITE. If such an offer is unacceptable, the UAC MUST form a valid answer and then immediately send a CANCEL (for initial INVITE) or BYE (for re-INVITE).
A UA receiving an unknown precondition-type with a 'mandatory' strength-tag MUST refuse the offer, unless the only unknown mandatory preconditions have the 'local' tag (in which case the UA need not participate). When refusing due to an unknown type, the 'unknown' strength-tag is used in the failure SDP.
A UA that supports preconditions SHOULD add desired-status lines with 'none' strength-tag to OPTIONS responses to indicate supported precondition-types, and SHOULD add the 'precondition' tag to the Supported header in those responses.
A UAS that cannot unilaterally meet all mandatory preconditions MUST include a confirm-status attribute in the SDP it sends, and that SDP MUST be sent as soon as allowed by SIP offer/answer rules.
A UAS that receives an offer with preconditions SHOULD NOT alert the user until all mandatory preconditions are met; session establishment is suspended until that point.
A user agent including preconditions in SDP MUST support the PRACK and UPDATE methods, MUST include the '100rel' tag in the Supported header, and SHOULD include an Allow header field with the 'UPDATE' tag.
All preconditions for a media stream MUST be met in order for session establishment to resume. A single stream may carry multiple preconditions of different types or status-types simultaneously.
An answer MUST be generated following Section 5.1.1 rules, with the additional rule that 'send'/'recv' and 'local'/'remote' tags MUST be inverted relative to the offer.
An answerer MAY upgrade the desired strength-tag in any entry of the transaction status table, but MUST NOT downgrade it. Valid upgrades are: none→optional, none→mandatory, optional→mandatory.
An offerer MUST include the 'precondition' option tag in the Require header if the offer contains any 'mandatory' strength-tags. If all tags are 'optional' or 'none', the tag MUST appear in either Supported or Require, with Supported RECOMMENDED.
Before generating an offer, the offerer MUST build a transaction status table containing current and desired status for each media stream. If the strength-tag is 'mandatory', session establishment MUST NOT continue unless resources are reserved.
Both offerer and answerer MUST ignore all preconditions affecting a media stream whose port is set to zero; such streams are not considered when deciding whether session establishment can resume.
Both user agents MUST maintain a local precondition status table (the 'local status table') tracking current and desired status for each direction and each media stream throughout the session duration.
For the e2e status type, the offerer MUST generate one current-status line with tag 'e2e'. If both direction strength-tags are equal, a single 'sendrecv' desired-status line MUST be used; if different, two separate 'send' and 'recv' lines MUST be included.
For the segmented status type, the offerer MUST generate two current-status lines (one 'local', one 'remote') and MUST add one or two desired-status lines per segment, collapsing matching direction strengths into a single 'sendrecv' line.
If a peer has requested confirmation on a stream, an agent MUST flag that stream; when all flagged rows have current='yes', a new offer MUST be sent. If any flagged row later transitions to 'no', a new offer MUST be sent as well.
If the resource reservation mechanism requires both UAs, the answerer SHOULD start reservation after sending the answer and the offerer SHOULD start after receiving the answer. Both user agents MUST keep their local status tables up to date using local information throughout the session.
When all rows whose strength-tag is 'mandatory' have a 'yes' current value in the local status table for all media lines, session establishment SHOULD resume.
While session establishment is suspended, user agents SHOULD NOT send any data over any media stream; for RTP, neither RTP nor RTCP packets are sent.
A new SIP status code 580 (Precondition Failure) is defined. When a UAS cannot or is unwilling to meet preconditions in an offer, it SHOULD reject the offer with this response.
The confirm-status attribute specifies a threshold for resource reservation. When that threshold is reached or crossed (in either direction), the receiving UA MUST send a new offer reflecting updated current status as soon as allowed by SIP offer/answer rules.
The strength-tag values form an ordered set: 'none' < 'optional' < 'mandatory', plus 'failure' and 'unknown' for error reporting. The direction-tag values are 'none', 'send', 'recv', 'sendrecv'. The status-type values are 'e2e', 'local', and 'remote'.
Three SDP media-level attributes are defined: 'a=curr:' (current status), 'a=des:' (desired status), and 'a=conf:' (confirmation status), each parameterized by precondition-type, status-type, direction-tag, and (for desired) a strength-tag.
Two status type models are defined: end-to-end (e2e), reflecting the reservation status across the entire path, and segmented (local/remote), reflecting per-access-network reservation status for each UA. The values 'send', 'recv', 'local', and 'remote' are from the perspective of the SDP-generating entity.
IANA maintains a registry for precondition-types. New types are registered only via standards-track RFCs. The initial registry entry is 'qos' (RFC 3312, Quality of Service preconditions). Registration requires a name (≤10 chars recommended) and descriptive text.
This document registers three SDP media-level attributes (curr, des, conf), a new SIP status code 580 (Precondition Failure), and a new SIP option tag 'precondition'.
A man-in-the-middle can add desired-status attributes to make session establishment impossible, or modify current-status parameters to allow a session to proceed without meeting preconditions. Integrity protection of SDP (e.g., S/MIME) is required to prevent these attacks.
An entity that performs resource reservations in response to unauthenticated SIP requests carrying preconditions is vulnerable to denial-of-service attacks. Requests with preconditions SHOULD be authenticated.
The answerer reconciles transaction and local status tables using four cases: (no/no)→no change; (yes/yes)→no change; (yes/no)→set local to yes; (no/yes)→if the UA has local confirmation info, set transaction to yes, else set local to no. This synchronizes both UAs' views after each offer/answer.
A 580 response, BYE, or CANCEL indicating precondition failure SHOULD contain an SDP description (not an offer/answer) based on the last SDP received, with all 'm=' port numbers set to zero and the failing desired-status line using the 'failure' strength-tag (e.g., 'a=des:qos failure e2e send').