SIPPING J. Rosenberg
Internet-Draft dynamicsoft
Expires: August 16, 2004 P. Kyzivat
Cisco Systems
February 16, 2004
Guidelines for Usage of the Session Initiation Protocol (SIP) Caller
Preferences Extension
draft-ietf-sipping-callerprefs-usecases-01
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.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 16, 2004.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
This document contains guidelines for usage of the Caller Preferences
Extension to the Session Initiation Protocol (SIP). It motivates 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 matching algorithm.
Rosenberg & Kyzivat Expires August 16, 2004 [Page 1]
Internet-Draft Caller Preferences Uses February 2004
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4
2. Motivations for Caller Preferences . . . . . . . . . . . . 5
2.1 One-Number . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2 Direct-to-Voicemail . . . . . . . . . . . . . . . . . . . 7
3. Caller Preference Use Cases . . . . . . . . . . . . . . . 9
3.1 Routing of INVITE and MESSAGE to different UA . . . . . . 9
3.1.1 Desired Behavior . . . . . . . . . . . . . . . . . . . . . 9
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 . . . . . . . . . . . . . . . . . . . . 13
3.4.1 Desired Behavior . . . . . . . . . . . . . . . . . . . . . 13
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 . . . . . . . . . . . . . . . . . . . . 19
3.9.1 Desired Behavior . . . . . . . . . . . . . . . . . . . . . 19
3.9.2 Solution . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.10 I Hate Voicemail! . . . . . . . . . . . . . . . . . . . . 20
3.10.1 Desired Behavior . . . . . . . . . . . . . . . . . . . . . 20
3.10.2 Solution . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.11 I Hate People! . . . . . . . . . . . . . . . . . . . . . . 21
3.11.1 Desired Behavior . . . . . . . . . . . . . . . . . . . . . 22
3.11.2 Solution . . . . . . . . . . . . . . . . . . . . . . . . . 22
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 . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.14 Speak to the Executive . . . . . . . . . . . . . . . . . . 24
3.14.1 Desired Behavior . . . . . . . . . . . . . . . . . . . . . 24
Rosenberg & Kyzivat Expires August 16, 2004 [Page 2]
Internet-Draft Caller Preferences Uses February 2004
3.14.2 Solution . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.15 Mobile Phone Only . . . . . . . . . . . . . . . . . . . . 24
3.15.1 Desired Behavior . . . . . . . . . . . . . . . . . . . . . 24
3.15.2 Solution . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.16 Simultaneous Languages . . . . . . . . . . . . . . . . . . 25
3.16.1 Desired Behavior . . . . . . . . . . . . . . . . . . . . . 25
3.16.2 Solution . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.17 UA Routing . . . . . . . . . . . . . . . . . . . . . . . . 26
3.17.1 Desired Behavior . . . . . . . . . . . . . . . . . . . . . 26
3.17.2 Solution . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.18 The Number you Have Called.. . . . . . . . . . . . . . . . 27
3.18.1 Desired Behavior . . . . . . . . . . . . . . . . . . . . . 27
3.18.2 Solution . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.19 The Number you Have Called, Take Two . . . . . . . . . . . 29
3.19.1 Desired Behavior . . . . . . . . . . . . . . . . . . . . . 29
3.19.2 Solution . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.20 Forwarding to a Colleague . . . . . . . . . . . . . . . . 29
3.20.1 Desired Behavior . . . . . . . . . . . . . . . . . . . . . 29
3.20.2 Solution . . . . . . . . . . . . . . . . . . . . . . . . . 29
4. Capability Use Cases . . . . . . . . . . . . . . . . . . . 32
4.1 Web Redirect . . . . . . . . . . . . . . . . . . . . . . . 32
4.2 Voicemail Icon . . . . . . . . . . . . . . . . . . . . . . 32
5. Usage of the Feature Tags . . . . . . . . . . . . . . . . 34
5.1 Traditional Cell Phone . . . . . . . . . . . . . . . . . . 34
5.2 Traditional Work Phone . . . . . . . . . . . . . . . . . . 35
5.3 PC Messenging Application . . . . . . . . . . . . . . . . 35
5.4 Standalone Videophone . . . . . . . . . . . . . . . . . . 35
6. Security Considerations . . . . . . . . . . . . . . . . . 37
7. IANA Considerations . . . . . . . . . . . . . . . . . . . 38
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 39
9. TODO . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Informative References . . . . . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 42
Intellectual Property and Copyright Statements . . . . . . 43
Rosenberg & Kyzivat Expires August 16, 2004 [Page 3]
Internet-Draft Caller Preferences Uses February 2004
1. Introduction
The Session Initiation Protocol (SIP) [1] extension for Callee
Capabilities [3] describes mechanisms that allow a UA to register
its capabilities in a REGISTER request. A caller can express
preferences [2], either explicitly or implicitly, about how that
request is to be handled. This is accomplished with the
Accept-Contact and Reject-Contact header fields.
The caller preferences extension can serve as a useful tool for
supporting many applications. However, it generality makes it
difficult to correctly and effectively use in any one situation. To
remedy that, this document serves as an compendium to the caller
preferences extension. This additional information is broken into
four sections.
First, Section 2 motivates the usage of caller preferences by
describing several concrete applications which 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 pre-dates the SIP change
process [4], no requirements work was ever done 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 it 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 [3]. 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.
Rosenberg & Kyzivat Expires August 16, 2004 [Page 4]
Internet-Draft Caller Preferences Uses February 2004
2. Motivations for Caller Preferences
At its core, SIP is protocol to facilitate 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 user can have a cell phone, a PDA, a work phone, a
home phone, and one of several PC-based communications applications.
When someone calls a 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. A user will frequently have preferences for their
devices, and wish the call to be routed to one of them first. As an
example, a user might prefer that their cell phone ring first, and if
no one answers, the call rings their work phone next. As an
alternative, a user might prefer that their cell phone ring first,
and then their home and work phones ring at the same time, and then,
if neither answer, the call is forwarded to voicemail. These
variations are all referred to as 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 (9am - 5pm)
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 them
should be routed by the network. However, the called party is not the
only one with preferences. A caller will also have preferences for
Rosenberg & Kyzivat Expires August 16, 2004 [Page 5]
Internet-Draft Caller Preferences Uses February 2004
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 to never reach voicemail. The may prefer to reach the user
on a device which 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.
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
Rosenberg & Kyzivat Expires August 16, 2004 [Page 6]
Internet-Draft Caller Preferences Uses February 2004
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 one 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 them 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 someones 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.
Rosenberg & Kyzivat Expires August 16, 2004 [Page 7]
Internet-Draft Caller Preferences Uses February 2004
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.
Rosenberg & Kyzivat Expires August 16, 2004 [Page 8]
Internet-Draft Caller Preferences Uses February 2004
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 being made.
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
so on, while 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,
ensure 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 which 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 which 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"
;+message
;schemes="sip,im"
;mobility="mobile"
Rosenberg & Kyzivat Expires August 16, 2004 [Page 9]
Internet-Draft Caller Preferences Uses February 2004
When a UAC 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 [2], the proxy will construct an implicit
require-flagged Accept-Contact preference that looks like:
(& (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
require-tagged Accept-Contact preference that looks like:
(& (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. Its a phone, and therefore supports
the INVITE, BYE, OPTIONS, CANCEL and ACK methods, but not 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 which 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"
Rosenberg & Kyzivat Expires August 16, 2004 [Page 10]
Internet-Draft Caller Preferences Uses February 2004
X sends a MESSAGE request. There are no explicit caller preferences.
This results in an implicit require-flagged Accept-Contact
preference:
(& (methods="MESSAGE"))
Since Y1 doesn't match and the Accept-Contact predicate is
require-flagged, it is discarded. However, according to the
specifications, if there are no matching targets, the original target
set is used, with its original q-values. Thus, the request is sent to
the one original target, Y1, as desired. Y1 then responds with a 405.
3.3 Package-Based Routing
3.3.1 Desired Behavior
AOR Y has a number of contacts, Y1, Y2, ..., Yn that can each support
normal calls - INVITE, ACK, BYE, etc., 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 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 which 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 which looks like, in part:
Rosenberg & Kyzivat Expires August 16, 2004 [Page 11]
Internet-Draft Caller Preferences Uses February 2004
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>"
;uri-domain="example.com"
;schemes="sip,pres"
;mobility="fixed"
;class="business"
A SUBSCRIBE request for presence will arrive at the proxy for
example.com. Since there are no explicit preferences, it constructs
an implicit require-tagged Accept-Contact preference from the
request:
(& (methods="SUBSCRIBE") (events="presence"))
This feature set only matches the one registered by Yp. Because the
require flag is set, the contacts which do not match are removed from
the target set. Therefore, Y1..Yn are eliminated. The request is sent
to the remaining contact, Yp, representing the PA.
An INVITE request without explicit preferences results in an implicit
require-flagged Accept-Contact preference:
(& (methods="INVITE"))
The implicit Accept-Contact feature set matches Y1..Yn, but not Yp.
The score for Y1..Yn against this predicate is 1.0. As a result, the
caller preference Qa for each contact is 1.0. The registrations did
not contain q-values, so the default q-value of 1.0 is applied to
each Contact URI. Since the caller and callee preferences are the
same, and all equal to 1.0, there is no reordering of contacts. The
result is that the proxy will consider Y1..Yn each as equally good
targets for the request, and possibly fork the request to each.
A SUBSCRIBE request for the dialog event package without explicit
preferences will result in an implicit require-flagged Accept-Contact
preference:
(& (methods="SUBSCRIBE") (events="dialog"))
This only matches Y1..Yn, so Yp is discarded, and the request is
routed to the remaining contacts just as the INVITE was.
Rosenberg & Kyzivat Expires August 16, 2004 [Page 12]
Internet-Draft Caller Preferences Uses February 2004
3.4 Package Routing II
3.4.1 Desired Behavior
This case is nearly identical to that of Section Section 3.3.
However, Y1..Yn omit the "events" feature tag from their
registration. Yp registers as in Section Section 3.3. A SUBSCRIBE for
the presence event package should still preferentially route to Yp.
3.4.2 Solution
The registration from Y1..Yn will look like:
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"
;uri-user="<Yi>"
;uri-domain="example.com"
;audio
;schemes="sip"
;mobility="fixed"
;class="personal"
When the caller sends a SUBSCRIBE for the presence event package
(without explicit preferences), the proxy computes an implicit
preference:
(& (methods="SUBSCRIBE") (events="presence"))
This predicate matches Y1..Yn and Yp. However, the score for Y1..Yn
against this predicate is 0.5, and the score of Yp is 1.0. The result
is a caller preference Qa of 0.5 for Y1..Yn, and a caller preference
Qa of 1.0 for Yp. Since the callee provided no q-values, the proxy
will assume a default of 1.0. Thus, all contacts are in the same
equivalence class. They are then sorted by Qa, so that Yp is first,
followed by Y1 through Yn. It will therefore route the request first
to Yp, and if that should fail, to Y1..Yn.
3.5 Audio/Video vs. Audio Only
3.5.1 Desired Behavior
X sends an invitation to Y to initiate an audio/video call, including
both m=audio and m=video lines in the SDP. AOR Y has two contacts, Y1
and Y2. Y1 represents a normal audio phone, where Y prefers to
Rosenberg & Kyzivat Expires August 16, 2004 [Page 13]
Internet-Draft Caller Preferences Uses February 2004
receive their calls. It will answer an audio/video call, refusing the
video. Y2 represents an audio/video phone that should only used when
needed. The caller really wants the called answered by a device that
supports video, but will take an audio-only call as a second choice.
3.5.2 Solution
Y1 will generate a registration which looks like, in part:
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:Y1@pc.example.com>;q=1.0
;methods="INVITE,BYE,OPTIONS,ACK,CANCEL"
;uri-user="<Y1>"
;uri-domain="example.com"
;audio
;schemes="sip,tel"
;mobility="fixed"
;class="business"
Y2 will generate a registration which looks like, in part:
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:Y2@pc.example.com>;q=0.6
;methods="INVITE,BYE,OPTIONS,ACK,CANCEL"
;uri-user="<Y2>"
;uri-domain="example.com"
;audio
;video
;schemes="sip,tel"
;mobility="fixed"
;class="business"
Note the different q-values, allowing Y2 to be selected as a device
of "last resort".
To have the call is preferentially routed to a device that supports
video, the caller X sends an INVITE that looks like, in part:
INVITE sip:Y@example.com SIP/2.0
Accept-Contact: *
;methods="INVITE"
;video
Rosenberg & Kyzivat Expires August 16, 2004 [Page 14]
Internet-Draft Caller Preferences Uses February 2004
The proxy will convert this to a feature set. This feature set
matches Y2 and Y1. However, the score for Y2 is 1.0, and 0.5 for Y1.
The two contacts are then ordered by q-value, and broken into
equivalence classes. There are two equivalence classes, each with one
contact. As a result, the caller preference values have no impact on
the ordering. The call will first try the higher priority Y1, which
will answer the call and reject the video stream. Thus, the desired
behavior is not achieved.
The desired behavior could be achieved by adding the "explicit" and
"require" tags to the Accept-Contact header field in the INVITE, as
is done in Section 3.6. However, doing so may result in calls failing
when they could occur, but without video. As discussed in [2], both
the "require" and "explicit" tags are generally used only when the
request cannot be serviced in any way unless the preferences are met.
That is not the case here.
OPEN ISSUE: This is a use case that used to work, but no longer
works because of the change in the way q-values are used. I think
the loss of support for this use case is acceptable. I also
believe it is worthwhile to keep this case in the use cases spec
to illustrate that not everything is possible.
3.6 Forcing Audio/Video
3.6.1 Desired Behavior
This case is similar to that of Section 3.5. However, X requires an
audio/video call, and would like the call to fail if this is not
possible, rather than succeeding with audio only.
3.6.2 Solution
The solution is similar to that of Section 3.5, however the
Accept-Contact header field now includes the explicit and require
tags, guaranteeing that the call is never established to any UA that
had not explicitly indicated support for video:
INVITE sip:Y@example.com SIP/2.0
Accept-Contact: *;video;require;explicit
This arrives at the example.com proxy. This explicit feature set
matches the feature set for Y2 and Y1. However, the match for Y1 did
not have a score of 1. Since the explicit and require tags are
present, the contact is discarded. That leaves Y2 only. The call will
therefore get routed to the videophone, and if the user is not there,
Rosenberg & Kyzivat Expires August 16, 2004 [Page 15]
Internet-Draft Caller Preferences Uses February 2004
the audio phone will never ring.
Because both the "require" and "explicit" flags are present, a
contact will also be discarded if it didn't say anything about
support for video. Thus, a UA that can do video, but neglected to
indicate it, would not be reached in this case. This is why it is
important for a UA to indicate all of its capabilities. Note that
this is only true for a contact that indicated other capabilities,
just not video. Contacts which don't indicate any capabilities are
"immune" from caller preferences filtering, and would not be
discarded.
3.7 Third Party Call Control - Forcing Media
3.7.1 Desired Behavior
Z is a third party call control controller [9] trying to establish an
audio/video call from X to Y. X has contacts X1 and X2, and Y has
contacts Y1 and Y2. X1 and X2 have capabilities identical to Y1 and
Y2, respectively. Z needs to send an offerless invite to X and use
the offer proposed by X to send an invite to Y. When sending the
offerless invite to X the 3pcc controller must ensure that an audio/
video contact (X2) is chosen over an audio only contact (X1).
3.7.2 Solution
X1 will generate a registration which looks like, in part:
REGISTER sip:example.com SIP/2.0
To: sip:X@example.com
Contact: <sip:X1@pc.example.com>;q=1.0
;methods="INVITE,BYE,OPTIONS,ACK,CANCEL"
;uri-user="<X1>"
;uri-domain="example.com"
;audio
;schemes="sip,tel"
;mobility="fixed"
;class="business"
X2 will generate a registration which looks like, in part:
Rosenberg & Kyzivat Expires August 16, 2004 [Page 16]
Internet-Draft Caller Preferences Uses February 2004
REGISTER sip:example.com SIP/2.0
To: sip:X@example.com
Contact: <sip:X2@pc.example.com>;q=0.6
;methods="INVITE,BYE,OPTIONS,ACK,CANCEL"
;uri-user="<X2>"
;uri-domain="example.com"
;audio
;video
;schemes="sip,tel"
;mobility="fixed"
;class="business"
Z would include, in its INVITE, an Accept-Contact header field:
INVITE sip:X@example.com SIP/2.0
Accept-Contact: *;audio;video;require;explicit
This caller preference matches both X1 and X2. However, it matches X1
with a score of .5 and X2 with a score of 1. Because of the require
and explicit tags, X1 is discarded despite X's preference for it.
Thus, the call is routed to X2.
The same caveats apply here as do in Section 3.6. Generally, it is
not advisable to mandate support for features (such as video), which
are not strictly neccesary for the request to proceed.
3.8 Maximizing Media Overlaps
3.8.1 Desired Behavior
AOR Y has two contacts, Y1 that is a regular audio phone, and Y2 that
is a PC capable of supporting both audio and session oriented IM
[10]. X is a PC with capability to support audio, video and session
oriented IM. X calls Y for the purpose of establishing a voice call.
However, X wishes to connect to the device which has the maximal
overlap with its media capabilities, in order to maximize the
functionality available to the caller.
3.8.2 Solution
Y1 will generate a registration which looks like, in part:
Rosenberg & Kyzivat Expires August 16, 2004 [Page 17]
Internet-Draft Caller Preferences Uses February 2004
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:Y1@phone.example.com>
;methods="INVITE,BYE,OPTIONS,ACK,CANCEL"
;uri-user="<Y1>"
;uri-domain="example.com"
;audio
;schemes="sip,tel"
;mobility="fixed"
;class="business"
Y2 will generate a registration which looks like, in part:
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:Y2@pc.example.com>
;methods="INVITE,BYE,OPTIONS,ACK,CANCEL,MESSAGE"
;uri-user="<Y2>"
;uri-domain="example.com"
;audio
;+message
;schemes="sip,tel"
;mobility="fixed"
;class="business"
The solution requires the caller to support caller preferences. They
would include, in their INVITE, an Accept-Contact header field that
lists all the media types they support. In this case:
INVITE sip:Y@example.com SIP/2.0
Accept-Contact: *;audio;video;+message
Both Y1 and Y2 match the predicate. Y1 matches with a score of 0.33,
and Y2 matches with a score of 0.66. Since there is only one
Accept-Contact predicate, the Qa for each contact is equal to the
score. The registered contacts are then sorted by q-value, and broken
into equivalence classes. There is a single equivalence class with
q-value of 1.0. The two contacts in that class are then re-ordered
based on the values of Qa. Y2 has a higher Qa, so it is used first,
followed by Y1. The result is that the call is routed to the device
with the maximum overlap in media capabilities, as desired.
EDITORS NOTE: This is a case that didn't work well before caller
prefs -09, but works very well now - as long as the registered
contacts have the same q-value.
Rosenberg & Kyzivat Expires August 16, 2004 [Page 18]
Internet-Draft Caller Preferences Uses February 2004
3.9 Multilingual Lines
3.9.1 Desired Behavior
AOR Y represents a shared line in an office. Several employees in the
office have phones registered for Y. Some of the employees speak only
English, some speak Spanish fluently and have some limited capability
for English, and some speak both English and Spanish fluently. Calls
from callers that speak only English should be parallel forked to all
office workers that speak fluent English. If the call isn't picked
up, then the phones of workers that speak English marginally should
be rung. Calls from callers that speak only Spanish should be forked
only to workers that speak Spanish.
3.9.2 Solution
A user at phone Y1 that speaks English only would generate a REGISTER
which looks like, in part:
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: sip:Y1@pc.example.com;languages="en"
A user at a phone Y2 that speak Spanish and a little bit of English
would generate a REGISTER that looks like, in part:
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: sip:Y2-es@pc2.example.com;languages="es"
Contact: <sip:Y2-en@pc2.example.com>;languages="en";q=0.2
Y2 has registered two contacts. Both of them route to the same device
(pc2.example.com), but they differ in their language support and
relative q-values. Multiple contacts are needed whenever a UA wishes
to express differing preferences for being reached for different
feature collections.
A user at phone Y3 that speaks English and Spanish fluently would
generate a REGISTER that looks like, in part:
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: sip:Y3@pc3.example.com;languages="es,en"
Notice that only a single contact is needed because the same q-value
Rosenberg & Kyzivat Expires August 16, 2004 [Page 19]
Internet-Draft Caller Preferences Uses February 2004
is applied across all feature collections.
For the language based routing to occur, the caller must indicate its
language preferences explicitly:
INVITE sip:Y@example.com SIP/2.0
Accept-Contact: *;languages="en";require
The predicate derived from this looks like:
(& (languages="en"))
This matches all Y1 phones, the second contact registered by Y2
phones, and Y3 phones, all with a score of 1.0. The first contact
registered by Y2 does not match, and because of the "require" flag,
is discarded. The remaining contacts are sorted by q-value, and
divided into equivalence classes. There are two equivalence classes.
The first contains Y1 and Y3 with a q-value of 1.0, and the second
contains Y2-en with a q-value of 0.2. The contacts in the first class
are ordered by Qa. However, since all contacts have the same value of
Qa (1.0), there is no change in ordering. Thus, Y1 and Y3 are tried
first, followed by Y2-en. This is the desired behavior.
A caller that speaks Spanish only would specify their preference
thusly:
INVITE sip:Y@example.com SIP/2.0
Accept-Contact: *;languages="es";require
This matches the first contact of Y2 phones, and Y3 phones, all with
a score of 1.0. The English contact of Y2, Y2-en, doesn't match, and
is discarded because of the "require" flag. The remaining contacts
are sorted by q-values (Y3, Y2-es), and broken into a single
equivalence class containing both contacts. Since the Qa for both
contacts is the same - 1.0 - there is no reordering. The result is
that the call is routed to either Y3 or Y2-es.
3.10 I Hate Voicemail!
3.10.1 Desired Behavior
AOR Y has two contacts, a phone Y1 and a voicemail service Y2. X
wishes to call Y and talk in person. X does not want to be sent to
voicemail under any circumstance.
Rosenberg & Kyzivat Expires August 16, 2004 [Page 20]
Internet-Draft Caller Preferences Uses February 2004
3.10.2 Solution
The phone would register with a Contact that looks like, in part:
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: sip:Y1@pc.example.com
;audio
;mobility="fixed"
and the voicemail server would register with a Contact that looks
like, in part:
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: sip:Y2@pc.example.com
;msgserver
;automata
;attendant
;audio
;q=0.2
The voicemail server registers with a lower q-value so that it is
used only after the phone itself is rung. Note that the voicemail
server need not actually register. There can be a configured contact
and feature set defined for it instead.
A caller that wishes to avoid voicemail can include an explicit
preference to avoid it. It would do this with the Reject-Contact
header field:
INVITE sip:Y@example.com SIP/2.0
Reject-Contact: *;msgserver
Since this feature set contains a feature tag that is not contained
in the registration for Y1, the feature set is discarded when
examining Y1. However, the registration for Y2 contains all feature
tags listed in the feature set, and so the rule is considered. There
is a match, and therefore, Y2 is discarded. The result is that the
user is never routed to voicemail.
3.11 I Hate People!
Rosenberg & Kyzivat Expires August 16, 2004 [Page 21]
Internet-Draft Caller Preferences Uses February 2004
3.11.1 Desired Behavior
The situation is similar to Section 3.10, except the caller wishes to
only leave a message, not actually speak to the person.
3.11.2 Solution
The caller would send an INVITE which looks like, in part:
INVITE sip:Y@example.com SIP/2.0
Accept-Contact: *;msgserver;require;explicit
This caller preference matches both Y1 and Y2. Y1 matches, but with a
score of zero. Y2 matches with a score of 1. Since both the require
and explicit flags are set, Y1 is discarded. Therefore, the call is
routed to Y2, the voicemail server, as desired.
If these preferences are used with a user that doesn't have voicemail
at all, the call will fail completely, rather than connecting to the
user.
3.12 Prefer Voicemail
3.12.1 Desired Behavior
The situation is similar to that of Section 3.10. However, the caller
prefers to leave a message. If voicemail is not available, they are
willing to talk to a person.
3.12.2 Solution
OPEN ISSUE: This cannot be done with caller prefs -09, as it would
require a re-ordering of the callee contacts, which is not done.
Is there another way? Is it OK to set a callee contact to q=0.0?
3.13 Routing to an Executive
3.13.1 Desired Behavior
Y is the AOR of an executive. It has three contacts. Y1 is the phone
on the executive's desk. Y2 is the phone on the desk of the
executive's assistant. Y3 is the address of an auto-attendant system
that can answer general questions, route calls to other parties, etc.
By default, calls to Y should be directed to Y2, and if that fails,
Rosenberg & Kyzivat Expires August 16, 2004 [Page 22]
Internet-Draft Caller Preferences Uses February 2004
to Y3. If Y3 doesn't answer then Y1 should ring.
3.13.2 Solution
This is primarily a called party feature, and is best accomplished
with a CPL script [5]. However, it can be accomplished with caller
preferences alone by properly setting the q-values across the three
devices. Assuming this coordination is possible, here are the
settings that would be made:
Y1 would generate a REGISTER that looks like, in part:
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: sip:Y1@pc.example.com;q=0.1
Y2 would generate a REGISTER that looks like, in part:
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: sip:Y2@pc2.example.com;attendant;q=1.0
Y3 would generate a REGISTER that looks like, in part:
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: sip:Y3@pc3.example.com;attendant;automata;q=0.5
Note that, in reality, the automated attendant would probably not use
REGISTER. Since the attendant would be used for every employee in the
company, a static contact would probably be added administratively
for each user in the enterprise. However, the information in that
static contact would be identical to the information in the
registration above.
When X makes a call to the executive, Y, and expresses no preference,
the proxy computes an implicit preference to support INVITE. All
three contacts match such a preference, even though they have not
indicated explicit support for INVITE. Thus, no contacts are
discarded. Since the contacts each have a different q-value, the
caller preferences do not cause any reordering. The result is that
the call is first routed to Y2, then Y3, then Y1, all as a result of
the proper setting of the q-values.
Rosenberg & Kyzivat Expires August 16, 2004 [Page 23]
Internet-Draft Caller Preferences Uses February 2004
3.14 Speak to the Executive
3.14.1 Desired Behavior
This case is similar to that of Section 3.13, but this time the
caller, X, has a preference. X calls Y, but wants to speak directly
to the executive. X doesn't want the call to ring either the
assistant or the auto attendant (automata).
3.14.2 Solution
X's INVITE would look like, in part:
INVITE sip:Y@example.com SIP/2.0
Reject-Contact: *;attendant
Reject-Contact: *;automata
Note that the caller uses two separate Reject-Contact header field
values, rather than a single one with two separate feature
parameters. The distinction is important. If X had use a single value
with two parameters, a matching UA would need to declare that it was
BOTH an attendant and an automata. If it only declared that it was
one of these, based on the matching rules in the caller preferences
specification, it would not be rejected.
The above request would result in the elimination of both Y2 and Y3
as contacts. The call would then be routed to Y1, as desired.
This case indicates why a CPL script, or some other programmed
version of the feature, is preferrable. With caller preferences, a
caller can override the desired ring sequence, and disturb the
executive without any kind of authorization. A proper version of this
service would simply not permit caller preferences to force the call
to go directly to the executive.
OPEN ISSUE: Should we discard this use case as a result?
3.15 Mobile Phone Only
3.15.1 Desired Behavior
The situation is similar to that in Section 3.13. However, the
executive also has a mobile phone which they have registered. Caller
X knows that the owner of Y is traveling, and that an assistant is
covering the office phone. X wants to call Y and ring only the mobile
phone.
Rosenberg & Kyzivat Expires August 16, 2004 [Page 24]
Internet-Draft Caller Preferences Uses February 2004
3.15.2 Solution
The mobile phone would generate a registration which looks like, in
part:
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: sip:Y4@mobile.example.com;mobility="mobile";q=0.5
The caller would express their preference by generating an INVITE
which looks like, in part:
INVITE sip:Y@example.com SIP/2.0
Accept-Contact: *;mobility="mobile";require;explicit
All four contacts match. However, Y1 through Y3 match with a score of
zero. Y4 matches with a score of 1. Because of the require and
explicit tags, Y1 through Y3 are discarded, and only Y4 is used, as
desired.
3.16 Simultaneous Languages
3.16.1 Desired Behavior
AOR Y is as in Section 3.9. Caller X, fluent in both English and
Spanish, has discovered that company's Spanish language documentation
is inconsistent with the English language documentation, and wants to
discuss the differences between the two. So X wants to speak with one
of the workers that is fluent in both English and Spanish.
3.16.2 Solution
The caller would generate an INVITE which looks like, in part:
INVITE sip:Y@example.com SIP/2.0
Accept-Contact: *;language="en";require
Accept-Contact: *;language="es";require
This will require a Contact URI to match both constraints. That means
it needs to support English and Spanish. This will achieve the
desired property.
Note that there are two separate Accept-Contact header fields. If the
caller had instead used this INVITE:
Rosenberg & Kyzivat Expires August 16, 2004 [Page 25]
Internet-Draft Caller Preferences Uses February 2004
INVITE sip:Y@example.com SIP/2.0
Accept-Contact: *;language="en,es";require
It would have connected them to a UA that speaks either English or
Spanish, which is not what is desired here.
3.17 UA Routing
3.17.1 Desired Behavior
AOR Y has contacts Y1 and Y2. The addresses Y1 and Y2 are behind a
firewall and are not addressable by all callers. Caller X makes a
call to Y and is connected to Y1. The call fails for some reason, and
X wants to reestablish it, reaching only Y1.
3.17.2 Solution
There is currently no generally workable solution to this problem.
The best solution that exists does make use of caller preferences.
Lets say that the Contact URI for Y1 was sip:Y1@host.example.com. The
caller would generate an INVITE which looks like, in part:
INVITE sip:Y@example.com SIP/2.0
Accept-Contact: *
;require
;explicit
;uri-user="<Y1>"
;uri-domain="host.example.com"
When this request arrives at the proxy for example.com, it attempts
to apply the caller preferences. Following the guidelines in the
caller preferences extension, Y1 would have included a uri-user and
uri-domain feature tag in its registration:
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: sip:Y1@host.example.com;uri-user="<Y1>"
;uri-domain="host.example.com"
as would have Y2:
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: sip:Y2@pc.example.com;uri-user="<Y2>"
;uri-domain="pc.example.com"
Rosenberg & Kyzivat Expires August 16, 2004 [Page 26]
Internet-Draft Caller Preferences Uses February 2004
The proxy then applies the caller preferences. Only Y1 is a match.
So, Y2 is discarded, and the request is routed to Y1 as desired.
The difficulty is that this solution won't always work. In a
multi-proxy scenario, it is possible that the routing logic changes,
and therefore the request is never even routed to the proxy where Y1
has registered.
3.18 The Number you Have Called..
3.18.1 Desired Behavior
Consider once more the case of the executive, where the caller wishes
to reach only their mobile phone (Section 3.15). However, there is a
twist. The callee Y has moved to new address YY, and all the
configuration described for the callee now applies to YY. The old
address Y remains with a pair of statically assigned contacts. One
contact is YY. The other is M referencing an automaton that generates
a voice message reporting that the number has been changed. The
caller is unaware of the move and calls Y, requesting to reach the
mobile phone in exactly the same way they did in Section 3.15. The
call should connect to the mobile.
3.18.2 Solution
There would be four registrations against YY:
YY1, the executive, would generate a REGISTER that looks like, in
part:
REGISTER sip:example.com SIP/2.0
To: sip:YY@example.com
Contact: sip:YY1@pc.example.com;q=0.1
YY2, the attendant, would generate a REGISTER that looks like, in
part:
REGISTER sip:example.com SIP/2.0
To: sip:YY@example.com
Contact: sip:YY2@pc2.example.com;attendant;q=1.0
YY3, the answering service, would generate a REGISTER that looks
like, in part:
REGISTER sip:example.com SIP/2.0
Rosenberg & Kyzivat Expires August 16, 2004 [Page 27]
Internet-Draft Caller Preferences Uses February 2004
To: sip:YY@example.com
Contact: sip:YY3@pc3.example.com;attendant;automata;q=0.5
YY4, the mobile, would generate a REGISTER that looks like, in part:
REGISTER sip:example.com SIP/2.0
To: sip:YY@example.com
Contact: sip:YY4@mobile.example.com;mobility="mobile";q=0.5
Athough it would be configured administratively, there are two
registered contacts for Y. The first is for the forwarding:
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: sip:YY@example.com;q=1.0
and the second for the automated answering service:
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: sip:machine@example.com;automata;q=0.5
The caller, not knowing that Y has moved, calls Y and asks for their
mobile phone:
INVITE sip:Y@example.com SIP/2.0
Accept-Contact: *;mobility="mobile";require;explicit
This reaches the example.com proxy, which finds two registrations.
Only one of these is associated with feature parameters (the
automata). The other has no feature parameters, and is therefore
immune from caller preferences processing. The caller preferences are
applied to the the automata's contact. The feature sets match, but
have a score of zero. Since the require and explicit tags are
present, the contact for the automata is dropped. The other contact,
YY@example.com, is then added back in as the sole contact. The proxy
therefore sends the call to sip:YY@example.com. There, there are four
registrations, all of which are associated with feature parameters.
The caller preferences are applied. Only YY4 matches explicitly,
however. Because of the presence of the require and explicit flags,
all other contacts are dropped. As such, the call is forwarded to
YY4, and the mobile phone rings.
Rosenberg & Kyzivat Expires August 16, 2004 [Page 28]
Internet-Draft Caller Preferences Uses February 2004
3.19 The Number you Have Called, Take Two
3.19.1 Desired Behavior
This use case is nearly identical to that of Section 3.18. However,
this time, the caller wishes to contact the personal phone of Y. They
don't feel strongly about it, and will accept other devices.
3.19.2 Solution
The INVITE generated by the caller in this case will look like:
INVITE sip:Y@example.com SIP/2.0
Accept-Contact: *;class="personal"
This reaches the example.com proxy. Once more, the first registration
(which forwards to the address-of-record for YY) is unaffected by the
caller preferences computation. The other contact, for the automata,
is a match, but its score is zero. Its caller preference Qa equals
zero. The other contact is added back in with a Qa of 1.0. The
contacts are sorted based on q-value, resulting in YY (q=1.0)
followed by machine (q=0.5). These are broken into equivalence
classes. There are two classes, one for each contact. As a result,
the caller's preferences have no impact on the ordering, and the call
is routed to YY.
When processing the request for YY@example.com, all four contacts
match. However, the score for all of them is zero (none are the
personal phone). As such, the contacts are ordered based on q-value.
Each contact has a different q-value, so no reordering based on
caller preference is possible (not that the caller preference would
cause a reordering - all contacts have a Qa of 0.0). Thus, the
highest q-value contact is tried, which is the executive assistant.
3.20 Forwarding to a Colleague
3.20.1 Desired Behavior
Alice wants to forward her phone to Bob, but doesn't want folks
calling her to get Bob's voicemail if he doesn't answer. She wants
her callers to get her voicemail.
3.20.2 Solution
Alice would create three registrations. The first, Y1, represents
Alice's phone. The second is Bob's AOR. The third is a voicemail
server. The three contacts have decreasing q-values. The registration
Rosenberg & Kyzivat Expires August 16, 2004 [Page 29]
Internet-Draft Caller Preferences Uses February 2004
for Bob's AOR contains an embedded Reject-Contact header field, which
rejects message servers.
REGISTER sip:example.com
To: <sip:alice@example.com>
Contact: <sip:Y1@192.0.2.150>;q=1.0
REGISTER sip:example.com
To: <sip:alice@example.com>
Contact: <sip:bob@example.com?Reject-Contact=*;msgserver>;q=0.3
REGISTER sip:example.com
To: <sip:alice@example.com>
Contact: <sip:alice-drop@msgcenter.example.com>
;msgserver;
;automata
;attendant
;q=0.1
Meanwhile, Bob is registered as follows:
REGISTER sip:example.com
To: <sip:bob@example.com>
Contact: <sip:bob3@192.0.2.212>;q=0.8
REGISTER sip:example.com
To: <sip:bob@example.com>
Contact: <sip:bob-drop@msgcenter.example.com>
;msgserver
;automata
;attendant
;q=0.2
Carol calls Alice, and doesn't include any caller preference
parameters. As such, the example.com proxy constructs an implicit
preference for INVITE. This preference matches all three registered
contacts, with a score of zero. Because each contact has a different
q-value, there is no reordering of contacts. So, the proxy tries the
highest q-value Contact, Alice's desk phone (Y1). The proxy cancels
after a few seconds (no answer). The proxy then tries the next
Contact, which is Bob's AOR. When constructing the request for this
Contact, the proxy includes the embedded Reject-Contact header field
Rosenberg & Kyzivat Expires August 16, 2004 [Page 30]
Internet-Draft Caller Preferences Uses February 2004
in the INVITE. This INVITE undergoes caller preferences processing
based on Bob's registered Contacts.
Bob has two registered Contacts. The second is a message server, and
it matches the Reject-Contact in the INVITE. Thus, this contact is
discarded. The other remaining Contact, Bob's phone, is tried. Bob is
not around, and so his phone rings for a while. Upon timeout, the
proxy determines it is unable to reach Bob's AOR. So, the proxy
handling Alice tries the final remaining contact, which is Alice's
message server.
Rosenberg & Kyzivat Expires August 16, 2004 [Page 31]
Internet-Draft Caller Preferences Uses February 2004
4. Capability Use Cases
The callee capabilities spec [3] allows the Contact header field in
OPTIONS responses and dialog initiating messages to contain
capabilities of the UA. These capabilities can be very useful for
developing new applications. In the subsections below, several usages
are outlined.
4.1 Web Redirect
A caller sends an INVITE to the called party. However, the called
party is not present. The proxy server representing the called party
would like to redirect the caller to a web page, where they can find
out more information on how to reach the called party. However, the
proxy needs to know whether or not the caller supports redirects to
web pages. If it doesn't, the proxy would connect the user to an IVR,
which would execute an answering machine application.
The proxy could make such a determination if the caller included the
"schemes" feature tag in the Contact header field of its INVITE:
INVITE sip:callee@example.com SIP/2.0
Contact: sip:host22.example.com;schemes="http,sip,sips,tel"
This tells the proxy that the UAC can be redirected to an http URI.
The INVITE from a normal "black phone" which lacked this capability
would look like:
INVITE sip:callee@example.com SIP/2.0
Contact: sip:host22.example.com;schemes="sip,sips,tel"
which indicates that it needs to be connected to the IVR.
4.2 Voicemail Icon
On the circuit network, when a user makes a call, and an answering
machine picks up, the caller usually requires several seconds to make
the determination that they are speaking to an answering machine. It
would be helpful if a phone could display an icon immediately on call
completion that indicated that an answering machine was reached.
This indication can be provided by the "msgserver" feature parameter.
When the answering machine picks up, its 200 OK looks like, in part:
SIP/2.0 200 OK
Rosenberg & Kyzivat Expires August 16, 2004 [Page 32]
Internet-Draft Caller Preferences Uses February 2004
Contact: sip:server33.example.com;msgserver;automata;attendant
This tells the caller that its an answering machine.
Rosenberg & Kyzivat Expires August 16, 2004 [Page 33]
Internet-Draft Caller Preferences Uses February 2004
5. Usage of the Feature Tags
The caller preferences extension briefly enumerates a list of media
feature tags which can be registered by a device, and included in the
Accept-Contact and Reject-Contact header fields in a request. Proper
operation of caller preferences depends strongly on consistent
interpretation of these feature tags by the caller and the callee. In
this section, we provide some guidelines on the usage of these
feature tags.
Generally speaking, the more information a device provides when it
registers, the more effective the caller preferences extension is.
This is why the callee capabilities extension recommends that a
device register as much information as it can. This point cannot be
understated.
OPEN ISSUE: Should we advise devices to register things they can't
do? As an example, if a phone doesn't support video, it would
include a "video=FALSE" feature parameter in its registration to
indicate that. This provides more information, and would improve
the operation of caller preferences, but can seriously bloat
registrations. It also seems odd to have to say what you can't do.
The subsections below show example registrations from typical
devices.
5.1 Traditional Cell Phone
A VoIP cell phone capable of making voice calls would generate a
registration that looks like, in part:
REGISTER sip:example.com SIP/2.0
To: sip:user@example.com
Contact: sip:cell-phone@example.com
;audio
;class="business"
;duplex="full"
;sip-extensions="100rel,path"
;mobility="mobile"
;methods="INVITE,BYE,OPTIONS,CANCEL,ACK"
;schemes="sip,sips,tel"
;uri-user="<cell-phone>"
;uri-domain="example.com"
Rosenberg & Kyzivat Expires August 16, 2004 [Page 34]
Internet-Draft Caller Preferences Uses February 2004
5.2 Traditional Work Phone
A traditional landline IP PBX phone would generate a registration
that looks like:
REGISTER sip:example.com SIP/2.0
To: sip:user@example.com
Contact: sip:ippbx-phone@example.com
;audio
;class="business"
;duplex="full"
;events="dialog"
;sip-extensions="100rel,privacy"
;mobility="fixed"
;methods="INVITE,BYE,OPTIONS,CANCEL,ACK,SUBSCRIBE"
;schemes="sip,sips,tel"
;uri-user="<ippbx-phone>"
;uri-domain="example.com"
This device also supports the dialog event package and several SIP
extensiosn that would be typical in an IP PBX phone.
5.3 PC Messenging Application
A PC messenger client, capable of just doing presence and IM (no
voice) would generate a registration that looks like:
REGISTER sip:example.com SIP/2.0
To: sip:user@example.com
Contact: sip:pc-msgr@example.com
;class="personal"
;mobility="fixed"
;methods="OPTIONS,MESSAGE,NOTIFY"
;schemes="sip,sips,im,pres"
;uri-user="<pc-msgr>"
;uri-domain="example.com"
5.4 Standalone Videophone
A standalone IP videophone, capable of audio and video would generate
a registration that looks like, in part
Rosenberg & Kyzivat Expires August 16, 2004 [Page 35]
Internet-Draft Caller Preferences Uses February 2004
REGISTER sip:example.com SIP/2.0
To: sip:user@example.com
Contact: sip:vp@example.com
;audio
;video
;class="business"
;duplex="full"
;mobility="fixed"
;methods="INVITE,BYE,OPTIONS,CANCEL,ACK"
;schemes="sip,sips,tel"
;uri-user="<vp>"
;uri-domain="example.com"
Rosenberg & Kyzivat Expires August 16, 2004 [Page 36]
Internet-Draft Caller Preferences Uses February 2004
6. Security Considerations
There are no security considerations associated with this
specification.
Rosenberg & Kyzivat Expires August 16, 2004 [Page 37]
Internet-Draft Caller Preferences Uses February 2004
7. IANA Considerations
There are no IANA considerations associated with this specification.
Rosenberg & Kyzivat Expires August 16, 2004 [Page 38]
Internet-Draft Caller Preferences Uses February 2004
8. Acknowledgements
The authors would like to thank Rohan Mahy for his input in this
specification.
Rosenberg & Kyzivat Expires August 16, 2004 [Page 39]
Internet-Draft Caller Preferences Uses February 2004
9. TODO
o Add a section showing an example implementation of the matching
algorithm in caller preferences [[OPEN ISSUE: Do we want this?]].
o Provide additional explanations in each routing use case on why
require and/or explicit tags were used.
o Show examples using the message server, automata, and attendant
tags.
Rosenberg & Kyzivat Expires August 16, 2004 [Page 40]
Internet-Draft Caller Preferences Uses February 2004
Informative References
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[2] Rosenberg, J., Schulzrinne, H. and P. Kyzivat, "Caller
Preferences for the Session Initiation Protocol (SIP)",
draft-ietf-sip-callerprefs-10 (work in progress), October 2003.
[3] Rosenberg, J., "Indicating User Agent Capabilities in the
Session Initiation Protocol (SIP)",
draft-ietf-sip-callee-caps-03 (work in progress), January 2004.
[4] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J. and B.
Rosen, "Change Process for the Session Initiation Protocol
(SIP)", BCP 67, RFC 3427, December 2002.
[5] Lennox, J. and H. Schulzrinne, "Call Processing Language
Framework and Requirements", RFC 2824, May 2000.
[6] Klyne, G., "A Syntax for Describing Media Feature Sets", RFC
2533, March 1999.
[7] Rosenberg, J. and H. Schulzrinne, "An INVITE Inititiated Dialog
Event Package for the Session Initiation Protocol (SIP)",
draft-ietf-sipping-dialog-package-03 (work in progress),
October 2003.
[8] Rosenberg, J., "A Presence Event Package for the Session
Initiation Protocol (SIP)", draft-ietf-simple-presence-10 (work
in progress), January 2003.
[9] Rosenberg, J., Peterson, J., Schulzrinne, H. and G. Camarillo,
"Best Current Practices for Third Party Call Control in the
Session Initiation Protocol", draft-ietf-sipping-3pcc-06 (work
in progress), January 2004.
[10] Campbell, B., "Instant Message Sessions in SIMPLE",
draft-ietf-simple-message-sessions-03 (work in progress),
January 2004.
Rosenberg & Kyzivat Expires August 16, 2004 [Page 41]
Internet-Draft Caller Preferences Uses February 2004
Authors' Addresses
Jonathan Rosenberg
dynamicsoft
600 Lanidex Plaza
Parsippany, NJ 07054
US
Phone: +1 973 952-5000
EMail: jdrosen@dynamicsoft.com
URI: http://www.jdrosen.net
Paul Kyzivat
Cisco Systems
Mail Stop LWL3/12/2
900 Chelmsford St.
Lowell, MA 01851
US
EMail: pkzivat@cisco.com
Rosenberg & Kyzivat Expires August 16, 2004 [Page 42]
Internet-Draft Caller Preferences Uses February 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2004). 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.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
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
Rosenberg & Kyzivat Expires August 16, 2004 [Page 43]
Internet-Draft Caller Preferences Uses February 2004
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Rosenberg & Kyzivat Expires August 16, 2004 [Page 44]
