leading "sip.", and the rangeparam was also encoded with a leading
"+". This is because neither of these feature tags are defined in
this specification. As such, the leading "sip." is not stripped off,
and a "+" is added.
6. Expressing Capabilities in a Registration
When a UA registers, it can choose to indicate a feature set
associated with a registered contact. Whether or not a UA does so
depends on what the registered URI represents. If the registered URI
represents a UA instance (the common case in registrations), a UA
compliant to this specification SHOULD indicate a feature set using
the mechanisms described here. If, however, the registered URI
represents an address-of-record, or some other resource that is not
representable by a single feature set, it SHOULD NOT include a
feature set. As an example, if a user wishes to forward calls from
sip:user1@example.com to sip:user2@example.org, it could generate a
registration that looks like, in part:
REGISTER sip:example.com SIP/2.0
To: sip:user1@example.com
Contact: sip:user2@example.org
In this case, the registered contact is not identifying a UA, but
rather, another address-of-record. In such a case, the registered
contact would not indicate a feature set.
However, in some cases, a UA may wish to express feature parameters
for an address-of-record. One example is an AOR which represents a
multiplicity of devices in a home network, and routes to a proxy
server in the user’s home. Since all devices in the home are for
personal use, the AOR itself can be described with the
;class="personal" feature parameter. A registration that forwards
calls to this home AOR could make use of that feature parameter.
Generally speaking, a feature parameter can only be associated with
an address-of-record if all devices bound to that address-of-record
share the exact same set of values for that feature parameter.
Similarly, in some cases, a UA can exhibit one characteristic or
another, but the characteristic is not known in advance. For
example, a UA could represent a device that is a phone with an
embedded answering machine. The ideal way to treat such devices is
to model them as if they were actually a proxy fronting two devices -
a phone (which is never an answering machine), and an answering
machine (which is never a phone). The registration from this device
would be constructed as if it were an AOR, as per the procedures
above. Generally, this means that, unless the characteristic is
identical between the logical devices, that characteristic will not
be present in any registration generated by the actual device.
The remainder of this section assumes that a UA would like to
associate a feature set with a contact that it is registering. This
feature set is constructed and converted to a series of Contact
header field parameters, as described in Section 5, and those feature
parameters are added to the Contact header field value containing the
URI to which the parameters apply. The Allow, Accept, Accept-
Language and Allow-Events [9] header fields are allowed in REGISTER
requests, and also indicate capabilities. However, their semantic in
REGISTER is different, indicating capabilities, used by the
registrar, for generation of the response. As such, they are not a
substitute or an alternate for the Contact feature parameters, which
indicate the capabilities of the UA generally speaking.
The REGISTER request MAY contain a Require header field with the
value "pref" if the client wants to be sure that the registrar
understands the extensions defined in this specification. This means
that the registrar will store the feature parameters, and make them
available to elements accessing the location service within the
domain. In the absence of the Require header field, a registrar that
does not understand this extension will simply ignore the Contact
header field parameters.
If a UA registers against multiple separate addresses-of-record, and
the contacts registered for each have different capabilities, a UA
MUST use different URIs in each registration. This allows the UA to
uniquely determine the feature set that is associated with the
request URI of an incoming request.
As an example, a voicemail server that is a UA that supports audio
and video media types and is not mobile would construct a feature
predicate like this:
(& (sip.audio=TRUE)
(sip.video=TRUE)
(sip.actor=msg-taker)
(sip.automata=TRUE)
(sip.mobility=fixed)
(| (sip.methods=INVITE) (sip.methods=BYE) (sip.methods=OPTIONS)
(sip.methods=ACK) (sip.methods=CANCEL)))
These would be converted into feature parameters and included in the
REGISTER request:
REGISTER sip:example.com SIP/2.0
From: sip:user@example.com;tag=asd98
To: sip:user@example.com
Call-ID: hh89as0d-asd88jkk@host.example.com
CSeq: 9987 REGISTER
Max-Forwards: 70
Via: SIP/2.0/UDP host.example.com;branch=z9hG4bKnashds8
Contact: <sip:user@host.example.com>;audio;video
;actor="msg-taker";automata;mobility="fixed"
;methods="INVITE,BYE,OPTIONS,ACK,CANCEL"
Content-Length: 0
Note that a voicemail server is usually an automata and a message
taker.
When a UAC refreshes its registration, it MUST include its feature
parameters in that refresh if it wishes for them to remain active.
Furthermore, when a registrar returns a 200 OK response to a REGISTER
request, each Contact header field value MUST include all of the
feature parameters associated with that URI.
7. Indicating Feature Sets in Remote Target URIs
Target refresh requests and responses are used to establish and
modify the remote target URI in a dialog. The remote target URI is
conveyed in the Contact header field. A UAC or UAS MAY add feature
parameters to the Contact header field value in target refresh
requests and responses for the purpose of indicating the capabilities
of the UA. To do that, it constructs a set of feature parameters
according to Section 5. These are then added as Contact header field
parameters in the request or response.
The feature parameters can be included in both initial requests and
mid-dialog requests, and MAY change mid-dialog to signal a change in
UA capabilities.
There is overlap in the callee capabilities mechanism with the Allow,
Accept, Accept-Language, and Allow-Events [9] header fields, which
can also be used in target refresh requests. Specifically, the Allow
header field and "sip.methods" feature tag indicate the same
information. The Accept header field and the "type" feature tag
indicate the same information. The Accept-Language header field and
the "language" feature tag indicate the same information. The
Allow-Events header field and the "sip.events" feature tag indicate
the same information. It is possible that other header fields and
feature tags defined in the future may also overlap. When there
exists a feature tag that describes a capability that can also be
represented with a SIP header field, a UA MUST use the header field
to describe the capability. A UA receiving a message that contains
both the header field and the feature tag MUST use the header field,
and not the feature tag.
8. OPTIONS Processing
When a UAS compliant to this specification receives an OPTIONS
request, it MAY add feature parameters to the Contact header field in
the OPTIONS response for the purpose of indicating the capabilities
of the UA. To do that, it constructs a set of feature parameters
according to Section 5. These are then added as Contact header field
parameters in OPTIONS response. Indeed, if feature parameters were
included in the registration generated by that UA, those same
parameters SHOULD be used in the OPTIONS response.
The guidelines in Section 7 regarding the overlap of the various
callee capabilities feature tags with SIP header fields applies to
the generation of OPTIONS responses as well. In particular, they
apply when a Contact header field is describing the UA which
generated the OPTIONS response. When a Contact header field in the
OPTIONS response is identifying a different UA, there is no overlap.
9. Contact Header Field
This specification extends the Contact header field. In particular,
it allows for the Contact header field parameters to include
feature-param. Feature-param is a feature parameter that describes a
feature of the UA associated with the URI in the Contact header
field. Feature parameters are identifiable because they either
belong to the well known set of base feature tags, or they begin with
a plus sign.
feature-param = enc-feature-tag [EQUAL LDQUOT (tag-value-list
/ string-value ) RDQUOT]
enc-feature-tag = base-tags / other-tags
base-tags = "audio" / "automata" /
"class" / "duplex" / "data" /
"control" / "mobility" / "description" /
"events" / "priority" / "methods" /
"schemes" / "application" / "video" /
"language" / "type" / "isfocus" /
"actor" / "text" / "extensions"
other-tags = "+" ftag-name
ftag-name = ALPHA *( ALPHA / DIGIT / "!" / "’" /
"." / "-" / "%" )
tag-value-list = tag-value *("," tag-value)
tag-value = ["!"] (token-nobang / boolean / numeric)
token-nobang = 1*(alphanum / "-" / "." / "%" / "*"
/ "_" / "+" / "`" / "’" / "~" )
boolean = "TRUE" / "FALSE"
numeric = "#" numeric-relation number
numeric-relation = ">=" / "<=" / "=" / (number ":")
number = [ "+" / "-" ] 1*DIGIT ["." 0*DIGIT]
string-value = "<" *(qdtext-no-abkt / quoted-pair ) ">"
qdtext-no-abkt = LWS / %x21 / %x23-3B / %x3D
/ %x3F-5B / %x5D-7E / UTF8-NONASCII
Note that the tag-value-list uses an actual comma instead of the
COMMA construction because it appears within a quoted string, where
line folding cannot take place.
The production for qdtext can be found in RFC 3261 [1].
There are additional constraints on the usage of feature-param that
cannot be represented in a BNF. There MUST only be one instance of
any feature tag in feature-param. Any numbers present in a feature
parameter MUST be representable using an ANSI C double.
The following production updates the one in RFC 3261 [1] for
contact-params:
contact-params = c-p-q / c-p-expires / feature-param
/ contact-extension
10. Media Feature Tag Definitions
This specification defines an initial set of media feature tags for
use with this specification. This section serves as the IANA
registration for these feature tags, which are made into the SIP
media feature tag tree. New media feature tags are registered in the
IETF or global trees based on the process defined for feature tag
registrations [3], or in the SIP tree based on the process defined in
Section 12.1.
Any registered feature tags MAY be used with this specification.
However, several existing ones appear to be particularly applicable.
These include the language feature tag [6], which can be used to
specify the language of the human or automata represented by the UA,
and the type feature tag [7], which can be used to specify the MIME
types that a SIP UA can receive in a SIP message. The audio, video,
application, data, and control feature tags in the SIP tree (each of
which indicate a media type, as defined in RFC 2327 [8]) are
different. They do not indicate top level MIME types which can be
received in SIP requests. Rather, they indicate media types that can
be used in media streams, and as a result, match up with the types
defined in RFC 2327 [8].
If a new SDP media type were to be defined, such as "message", a new
feature tag registration SHOULD be created for it in the SIP tree.
The name of the feature tag MUST equal "sip." concatenated with the
name of the media type, unless there is an unlikely naming collision
between the new media type and an existing feature tag registration.
As a result, implementations can safely construct caller preferences
and callee capabilities for the new media type before it is
registered, as long as there is no naming conflict.
If a new media feature tag is registered with the intent of using
that tag with this specification, the registration is done for the
unencoded form of the tag (see Section 5). In other words, if a new
feature tag "foo" is registered in the IETF tree, the IANA
registration would be for the tag "foo" and not "+foo". Similarly,
if a new feature tag "sip.gruu" is registered in the SIP tree, the
IANA registration would be for the tag "sip.gruu" and not "+sip.gruu"
or "gruu". As such, all registrations into the SIP tree will have
the "sip." prefix.
The feature tags in this section are all registered in the SIP media
feature tag tree created by Section 12.1.
10.1. Audio
Media feature tag name: sip.audio
ASN.1 Identifier: 1.3.6.1.8.4.1
Summary of the media feature indicated by this tag: This feature tag
indicates that the device supports audio as a streaming media
type.
Values appropriate for use with this feature tag: Boolean.
The feature tag is intended primarily for use in the following
applications, protocols, services, or negotiation mechanisms: This
feature tag is most useful in a communications application for
describing the capabilities of a device, such as a phone or PDA.
Examples of typical use: Routing a call to a phone that can support
audio.
Related standards or documents: RFC 3840
Security Considerations: Security considerations for this media
feature tag are discussed in Section 11.1 of RFC 3840.
10.2. Application
Media feature tag name: sip.application
ASN.1 Identifier: 1.3.6.1.8.4.2
Summary of the media feature indicated by this tag: This feature tag
indicates that the device supports application as a streaming
media type. This feature tag exists primarily for completeness.
Since so many MIME types are underneath application, indicating
the ability to support applications provides little useful
information.
Values appropriate for use with this feature tag: Boolean.
The feature tag is intended primarily for use in the following
applications, protocols, services, or negotiation mechanisms: This
feature tag is most useful in a communications application, for
describing the capabilities of a device, such as a phone or PDA.
Examples of typical use: Routing a call to a phone that can support a
media control application.
Related standards or documents: RFC 3840
Security Considerations: Security considerations for this media
feature tag are discussed in Section 11.1 of RFC 3840.
10.3. Data
Media feature tag name: sip.data
ASN.1 Identifier: 1.3.6.1.8.4.3
Summary of the media feature indicated by this tag: This feature tag
indicates that the device supports data as a streaming media type.
Values appropriate for use with this feature tag: Boolean.
The feature tag is intended primarily for use in the following
applications, protocols, services, or negotiation mechanisms: This
feature tag is most useful in a communications application for
describing the capabilities of a device, such as a phone or PDA.
Examples of typical use: Routing a call to a phone that can support
a data streaming application.
Related standards or documents: RFC 3840
Security Considerations: Security considerations for this media
feature tag are discussed in Section 11.1 of RFC 3840.
10.4. Control
Media feature tag name: sip.control
ASN.1 Identifier: 1.3.6.1.8.4.4
Summary of the media feature indicated by this tag: This feature tag
indicates that the device supports control as a streaming media
type.
Values appropriate for use with this feature tag: Boolean.
The feature tag is intended primarily for use in the following
applications, protocols, services, or negotiation mechanisms: This
feature tag is most useful in a communications application for
describing the capabilities of a device, such as a phone or PDA.
Examples of typical use: Routing a call to a phone that can support
a floor control application.
Related standards or documents: RFC 3840
Security Considerations: Security considerations for this media
feature tag are discussed in Section 11.1 of RFC 3840.
10.5. Video
Media feature tag name: sip.video
ASN.1 Identifier: 1.3.6.1.8.4.5
Summary of the media feature indicated by this tag: This feature tag
indicates that the device supports video as a streaming media
type.
Values appropriate for use with this feature tag: Boolean.
The feature tag is intended primarily for use in the following
applications, protocols, services, or negotiation mechanisms: This
feature tag is most useful in a communications application for
describing the capabilities of a device, such as a phone or PDA.
Examples of typical use: Routing a call to a phone that can support
video.
Related standards or documents: RFC 3840
Security Considerations: Security considerations for this media
feature tag are discussed in Section 11.1 of RFC 3840.
10.6. Text
Media feature tag name: sip.text
ASN.1 Identifier: 1.3.6.1.8.4.6
Summary of the media feature indicated by this tag: This feature tag
indicates that the device supports text as a streaming media type.
Values appropriate for use with this feature tag: Boolean.
The feature tag is intended primarily for use in the following
applications, protocols, services, or negotiation mechanisms: This
feature tag is most useful in a communications application for
describing the capabilities of a device, such as a phone or PDA.
Examples of typical use: Routing a call to a phone that can support
text.
Related standards or documents: RFC 3840
Security Considerations: Security considerations for this media
feature tag are discussed in Section 11.1 of RFC 3840.
10.7. Automata
Media feature tag name: sip.automata
ASN.1 Identifier: 1.3.6.1.8.4.7
Summary of the media feature indicated by this tag: The sip.automata
feature tag is a boolean value that indicates whether the UA
represents an automata (such as a voicemail server, conference
server, IVR, or recording device) or a human.
Values appropriate for use with this feature tag: Boolean. TRUE
indicates that the UA represents an automata.
The feature tag is intended primarily for use in the following
applications, protocols, services, or negotiation mechanisms: This
feature tag is most useful in a communications application for
describing the capabilities of a device, such as a phone or PDA.
Examples of typical use: Refusing to communicate with an automata
when it is known that automated services are unacceptable.
Related standards or documents: RFC 3840
Security Considerations: Security considerations for this media
feature tag are discussed in Section 11.1 of RFC 3840.
10.8. Class
Media feature tag name: sip.class
ASN.1 Identifier: 1.3.6.1.8.4.8
Summary of the media feature indicated by this tag: This feature tag
indicates the setting, business or personal, in which a
communications device is used.
Values appropriate for use with this feature tag: Token with an
equality relationship. Typical values include:
business: The device is used for business communications.
personal: The device is used for personal communications.
The feature tag is intended primarily for use in the following
applications, protocols, services, or negotiation mechanisms: This
feature tag is most useful in a communications application, for
describing the capabilities of a device, such as a phone or PDA.
Examples of typical use: Choosing between a business phone and a home
phone.
Related standards or documents: RFC 3840
Security Considerations: Security considerations for this media
feature tag are discussed in Section 11.1 of RFC 3840.
10.9. Duplex
Media feature tag name: sip.duplex
ASN.1 Identifier: 1.3.6.1.8.4.9
Summary of the media feature indicated by this tag: The sip.duplex
media feature tag indicates whether a communications device can
simultaneously send and receive media ("full"), alternate between
sending and receiving ("half"), can only receive ("receive-only")
or only send ("send-only").
Values appropriate for use with this feature tag: Token with an
equality relationship. Typical values include:
full: The device can simultaneously send and receive media.
half: The device can alternate between sending and receiving
media.
receive-only: The device can only receive media.
send-only: The device can only send media.
The feature tag is intended primarily for use in the following
applications, protocols, services, or negotiation mechanisms:
This feature tag is most useful in a communications application
for describing the capabilities of a device, such as a phone or
PDA.
Examples of typical use: Choosing to communicate with a broadcast
server, as opposed to a regular phone, when making a call to hear
an announcement.
Related standards or documents: RFC 3840
Security Considerations: Security considerations for this media
feature tag are discussed in Section 11.1 of RFC 3840.
10.10. Mobility
Media feature tag name: sip.mobility
ASN.1 Identifier: 1.3.6.1.8.4.10
Summary of the media feature indicated by this tag: The sip.mobility
feature tag indicates whether the device is fixed (meaning that it
is associated with a fixed point of contact with the network), or
mobile (meaning that it is not associated with a fixed point of
contact). Note that cordless phones are fixed, not mobile, based
on this definition.
Values appropriate for use with this feature tag: Token with an
equality relationship. Typical values include:
fixed: The device is stationary.
mobile: The device can move around with the user.
The feature tag is intended primarily for use in the following
applications, protocols, services, or negotiation mechanisms:
This feature tag is most useful in a communications application
for describing the capabilities of a device, such as a phone or
PDA.
Examples of typical use: Choosing to communicate with a wireless
phone instead of a desktop phone.
Related standards or documents: RFC 3840
Security Considerations: Security considerations for this media
feature tag are discussed in Section 11.1 of RFC 3840.
10.11. Description
Media feature tag name: sip.description
ASN.1 Identifier: 1.3.6.1.8.4.11
Summary of the media feature indicated by this tag: The
sip.description feature tag provides a textual description of the
device.
Values appropriate for use with this feature tag: String with an
equality relationship.
The feature tag is intended primarily for use in the following
applications, protocols, services, or negotiation mechanisms: This
feature tag is most useful in a communications application for
describing the capabilities of a device, such as a phone or PDA.
Examples of typical use: Indicating that a device is of a certain