Caller Preferences for the Session Initiation Protocol (SIP)
Extracted elements (27)
Reject-Contact is designed to only discard contacts where the UA has explicitly indicated support for the unwanted features. A Reject-Contact predicate is discarded for a given contact if any feature tag in the predicate is absent from the contact predicate, preventing rejection of contacts that simply haven't declared the feature.
The set of Request-Disposition directives is intentionally non-extensible to avoid proliferation of new SIP extensions tunneled through this header field.
When implicit preferences cause the elimination of all potential targets, the proxy reverts to the original target set ordered by q-values rather than returning a 480. This ensures the UAC receives a 405 or 489 explaining why the request failed, rather than a misleading 480 with no indication of the true cause.
A proxy MUST NOT apply the preferences matching operation unless it is the owner of the domain in the request URI and is accessing a location service that has capabilities associated with request targets. If it does perform matching, it MUST do so as described in Section 7.2.
A proxy MUST NOT modify or remove an existing caller preferences header field value. This is particularly important when S/MIME is used, as the message signature may include these header fields.
A redirect server returning contacts MUST NOT include feature parameters for entries in the target set after applying caller preferences, to prevent double application. If feature parameters are desired, it MUST redirect using the original target set and q-values before preference application.
A UAS SHOULD process any queue directive present in a Request-Disposition header field. All other Request-Disposition directives MUST be ignored by the UAS.
Header fields Accept-Contact, Reject-Contact, and Request-Disposition included in an ACK for a non-2xx final response, or in a CANCEL request, MUST be equal to the values in the original request being acknowledged or cancelled, to ensure proper operation through stateless proxies.
If a proxy server receives a request with the cancel-directive set to 'no-cancel', it SHOULD NOT CANCEL any outstanding branches upon receipt of a 2xx. It would still send CANCEL on outstanding branches upon receipt of a 6xx.
If, after performing preference matching processing, a UAS finds no URIs remaining in the target set, it SHOULD reject the request with a 480 response.
It is RECOMMENDED that a UAC include a term in an Accept-Contact feature set with the 'sip.methods' feature tag whose value includes the method of the request. For SUBSCRIBE, it is RECOMMENDED to include a term with the 'sip.events' feature tag matching the event package.
The BNF grammar requires that there MUST NOT be more than one req-param or explicit-param in an ac-params, and there can only be one instance of any feature tag in a feature-param.
When a UAS receives a request whose request-URI corresponds to one of its registered contacts, it SHOULD apply the preference and capability matching behavior described in Section 7.2 as if it were a proxy, allowing caller preferences to be honored even if the proxy doesn't support the extension.
Contact predicates are constructed from feature parameters in registered Contact header fields. URIs with no feature parameters are treated as immune to caller preference processing: they are temporarily removed, preference processing is applied to the remainder, and then added back with Qa=1.0.
Feature parameters are mapped to RFC 2533 conjunctive normal form predicates. Base feature tag names (e.g., 'audio', 'video', 'methods') get the 'sip.' prefix added; tags with a leading '+' have the '+' stripped; '!' is negation; '#' prefix signals numeric comparison; angle-bracket-quoted values use case-sensitive string matching.
Implicit preferences are derived by a proxy when no explicit Accept-Contact or Reject-Contact header fields are present. The proxy infers preferences from the request method (route to UAs supporting that method) and, for subscriptions, from the Event header field (route to UAs supporting that event package).
RFC 3841 defines three new SIP request header fields: Accept-Contact (compact form 'a'), Reject-Contact (compact form 'j'), and Request-Disposition (compact form 'd'). Accept-Contact and Reject-Contact carry feature set preferences; Request-Disposition carries request handling directives.
The Accept-Contact header field contains feature sets (parameterized with '*') describing UAs the caller wishes to reach. Optional 'require' and 'explicit' parameters control whether non-matching contacts are discarded or merely deprioritized.
The matching algorithm computes a score (0 to 1) per contact against each Accept-Contact predicate by counting the fraction of predicate feature tags explicitly present in the contact predicate. The overall caller preference Qa is the arithmetic average of all per-predicate scores. Contacts are sorted first by callee-provided q-value, then within each equivalence class by Qa.
The Reject-Contact header field contains feature sets (parameterized with '*') describing UAs that should not be contacted. A contact is discarded only if it explicitly indicates support for the features listed in a Reject-Contact predicate.
The Request-Disposition header field carries a list of directive tokens grouped by type: proxy-directive (proxy/redirect), cancel-directive (cancel/no-cancel), fork-directive (fork/no-fork), recurse-directive (recurse/no-recurse), parallel-directive (parallel/sequential), and queue-directive (queue/no-queue). Only one directive of each type is permitted per request.
Three new SIP header fields are registered per RFC 3261 procedures: Accept-Contact (compact form 'a'), Reject-Contact (compact form 'j'), and Request-Disposition (compact form 'd'), all defined in RFC 3841.
Processing caller preferences requires set operations and searches that can consume significant computation, enabling a DoS attack via requests with large numbers of caller preferences. Servers SHOULD reject requests with too many rules; a reasonable limit is around 20.
Requests containing caller preferences SHOULD be integrity-protected using the SIPS mechanism specified in RFC 3261 Section 26, because caller preferences affect request handling at servers and could be maliciously altered.
When the caller preferences target set is empty after explicit preference processing, the proxy returns a 480 without indicating the callee's capabilities. Revealing capabilities without callee authorization would leak potentially sensitive information, so the specification deliberately provides no mechanism for it.
Accept-Contact BNF: ('Accept-Contact' / 'a') HCOLON ac-value *(COMMA ac-value), where ac-value = '*' *(SEMI ac-params) and ac-params includes feature-param, req-param ('require'), explicit-param ('explicit'), or generic-param.
Request-Disposition BNF: ('Request-Disposition' / 'd') HCOLON directive *(COMMA directive), where directive is one of proxy-directive, cancel-directive, fork-directive, recurse-directive, parallel-directive, or queue-directive, each being a pair of mutually exclusive token values.