make and model.
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.12. Event Packages
Media feature tag name: sip.events
ASN.1 Identifier: 1.3.6.1.8.4.12
Summary of the media feature indicated by this tag: Each value of the
sip.events (note the plurality) feature tag indicates a SIP event
package [9] supported by a SIP UA. The values for this tag equal
the event package names that are registered by each event package.
Values appropriate for use with this feature tag: Token with an
equality relationship. Values are taken from the IANA SIP Event
types namespace registry.
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 server that
supports the message waiting event package, such as a voicemail
server [12].
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.13. Priority
Media feature tag name: sip.priority
ASN.1 Identifier: 1.3.6.1.8.4.13
Summary of the media feature indicated by this tag: The sip.priority
feature tag indicates the call priorities the device is willing to
handle. A value of X means that the device is willing to take
requests with priority X and higher. This does not imply that a
phone has to reject calls of lower priority. As always, the
decision on handling of such calls is a matter of local policy.
Values appropriate for use with this feature tag: An integer. Each
integral value corresponds to one of the possible values of the
Priority header field as specified in SIP [1]. The mapping is
defined as:
non-urgent: Integral value of 10. The device supports non-urgent
calls.
normal: Integral value of 20. The device supports normal calls.
urgent: Integral value of 30. The device supports urgent calls.
emergency: Integral value of 40. The device supports calls in the
case of an emergency situation.
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 the emergency
cell phone of a user.
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.14. Methods
Media feature tag name: sip.methods
ASN.1 Identifier: 1.3.6.1.8.4.14
Summary of the media feature indicated by this tag: Each value of the
sip.methods (note the plurality) feature tag indicates a SIP
method supported by this UA. In this case, "supported" means that
the UA can receive requests with this method. In that sense, it
has the same connotation as the Allow header field.
Values appropriate for use with this feature tag: Token with an
equality relationship. Values are taken from the Methods table
defined in the IANA SIP parameters registry.
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 presence
application on a PC, instead of a PC phone 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.15. Extensions
Media feature tag name: sip.extensions
ASN.1 Identifier: 1.3.6.1.8.4.15
Summary of the media feature indicated by this tag: Each value of the
sip.extensions feature tag (note the plurality) is a SIP extension
(each of which is defined by an option-tag registered with IANA)
that is understood by the UA. Understood, in this context, means
that the option tag would be included in a Supported header field
in a request.
Values appropriate for use with this feature tag: Token with an
equality relationship. Values are taken from the option tags
table in the IANA SIP parameters registry.
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 phone that
supports quality of service preconditions instead of one that does
not.
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.16. Schemes
Media feature tag name: sip.schemes
ASN.1 Identifier: 1.3.6.1.8.4.16
Summary of the media feature indicated by this tag: Each value of the
sip.schemes (note the plurality) media feature tag indicates a URI
scheme [10] that is supported by a UA. Supported implies, for
example, that the UA would know how to handle a URI of that scheme
in the Contact header field of a redirect response.
Values appropriate for use with this feature tag: Token with an
equality relationship. Values are taken from the IANA URI scheme
registry.
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 get redirected to a phone number
when a called party is busy, rather than a web page.
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.17. Actor
Media feature tag name: sip.actor
ASN.1 Identifier: 1.3.6.1.8.4.17
Summary of the media feature indicated by this tag: This feature tag
indicates the type of entity that is available at this URI.
Values appropriate for use with this feature tag: Token with an
equality relationship. The following values are defined:
principal: The device provides communication with the principal
that is associated with the device. Often this will be a
specific human being, but it can be an automata (for example,
when calling a voice portal).
attendant: The device provides communication with an automaton or
person that will act as an intermediary in contacting the
principal associated with the device, or a substitute.
msg-taker: The device provides communication with an automaton or
person that will take messages and deliver them to the
principal.
information: The device provides communication with an automaton
or person that will provide information about the principal.
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: Requesting that a call not be routed to
voicemail.
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.18. Is Focus
Media feature tag name: sip.isfocus
ASN.1 Identifier: 1.3.6.1.8.4.18
Summary of the media feature indicated by this tag: This feature tag
indicates that the UA is a conference server, also known as a
focus, and will mix together the media for all calls to the same
URI [13].
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: Indicating to a UA that the server to which
it has connected is a conference server.
Related standards or documents: RFC 3840
Security Considerations: Security considerations for this media
feature tag are discussed in Section 11.1 of RFC 3840.
11. Security Considerations
11.1. Considerations for Media Feature Tags
This section discusses security considerations for the media feature
tags, including, but not limited to, this specification.
The media feature tags defined in Section 10 reveal sensitive
information about a user or the user agent they are describing. Some
of the feature tags convey capability information about the agent -
for example, the media types it can support, the SIP methods it can
support, and the SIP extensions it can support. This capability
information might be used for industrial espionage, for example, and
so its protection may be important. Other attributes, such as the
mobility, priority, and isfocus attributes, reveal characteristics of
the user agent. These attributes are more sensitive than the
capability information. They describe the way in which a user agent
is utilized by a user, and thus reveal information about user
preferences and the ways in which they want calls handled. Some
feature tags, such as languages, reveal information about the user
themself. As a result, applications which utilize these media
feature tags SHOULD provide a means for ensuring their
confidentiality.
The media feature tags can be used in ways which affect application
behaviors. For example, the SIP caller preferences extension [11]
allows for call routing decisions to be based on the values of these
parameters. Therefore, if an attacker can modify the values of these
feature tags, they may be able to affect the behavior of
applications. As a result of this, applications which utilize these
media feature tags SHOULD provide a means for ensuring their
integrity. Similarly, media feature tags should only be trusted as
valid when they come from the user or user agent described by those
feature tags. As a result, mechanisms for conveying feature tags
SHOULD provide a mechanism for guaranteeing authenticity.
11.2. Considerations for Registrations
As per the general requirements in Section 11.1, when media feature
tags are carried in a registration, authenticity, confidentiality,
and integrity need to be provided. To accomplish this, registrations
containing capability information SHOULD be made by addressing the
registration to a SIPS URI (in other words, the Request URI of the
request would be sips:example.com when creating a registration in the
example.com domain). Furthermore, the registrar SHOULD challenge the
UA using digest over TLS, to verify its authenticity. The
combination of TLS and digest provide integrity, confidentiality, and
authenticity, as required.
It is not necessary for the Contact in the registration to itself
contain a sips URI, since the feature tags are not carried in
incoming requests sent to the UA.
11.3. Considerations for OPTIONS Responses
When including information on capabilities in a response to an
OPTIONS request, a UA SHOULD verify with the user (either through a
user interface or though prior configuration) whether or not
capability information should be divulged to the requester. If the
identity of the requester cannot be cryptographically verified (using
digest or the SIP identity enhancements [15]), the user SHOULD also
be alerted to this fact, and be allowed to choose whether such
information should be divulged.
If the user does wish to reveal capability information to the
requester, and wishes to guarantee its confidentiality, but the
request did not arrive using SIPS, the UAS SHOULD redirect the
request to a sips URI. This will cause the UAC to send the OPTIONS
request using SIPS instead, and therefore provide confidentiality of
any responses sent over the secure connections.
Furthermore, S/MIME MAY be used in the OPTIONS response. In that
case, the capability information would be contained only in the
secured S/MIME body, and not in the header fields of the OPTIONS
response.
11.4. Considerations for Dialog Initiating Messages
When a UAS generates a response that will initiate a dialog, and they
wish to include capability information in the Contact header field,
the same considerations as described in Section 11.3 apply.
When a UAC generates a request that will initiate a dialog, it SHOULD
obtain permission from the user (either through a user interface or
apriori configuration) before including capability information in the
Contact header field of the request. Confidentiality and integrity
of the information SHOULD be provided using SIPS. S/MIME MAY be
used.
12. IANA Considerations
There are a number of IANA considerations associated with this
specification.
12.1. SIP Media Feature Tag Registration Tree
This specification serves to create a new media feature tag
registration tree, per the guidelines of Section 3.1.4 of RFC 2506
[3]. The name of this tree is the "SIP Media Feature Tag
Registration Tree", and its prefix is "sip.". It is used for the
registration of media feature tags that are applicable to the Session
Initiation Protocol, and whose meaning is only defined within that
usage.
The addition of entries into this registry occurs through IETF
consensus, as defined in RFC 2434 [18]. This requires the
publication of an RFC that contains the registration. The
information required in the registration is identical to the IETF
tree. As such, specifications adding entries to the registry should
use the template provided in Section 3.4 of RFC 2506. Note that all
media feature tags registered in the SIP tree will have names with a
prefix of "sip.". No leading "+" is used in the registrations in any
of the media feature tag trees.
12.2. Media Feature Tags
This specification registers a number of new Media feature tags
according to the procedures of RFC 2506 [3]. These registrations are
all made in the newly created SIP tree for media feature tags. These
registrations are:
sip.audio: The information for registering the sip.audio media
feature tag is contained in Section 10.1.
sip.application: The information for registering the sip.application
media feature tag is contained in Section 10.2.
sip.data: The information for registering the sip.data media feature
tag is contained in Section 10.3.
sip.control: The information for registering the sip.control media
feature tag is contained in Section 10.4.
sip.video: The information for registering the sip.video media
feature tag is contained in Section 10.5.
sip.text: The information for registering the sip.text media feature
tag is contained in Section 10.6.
sip.automata: The information for registering the sip.automata media
feature tag is contained in Section 10.7.
sip.class: The information for registering the sip.class media
feature tag is contained in Section 10.8.
sip.duplex: The information for registering the sip.duplex media
feature tag is contained in Section 10.9.
sip.mobility: The information for registering the sip.mobility media
feature tag is contained in Section 10.10.
sip.description: The information for registering the sip.description
media feature tag is contained in Section 10.11.
sip.events: The information for registering the sip.events media
feature tag is contained in Section 10.12.
sip.priority: The information for registering the sip.priority media
feature tag is contained in Section 10.13.
sip.methods: The information for registering the sip.methods media
feature tag is contained in Section 10.14.
sip.extensions: The information for registering the sip.extensions
media feature tag is contained in Section 10.15.
sip.schemes: The information for registering the sip.schemes media
feature tag is contained in Section 10.16.
sip.actor: The information for registering the sip.actor media
feature tag is contained in Section 10.17.
sip.isfocus: The information for registering the sip.isfocus media
feature tag is contained in Section 10.18.
12.3. SIP Option Tag
This specification registers a single SIP option tag, pref. The
required information for this registration, as specified in RFC 3261
[1], is:
Name: pref
Description: This option tag is used in a Require header field of
a registration to ensure that the registrar supports the caller
preferences extensions.
13. Acknowledgments
The initial set of media feature tags used by this specification were
influenced by Scott Petrack’s CMA design. Jonathan Lennox, Bob
Penfield, Ben Campbell, Mary Barnes, Rohan Mahy, and John Hearty
provided helpful comments. Graham Klyne provided assistance on the
usage of RFC 2533. Thanks to Allison Mankin for her comments and
support, and to Ted Hardie for his guidance on usage of the media
feature tags.
14. References
14.1. Normative References
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] Holtman, K., Mutz, A., and T. Hardie, "Media Feature Tag
Registration Procedure", BCP 31, RFC 2506, March 1999.
[4] Klyne, G., "A Syntax for Describing Media Feature Sets", RFC
2533, March 1999.
[5] Klyne, G., "Corrections to "A Syntax for Describing Media
Feature Sets"", RFC 2738, December 1999.
[6] Hoffman, P., "Registration of Charset and Languages Media
Features Tags", RFC 2987, November 2000.
[7] Klyne, G., "MIME Content Types in Media Feature Expressions",
RFC 2913, September 2000.
[8] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[9] Roach, A.B., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002.
[10] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396, August
1998.
14.2. Informative References
[11] Rosenberg, J., Schulzrinne, H. and P. Kyzivat, "Caller
Preferences for the Session Initiation Protocol (SIP)", RFC
3841, August 2004.
[12] Mahy, R., "A Message Summary and Message Waiting Indication
Event Package for the Session Initiation Protocol (SIP)", RFC
3842, August 2004.
[13] Rosenberg, J., "A Framework for Conferencing with the Session
Initiation Protocol", Work in Progress, May 2003.
[14] Howes, T. and M. Smith, "LDAP: String Representation of Search
Filters", Work in Progress, March 2003.
[15] Peterson, J., "Enhancements for Authenticated Identity
Management in the Session Initiation Protocol (SIP)", Work in
Progress, March 2003.
[16] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and
D. Gurle, "Session Initiation Protocol (SIP) Extension for
Instant Messaging", RFC 3428, December 2002.
[17] Klyne, G., "Protocol-independent Content Negotiation
Framework", RFC 2703, September 1999.
[18] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October
1998.
Appendix A. Overview of RFC 2533
This section provides a brief overview of RFC 2533 and related
specifications that form the content negotiation framework. This
section does not represent normative behavior. In the event of any
conflict between the tutorial material here and the normative text in
RFC 2533, RFC 2533 takes precedence.
A critical concept in the framework is that of a feature set. A
feature set is information about an entity (in our case, a UA), which
describes a set of features it can handle. A feature set can be
thought of as a region in N-dimensional space. Each dimension in
this space is a different media feature, identified by a media
feature tag. For example, one dimension (or axis) might represent
languages, another might represent methods, and another, MIME types.
A feature collection represents a single point in this space. It
represents a particular rendering or instance of an entity (in our
case, a UA). For example, a "rendering" of a UA would define an
instantaneous mode of operation that it can support. One such
rendering would be processing the INVITE method, which carried the
application/sdp MIME type, sent to a UA for a user that is speaking
English.
A feature set can therefore be defined as a set of feature
collections. In other words, a feature set is a region of N-
dimensional feature-space, that region being defined by the set of
points - feature collections - that make up the space. If a
particular feature collection is in the space, it means that the
rendering described by that feature collection is supported by the
device with that feature set.
How does one represent a feature set? There are many ways to
describe an N-dimensional space. One way is to identify mathematical
functions which identify its contours. Clearly, that is too complex
to be useful. The solution taken in RFC 2533 is to define the space
with a feature set predicate. A feature predicate defines a relation
over an N-dimensional space; its input is any point in that space
(i.e., a feature collection), and is true for all points that are in
the region thus defined.
RFC 2533 describes a syntax for writing down these N-dimensional
boolean functions, borrowed from LDAP [14]. It uses a prolog-style
syntax which is fairly self-explanatory. This representation is
called a feature set predicate. The base unit of the predicate is a
filter, which is a boolean expression encased in round brackets. A
filter can be complex, where it contains conjunctions and
disjunctions of other filters, or it can be simple. A simple filter
is one that expresses a comparison operation on a single media
feature tag.
For example, consider the feature set predicate:
(& (foo=A)
(bar=B)
(| (baz=C) (& (baz=D) (bif=E))))
This defines a function over four media features - foo, bar, baz, and
bif. Any point in feature space with foo equal to A, bar equal to B,
and baz equal to either C or D, and bif equal to E, is in the feature
set defined by this feature set predicate.
Note that the predicate doesn’t say anything about the number of
dimensions in feature space. The predicate operates on a feature
space of any number of dimensions, but only those dimensions labeled
foo, bar, baz, and bif matter. The result is that values of other