Internet Engineering Task Force SIP WG
Internet Draft H. Schulzrinne
Columbia U.
J. Rosenberg
dynamicsoft
draft-ietf-sip-callerprefs-06.txt
July 1, 2002
Expires: January 2003
Session Initiation Protocol (SIP) Caller Preferences and Callee Capabilities
STATUS OF THIS MEMO
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html.
Abstract
This document describes a set of extensions to the Session Initiation
Protocol (SIP) which allow a caller to express preferences about
request handling in servers. These preferences include the ability to
select which URIs a request gets routed to, and to specify certain
request handling directives in proxies and redirect servers. It does
so by defining three new request headers, Accept-Contact, Reject-
Contact and Request-Disposition, which specify the caller's
preferences. The extension also defines new parameters for the
Contact header that describe the characterstics of a UA.
H. Schulzrinne et. al. [Page 1]
Internet Draft SIP Caller Preferences July 1, 2002
Table of Contents
1 Introduction ........................................ 3
2 Overview of Operation ............................... 4
3 Terminology ......................................... 5
4 UA Behavior ......................................... 5
4.1 Expressing Capabilities in a Registration ........... 5
4.2 Expressing Preferences in a Request ................. 6
4.2.1 Request Handling .................................... 7
4.2.2 Feature Set Preferences ............................. 7
4.3 Indicating Feature Sets in Remote Target URIs ....... 8
5 Proxy Behavior ...................................... 8
5.1 Request-Disposition Processing ...................... 8
5.2 Preference and Capability Matching .................. 8
6 Header Field Definitions ............................ 12
6.1 Request Disposition ................................. 12
6.2 Accept-Contact and Reject-Contact ................... 14
6.3 Contact Header ...................................... 15
7 Media Feature Tag Definitions ....................... 15
7.1 Class ............................................... 16
7.2 Duplex .............................................. 16
7.3 Features ............................................ 17
7.4 Mobility ............................................ 18
7.5 Media ............................................... 18
7.6 Description ......................................... 19
7.7 Priority ............................................ 20
7.8 Methods ............................................. 20
7.9 Automata ............................................ 21
7.10 Event Packages ...................................... 22
7.11 Schemes ............................................. 22
8 Mapping Contact Header Values and Feature
Predicates ..................................................... 23
9 Security Considerations ............................. 24
10 IANA Considerations ................................. 24
10.1 Media Feature Tags .................................. 24
10.2 SIP Header Fields ................................... 25
11 Acknowledgements .................................... 25
12 Author's Addresses .................................. 25
13 Normative References ................................ 26
14 Informative References .............................. 27
H. Schulzrinne et. al. [Page 2]
Internet Draft SIP Caller Preferences July 1, 2002
1 Introduction
When a SIP [1] server receives a request, there are a number of
decisions it can make regarding processing of the request. These
include
o whether to proxy or redirect the request;
o which URIs to proxy or redirect to;
o whether to fork or not;
o whether to search recursively or not;
o whether to search in parallel or sequentially;
The server can base these decisions on any local policy. This policy
can be statically configured, or can be based on programmtic
execution or database access.
However, the administrator of the server is the not the only entity
with an interest in call processing. There are at least three parties
which have an interest: (1) the administrator of the server, (2) the
requestor, and (3) the user to whom the request is directed. The
directives of the administrator are embedded in the policy of the
server. The preferences of the user to whom the request is directed
(referred to as callee, even though the request may not be INVITE)
can be expressed most easily through a script written in some type of
scripting language, such as the call processing language (CPL) [13].
However, no mechanism exists to incorporate the preferences of the
requestor (also referred to as the caller, even though the request
may not be INVITE). For example, the requestor might want to speak to
a specific user, but want to reach them only at work, because the
call is a business call. As another example, the requestor might want
to reach a user, but not their voicemail, since it is important that
the caller talk to the called party. In both of these examples, the
caller's preference amounts to having a proxy make a particular
routing choice based on the preferences of the caller.
This extension allows the requestor to have these preferences met. It
does so by specifying mechanisms by which a caller can provide
preferences on processing of a request. There are two types of
preferences. One of them, encapsulated in the Request-Disposition
header, provides specific request handling directives for a proxy.
The other, present in the Accept-Contact and Reject-Contact headers,
allows the caller to provide a feature set [2] that expresses its
preferences on the characteristics of the UA that is to be reached.
These are matched with a feature set carried in the Contact header of
H. Schulzrinne et. al. [Page 3]
Internet Draft SIP Caller Preferences July 1, 2002
a REGISTER request, which describes the capabilities of the UA
represented by the URI. The extension is very general purpose, and
not tied to a particular service. Rather, it is a tool that can be
used in the development of many services.
2 Overview of Operation
This extension defines a set of additional parameters to the Contact
header. Each parameter is a feature tag, as defined in [14], that
defines a capability for the UA associated with the Contact header.
For example, there is a parameter for the SIP methods supported by
the UA. Each Contact parameter has a value; that value is the set of
feature values for that feature tag. Put together, all of the Contact
parameters specify a feature set that is supported by the UA
associated with that Contact.
When a UA registers, it places these parameters in the Contact
headers to provide a feature set for each URI it is registering. The
parameters are also mirrored in the Contact header in a REGISTER
response. The proxy can use this feature set to route requests based
on caller preferences. Furthermore, Contact headers in requests and
responses that establish a dialog can also contain these parameters.
That allows a UA in a dialog to indicate its feature set to its peer.
For example, by including the "feature" feature tag with value
"voicemail" in the 200 OK to an INVITE, the UAS can indicate to the
UAC that it is a voicemail server. This information is useful for
user interfaces, as well as automated call handling.
When a caller sends a request, it can optionally include new headers
which request certain handling at a server. These preferences fall
into two categories. The first category, carried in the Request-
Disposition header, describe desired server behavior. This includes
whether the caller wishes the server to proxy or redirect, and
whether sequential or parallel search is desired. These preferences
can be applied at every proxy or redirect server on the call
signaling path.
The second category of preferences are carried in the Accept-Contact
and Reject-Contact headers. These headers also contain feature sets,
that represent the callers preference for the capabilities of the UA
it would like to reach. Each Accept-Contact header field value
contains a feature set and a preference, defining a UA it would like
to reach. Each Reject-Contact header field value contains a feature
set, defining a UA it does not want to reach. Proxies apply the
matching operation, described in Section 5 of RFC 2533 [2], between
the feature sets in the request and the feature sets learned through
the registration. Any registered contact whose feature set matches a
feature set in the Reject-Contact header field is discarded. If the
H. Schulzrinne et. al. [Page 4]
Internet Draft SIP Caller Preferences July 1, 2002
feature set in a registered contact matches a feature set in an
Accept-Contact header field value, their preference values are
merged. The result is an ordered list of registered contacts, using
the merged preference values. The proxy then attempts each contact in
that order of preference.
Both types of preferences can appear in any request, not just INVITE.
However, they are only useful in requests where proxies need to
determine a request target. If the domain in the request URI is not
owned by any proxies along the request path, those proxies will never
access a location service, and therefore, never have the opportunity
to apply the caller preferences. This makes sense; typically, the
request URI will identify a UAS for mid-dialog requests. In those
cases, the routing decisions were already made on the initial
request, and it makes no sense to redo them for subsequent requests
in the dialog.
3 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 RFC 2119 [3] and
indicate requirement levels for compliant SIP implementations.
4 UA Behavior
UA behavior covers three separate cases. The first is registration,
where a UA can declare its capabilities. The second is expression of
preferences, where a UA can tell a proxy how it wants the request to
be processed and routed. The third is expressing of capabilities,
through a feature set, in the Contact headers of an INVITE request or
2xx response, or more generally, in a Contact header in a request or
response that establishes a dialog.
4.1 Expressing Capabilities in a Registration
When a UA registers, it MAY construct a feature set for each Contact
URI it registers. This feature set MUST be an AND or ORs (also known
as conjunctive normal form [2]) with the optional negation of the
disjunction. Each disjunction MUST indicate feature values for a
single feature tag (i.e., the disjunction represents a set of values
for a particular feature tag), and each disjunction MUST be for a
different feature tag. Each element in the disjunction MUST be an
equality operator. This feature set is then converted to a list of
Contact parameters using the procedure specified in Section 8. Those
contact parameters are added to the the Contact header field for the
URI being registered.
H. Schulzrinne et. al. [Page 5]
Internet Draft SIP Caller Preferences July 1, 2002
A UA MAY include the "schemes" feature tag in its feature set.
However, this tag MUST include a value that matches the scheme of the
URI being registered. For example, if a SIP URI is being registered,
the schemes parameter can include a SIP and TEL URI [4]. If this
feature tag is omitted, the proxy will assume an implicit value for
it, equal to the scheme of the registered URI.
The REGISTER request MAY contain a Require header with the option tag
"pref" if the client wants to be sure that the registration server
honors caller preferences. In absence of the Require header, a server
that does not understand this extension will simply ignore the
Contact parameters.
As an example, a UA that supports audio and video media types, and
has a voicemail and attendant amongst its features, but is not
mobile, would construct a feature set like this:
(& (| (media=audio) (media=video))
(| (feature=voicemail) (feature=attendant))
(! (| (mobility=mobile))))
These would be converted into Contact parameters:
;media="audio,video";feature="voicemail,attendant";mobility="!mobile"
4.2 Expressing Preferences in a Request
A UAC wishing to express preferences for a request includes the
Accept-Contact, Reject-Contact, or Request-Disposition headers in the
request, depending on its particular preferences. No additional
behavior is required after the request is sent.
The Accept-Contact, Reject-Contact and Request-Disposition headers in
an ACK or CANCEL MUST be equal to the values in the original request
being acknowledged or cancelled. This is to ensure proper operation
through stateless elements.
If the client wants to be sure that servers understand the headers
described in this specification, it MAY include a Proxy-Require and
Require option tag of "pref". However, this is NOT RECOMMENDED, as it
H. Schulzrinne et. al. [Page 6]
Internet Draft SIP Caller Preferences July 1, 2002
leads to interoperability problems. In any case, client preferences
can only be considered as preferences - there is no guarantee that
the requested service or capability is executed. As such, inclusion
of Proxy-Require and Require does not mean the preferences will be
executed.
4.2.1 Request Handling
The Request-Disposition header field specifies caller preferences for
how a proxy or redirect server should process a request. It is not
processed by user agents. Its value is a list of tokens, each of
which specifies a particular feature.
The syntax and meaning of the tokens is defined in Section XXX.
4.2.2 Feature Set Preferences
A UAC can indicate preferences for the capabilities of a UA that
should be reached or not reached as a result of sending a SIP INVITE
request. To do that, it constructs zero or more feature sets that
describe the desired (or undesired) UA. Each feature set MUST follow
the constraints of Section 4.1. That is, each feature set MUST be in
conjunctive normal form, with an optional negation of the
disjunction, each disjunction MUST express values for the same
feature tag, and each disjunction MUST be for different feature tags.
Each element in the disjunction MUST be an equality operator. The
feature sets MAY overlap; that is, a UA MAY request preferences for
feature sets that match according to the matching algorithm of
Section 5 of RFC 2533 [2].
Note that the UAC can express explicit preferences for the methods,
event packages and priorities supported by a UA. As described in
Section XXX, a proxy will compute implicit preferences from the
request if explicit ones are not provided.
A UAC can also request preferences for contacting or not contacting a
UA with a specific URI.
The UAC adds a Reject-Contact header to the request if it has any
preferences for UAs that are not to be reached. For each feature set
(and optionally URI) that describe a UA that is not to be reached,
the UAC adds a Reject-Contact header field value. The value is a "*"
if the UAC doesn't care about the URI for the UA, or equal to the URI
that is not to be reached. The feature set is converted to a set of
Contact parameters according to the rules of Section XXX, and added
as parameters to the Contact header field value.
The UAC adds an Accept-Contact header field to the request if it has
H. Schulzrinne et. al. [Page 7]
Internet Draft SIP Caller Preferences July 1, 2002
any preferences for UAs that it wants to reach. For each feature set
(and optionally URI) that describe a UA to be reached, the UAC adds
an Accept-Contact header field value. The value is a "*" if the UAC
doesn't care about the URI for the UA, or equal to the URI that is to
be reached. The feature set is converted to a set of Contact
parameters according to the rules of Section XXX, and added as
parameters to the Contact header field value. Each Contact header
field value MAY include a q parameter that indicates the relative
preference for reaching that URI and feature set amongst all others
listed in the Accept-Contact header field.
4.3 Indicating Feature Sets in Remote Target URIs
In SIP requests or responses that establish a dialog, or are target
refresh requests, and contain a Contact header, a UAC or UAS MAY add
Contact parameters indicating the capabilities of the UA. To do that,
it constructs a feature set according to the constraints of Section
4.1, and converts it to a list of Contact header parameters using the
rules in Section XXX. These are then added as Contact header field
parameters in the request or response.
OPEN ISSUE: There is overlap in this mechanism with the
Allow, Accept, and other capability header that can be used
in these requests. We need to address that.
5 Proxy Behavior
Proxy behavior consists of two orthogonal sets of rules - one for
processing the Request-Disposition header field, and one for
processing the feature set preferences.
5.1 Request-Disposition Processing
If the request contains a Request-Disposition header, the server
SHOULD execute the behaviors described by the tokens, unless it has
local policy configured to direct it otherwise.
5.2 Preference and Capability Matching
A proxy compliant to this specification MUST NOT apply the
preferences matching operation described here unless it is the owner
of the domain in the request URI and accessing a location service
that has capabilities associated with request targets.
To apply preferences, it looks for the Accept-Contact and Reject-
Contact header fields. For each value of those header fields, SHOULD
convert all URI parameters except for the q parameter to the syntax
H. Schulzrinne et. al. [Page 8]
Internet Draft SIP Caller Preferences July 1, 2002
of RFC 2533, based on the rules in Section XXX. If the value of the
Accept-Contact or Reject-Contact header field was not a "*", it
SHOULD take the URI in that field, and add two disjunctions to the
feature predicate. These are:
(| (uri-user=<user part of URI>))
and
(| (user-domain=<host portion of URI>)
If the user part of the SIP URI is absent, the user-user disjunction
is not added, only the domain one. No URI parameters are used. Note
that these are not "real" feature tags; they are not registered with
IANA and cannot appear anywhere in actual form. They are merely added
in order to perform the matching operation.
The proxy then applies any "implicit" preferences. These preferences
are ones not explicitly stated in the Accept-Contact header fields,
but implied by the presence of other headers in the request. To do
that, the proxy goes through each feature set obtained from the
Accept-Contact header field, and applies the rules below. If there
was no Accept-Contact header field, the proxy creates an empty
feature set, populated entirely from the implicit preferences below.
If the request contained a Priority header field, and there were no
feature-tags in the feature set with value "priority", the proxy
SHOULD add a disjunction of the following form to the feature set:
(| (priority>=[value of the Priority header field]))
If the request did not have any feature tags in the feature set with
value "methods", the proxy SHOULD add a disjunction of the following
form to the feature set:
H. Schulzrinne et. al. [Page 9]
Internet Draft SIP Caller Preferences July 1, 2002
(| (methods=[method of request]))
If the request had an Event header field, and it did not have any
feature tags in the feature set with value "events", the proxy SHOULD
add a disjunction of the following form to the feature set:
(| (events=[value of the Event header field]))
The proxy then takes each URI in the target set (the set of URI it is
going to proxy to), and obtains there capabilities as an RFC 2533
formatted feature set. If target URI was obtained through a
registration, the proxy computes the feature set by taking all
Contact URI parameters except for the q and expires parameters, and
converting them to RFC 2533 syntax using the rules of Section 6.1.
The proxy SHOULD add several implicit values to the disjunction.
These are the uri-user and uri-domain feature tags, as described
above, whose values are populated from the target URI. If the feature
set doesn't already contain a "schemes" feature tag, the proxy SHOULD
add a disjunction containing one, whose value is equal to the scheme
of the URI. The resulting feature set is associated with a q-value.
If the feature set was learned through a REGISTER request, the q-
value is equal to the q-value in the Contact header field parameter,
else "1.0" if not specified.
As an example, if a REGISTER request had the following Contact URI:
Contact: sip:1.2.3.4;mobility="fixed";q=0.8
The proxy would compute the following feature set, associating it
with a q-value of 0.8:
(& (| (mobility=fixed))
(| (uri-domain=1.2.3.4))
(| (schemes=sip)))
H. Schulzrinne et. al. [Page 10]
Internet Draft SIP Caller Preferences July 1, 2002
For each feature set obtained from the Reject-Contact header, the
proxy performs the matching operation in Section 5 of RFC 2533 [2]
against each URI in the target set. All URI in the target set whose
feature set matches at least one feature set from the Reject-Contact
header SHOULD be removed from the target set of the proxy.
For each feature set obtained from the Accept-Contact header field,
or if there was none, the feature set created through implicit
preferences, the proxy performs the matching operation in Section 5
of RFC 2533 [2] against each URI in the target set.
If the feature set matches the feature set from a target URI, the q-
value of that target URI is modified for this transaction only, in
order to incorporate the caller's preferences. If the feature set
does not match a target URI, nothing is done. This document does not
prescribe a specific algorithm for updating the q-value. Among many
possibilities, a server MAY set the q-value to the average of the
original value specified in the registration, and the average q-value
amongst all feature sets that match the URI. This gives equal weight
to caller and callee preferences. The only requirement for the
updating process is that if a target URI has a q-value of q1, and the
q values among the matching feature sets are q2,q3,..qn, the merged q
value, qm, must satisfy:
MIN(q1,q2,q3,..qn) <= qm <= MAX(q1,q2,q3,..,qn)
For those target URI which did not match any feature set, their final
q value SHOULD be set to zero.
Note that this preference computation only determines the
ordering of request attempts, so that the properties of the
preference computation are of secondary importance. The q-
value ordering provides only limited flexibility to
indicate, for example, that a particular parameter is more
important than another one or that combinations of two
parameters should be weighed heavily.
If the server proxies, the target set is then sorted according to the
updated q-value. Processing from this point depends on the
configuration and policy of the server. If the server elects to do a
sequential proxy, it SHOULD try the highest q-value contact entry
first, trying addresses with decreasing q-values as each attempt
fails. If the server elects to do a parallel proxy, it SHOULD group
H. Schulzrinne et. al. [Page 11]
Internet Draft SIP Caller Preferences July 1, 2002
contact entries with "close" q-values together, and try the group
with the highest q-value first, then the group with the next lowest
q-values, and so on. The precise method of the grouping is left to
the implementor. A reasonable choice is to round each q-value to the
nearest tenth, and group those with the same rounded value.
If a proxy server is recursing, it SHOULD apply the caller
preferences to the Contact header fields returned in the redirect
responses. Any target URI remaining after the application of caller
preferences SHOULD be added to the list of untried addresses. This
list is then resorted based on q values. The server uses this list
for subsequent proxy operations.
If the server is redirecting, it SHOULD return all entries in the
target set, including a q-value for each as obtained through the
updating process. This SHOULD include any URI with a zero q-value.
If the server is executing any other type of policy, as a general
guideline, it SHOULD prefer target URI with higher q values than
those with lower q values.
6 Header Field Definitions
This specification defines three new header fields - Accept-Contact,
Reject Contact, and Request Disposition.
Table 1 is an extension of Tables 2 and 3 in [1] for the Accept-
Contact, Reject-Contact and Request-Disposition header fields. The
column "PRA" is for the PRACK method [5], "UPD" is for the UPDATE
method [6], "SUB" is for the SUBSCRIBE method [7], and "NOT" is for
the NOTIFY method [7].
Header field where proxy ACK BYE CAN INV OPT REG PRA UPD SUB NOT
_________________________________________________________________________
Accept-Contact R amr o o o o o - o o o o
Reject-Contact R amr o o o o o - o o o o
Request-Disposition R amr o o o o o o o o o o
Table 1: Accept-Contact, Reject-Contact and Request-Disposition
header fields
6.1 Request Disposition
The Request-Disposition header field specifies caller preferences for
how a proxy or redirect server should process a request. It is not
processed by user agents. Its value is a list of tokens, each of
H. Schulzrinne et. al. [Page 12]
Internet Draft SIP Caller Preferences July 1, 2002
which specifies a particular feature.
When the caller specifies a feature, the server SHOULD treat it as a
hint, not as a requirement and MAY ignore the feature request.
The header field has the following syntax:
Request-Disposition = ( "Request-Disposition" | "d" ) ":"
1# (proxy-feature | cancel-feature |
fork-feature | recurse-feature |
parallel-feature | queue-feature)
proxy-feature = "proxy" | "redirect"
cancel-feature = "cancel" | "no-cancel"
fork-feature = "fork" | "no-fork"
recurse-feature = "recurse" | "no-recurse"
parallel-feature = "parallel" | "sequential"
queue-feature = "queue" | "no-queue"
Note that a compact form, using the letter d, has been defined. There
can only be one instance of feature per header (i.e., you can't have
both "proxy" and "redirect" in the same Request Disposition header).
proxy-feature: This feature indicates whether the caller would
like each server to proxy or redirect. If the server is
incapable of performing the requested feature, it SHOULD
ignore the feature request.
cancel-feature: This feature indicates whether the caller would
like each proxy server to send a CANCEL request downstream
in response to a 200 OK from the downstream server (which
is the normal mode of operation, making it somewhat
redundant), or whether this function should be left to the
caller. If a proxy receives a request with this parameter
set to "no-cancel", it SHOULD NOT CANCEL any outstanding
branches on receipt of a 2xx. However, it would still send
CANCEL on any outstanding branches on receipt of a 6xx.
fork-feature: This feature indicates whether a proxy should fork
a request, or proxy to only a single address. If the server
is requested not to fork, the server SHOULDproxy the
request to the "best" address (generally the one with the
highest q value). The feature is ignored if "redirect" has
been requested.
recurse-feature: This feature indicates whether a proxy server
H. Schulzrinne et. al. [Page 13]
Internet Draft SIP Caller Preferences July 1, 2002
receiving a 300-class response should send requests to the
addresses listed in the response (i.e., recurse), or
forward the list of addresses upstream towards the caller.
The feature is ignored if "redirect" has been requested.
parallel-feature: For a forking proxy server, this feature
indicates whether the caller would like the proxy server to
proxy the request to all known addresses at once, or go
through them sequentially, contacting the next address only
after it has received a non-200 or non-600 final response
for the previous one. The feature is ignored if "redirect"
has been requested.
queue-feature: If the called party is temporarily unreachable,
e.g., because it is in another call, the caller can
indicate that it wants to have its call queued rather than
rejected immediately. If the call is queued, the server
returns "182 Queued". A queued call can be terminated as
described in [1].
Example:
Request-Disposition: proxy, recurse, parallel
6.2 Accept-Contact and Reject-Contact
The Accept-Contact and Reject-Contact header fields have the
following syntax:
Accept-Contact = ("Accept-Contact" / "a") HCOLON feature-set
*(COMMA feature-set)
Reject-Contact = ("Reject-Contact" / "j") HCOLON feature-set
*(COMMA feature-set)
feature-set = ( name-addr / addr-spec / "*")
*(SEMI tag-set) [q-param]
tag-set = feature-tag EQUAL (tag-value-list | string-value)
tag-value-list = LDQUOT ["!"] tag-values RDQUOT
feature-tag = ftag ; From RFC 2533
tag-values = tag-value *("," tag-value)
tag-value = boolean / number / token
boolean = "TRUE" / "FALSE"
number = integer / rational
integer = [ "+" / "-" ] 1*DIGIT
H. Schulzrinne et. al. [Page 14]
Internet Draft SIP Caller Preferences July 1, 2002
rational = [ "+" / "-" ] 1*DIGIT "/" 1*DIGIT
string-value = quoted-string
q-param = "q" EQUAL qvalue
The feature-tag is any valid feature tag, a number of which are
applicable to SIP, and defined in Section 7.
OPEN ISSUE: One of the changes from a previous rev was to
eliminate the ampersand construct in the Accept and Reject
contact headers. If we add it back in, its probably easier
just to allow an actual RFC 2533 expression in this header.
A compact form, with the letter a, has been defined for the Accept-
Contact header field, and with the letter j for the Reject-Contact
header field.
6.3 Contact Header
This specification extends the Contact header. In particular, it
allows for the Contact header parameter to include tag-set:
contact-params = c-p-q / c-p-expires / tag-set
= / contact-extension
This tag set describes the feature set of the UA associated with the
URI being registered.
OPEN ISSUE: A problem here is that there is no way to
differentiate, by syntax, Contact parameters that are part
of tag-set or just other extensions. If proxies need to
know the set of feature tags to compare them, there is no
problem. That is not clear from RFC 2533. If they do not
need to know, it might be OK anyway. Things that are not
really feature tags would not be present in the Accept-
Contact and Reject-Contact headers, and thus effectively be
ignored in the matching process anyway.
7 Media Feature Tag Definitions
This specification defines an initial set of media feature tags for
use with this specification. New media feature tags MAY be registered
with IANA, based on the process defined for feature tag registrations
H. Schulzrinne et. al. [Page 15]
Internet Draft SIP Caller Preferences July 1, 2002
[8]. This section also serves as the IANA registration for these
feature tags.
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 [9], which can be used to
specify the language of the human or automata represented by the UA,
and the type feature tag [10], which can be used to specify the MIME
types of the media formats supported by the UA. However, the usage of
the media feature tag (which indicates the top level media types
supported by the UA) is preferred to indicating support for specific
media formats.
7.1 Class
Media feature tag name: class
ASN.1 Identifier: None
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 XXXX [[Note to IANA: Please
replace XXXX with the RFC number of this specification.]]
7.2 Duplex
Media feature tag name: duplex
ASN.1 Identifier: None
H. Schulzrinne et. al. [Page 16]
Internet Draft SIP Caller Preferences July 1, 2002
Summary of the media feature indicated by this tag: The duplex
media feature tag lists 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 XXXX [[Note to IANA: Please
replace XXXX with the RFC number of this specification.]]
7.3 Features
Media feature tag name: features
ASN.1 Identifier: None
Summary of the media feature indicated by this tag: The features
feature tag describes call handling features of the UA. It
is assumed that these features are orthogonal, and could
occur in any combination.
Values appropriate for use with this feature tag: Token with an
equality relationship. Typical values include:
voicemail: An automated system exists at this device, which
is capable of recording messages.
H. Schulzrinne et. al. [Page 17]
Internet Draft SIP Caller Preferences July 1, 2002
attendant: A human operator is available to take messages.
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 has voicemail.
Related standards or documents: RFC XXXX [[Note to IANA: Please
replace XXXX with the RFC number of this specification.]]
7.4 Mobility
Media feature tag name: mobility
ASN.1 Identifier: None
Summary of the media feature indicated by this tag: The mobility
feature tag indicates whether the device is fixed,
wireless, or somewhere in-between.
Values appropriate for use with this feature tag: Token with an
equality relationship. Typical values include:
fixed: The device is wired.
mobile: The device is wireless.
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 XXXX [[Note to IANA: Please
replace XXXX with the RFC number of this specification.]]
7.5 Media
Media feature tag name: media
ASN.1 Identifier: None
H. Schulzrinne et. al. [Page 18]
Internet Draft SIP Caller Preferences July 1, 2002
Summary of the media feature indicated by this tag: The media
feature tag indicates the top-level MIME media types
supported by this device. Examples include audio and video.
Values appropriate for use with this feature tag: Token with an
equality relationship. Typical values include:
video: The device supports video.
audio: The device supports audio.
message: The device supports messaging.
application: The device supports applications.
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
videophone instead of a voice phone.
Related standards or documents: RFC XXXX [[Note to IANA: Please
replace XXXX with the RFC number of this specification.]]
7.6 Description
Media feature tag name: description
ASN.1 Identifier: None
Summary of the media feature indicated by this tag: The
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 make and model.
H. Schulzrinne et. al. [Page 19]
Internet Draft SIP Caller Preferences July 1, 2002
Related standards or documents: RFC XXXX [[Note to IANA: Please
replace XXXX with the RFC number of this specification.]]
7.7 Priority
Media feature tag name: priority
ASN.1 Identifier: None
Summary of the media feature indicated by this tag: The priority
feature tag indicates the call priorities the device is
willing to handle.
Values appropriate for use with this feature tag: Token with an
ordered relationship. The defined values, in increasing
order, are:
non-urgent: The device supports non-urgent calls.
normal: The device supports normal calls.
urgent: The device supports urgent calls.
emergency: The device supports emergency calls.
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 the
emergency cell phone of a user, instead of their regular
phone.
Related standards or documents: RFC XXXX [[Note to IANA: Please
replace XXXX with the RFC number of this specification.]]
7.8 Methods
Media feature tag name: methods
ASN.1 Identifier: None
Summary of the media feature indicated by this tag: The methods
feature tag (note the plurality) indicates the SIP methods
supported by this UA.
H. Schulzrinne et. al. [Page 20]
Internet Draft SIP Caller Preferences July 1, 2002
Values appropriate for use with this feature tag: Token with an
equality relationship. Typical values include:
INVITE: The SIP INVITE method [1].
ACK: The SIP ACK method [1].
BYE: The SIP BYE method [1].
CANCEL: The SIP CANCEL method [1].
OPTIONS: The SIP OPTIONS method [1].
REGISTER: The SIP REGISTER method [1].
UPDATE: The SIP UPDATE method [6].
SUBSCRIBE: The SIP SUBSCRIBE method [7].
NOTIFY: The SIP NOTIFY method [7].
PRACK: The SIP PRACK method [5].
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 XXXX [[Note to IANA: Please
replace XXXX with the RFC number of this specification.]]
7.9 Automata
Media feature tag name: automata
ASN.1 Identifier: None
Summary of the media feature indicated by this tag: The automata
feature tag is a boolean value that indicates whether the
UA is an automata (such as a voicemail server, conference
server, or recording device) or a human.
Values appropriate for use with this feature tag: Boolean. TRUE
indicates that the UA is an automata.
H. Schulzrinne et. al. [Page 21]
Internet Draft SIP Caller Preferences July 1, 2002
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 message
recording device instead of a user.
Related standards or documents: RFC XXXX [[Note to IANA: Please
replace XXXX with the RFC number of this specification.]]
7.10 Event Packages
Media feature tag name: events
ASN.1 Identifier: None
Summary of the media feature indicated by this tag: The event
packages [7] 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. Typical values include:
presence: SIP event package for for user presence [15].
winfo: SIP event package for watcher information [16].
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 [17].
Related standards or documents: RFC XXXX [[Note to IANA: Please
replace XXXX with the RFC number of this specification.]]
7.11 Schemes
Media feature tag name: schemes
ASN.1 Identifier: None
H. Schulzrinne et. al. [Page 22]
Internet Draft SIP Caller Preferences July 1, 2002
Summary of the media feature indicated by this tag: The set of
URI schemes [11] that are supported by a UA.
Values appropriate for use with this feature tag: Token with an
equality relationship. Typical values include:
sip: The SIP URI scheme [1].
tel: The tel URI scheme [4].
http: The HTTP URI scheme [12].
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 get redirected to a phone
number when a called party is busy, rather than a web page.
Related standards or documents: RFC XXXX [[Note to IANA: Please
replace XXXX with the RFC number of this specification.]]
8 Mapping Contact Header Values and Feature Predicates
Mapping between contact header values and feature predicates,
formatted according to the syntax of RFC 2533 [2] is trivial.
Starting from a set of Contact URI parameters, the procedure is as
follows. Construct a conjunction. Each element in the conjunction
derives from one Contact parameter. If the value of the Contact
parameter begins with an exclamation point (!), the element is a
negation of a conjunction, otherwise, its a conjunction. In either
case, if the Contact parameter value is a comma separated list, there
is one element of the conjunction for each element in the list. Each
conjunction is of the form name=value, where name is the name of the
Contact parameter, and value is the value of the element in the list.
As an example, the Contact parameter:
Contact: *;mobility="fixed";events="!presence,winfo";languages="en,de"
would be converted to the following feature set:
H. Schulzrinne et. al. [Page 23]
Internet Draft SIP Caller Preferences July 1, 2002
(& (| (mobility=fixed))
(! (| (events=presence) (events=winfo)))
(| (languages=en) (languages=de)))
The conversion of an RFC 2533 formatted feature set to a list of
Contact parameters proceeds in the same way, but in reverse. The
conversion can only be done for feature sets constrained as described
in Section 4.1. The feature set will be a conjunction of elements.
Each element is either a disjunction, or a negation of a disjunction.
The elements in each disjunction will have the same feature tag name.
That feature tag name is set to the name of the Contact parameter. If
the disjunction was negated, the value begins with an exclamation
point. The remainder of the value is a comma separate list, where
each value is the value of one of the elements of the the
disjunction.
9 Security Considerations
The presence of caller preferences in a request has a significant
effect on the ways in which the request is handled at a server. As a
result, is is especially important that requests with caller
preferences be authenticated. The same holds true for registrations
with contact parameters.
Processing of caller preferences requires set operations and searches
which can require some amount of computation. This enables a DOS
attack whereby a user can send requests with substantial numbers of
caller preferences, in the hopes of overloading the server. To
counter this, servers SHOULD reject requests with too many rules. A
reasonable number is around 20.
Feature sets contained in REGISTER requests can reveal sensitive
information about a user or UA (for example, the languages spoken).
If this information is sensitive, it SHOULD be encrypted using SIP
S/MIME capabilities.
10 IANA Considerations
There are a number of IANA considerations associated with this
specification.
10.1 Media Feature Tags
This specification registers a number of new Media feature tags
according to the procedures of RFC 2506 [8]. Those registrations are
contained in Section 7.
H. Schulzrinne et. al. [Page 24]
Internet Draft SIP Caller Preferences July 1, 2002
10.2 SIP Header Fields
This specification registers three new SIP header fields, according
to the process of RFC 3261 [1].
The following is the registration for the Accept-Contact header
field:
RFC Number: RFC XXXX [Note to IANA: Fill in with the RFC number
of this specification.]
Header Name: Accept-Contact
Compact Form: a
The following is the registration for the Reject-Contact header
field:
RFC Number: RFC XXXX [Note to IANA: Fill in with the RFC number
of this specification.]
Header Name: Reject-Contact
Compact Form: j
The following is the registration for the Request-Disposition header
field:
RFC Number: RFC XXXX [Note to IANA: Fill in with the RFC number
of this specification.]
Header Name: Request-Disposition
Compact Form: d
11 Acknowledgements
The initial set of media feature tags used by this specification were
influenced by Scott Petrack's CMA design. Jonathan Lennox, Paul
Kyzivat and John Hearty provided helpful comments.
12 Author's Addresses
Jonathan Rosenberg
dynamicsoft
72 Eagle Rock Avenue
H. Schulzrinne et. al. [Page 25]
Internet Draft SIP Caller Preferences July 1, 2002
First Floor
East Hanover, NJ 07936
email: jdrosen@dynamicsoft.com
Henning Schulzrinne
Columbia University
M/S 0401
1214 Amsterdam Ave.
New York, NY 10027-7003
email: schulzrinne@cs.columbia.edu
13 Normative References
[1] J. Rosenberg, H. Schulzrinne, et al. , "SIP: Session initiation
protocol," RFC 3261, Internet Engineering Task Force, June 2002.
[2] G. Klyne, "A syntax for describing media feature sets," RFC 2533,
Internet Engineering Task Force, Mar. 1999.
[3] S. Bradner, "Key words for use in RFCs to indicate requirement
levels," RFC 2119, Internet Engineering Task Force, Mar. 1997.
[4] A. Vaha-Sipila, "URLs for telephone calls," RFC 2806, Internet
Engineering Task Force, Apr. 2000.
[5] J. Rosenberg and H. Schulzrinne, "Reliability of provisional
responses in SIP," RFC 3262, Internet Engineering Task Force, June
2002.
[6] J. Rosenberg, "The session initiation protocol UPDATE method,"
Internet Draft, Internet Engineering Task Force, May 2002. Work in
progress.
[7] A. Roach, "SIP-specific event notification," RFC 3265, Internet
Engineering Task Force, June 2002.
[8] K. Holtman, A. Mutz, and T. Hardie, "Media feature tag
registration procedure," RFC 2506, Internet Engineering Task Force,
Mar. 1999.
[9] P. Hoffman, "Registration of charset and languages media features
tags," RFC 2987, Internet Engineering Task Force, Nov. 2000.
[10] G. Klyne, "MIME content types in media feature expressions," RFC
2913, Internet Engineering Task Force, Sept. 2000.
H. Schulzrinne et. al. [Page 26]
Internet Draft SIP Caller Preferences July 1, 2002
[11] T. Berners-Lee, R. Fielding, and L. Masinter, "Uniform resource
identifiers (URI): generic syntax," RFC 2396, Internet Engineering
Task Force, Aug. 1998.
[12] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P.
Leach, and T. Berners-Lee, "Hypertext transfer protocol -- HTTP/1.1,"
RFC 2616, Internet Engineering Task Force, June 1999.
14 Informative References
[13] J. Lennox and H. Schulzrinne, "Call processing language
framework and requirements," RFC 2824, Internet Engineering Task
Force, May 2000.
[14] G. Klyne, "Protocol-independent content negotiation framework,"
RFC 2703, Internet Engineering Task Force, Sept. 1999.
[15] J. Rosenberg, "Session initiation protocol (SIP) extensions for
presence," Internet Draft, Internet Engineering Task Force, May 2002.
Work in progress.
[16] J. Rosenberg, "A session initiation protocol (SIP)event
template-package for watcher information," Internet Draft, Internet
Engineering Task Force, May 2002. Work in progress.
[17] R. Mahy, "A message summary and message waiting indication event
package for the session initiation protocol (SIP)," Internet Draft,
Internet Engineering Task Force, June 2002. Work in progress.
Full Copyright Statement
Copyright (c) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
H. Schulzrinne et. al. [Page 27]
Internet Draft SIP Caller Preferences July 1, 2002
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
H. Schulzrinne et. al. [Page 28]
