Request for Comments: 4596 P. Kyzivat
Category: Informational Cisco Systems
July 2006
Guidelines for Usage of the Session Initiation Protocol (SIP)
Caller Preferences Extension
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document contains guidelines for usage of the Caller Preferences
Extension to the Session Initiation Protocol (SIP). It demonstrates
the benefits of caller preferences with specific example
applications, provides use cases to show proper operation, provides
guidance on the applicability of the registered feature tags, and
describes a straightforward implementation of the preference and
capability matching algorithm specified in Section 7.2 of RFC 3841.
Table of Contents
1. Introduction ....................................................4
2. Motivations for Caller Preferences ..............................5
2.1. One-Number .................................................7
2.2. Direct-to-Voicemail ........................................7
3. Caller Preference Use Cases .....................................8
3.1. Routing of INVITE and MESSAGE to Different UA ..............8
3.1.1. Desired Behavior ....................................8
3.1.2. Solution ............................................9
3.2. Single Contact Not Matching Implicit Preferences ..........10
3.2.1. Desired Behavior ...................................10
3.2.2. Solution ...........................................10
3.3. Package-Based Routing .....................................11
3.3.1. Desired Behavior ...................................11
3.3.2. Solution ...........................................11
3.4. Package Routing II ........................................12
3.4.1. Desired Behavior ...................................12
3.4.2. Solution ...........................................13
3.5. Audio/Video vs. Audio Only ................................13
3.5.1. Desired Behavior ...................................13
3.5.2. Solution ...........................................14
3.6. Forcing Audio/Video .......................................15
3.6.1. Desired Behavior ...................................15
3.6.2. Solution ...........................................15
3.7. Third-Party Call Control: Forcing Media ...................16
3.7.1. Desired Behavior ...................................16
3.7.2. Solution ...........................................16
3.8. Maximizing Media Overlaps .................................17
3.8.1. Desired Behavior ...................................17
3.8.2. Solution ...........................................17
3.9. Multilingual Lines ........................................18
3.9.1. Desired Behavior ...................................18
3.9.2. Solution ...........................................19
3.10. I Hate Voicemail! ........................................20
3.10.1. Desired Behavior ..................................20
3.10.2. Solution ..........................................20
3.11. I Hate People! ...........................................21
3.11.1. Desired Behavior ..................................21
3.11.2. Solution ..........................................21
3.12. Prefer Voicemail .........................................22
3.12.1. Desired Behavior ..................................22
3.12.2. Solution ..........................................22
3.13. Routing to an Executive ..................................22
3.13.1. Desired Behavior ..................................22
3.13.2. Solution ..........................................22
3.14. Speak to the Executive ...................................23
3.14.1. Desired Behavior ..................................23
3.14.2. Solution ..........................................24
3.15. Mobile Phone Only ........................................24
3.15.1. Desired Behavior ..................................24
3.15.2. Solution ..........................................24
3.16. Simultaneous Languages ...................................25
3.16.1. Desired Behavior ..................................25
3.16.2. Solution ..........................................25
3.17. The Number You Have Called... ............................26
3.17.1. Desired Behavior ..................................26
3.17.2. Solution ..........................................26
3.18. The Number You Have Called, Take Two .....................27
3.18.1. Desired Behavior ..................................27
3.18.2. Solution ..........................................27
3.19. Forwarding to a Colleague ................................28
3.19.1. Desired Behavior ..................................28
3.19.2. Solution ..........................................28
4. Capability Use Cases ...........................................30
4.1. Web Redirect ..............................................30
4.2. Voicemail Icon ............................................30
5. Usage of the Feature Tags ......................................31
5.1. Traditional Cell Phone ....................................31
5.2. Traditional Work Phone ....................................32
5.3. PC Messaging Application ..................................32
5.4. Standalone Videophone .....................................33
6. Example of Implementation of Preference and Capability
Matching .......................................................33
6.1. Extracting a Feature Set from a Header ....................34
6.2. Extracting Values from a Feature Parameter ................35
6.3. Comparing Two Value-Ranges ................................36
6.4. Feature Set to Feature Set Matching .......................36
6.5. Selecting and Ordering Contacts Based on Caller
Preferences ...............................................37
6.5.1. Reject-Contact Processing ..........................37
6.5.2. Accept-Contact Processing ..........................37
7. Security Considerations ........................................38
8. Acknowledgements ...............................................38
9. Informative References .........................................38
1. Introduction
The Session Initiation Protocol (SIP) [1] extension for Callee
Capabilities [2] describes mechanisms that allow a UA (User Agent) to
register its capabilities in a REGISTER request. A caller can
express preferences, either explicitly or implicitly, about how that
request is to be handled. This is accomplished with the Accept-
Contact and Reject-Contact header fields described in Caller
Preferences for the Session Initiation Protocol[3].
The caller preferences extension can serve as a useful tool for
supporting many applications. However, its generality makes it
difficult to use correctly and effectively in any one situation. To
remedy that, this document serves as a compendium of examples of the
usage of the caller preferences extension.
NOTE: This document is intended to assist the reader in
understanding RFCs 3840 and 3841. It is not intended to serve as
a substitute for reading those documents. The examples presented
in this document cannot be fully understood without awareness of
the mechanisms defined in RFCs 3840 and 3841.
First, Section 2 demonstrates the benefits of using caller
preferences by describing several concrete applications that are
enabled by the extension. Section 3 describes a set of detailed use
cases for expressing caller preferences. Each use case presents a
situation, describes how caller preferences can be used to handle the
requirements for the situation, and verifies that the desired
behavior occurs by showing the results of the matching operation.
These use cases validate that the caller preferences specification is
complete and capable of meeting a specific set of requirements.
Since the caller preferences specification predates the SIP change
process [4], no requirements document was ever published for it. To
some degree, this document "backfills" requirements. However, this
is not an academic exercise only, since the use cases described here
did result in changes in the caller preferences document as it
evolved. These use cases also help implementors figure out how to
use caller preferences in their own applications.
Section 4 discusses applications for the callee capabilities
specification. Section 5 discusses the example registrations of the
feature tags described in [2]. Proper usage of the caller
preferences extension depends on proper interpretation of the
semantics of these tags. More detail is provided on the tags, and
example registrations are included that show typical usage.
Section 6 outlines an implementation approach to the matching
algorithm that doesn’t require RFC 2533 [6] to be implemented in all
its generality.
2. Motivations for Caller Preferences
At its core, SIP is a protocol that facilitates rendezvous of users.
The caller and callee need to meet up in order to exchange session
information, so that they may communicate. The rendezvous process is
complicated by the fact that a user has multiple points of attachment
to the network. A called user (callee) can have a cell phone, a PDA,
a work phone, a home phone, and one of several PC-based
communications applications. When someone calls that user, to which
of these devices is the call routed?
Certainly, the call can be routed to all of them at the same time, a
process known as parallel forking. However, that is not always the
desired behavior. Users may prefer that their registered devices be
tried in a particular order. As an example, a user might prefer that
his cell phone ring first, and if no one answers, that his work phone
ring next. Another user might prefer that her cell phone ring first,
and then her home and work phones ring at the same time, and then, if
no one answers either of those, that the call be forwarded to
voicemail. These variations are all referred to as find-me/
follow-me features.
SIP supports find-me/follow-me features in many ways. The most basic
is through the SIP registration process. Each device at which a user
can be contacted registers to the network. This registration
associates the device with the canonical name of the user, called the
address-of-record (AOR), which is a SIP URI. Each registration can
include a preference value, indicating the relative preference for
receiving calls at that device, compared to other devices. When
someone makes a call to the AOR, proxies compliant to RFC 3261 will
try the registered devices in order of preference, unless
administrative policy overrides user preferences.
Preference values in SIP registrations can only provide basic find-
me/follow-me features. To support more complex features, the Call
Processing Language (CPL) [5] has been specified. It is an XML
script that provides specific call routing instructions. Users can
upload these scripts to the network, instructing the servers how
calls should be routed. As an example, a CPL script can instruct a
proxy to route a call to the work phone during work hours (9 am -
5 pm) and then to the cell phone after hours, unless the call is from
a family member, in which case it always goes to the cell phone.
It is important to note that both CPL scripts and preference values
in registrations describe operation of a service from the perspective
of the called party. That is, they describe how a call made to the
called party should be routed by the network. However, the called
party is not the only one with preferences. A caller will also have
preferences for how they want their call to be routed. As an
example, a caller will often want to reach a user on their cell
phone. In the current telephone network, this is accomplished by
requiring a user to have a separate number for each device. This
way, when a caller wishes to reach the cell phone, they dial the
number for the cell phone. This requires users to maintain lists of
potential reach numbers for a user, and then select the appropriate
one. A far better approach is for a user to maintain a single
address-of-record. When someone wishes to reach them on their cell
phone, they call the AOR, but indicate a preference for the call to
be routed to the cell phone.
A caller may actually have a wide variety of preferences for how a
call should be routed. They may prefer to go right to voicemail.
They may prefer never to reach voicemail. The may prefer to reach
the user on a device that supports video (because a video-conference
is desired). They may wish to reach a device that has an attendant
who can answer if the user is not there.
The SIP caller preferences extension allows a caller to express these
preferences for the way in which their calls are handled. These
preferences are expressed in terms of properties of the desired
device. These properties are name-value pairs that convey some kind
of information about a device. One example is the property
"mobility", which can have the values "mobile" or "fixed". When a
caller wishes to reach a cell phone, they include information in
their call setup request (the INVITE method) which indicates that the
call should be routed to a device that has the property "mobility"
set to "mobile". When devices register to the network, they include
their properties (also known as callee capabilities) as part of the
registration. In this way, a proxy can match the caller’s
preferences against the capabilities of the various devices
registered to the user and route the call appropriately.
While this document addresses the preferences of a caller, it does so
from the perspective of a SIP User Agent representing the caller.
Caller preferences are herein represented via syntactic elements
placed in a SIP request. This document does not attempt to address
how preferences might be conveyed by a human user to the User Agent.
Thus this document is likely to be of most value to the developer of
a User Agent.
The caller preferences extension can support a wide variety of call
routing applications and features. Two particularly important
examples are "one-number" and "direct-to-voicemail".
2.1. One-Number
In today’s circuit-switched telephony networks, users have multiple
devices, and each device is associated with its own phone number. A
user will typically list all of these numbers on a business card:
cell phone, work phone, home office phone, and so on. Other users
need to store and manage all of these numbers. It is difficult to
keep these numbers complete and up-to-date. Worse, when you want to
call someone, you need to pick a number to try. Sometimes, you want
a specific device (the cell phone); and other times, you just want to
reach them wherever they are. In the latter case, a user is forced
to try each number, one at a time. This is inefficient, and
difficult to do while driving, for example.
As an alternative, a user can have a single address. This is the one
and only address they give out to other users on their business
cards. If a caller wishes to reach that user on their cell phone,
they select that one address, and then access a pull-down menu of
device types. This menu would include home phone, work phone, and
cell phone. The caller can select cell-phone, and then the call is
placed to the cell phone. There is no need to manage or maintain
more than one number for the user -- a single number will suffice.
If, on the other hand, the caller wishes to reach the user wherever
they are, they make a call to that one number without a selection of
a preferred device. The network will ring all devices at the same
time, and therefore reach the user as fast as possible.
This one-number service makes use of caller preferences. To express
a preference for the cell phone, the caller’s device would include a
header in the SIP INVITE request, indicating a desire to reach a
device with "mobility" equal to "mobile".
2.2. Direct-to-Voicemail
Frequently, a busy executive on the road wants to quickly pass a
message to a colleague by voice. As an example, a boss might want to
instruct an employee to call a specific customer and resolve a
pending issue. In such a case, the user doesn’t actually want to
talk to the person; they just want to leave a voice message. Having
a phone conversation may require too much time, whereas a voice
message can be quick and to the point. The voice message can also
serve as a record of exactly what is desired, whereas a fleeting
voice conversation can be forgotten or misremembered.
In today’s circuit-switched telephone networks, there is often no way
to go directly to someone’s voicemail and leave a message.
Sometimes, you can dial the main number for the voicemail system,
enter in the extension of the desired party, and leave a message by
entering a specific prompt. This is time consuming, and requires the
caller to know the main voicemail number.
Instead, an address book in a cell phone can have an option called
"leave voice message", available for each entry in the address book.
When this option is selected, a call is made directly to the
voicemail for that user, which immediately picks up and prompts for a
message. In fact, a rapid greeting is played, so that the caller can
go directly to the recording procedure.
This saves time for the caller, making it very easy to quickly leave
recorded messages for a large number of people.
This feature is possible using the caller preferences extension.
When the user selects the "leave voice message" option, the phone
sends a SIP INVITE request, and includes a caller preferences header
field that indicates a preference for devices whose "msgserver"
attribute has a value of "true". This will cause the proxy to route
the call directly to a registered voicemail service. Furthermore,
the voicemail server will see that the caller asked to go directly to
voicemail, and can therefore play an abbreviated greeting explicitly
designed for this case.
3. Caller Preference Use Cases
Each use case is described as a situation along with a desired
behavior. Then, it demonstrates how the various caller preferences
headers and the proxy processing logic would result in the
appropriate decision.
3.1. Routing of INVITE and MESSAGE to Different UA
3.1.1. Desired Behavior
Address of Record (AOR) Y has two contacts, Y1 and Y2. Y1 is a phone
and supports the standard operations INVITE, ACK, OPTIONS, BYE, and
CANCEL but does not support MESSAGE, whereas Y2 is a pager and
supports only OPTIONS and MESSAGE. Caller X wants to send pages to
Y. There is a lot of traffic in the network of both calls and pages,
so there is a goal not to unnecessarily fork messages to devices that
can’t support them. So, this is done by ensuring that INVITEs of Y
are delivered only to Y1, while MESSAGEs to Y are delivered only to
Y2.
3.1.2. Solution
Y1 will create a registration that looks like, in part:
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact:<sip:Y1@pc.example.com>
;methods="INVITE,ACK,OPTIONS,BYE,CANCEL"
;uri-user="<Y1>"
;uri-domain="example.com"
;audio
;schemes="sip"
;mobility="mobile"
Y2 will create a registration that looks like, in part:
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:Y2@pc.example.com>
;methods="OPTIONS,MESSAGE"
;uri-user="<Y2>"
;uri-domain="example.com"
;+sip.message
;schemes="sip,im"
;mobility="mobile"
When a UAC (User Agent Client) sends an INVITE, it will arrive at the
proxy for example.com. There are no caller preferences in the
request. However, per Section 7.2.2 of [3], the proxy will construct
an implicit require-flagged Accept-Contact preference that looks
like:
(& (sip.methods="INVITE"))
Applying the matching algorithm of RFC 2533 [6] to this feature set
and those registered by Y1 and Y2, the feature set of Y1 alone
matches. Because the Accept-Contact predicate has its require flag
set, Y2 is discarded, and the INVITE is routed to Y1.
If the request was MESSAGE, the proxy constructs an implicit Accept-
Contact preference with its require flag set (require-flagged) that
looks like:
(& (sip.methods="MESSAGE"))
which matches the feature set of Y2, but not Y1. Thus, Y1 is
discarded, and the request is routed to Y2.
3.2. Single Contact Not Matching Implicit Preferences
3.2.1. Desired Behavior
AOR Y has a single contact, Y1. It’s a phone, and therefore supports
the standard operations INVITE, ACK, OPTIONS, BYE, and CANCEL but
does not support MESSAGE. A caller X sends a MESSAGE request. The
desired behavior is that the request is still routed to the solitary
contact so that it can generate a 405 response.
3.2.2. Solution
The single contact Y1 will generate a registration that looks like,
in part:
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:Y1@pc.example.com>
;methods="INVITE,ACK,OPTIONS,BYE,CANCEL"
;uri-user="<Y1>"
;uri-domain="example.com"
;audio
;schemes="sip"
;mobility="fixed"
;class="personal"
X sends a MESSAGE request. There are no explicit caller preferences.
This results in an implicit require-flagged Accept-Contact
preference:
(& (sip.methods="MESSAGE"))
Since Y1 doesn’t match and the Accept-Contact predicate is require-
flagged, it is discarded. However, according to section 7.2.4 of RFC
3841, if there are no matching targets, the original target set is
used. Thus, the request is sent to the one original target, Y1, as
desired. Y1 then responds with a 405.
If there were multiple contacts, and none of them matched the Accept-
Contact predicate, then the original target set including all of the
contacts would be restored. Then all the contacts would be processed
according to Section 16.6 of RFC 3261.
3.3. Package-Based Routing
3.3.1. Desired Behavior
AOR Y has a number of contacts, Y1, Y2, ..., Yn, that can each
support the standard operations INVITE, ACK, OPTIONS, BYE, and CANCEL
and can also support SUBSCRIBE for the "dialog" event package [7]. Y
also has another contact, Yp, that is a presence agent (PA) [8]: it
can accept only SUBSCRIBE requests for the "presence" event package.
The goal is for SUBSCRIBE requests for presence to be routed to Yp
while INVITEs and SUBSCRIBEs for the dialog package are forked to
Y1...Yn.
3.3.2. Solution
Y1..Yn will generate REGISTER requests that look like, in part:
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:Yi@pc.example.com>
;methods="INVITE,BYE,OPTIONS,ACK,CANCEL,SUBSCRIBE"
;events="dialog"
;uri-user="<Yi>"
;uri-domain="example.com"
;audio
;schemes="sip"
;mobility="fixed"
;class="personal"
and Yp will generate a REGISTER request that looks like, in part:
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:Yp@pc.example.com>;methods="SUBSCRIBE"
;events="presence"
;uri-user="<Yp>"