Request for Comments: 3841 dynamicsoft
Category: Standards Track H. Schulzrinne
Columbia University
P. Kyzivat
Cisco Systems
August 2004
Caller Preferences for the Session Initiation Protocol (SIP)
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2004).
Abstract
This 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 Uniform Resource Identifiers (URI) 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 header fields, Accept-Contact, Reject-Contact, and Request-
Disposition, which specify the caller’s preferences.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Overview of Operation . . . . . . . . . . . . . . . . . . . . 4
5. UAC Behavior . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. Request Handling Preferences . . . . . . . . . . . . . . 6
5.2. Feature Set Preferences . . . . . . . . . . . . . . . . 6
6. UAS Behavior . . . . . . . . . . . . . . . . . . . . . . . . . 8
7. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. Request-Disposition Processing . . . . . . . . . . . . . 9
7.2. Preference and Capability Matching . . . . . . . . . . . 9
7.2.1. Extracting Explicit Preferences . . . . . . . . . 10
7.2.2. Extracting Implicit Preferences . . . . . . . . . 10
7.2.2.1. Methods. . . . . . . . . . . . . . . . . 10
7.2.2.2. Event Packages . . . . . . . . . . . . . 11
7.2.3. Constructing Contact Predicates . . . . . . . . . 11
7.2.4. Matching. . . . . . . . . . . . . . . . . . . . . 12
7.2.5. Example . . . . . . . . . . . . . . . . . . . . . 16
8. Mapping Feature Parameters to a Predicate. . . . . . . . . . . 17
9. Header Field Definitions . . . . . . . . . . . . . . . . . . . 19
9.1. Request Disposition . . . . . . . . . . . . . . . . . . 20
9.2. Accept-Contact and Reject-Contact Header Fields . . . . 21
10. Augmented BNF . . . . . . . . . . . . . . . . . . . . . . . . 22
11. Security Considerations . . . . . . . . . . . . . . . . . . . 22
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
14.1. Normative References . . . . . . . . . . . . . . . . . . 24
14.2. Informative References . . . . . . . . . . . . . . . . . 24
15. Authors’ Addresses . . . . . . . . . . . . . . . . . . . . . . 25
16. Full Copyright Statements. . . . . . . . . . . . . . . . . . . 26
1. Introduction
When a Session Initiation Protocol (SIP) [1] server receives a
request, there are a number of decisions it can make regarding the
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 execution of a
program or database access.
However, the administrator of the server is the not the only entity
with an interest in request processing. There are at least three
parties which have an interest: (1) the administrator of the server,
(2) the user that sent the request, 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 the callee, even though
the request method 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) [11]. However, no mechanism
exists to incorporate the preferences of the user that sent the
request (also referred to as the caller, even though the request
method may not be INVITE). For example, the caller might want to
speak to a specific user, but wants to reach them only at work,
because the call is a business call. As another example, the caller
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 caller 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, called request handling preferences, are
encapsulated in the Request-Disposition header field. They provide
specific request handling directives for a server. The other, called
feature preferences, is present in the Accept-Contact and Reject-
Contact header fields. They allow 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
provided by a UA to its registrar [3]. 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.
One example of a service enabled by caller preferences is a "one
number" service. A user can have a single identity (their SIP URI)
for all of their devices - their cell phone, PDA, work phone, home
phone, and so on. If the caller wants to reach the user at their
business phone, they simply select "business phone" from a pull-down
menu of options when calling that URI. Users would no longer need to
maintain and distribute separate identities for each device.
2. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119
[4] and indicate requirement levels for compliant implementations.
3. Definitions
Much of the terminology used in this specification is presented in
[3]. This specification defines the following additional terms:
Caller: Within the context of this specification, a caller refers to
the user on whose behalf a UAC is operating. It is not limited to
a user whose UAC sends an INVITE request.
Feature Preferences: Caller preferences that describe desired
properties of a UA to which the request is to be routed. Feature
preferences can be made explicit with the Accept-Contact and
Reject-Contact header fields.
Request Handling Preferences: Caller preferences that describe
desired request treatment at a server. These preferences are
carried in the Request-Disposition header field.
Target Set: A target set is a set of candidate URIs to which a proxy
or redirect server can send or redirect a request. Frequently,
target sets are obtained from a registration, but they need not
be.
Explicit Preference: A caller preference indicated explicitly in the
Accept-Contact or Reject-Contact header fields.
Implicit Preference: A caller preference that is implied through the
presence of other aspects of a request. For example, if the
request method is INVITE, it represents an implicit caller
preference to route the request to a UA that supports the INVITE
method.
4. Overview of Operation
When a caller sends a request, it can optionally include new header
fields which request certain handling at a server. These preferences
fall into two categories. The first category, called request
handling preferences, is carried in the Request-Disposition header
field. It describes specific behavior that is desired at a server.
Request handling preferences include 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, called feature preferences, is
carried in the Accept-Contact and Reject-Contact header fields.
These header fields contain feature sets, represented by the same
feature parameters that are used to indicate capabilities [3]. Here,
the feature parameters represent the caller’s preferences. The
Accept-Contact header field contains feature sets that describe UAs
that the caller would like to reach. The Reject-Contact header field
contains feature sets which, if matched by a UA, imply that the
request should not be routed to that UA.
Proxies use the information in the Accept-Contact and Reject-Contact
header fields to select amongst contacts in their target set. When
neither of those header fields are present, the proxy computes
implicit preferences from the request. These are caller preferences
that are not explicitly placed into the request, but can be inferred
from the presence of other message components. As an example, if the
request method is INVITE, this is an implicit preference to route the
call to a UA that supports the INVITE method.
Both request handling and feature 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 because 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.
5. UAC Behavior
A caller wishing to express preferences for a request includes
Accept-Contact, Reject-Contact, or Request-Disposition header fields
in the request, depending on their particular preferences. No
additional behavior is required after the request is sent.
The Accept-Contact, Reject-Contact, and Request-Disposition header
fields in an ACK for a non-2xx final response, or in a CANCEL
request, MUST be equal to the values in the original request being
acknowledged or cancelled. This is to ensure proper operation
through stateless proxies.
If the UAC wants to determine whether servers along the path
understand the header fields described in this specification, it
includes a Proxy-Require header field with a value of "pref" [3] in
its request. If the request should fail with a 420 response code,
the UAC knows that the extension is not supported. In that case, it
SHOULD retry, and may decide whether or not to use caller
preferences. A UA should only use Proxy-Require if knowledge about
support is essential for handling of the request. Note that, in any
case, caller preferences can only be considered preferences - there
is no guarantee that the requested service will be executed. As
such, inclusion of a Proxy-Require header field does not mean that
the preferences will be executed, just that the caller preferences
extension is understood by the proxies.
5.1. Request Handling Preferences
The Request-Disposition header field specifies caller preferences for
how a server should process a request. Its value is a list of
tokens, each of which specifies a particular processing directive.
The syntax of the header field can be found in Section 10, and the
semantics of the directives are described in Section 9.1.
5.2. Feature Set Preferences
A UAC can indicate caller preferences for the capabilities of a UA
that should be reached or not reached as a result of sending a SIP
request. To do that, it adds one or more Accept-Contact and Reject-
Contact header field values. Each header field value contains a set
of feature parameters that define a feature set. The syntax of the
header field can be found in Section 10, and a discussion of their
usage in Section 9.2.
Each feature set is constructed as described in Section 5 of [3].
The feature sets placed into these header fields MAY overlap; that
is, a UA MAY indicate preferences for feature sets that match
according to the matching algorithm of RFC 2533 [2].
A UAC can express explicit preferences for the methods and event
packages supported by a UA. It is RECOMMENDED that a UA include a
term in an Accept-Contact feature set with the "sip.methods" feature
tag (note, however, that even though the name of this feature tag is
sip.methods, it would be encoded into the Accept-Contact header field
as just "methods"), whose value includes the method of the request.
When a UA sends a SUBSCRIBE request, it is RECOMMENDED that a UA
include a term in an Accept-Contact feature set with the "sip.events"
feature tag, whose value includes the event package of the request.
Whether these terms are placed into a new feature set, or whether
they are included in each feature set, is at the discretion of the
implementor. In most cases, the right effect is achieved by
including a term in each feature set.
As an example, the following Accept-Contact header field expresses a
desire to route a call to a mobile device, using feature parameters
taken from [3]:
Accept-Contact: *;mobility="mobile";methods="INVITE"
The Reject-Contact header field allows the UAC to specify that a UA
should not be contacted if it matches any of the values of the header
field. Each value of the Reject-Contact header field contains a "*",
purely to align the syntax with guidelines for SIP extensions [12],
and is parameterized by a set of feature parameters. Any UA whose
capabilities match the feature set described by the feature
parameters matches the value.
The Accept-Contact header field allows the UAC to specify that a UA
should be contacted if it matches some or all of the values of the
header field. Each value of the Accept-Contact header field contains
a "*", and is parameterized by a set of feature parameters. Any UA
whose capabilities match the feature set described by the feature
parameters matches the value. The precise behavior depends heavily
on whether the "require" and "explicit" parameters are present. When
both of them are present, a proxy will only forward the request to
contacts which have explicitly indicated that they support the
desired feature set. Any others are discarded. As such, a UAC
should only use "require" and "explicit" together when it wishes the
call to fail unless a contact definitively matches. It’s possible
that a UA supports a desired feature, but did not indicate it in its
registration. When a UAC uses both "explicit" and "require", such a
contact would not be reached. As a result, this combination is often
not the one a UAC will want.
When only "require" is present, it means that a contact will not be
used if it doesn’t match. If it does match, or if it’s not known
whether it’s a complete match, the contact is still used. A UAC
would use "require" alone when a non-matching contact is useless.
This is common for services where the request simply can’t be
serviced without the necessary features. An example is support for
specific methods or event packages. When only "require" is present,
the proxy will also preferentially route the request to the UA which
represents the "best" match. Here, "best" means that the UA has
explicitly indicated it supports more of the desired features than
any other. Note, however, that this preferential routing will never
override an ordering provided by the called party. The preferential
routing will only choose amongst contacts of equal q-value.
When only "explicit" is present, it means that all contacts provided
by the callee will be used. However, if the contact isn’t an
explicit match, it is tried last amongst all other contacts with the
same q-value. The principle difference, therefore, between this
configuration and the usage of both "require" and "explicit" is the
fallback behavior for contacts that don’t match explicitly. Here,
they are tried as a last resort. If "require" is also present, they
are never tried.
Finally, if neither "require" nor "explicit" are present, it means
that all contacts provided by the callee will be used. However, if
the contact doesn’t match, it is tried last amongst all other
contacts with the same q-value. If it does match, the request is
routed preferentially to the "best" match. This is a common
configuration for preferences that, if not honored, will still allow
for a successful call, and the greater the match, the better.
6. UAS Behavior
When a UAS compliant to this specification receives a request whose
request-URI corresponds to one of its registered contacts, it SHOULD
apply the behavior described in Section 7.2 as if it were a proxy for
the domain in the request-URI. The UAS acts as if its location
database contains a single request target for the request-URI. That
target is associated with a feature set. The feature set is the same
as the one placed in the registration of the URI in the request-URI.
If a UA had registered against multiple separate addresses-of-record,
and the contacts registered for each had different capabilities, it
will have used a different URI in each registration, so it can
determine which feature set to use.
This processing occurs after the client authenticates and authorizes
the request, but before the remainder of the general UAS processing
described in Section 8.2.1 of RFC 3261.
If, after performing this processing, there are no URI left in the
target set, the UA SHOULD reject the request with a 480 response. If
there is a URI remaining (there was only one to begin with), the UA
proceeds with request processing as per RFC 3261.
Having a UAS perform the matching operations as if it were a proxy
allows certain caller preferences to be honored, even if the proxy
doesn’t support the extension.
A UAS SHOULD process any queue directive present in a Request-
Disposition header field in the request. All other directives MUST
be ignored.
7. Proxy Behavior
Proxy behavior consists of two orthogonal sets of rules - one for
processing the Request-Disposition header field, and one for
processing the URI and feature set preferences in the Accept-Contact
and Reject-Contact header fields.
In addition to processing these headers, a proxy MAY add one if not
present, or add a value to an existing header field, as if it were a
UAC. This is useful for a proxy to request processing in downstream
proxies in the implementation of a feature. However, a proxy MUST
NOT modify or remove an existing header field value. This is
particularly important when S/MIME is used. The message signature
could include the caller preferences header fields, allowing the UAS
to verify that, even though proxies may have added header fields, the
original caller preferences were still present.
7.1. Request-Disposition Processing
If the request contains a Request-Disposition header field and it is
the owner of the domain in the Request URI, the server SHOULD execute
the directives as described in Section 9.1, unless it has local
policy configured to direct it otherwise.
7.2. Preference and Capability Matching
A proxy compliant to this specification MUST NOT apply the
preferences matching operation described here to a request unless it
is the owner of the domain in the request URI, and accessing a
location service that has capabilities associated with request
targets. However, if it is the owner of the domain, and accessing a
location service that has capabilities associated with request
targets, it SHOULD apply the processing described in this section.
Typically, this is a proxy that is using a registration database to
determine the request targets. However, if a proxy knows about
capabilities through some other means, it SHOULD apply the processing
defined here as well. If it does perform the processing, it MUST do
so as described below.
The processing is described through a conversion from the syntax
described in this specification to RFC 2533 [2] syntax, followed by a
matching operation and a sorting of resulting contact values. The
usage of RFC 2533 syntax as an intermediate step is not required; it
only serves as a useful tool to describe the behavior required of the
proxy. A proxy can use any steps it likes, so long as the results
are identical to the ones that would be achieved with the processing
described here.
7.2.1. Extracting Explicit Preferences
The first step in proxy processing is to extract explicit
preferences. To do that, it looks for the Accept-Contact and
Reject-Contact header fields.
For each value of those header fields, it extracts the feature
parameters. These are the header field parameters whose name is
"audio", "automata", "class", "duplex", "data", "control",
"mobility", "description", "events", "priority", "methods",
"extensions", "schemes", "application", "video", "language", "type",
"isfocus", "actor", or "text", or whose name begins with a plus (+)
[3]. The proxy converts all of those parameters to the syntax of RFC
2533, based on the rules in Section 8.
The result will be a set of feature set predicates in conjunctive
normal form, each of which is associated with one of the two
preference header fields. If there was a req-parameter associated