Mechanism to Indicate Support of Features and Capabilities in the Session Initiation Protocol (SIP)
Extracted elements (25)
Feature-capability indicators were introduced because media feature tags (RFC 3840) can only be conveyed in the Contact header field, which is tied to the URI of the SIP entity. Proxies, registrars, and B2BUAs whose Contact URI represents another entity have no existing mechanism to signal their own capabilities.
The Feature-Caps header field does not convey the address of the SIP entity that inserted it. If address information about the inserting entity is needed, the individual feature-capability indicator definition must specify a way to include that address as an indicator value.
Unlike media feature tags, feature-capability indicators are intended to be used only with SIP, not as general-purpose media feature tags. This distinction is deliberate to keep the two mechanisms separate in scope and registry.
Because 2xx responses to SIP SUBSCRIBE may not reach the UAC due to forking, entities need to indicate supported features and capabilities in the SIP NOTIFY request that will be sent for each created subscription dialog.
If SIP outbound (RFC 5626) is used, feature-capability support only applies to the specific registration flow on which support has been explicitly indicated, not to all flows associated with the registration.
A feature-capability indicator specification MUST address overall description, values, usage restrictions, interoperability considerations, and security considerations. It MUST NOT modify the Feature-Caps header field rules defined in RFC 6809, and MUST NOT weaken any SHOULD or MUST behaviors in this specification.
A SIP entity SHOULD NOT re-order the Feature-Caps header fields within a SIP message. Entities MAY remove a Feature-Caps header field or individual feature-capability indicators from a message based on features and policies.
Feature-capability indicators in a REGISTER request or response apply only for the duration of the registration of the contact explicitly conveyed in that REGISTER request. SIP entities MUST NOT insert a Feature-Caps header field in pure registration binding fetching messages (REGISTER without a Contact header field).
For a given dialog, a SIP entity MUST insert the same feature-capability indicators in all 18x and 2xx responses associated with a given transaction.
If the URI in a Contact header field of a request or response represents a SIP entity, that entity MUST NOT indicate supported features and capabilities using a Feature-Caps header field within that request or response.
The feature-capability indicator specification MUST define the syntax and semantics of any values for the indicator in accordance with the ABNF in Section 6.3.2, and MUST define whether the indicator has a default value. It is strongly RECOMMENDED to not re-use values already defined for another indicator unless the semantics are identical.
When a SIP entity adds a Feature-Caps header field to a SIP message, it MUST place the header field before any existing Feature-Caps header field so that the added header field becomes the top-most one, ensuring that the nearest entity's capabilities appear first.
A B2BUA referenced by a Record-Route header field (not a Contact URI) inserts Feature-Caps in outgoing requests to signal capabilities toward downstream entities, and in responses toward upstream entities. It MAY also copy received Feature-Caps from an incoming request/response to the outgoing message before inserting its own.
A SIP proxy inserts a Feature-Caps header field in a forwarded SIP request to signal capabilities toward downstream entities, and in a forwarded response to signal capabilities toward upstream entities.
A SIP registrar that wants to indicate support of features and capabilities toward upstream SIP entities inserts a Feature-Caps header field in a REGISTER response (200 OK).
Feature-capability indicators use a registration tree hierarchy distinguished by a leading facet prefix (e.g., 'g.' for the global tree, 'sip.' for the SIP tree). A dot-separated naming scheme allows sub-feature hierarchies (e.g., 'tree.feature.subfeature'). No leading '+' is used in IANA registrations.
The Feature-Caps header field is a new SIP header field that conveys feature-capability indicators indicating support of features and capabilities for SIP entities not represented by the URI of the Contact header field, such as proxies, registrars, and B2BUAs.
The 'Global Feature-Capability Indicator Registration Tree' (leading facet 'g.') is created within the Proxy-Feature registry. Registration requires 'Specification Required' per RFC 5226 and designated expert review. No initial values are registered.
The 'SIP Feature-Capability Indicator Registration Tree' (leading facet 'sip.') is created within the Proxy-Feature registry. Registration requires 'IETF Review' per RFC 5226 and submission of an Internet-Draft to the IESG. No initial values are registered.
This specification creates the IANA 'Proxy-Feature Feature-Capability Indicator Trees' sub-registry under 'Session Initiation Protocol (SIP) Parameters'. Feature-capability indicators are organized by leading facet into trees. New trees require 'Standards Action' per RFC 5226.
This specification registers the 'Feature-Caps' header field in the IANA 'Header Fields' registry and adds it to the 'Header Field Parameters and Parameter Values' registry, where valid feature-capability indicator names conforming to the fcap-name syntax are registered as parameters.
Feature-capability indicators can reveal application deployment details or identify elements with exploitable implementation weaknesses. Unlike media feature tags (RFC 3840), they do not expose end-user equipment capabilities, but they may expose sensitive SIP infrastructure information.
If feature-capability indicators require data integrity or origin authentication, such mechanisms MUST be provided. If confidentiality is required, the specification MUST call for TLS at all hops. Specifications SHOULD NOT define indicators needing confidentiality beyond what hop-by-hop TLS provides, as no satisfactory middle-to-end SIP confidentiality mechanism exists.
The feature-capability indicator ABNF: `feature-cap = "+" fcap-name [EQUAL LDQUOT (fcap-value-list / fcap-string-value) RDQUOT]`. The leading '+' sign is mandatory for feature-capability indicators, distinguishing them from media feature tags.
The Feature-Caps header field ABNF: `Feature-Caps = "Feature-Caps" HCOLON fc-value *(COMMA fc-value)` and `fc-value = "*" *(SEMI feature-cap)`. The '*' wildcard value is present to follow RFC 4485 guidelines and maintain consistency with RFCs 3840/3841.