Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)
Extracted elements (29)
Capability and characteristic information about a UA is carried as parameters of the Contact header field rather than as separate header fields, because existing SIP header fields (Allow, Accept, Accept-Language, Supported) convey only a small part of the needed information and do not provide a general framework for expression of capabilities.
Feature tags for new SDP media types SHOULD use the name 'sip.' concatenated with the media type name, so that implementations can safely construct caller preferences and callee capabilities for new media types before they are formally registered, as long as there is no naming conflict.
The content negotiation framework from RFC 2533 is applied to SIP UAs by modeling a feature collection as an instantaneous modality — a snapshot of what the UA is doing at a given instant. This guides whether two properties should be separate feature tags (if they can be exhibited simultaneously) or values of the same tag (if they are mutually exclusive at any instant).
In the absence of a Require header field with value 'pref', a registrar that does not understand this extension will simply ignore the Contact header field parameters carrying feature information, resulting in silent loss of capability data without error.
A UA MUST NOT include values in 'sip.methods', 'sip.events', 'sip.schemes', or 'sip.extensions' feature tags that correspond to methods, event packages, schemes, or option tags not standardized in IETF standards track RFCs.
If a UA registers against multiple separate addresses-of-record and the contacts have different capabilities, the UA MUST use different URIs in each registration to allow unique determination of the feature set associated with an incoming request URI.
It is RECOMMENDED that a UA provide complete information in its contact predicate; it SHOULD provide information on as many feature tags as possible, and when it registers values for a particular feature tag, it MUST list all values it supports.
The contact predicate constructed by a UA MUST be an AND of terms (a conjunction), where each term in the conjunction MUST be for a different feature tag. If a string value is used in a simple filter, it MUST NOT include '<' or '>' characters, MUST NOT be negated, and MUST be the only simple filter for that feature tag.
The REGISTER request MAY contain a Require header field with value 'pref' if the client wants to ensure the registrar understands the caller preferences extensions and will store and make available the feature parameters.
There MUST be only one instance of any feature tag in feature-param. Any numbers present in a feature parameter MUST be representable using an ANSI C double.
When a feature tag describes a capability that can also be represented with a SIP header field (e.g., Allow and sip.methods, Accept and type, Accept-Language and language, Allow-Events and sip.events), a UA MUST use the header field. A UA receiving a message with both MUST use the header field, not the feature tag.
When a UAC refreshes its registration, it MUST include its feature parameters in the refresh if it wishes them to remain active. When a registrar returns a 200 OK to a REGISTER, each Contact header field value MUST include all feature parameters associated with that URI.
Feature parameters are encoded in the Contact header field. Base tags (sip.audio, sip.video, sip.methods, etc.) appear with the leading 'sip.' stripped and no '+' prefix. Non-base tags MUST have a leading '+' and retain any 'sip.' prefix. Boolean TRUE values result in a parameter with no value; disjunctions and negations are encoded as quoted strings.
The sip.actor feature tag indicates the type of entity at the URI: 'principal' (the associated person or automata), 'attendant' (intermediary), 'msg-taker' (message-taking automaton or person), or 'information' (provides information about the principal).
The sip.audio, sip.video, sip.data, sip.control, sip.application, and sip.text boolean feature tags indicate support for the corresponding streaming media types (matching SDP media types from RFC 2327), not top-level MIME types receivable in SIP requests.
The sip.automata boolean feature tag indicates whether the UA represents an automata (voicemail server, conference server, IVR, recording device) or a human; TRUE means automata.
The sip.duplex feature tag indicates media send/receive capability: 'full' (simultaneous send and receive), 'half' (alternate), 'receive-only', or 'send-only'.
The sip.events feature tag lists SIP event packages (RFC 3265) supported by the UA; values are taken from the IANA SIP Event types namespace registry. The sip.methods tag lists SIP methods the UA can receive (same semantics as the Allow header field).
The sip.isfocus boolean feature tag indicates that the UA is a conference focus server that mixes media for all calls to the same URI.
The sip.mobility feature tag indicates whether the device is 'fixed' (associated with a fixed network point, including cordless phones) or 'mobile' (not associated with a fixed point).
The sip.priority feature tag uses integer values mapping to SIP Priority header values: non-urgent=10, normal=20, urgent=30, emergency=40. A value of X means the device is willing to handle requests with priority X and higher.
This specification creates the 'SIP Media Feature Tag Registration Tree' with prefix 'sip.', for registering media feature tags applicable to SIP. New entries require IETF consensus (publication of an RFC). All tags in this tree have a 'sip.' prefix and no leading '+' in registrations.
This specification registers 18 media feature tags in the SIP tree: sip.audio, sip.application, sip.data, sip.control, sip.video, sip.text, sip.automata, sip.class, sip.duplex, sip.mobility, sip.description, sip.events, sip.priority, sip.methods, sip.extensions, sip.schemes, sip.actor, and sip.isfocus.
This specification registers a single SIP option tag 'pref', used in a Require header field of a registration to ensure the registrar supports the caller preferences extensions defined in this specification.
Media feature tags reveal sensitive information about the user or UA, including capability information (media types, methods, extensions) that could be used for industrial espionage, and more sensitive characteristics (mobility, priority, isfocus, language) that reveal user preferences and behavior. Applications utilizing these tags SHOULD provide confidentiality, integrity, and authenticity mechanisms.
Registrations containing capability information SHOULD be made to a SIPS URI, and the registrar SHOULD challenge the UA using digest over TLS to provide authenticity, confidentiality, and integrity. Feature tags should only be trusted when they come from the user or UA they describe.
When a UAC generates a dialog-initiating request, it SHOULD obtain permission from the user before including capability information in the Contact header field, and SHOULD provide confidentiality and integrity using SIPS.
When including capabilities in OPTIONS responses, a UA SHOULD verify with the user whether capability information should be divulged; if the requester's identity cannot be cryptographically verified, the user SHOULD be alerted. S/MIME MAY be used to protect capability information in OPTIONS responses.
The feature-param production extends Contact header field parameters: enc-feature-tag is either a base-tag (e.g., 'audio', 'video', 'methods') or an other-tag prefixed with '+'. Values are either a tag-value-list (comma-separated tokens, booleans, or numeric comparisons) within a quoted string, or a string-value enclosed in '<' and '>'.