Request for Comments: 3840 dynamicsoft
Category: Standards Track H. Schulzrinne
Columbia University
P. Kyzivat
Cisco Systems
August 2004
Indicating User Agent Capabilities in
the Session Initiation Protocol (SIP)
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2004).
Abstract
This specification defines mechanisms by which a Session Initiation
Protocol (SIP) user agent can convey its capabilities and
characteristics to other user agents and to the registrar for its
domain. This information is conveyed as parameters of the Contact
header field.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Usage of the Content Negotiation Framework . . . . . . . . . . 6
5. Computing Capabilities . . . . . . . . . . . . . . . . . . . . 7
6. Expressing Capabilities in a Registration . . . . . . . . . . 10
7. Indicating Feature Sets in Remote Target URIs . . . . . . . . 12
8. OPTIONS Processing . . . . . . . . . . . . . . . . . . . . . . 13
9. Contact Header Field . . . . . . . . . . . . . . . . . . . . . 13
10. Media Feature Tag Definitions . . . . . . . . . . . . . . . . 14
10.1. Audio . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.2. Application . . . . . . . . . . . . . . . . . . . . . . 16
10.3. Data. . . . . . . . . . . . . . . . . . . . . . . . . . 16
10.4. Control . . . . . . . . . . . . . . . . . . . . . . . . 17
10.5. Video . . . . . . . . . . . . . . . . . . . . . . . . . 17
10.6. Text. . . . . . . . . . . . . . . . . . . . . . . . . . 18
10.7. Automata. . . . . . . . . . . . . . . . . . . . . . . . 18
10.8. Class . . . . . . . . . . . . . . . . . . . . . . . . . 19
10.9. Duplex. . . . . . . . . . . . . . . . . . . . . . . . . 20
10.10. Mobility. . . . . . . . . . . . . . . . . . . . . . . . 20
10.11. Description . . . . . . . . . . . . . . . . . . . . . . 21
10.12. Event Packages. . . . . . . . . . . . . . . . . . . . . 22
10.13. Priority. . . . . . . . . . . . . . . . . . . . . . . . 22
10.14. Methods . . . . . . . . . . . . . . . . . . . . . . . . 23
10.15. Extensions. . . . . . . . . . . . . . . . . . . . . . . 24
10.16. Schemes . . . . . . . . . . . . . . . . . . . . . . . . 24
10.17. Actor . . . . . . . . . . . . . . . . . . . . . . . . . 25
10.18. Is Focus. . . . . . . . . . . . . . . . . . . . . . . . 26
11. Security Considerations . . . . . . . . . . . . . . . . . . . 26
11.1. Considerations for Media Feature Tags . . . . . . . . . 26
11.2. Considerations for Registrations. . . . . . . . . . . . 27
11.3. Considerations for OPTIONS Responses. . . . . . . . . . 28
11.4. Considerations for Dialog Initiating Messages . . . . . 28
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
12.1. SIP Media Feature Tag Registration Tree . . . . . . . . 28
12.2. Media Feature Tags. . . . . . . . . . . . . . . . . . . 29
12.3. SIP Option Tag. . . . . . . . . . . . . . . . . . . . . 30
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
14.1. Normative References. . . . . . . . . . . . . . . . . . 31
14.2. Informative References. . . . . . . . . . . . . . . . . 31
Appendix. Overview of RFC 2533. . . . . . . . . . . . . . . . . . 33
Authors’ Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 36
1. Introduction
Session Initiation Protocol (SIP) [1] user agents vary widely in
their capabilities and in the types of devices they represent.
Frequently, it is important for another SIP element to learn the
capabilities and characteristics of a SIP UA. Some of the
applications of this information include:
o One user agent, a PC-based application, is communicating with
another that is embedded in a limited-function device. The PC
would like to be able to "grey out" those components of the user
interface that represent features or capabilities not supported by
its peer. To do that, there needs to be a way to exchange
capability information within a dialog.
o A user has two devices at their disposal. One is a videophone,
and the other, a voice-only wireless phone. A caller wants to
interact with the user using video. As such, they would like
their call preferentially routed to the device which supports
video. To do this, the INVITE request can contain parameters that
express a preference for routing to a device with the specified
capabilities [11].
o A network application would like to asynchronously send
information to a user agent in a MESSAGE [16] request. However,
before sending it, they would like to know if the UA has the
capabilities necessary to receive the message. To do that, they
would ideally query a user database managed by the domain which
holds such information. Population of such a database would
require that a UA convey its capabilities as part of its
registration. Thus, there is a need for conveying capabilities in
REGISTER requests.
SIP has some support for expression of capabilities. The Allow,
Accept, Accept-Language, and Supported header fields convey some
information about the capabilities of a user agent. However, these
header fields convey only a small part of the information that is
needed. They do not provide a general framework for expression of
capabilities. Furthermore, they only specify capabilities
indirectly; the header fields really indicate the capabilities of the
UA as they apply to this request. SIP also has no ability to convey
characteristics, that is, information that describes a UA.
As a result, this specification provides a more general framework for
an indication of capabilities and characteristics in SIP. Capability
and characteristic information about a UA is carried as parameters of
the Contact header field. These parameters can be used within
REGISTER requests and responses, OPTIONS responses, and requests and
responses that create dialogs (such as INVITE).
2. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119
[2] and indicate requirement levels for compliant implementations.
3. Definitions
Feature: As defined in RFC 2703 [17], a piece of information about
the media handling properties of a message passing system
component or of a data resource. For example, the SIP methods
supported by a UA represent a feature.
Feature Tag: As defined in RFC 2703 [17], a feature tag is a name
that identifies a feature. An example is "sip.methods".
Media Feature: As defined in RFC 2703, [17], a media feature is
information that indicates facilities assumed to be available for
the message content to be properly rendered or otherwise
presented. Media features are not intended to include information
that affects message transmission.
In the context of this specification, a media feature is
information that indicates facilities for handling SIP requests,
rather than specifically for content. In that sense, it is used
synonymously with feature.
Feature Collection: As defined in RFC 2533 [4], a feature collection
is a collection of different media features and associated values.
This might be viewed as describing a specific rendering of a
specific instance of a document or resource by a specific
recipient.
Feature Set: As defined in RFC 2703 [17], a feature set is
information about a sender, recipient, or other participant in a
message transfer which describes the set of features that it can
handle. Where a ’feature’ describes a single identified attribute
of a resource, a ’feature set’ describes a full set of possible
attributes.
Feature Parameters: A set of SIP header field parameters that can
appear in the Contact header field. The feature parameters
represent an encoding of a feature set. Each set of feature
parameters maps to a feature set predicate.
Capability: As defined in RFC 2703 [17], a capability is an attribute
of a sender or receiver (often the receiver) which indicates an
ability to generate or process a particular type of message
content. A capability is distinct from a characteristic in that a
capability may or may not be utilized in any particular call,
whereas a characteristic is a non-negotiable property of a UA.
SIP itself will often negotiate whether or not capabilities are
used in a call.
Characteristic: A characteristic is like a capability, but describes
an aspect of a UA which is not negotiable. As an example, whether
or not a UA is a mobile phone is a characteristic, not a
capability. The semantics of this specification do not
differentiate between capability and characteristic, but the
distinction is useful for illustrative purposes. Indeed, in the
text below, when we say "capability", it refers to both
capabilities and characteristics, unless the text explicitly says
otherwise.
Filter: A single expression in a feature set predicate.
Simple Filter: An expression in a feature set predicate which is a
comparison (equality or inequality) of a feature tag against a
feature value.
Disjunction: A boolean OR operation across some number of terms.
Conjunction: A boolean AND operation across some number of terms.
Predicate: A boolean expression.
Feature Set Predicate: From RFC 2533 [4], a feature set predicate is
a function of an arbitrary feature collection value which returns
a Boolean result. A TRUE result is taken to mean that the
corresponding feature collection belongs to some set of media
feature handling capabilities defined by this predicate.
Contact Predicate: The feature set predicate associated with a URI
registered in the Contact header field of a REGISTER request. The
contact predicate is derived from the feature parameters in the
Contact header field.
4. Usage of the Content Negotiation Framework
This specification makes heavy use of the terminology and concepts in
the content negotiation work carried out within the IETF, and
documented in several RFCs. The ones relevant to this specification
are RFC 2506 [3], which provides a template for registering media
feature tags, RFC 2533 [4], which presents a syntax and matching
algorithm for media feature sets, RFC 2738 [5], which provides a
minor update to RFC 2533, and RFC 2703 [17], which provides a general
framework for content negotiation.
In case the reader does not have the time to read those
specifications, Appendix A provides a brief overview of the concepts
and terminology in those documents that is critical for understanding
this specification.
Since the content negotiation work was primarily meant to apply to
documents or other resources with a set of possible renderings, it is
not immediately apparent how it is used to model SIP user agents. A
feature set is composed of a set of feature collections, each of
which represents a specific rendering supported by the entity
described by the feature set. In the context of a SIP user agent, a
feature collection represents an instantaneous modality. That is, if
you look at the run time processing of a SIP UA and take a snapshot
in time, the feature collection describes what it is doing at that
very instant.
This model is important, since it provides guidance on how to
determine whether something is a value for a particular feature tag,
or a feature tag by itself. If two properties can be exhibited by a
UA simultaneously so that both are present in an instantaneous
modality, they need to be represented by separate media feature tags.
For example, a UA may be able to support some number of media types -
audio, video, and control. Should each of these be different values
for a single "media-types" feature tag, or should each of them be a
separate boolean feature tag? The model provides the answer. Since,
at any instance in time, a UA could be handling both audio and video,
they need to be separate media feature tags. However, the SIP
methods supported by a UA can each be represented as different values
for the same media feature tag (the "sip.methods" tag), because
fundamentally, a UA processes a single request at a time. It may be
multi-threading, so that it appears that this is not so, but at a
purely functional level, it is true.
Clearly, there are weaknesses in this model, but it serves as a
useful guideline for applying the concepts of RFC 2533 to the problem
at hand.
5. Computing Capabilities
To construct a set of Contact header field parameters that indicate
capabilities, a UA constructs a feature predicate for that contact.
This process is described in terms of RFC 2533 [4] (and its minor
update, RFC 2738 [5]) syntax and constructs, followed by a conversion
to the syntax used in this specification. However, this represents a
logical flow of processing. There is no requirement that an
implementation actually use RFC 2533 syntax as an intermediate step.
A UA MAY use any feature tags that are registered through IANA in the
SIP tree (Established in Section 12.1), IETF, or global trees [3];
this document registers several into the SIP tree. The feature tags
discussed in this specification are referred to as base tags. While
other tags can be used, in order to identify them as feature
parameters (as opposed to parameters for another SIP extension), they
are encoded with a leading "+" sign in the Contact header field. It
is also permissible to use the URI tree [3] for expressing vendor-
specific feature tags. Feature tags in any other trees created
through IANA MAY also be used.
When using the "sip.methods" feature tag, a UA MUST NOT include
values that correspond to methods not standardized in IETF standards
track RFCs. When using the "sip.events" feature tag, a UA MUST NOT
include values that correspond to event packages not standardized in
IETF standards track RFCs. When using the "sip.schemes" feature tag,
a UA MUST NOT include values that correspond to schemes not
standardized in IETF standards track RFCs. When using the
"sip.extensions" feature tag, a UA MUST NOT include values that
correspond to option tags not standardized in IETF standards track
RFCs.
Note that the "sip.schemes" feature tag does not indicate the scheme
of the registered URI. Rather, it indicates schemes that a UA is
capable of sending requests to, should such a URI be received in a
web page or Contact header field of a redirect response.
It is RECOMMENDED that a UA provide complete information in its
contact predicate. That is, it SHOULD provide information on as many
feature tags as possible. The mechanisms in this specification work
best when user agents register complete feature sets. Furthermore,
when a UA registers values for a particular feature tag, it MUST list
all values that it supports. For example, when including the
"sip.methods" feature tag, a UA MUST list all methods it supports.
The contact predicate constructed by a UA MUST be an AND of terms
(called a conjunction). Each term is either an OR (called a
disjunction) of simple filters or negations of simple filters, or a
single simple filter or negation of a single filter. In the case of
a disjunction, each filter in the disjunction MUST indicate feature
values for the same feature tag (i.e., the disjunction represents a
set of values for a particular feature tag), while each element of
the conjunction MUST be for a different feature tag. Each simple
filter can be an equality, or in the case of numeric feature tags, an
inequality or range. If a string (as defined in RFC 2533 [4]) is
used as the value of a simple filter, that value MUST NOT include the
"<" or ">" characters, the simple filter MUST NOT be negated, and it
MUST be the only simple filter for that particular feature tag. This
contact predicate is then converted to a list of feature parameters,
following the procedure outlined below.
The contact predicate is a conjunction of terms. Each term indicates
constraints on a single feature tag, and each term is represented by
a separate feature parameter that will be present in the Contact
header field. The syntax of this parameter depends on the feature
tag. Each forward slash in the feature tag is converted to a single
quote, and each colon are converted to an exclamation point. For the
base tags - that is, those feature tags documented in this
specification (sip.audio, sip.automata, sip.class, sip.duplex,
sip.data, sip.control, sip.mobility, sip.description, sip.events,
sip.priority, sip.methods, sip.extensions, sip.schemes,
sip.application, sip.video, language, type, sip.isfocus, sip.actor
and sip.text), the leading "sip.", if present, is stripped. For
feature tags not in this list, the leading "sip." MUST NOT be
stripped if present, and indeed, a plus sign ("+") MUST be added as
the first character of the Contact header field parameter. The
result is the feature parameter name. As a result of these rules,
the base tags appear "naked" in the Contact header field - they have
neither a "+" nor a "sip." prefix. All other tags will always have a
leading "+" when present in the Contact header field, and will
additionally have a "sip." if the tag is in the SIP tree.
The value of the feature parameter depends on the term of the
conjunction. If the term is a boolean expression with a value of
true, i.e., (sip.audio=TRUE), the contact parameter has no value. If
the term of the conjunction is a disjunction, the value of the
contact parameter is a quoted string. The quoted string is a comma
separated list of strings, each one derived from one of the terms in
the disjunction. If the term of the conjunction is a negation, the
value of the contact parameter is a quoted string. The quoted string
begins with an exclamation point (!), and the remainder is
constructed from the expression being negated.
The remaining operation is to compute a string from a primitive
filter. If the filter is a simple filter that is performing a numeric
comparison, the string starts with an octothorpe (#), followed by the
comparator in the filter (=, >=, or <=), followed by the value from
the filter. If the value from the filter is expressed in rational
form (X / Y), then X and Y are divided, yielding a decimal number,
and this decimal number is output to the string.
RFC 2533 uses a fractional notation to describe rational numbers.
This specification uses a decimal form. The above text merely
converts between the two representations. Practically speaking,
this conversion is not needed since the numbers are the same in
either case. However, it is described in case implementations
wish to directly plug the predicates generated by the rules in
this section into an RFC 2533 implementation.
If the filter is a range (foo=X..Y), the string is equal to X:Y,
where X and Y have been converted from fractional numbers (A / B) to
their decimal equivalent.
If the filter is an equality over a token or boolean, then that token
or boolean value ("TRUE" or "FALSE") is output to the string.
If the filter is an equality over a quoted string, the output is a
less than (<), followed by the quoted string, followed by a greater
than (>).
As an example, this feature predicate:
(& (sip.mobility=fixed)
(| (! (sip.events=presence)) (sip.events=message-summary))
(| (language=en) (language=de))
(sip.description="PC")
(sip.newparam=TRUE)
(rangeparam=-4..5125/1000))
would be converted into the following feature parameters:
mobility="fixed";events="!presence,message-summary";language="en,de"
;description="<PC>";+sip.newparam;+rangeparam="#-4:+5.125"
These feature tags would then appear as part of the Contact header
field:
Contact: <sip:user@pc.example.com>
;mobility="fixed";events="!presence,message-summary"
;language="en,de";description="<PC>"
;+sip.newparam;+rangeparam="#-4:+5.125"
Notice how the leading "sip." was stripped from the sip.mobility,
sip.events and sip.description feature tags before encoding them in
the Contact header field. This is because these feature tags are
amongst the base tags listed above. It is for this reason that these
feature tags were not encoded with a leading "+" either. However,
the sip.newparam feature tag was encoded with both the "+" and its