[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

Internet Engineering Task Force                               SIPPING WG
Internet Draft                                              J. Rosenberg
                                                             dynamicsoft
                                                              P. Kyzivat
                                                                   Cisco
draft-rosenberg-sipping-callerprefs-usecases-00.txt
February 24, 2003
Expires: August 2003


   Use Cases for Session Initiation Protocol (SIP) Caller Preferences

STATUS OF THIS MEMO

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress".

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   To view the list Internet-Draft Shadow Directories, see
   http://www.ietf.org/shadow.html.


Abstract

   This document describes a set of use cases for the SIP Caller
   Preferences and Callee Capabilities extension. Each use case is
   presented as a desired routing decision, followed by the actual
   headers and processing logic which would result in that decision.











J. Rosenberg et. al.                                          [Page 1]

Internet Draft         Caller Preferences Usages        January 30, 2003





















































J. Rosenberg et. al.                                          [Page 2]

Internet Draft         Caller Preferences Usages        January 30, 2003


1 Introduction

   The SIP extension for Caller Preferences and Callee Capabilities [1]
   describes mechanisms that allow a UA 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.

   The purpose of this document is to demonstrate the ability of these
   basic primitives to meet the needs of many different routing
   problems. To do that, it presents a set of use cases. Each use case
   is described as a situation along with a desired routing goal. Then,
   it demonstrates how the various caller preferences headers and the
   proxy processing logic would result in the appropriate decision being
   made.

   Demonstrating the ability of caller preferences to meet the needs of
   these routing problems serves two higher level goals. The first is to
   validate that the caller preferences specification is complete, and
   capable of solving real requirements. Since the caller preferences
   specification pre-dates the SIP change process [2], no requirements
   work was ever done for this extension. 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
   specification in later versions.

   The second goal of the usage cases is to motivate support for the
   draft. The caller preferences specification has received scant
   attention from the working group beyond the authors of this document.
   This is likely because people are not aware of the scope of problems
   which this extension can solve.

2 Routing of INVITE and MESSAGE to different UA

2.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.

2.2 Solution




J. Rosenberg et. al.                                          [Page 4]

Internet Draft         Caller Preferences Usages        January 30, 2003


   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"



   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"



   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 [1], the proxy will construct an implicit
   require-tagged Accept-Contact preference that looks like:


   (& (methods="INVITE"))



   Applying the matching algorithm of RFC 2533 [3] to this feature set
   and those registered by Y1 and Y2, the feature set of Y1 alone
   matches. Thus, 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 Single Contact Not Matching Implicit Preferences

3.1 Desired Behavior

   AOR Y has a single contact Y1. Its a phone, and therefore supports



J. Rosenberg et. al.                                          [Page 5]

Internet Draft         Caller Preferences Usages        January 30, 2003


   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 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"



   X sends a MESSAGE request. This results in an implicit require-tagged
   Accept-Contact preference:


   (& (methods="MESSAGE"))



   Since Y1 doesn't match, it is discarded. However, according to the
   specifications, if there are no matching targets, the preference
   operation is re-run without implicit preferences. Since there were no
   explict preferences, the request is routed without the caller
   preferences processing at all, and is sent to the single contact Y1
   as desired.

4 Package-Based Routing

4.1 Desired Behavior

   AOR Y has a number of contacts, Y1, Y2, ..., Yn that can each support
   normal calls - INVITE, ACK, BYE, etc., and that can also support
   SUBSCRIBE for the "dialog" event package [4]. Y also has another
   contact YP that is a presence agent [5] - 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.

4.2 Solution

   Y1..Yn will generate REGISTER requests which look like, in part:




J. Rosenberg et. al.                                          [Page 6]

Internet Draft         Caller Preferences Usages        January 30, 2003


   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"



   and Yp will generate a REGISTER request which 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"



   A SUBSCRIBE request for presence will arrive at the proxy for
   example.com. 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. Therefore,
   Y1..Yn are eliminated, and the request is properly routed to the PA.
   Note that, had Y1..Yn not registered the event packages they support,
   the proxy would have preferentially routed the request to YP, and if
   that had failed, then forked to Y1..Yn. That is because of the
   greater score associated with YP.

   INVITE requests result in an implicit require-tagged Accept-Contact
   preference:


   (& (methods="INVITE"))



   The implicit Accept-Contact feature set matches Y1..Yn, but not Yp.
   Thus, Yp is discarded and the call is delivered to Y1..Yn only.

   A SUBSCRIBE for the dialog event package will result in an implicit
   require-tagged Accept-Contact preference:





J. Rosenberg et. al.                                          [Page 7]

Internet Draft         Caller Preferences Usages        January 30, 2003


   (& (methods="SUBSCRIBE") (events="dialog"))



   This only matches Y1..Yn, so Yp is discarded, and the request is
   routed to the remaining contacts.

5 Audio/Video vs. Audio Only

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 which is preferred for
   normal audio 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.

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>;audio;q=1.0



   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>;audio;video;q=0.2



   Note the different q-values, allowing Y2 to be selected as a device
   of "last resort". Of course, both Y1 and Y2 need to be configured to
   express these two q-values.

   To ensure that the call is preferentially routed to a device that
   supports video, the caller X sends an INVITE that looks like, in
   part:





J. Rosenberg et. al.                                          [Page 8]

Internet Draft         Caller Preferences Usages        January 30, 2003


   INVITE sip:Y@example.com SIP/2.0
   Accept-Contact: *;video;require



   The proxy will convert this to a feature predicate and also compute
   an implicit preference to support INVITE. Since neither contact
   indicated anything about methods, the implicit preference matches
   both and has no effect on the relative q-values.

   The explicit feature set from the Accept-Contact matches Y2 and Y1.
   However, the score for Y2 is 1, and 0 for Y1. The result is that the
   audio/video phone (Y2) will receive the call first.

6 Audio/Video vs. Audio Only: A/V UA Fails

6.1 Desired Behavior

   This case is identical to that of Section 5. However, for some reason
   the Audio/Video UA is not available (for example, its in use or
   offline). The desired behavior is for an audio-only call.

6.2 Solution

   This will happen. Since Y1 didnt say anything about video, it still
   matched the caller preference, just not explicitly. The caller
   preference did not include the explicit tag, so Y1 remains as a
   viable contact, but with a lower q value than Y2. Once the request to
   Y2 fails, the proy will try Y1.

7 Forcing Audio/Video

7.1 Desired Behavior

   This case is similar to that of Section 5. However, X requires an
   audio/video call, and would like the call to fail if this is not
   possible rather than succeeding with only audio.

7.2 Solution

   The solution is similar to that of Section 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



J. Rosenberg et. al.                                          [Page 9]

Internet Draft         Caller Preferences Usages        January 30, 2003


   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.

8 Third Party Call Control - Forcing Media

8.1 Desired Behavior

   Z is a third party call control controller [6] trying to establish an
   audio/video call from X to Y. (Both X and Y are configured the way Y
   is in 5) Z needs to send a offerless invite to X and use the
   resulting offer to send an invite to Y. When sending the offerless
   invite to X it must ensure that an audio/video contact (X2) is chosen
   over an audio only contact (X1).

8.2 Solution

   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 the callee's preference
   for it. Thus, the call is routed to X2.

9 Maximizing Media Overlaps

9.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 [7].
   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.

9.2 Solution

   Y1 will generate a registration which looks like, in part:





J. Rosenberg et. al.                                         [Page 10]

Internet Draft         Caller Preferences Usages        January 30, 2003


   REGISTER sip:example.com SIP/2.0
   To: sip:Y@example.com
   Contact: <sip:Y1@phone.example.com>;audio



   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>;audio;message



   The solution requires the caller to support caller preferences. They
   would include, in their INVITE, an Accept-Contact that lists all the
   media types they support. In this case:


   INVITE sip:Y@example.com SIP/2.0
   Accept-Contact: *;audio;video;message



   This would prefer a UA that supports all of the same types. Both Y1
   and Y2 match. However, Y1 matches with a score of .33, and Y2 matches
   with a score of .66. This would result in the call being routed to Y2
   first.

10 Multilingual Lines

10.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.

10.2 Solution

   A user at phone Y1 that speaks English only would generate a REGISTER
   which looks like, in part:



J. Rosenberg et. al.                                         [Page 11]

Internet Draft         Caller Preferences Usages        January 30, 2003


   REGISTER sip:example.com SIP/2.0
   To: sip:Y@example.com
   Contact: sip:Y1@pc.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@pc.example.com;languages="es"
   Contact: <sip:Y2-en@pc.example.com>;languages="en";q=0.2



   Effectively, Y2 has registered two contacts. Both of them route to
   the same device (pc.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@pc.example.com;languages="es,en"



   Notice that only a single contact is needed because the same q-value
   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"



   When a caller makes a call, and indicates that their language is
   English only, the result is an Accept-Contact feature set that looks
   like:



J. Rosenberg et. al.                                         [Page 12]

Internet Draft         Caller Preferences Usages        January 30, 2003


   (& (languages="en"))



   This matches all Y1 phones, the second contact registered by Y2
   phones, and Y3 phones. However, the second contact registered by Y2
   phones has a lower q-value, 0.2, and therefore, will be chosen with
   lower preference than Y1 and Y3. The call will be routed to Y1 or Y3
   UAs first, as desired. If neither of those pick up, the call is
   routed to the English-language contact of Y2, which represents a user
   with moderate English skills. In fact, the user will know to answer
   with "Hello" instead of "Hola" because the request-URI will contain
   Y2-en instead of just Y2. A nice bonus feature.

   When a caller makes a call, and indicates that their language is
   Spanish only, the result is an Accept-Contact feature set that looks
   like:


   (& (languages="es"))



   This matches the first contact of Y2 phones, and Y3 phones, all with
   equal preference. The result is that a call is routed to a user that
   speaks Spanish.

11 I Hate Voicemail!

11.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.

11.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



   and the voicemail server would register with a Contact that looks
   like, in part:



J. Rosenberg et. al.                                         [Page 13]

Internet Draft         Caller Preferences Usages        January 30, 2003


   REGISTER sip:example.com SIP/2.0
   To: sip:Y@example.com
   Contact: sip:Y2@pc.example.com;msgserver;automata;attendant;audio



   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.

12 I Hate People!

12.1 Desired Behavior

   The situation is similar to Section 11, except the caller wishes to
   only leave a message, not actually speak to the person. Therefore,
   they 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.

13 Prefer Voicemail




J. Rosenberg et. al.                                         [Page 14]

Internet Draft         Caller Preferences Usages        January 30, 2003


13.1 Desired Behavior

   The situation is similar to that of Section 11. However, the caller
   prefers to leave a message. If voicemail is not available, they are
   willing to talk to a person.

13.2 Solution

   To accomplish this behavior, the caller would generate an INVITE that
   looks like, in part:


   INVITE sip:Y@example.com SIP/2.0
   Accept-Contact: *;voicemail



   This matches Y1 with a score of zero and Y2 with a score of 1.
   Therefore, Y2 (the voicemail server) is tried first, and if that
   fails, the lower priority Y1 (the phone) is tried next.

14 Routing to an Executive

14.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,
   to Y3. If Y3 doesn't answer then Y1 should ring.

14.2 Solution

   This is primarily a called party feature, and is best accomplished
   with a CPL script [8]. 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





J. Rosenberg et. al.                                         [Page 15]

Internet Draft         Caller Preferences Usages        January 30, 2003


   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
   preferences, the call is first routed to Y2, then Y3, then Y1, all as
   a result of the proper setting of the q-values.

15 Speak to the Executive

15.1 Desired Behavior

   This case is similar to that of Section 14, 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).

15.2 Solution

   X's INVITE would look like, in part:


   INVITE sip:Y@example.com SIP/2.0
   Reject-Contact: *;attendant
   Reject-Contact: *;automata





J. Rosenberg et. al.                                         [Page 16]

Internet Draft         Caller Preferences Usages        January 30, 2003


   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.

16 Mobile Phone Only

16.1 Desired Behavior

   The situation is similar to that in Section 14. 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.

16.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 three 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.

17 Simultaneous Languages



J. Rosenberg et. al.                                         [Page 17]

Internet Draft         Caller Preferences Usages        January 30, 2003


17.1 Desired Behavior

   AOR Y is as in Section 10. 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.

17.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:


   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.

18 UA Routing

18.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.

18.2 Solution

   There is currently no generally workable solution to this problem.
   The best solution that exists does make use of caller preferences.



J. Rosenberg et. al.                                         [Page 18]

Internet Draft         Caller Preferences Usages        January 30, 2003


   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: sip:Y1@host.example.com;require



   or, equivalently:


   INVITE sip:Y@example.com SIP/2.0
   Accept-Contact: *;uri-user="<Y1>";uri-domain="host.example.com";require



   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"



   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.




J. Rosenberg et. al.                                         [Page 19]

Internet Draft         Caller Preferences Usages        January 30, 2003


19 The Number you Have Called..

19.1 Desired Behavior

   Consider once more the case of the executive, where the caller wishes
   to reach only their mobile phone (Section 16). 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 16. The call
   should connect to the mobile.

19.2 Solution

   There would be four registrations against YY:

   YY1 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 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 would generate a REGISTER that looks like, in part:


   REGISTER sip:example.com SIP/2.0
   To: sip:YY@example.com
   Contact: sip:YY3@pc3.example.com;attendant;automata;q=0.5



   YY4 would generate a REGISTER that looks like, in part:




J. Rosenberg et. al.                                         [Page 20]

Internet Draft         Caller Preferences Usages        January 30, 2003


   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). Therefore, the caller preferences are applied to it alone.
   The feature sets match, but not explicitly. Since the require and
   explicit tags are present, the contact for the automata is dropped.
   The proxy therefore sends the call to sip:Y@example.com, which
   remains because it was unfiltered by the caller preferences
   processing. There, there are four registrations, all of which are
   associated with feature parameters. The caller preferences are
   applied. Only YY4 matches explicitly, however. As such, the call is
   forwarded there, and the mobile phone rings.

20 The Number you Have Called, Take Two




J. Rosenberg et. al.                                         [Page 21]

Internet Draft         Caller Preferences Usages        January 30, 2003


20.1 Desired Behavior

   This use case is nearly identical to that of Section 19. 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.

20.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. Therefore, the first contact is
   preferred. This causes the call to be routed to sip:YY@example.com.
   There, all four contacts match, but none explicitly. Indeed, all four
   have a score of zero against the explicit preference. However, they
   each match the implicit preference for the INVITE method. The result
   is that the the q-values are unaffected, and the call is routed to
   YY2 first.

21 Security Considerations

   There are no security considerations associated with this
   specification.

22 IANA Considerations

   There are no IANA considerations associated with this specification.

23 Author's Addresses


   Jonathan Rosenberg
   dynamicsoft
   72 Eagle Rock Avenue
   First Floor
   East Hanover, NJ 07936
   email: jdrosen@dynamicsoft.com

   Paul Kyzivat
   Cisco Systems



J. Rosenberg et. al.                                         [Page 22]

Internet Draft         Caller Preferences Usages        January 30, 2003


   email: pkyzivat@cisco.com



24 Normative References

25 Informative References

   [1] H. Schulzrinne and J. Rosenberg, "Session initiation protocol
   (SIP) caller preferences and callee capabilities," internet draft,
   Internet Engineering Task Force, Nov. 2002.  Work in progress.

   [2] A. Mankin, S. Bradner, R. Mahy, D. Willis, J. Ott, and B. Rosen,
   "Change process for the session initiation protocol (SIP)," RFC 3427,
   Internet Engineering Task Force, Dec. 2002.

   [3] G. Klyne, "A syntax for describing media feature sets," RFC 2533,
   Internet Engineering Task Force, Mar. 1999.

   [4] J. Rosenberg and H. Schulzrinne, "A session initiation protocol
   (SIP) event package for dialog state," internet draft, Internet
   Engineering Task Force, June 2002.  Work in progress.

   [5] J. Rosenberg, "A presence event package for the session
   initiation protocol (SIP)," internet draft, Internet Engineering Task
   Force, Dec. 2002.  Work in progress.

   [6] J. Rosenberg, J. Peterson, H. Schulzrinne, and G. Camarillo,
   "Best current practices for third party call control in the session
   initiation protocol," internet draft, Internet Engineering Task
   Force, June 2002.  Work in progress.

   [7] B. Campbell and J. Rosenberg, "Instant message sessions in
   SIMPLE," internet draft, Internet Engineering Task Force, Oct. 2002.
   Work in progress.

   [8] J. Lennox and H. Schulzrinne, "Call processing language framework
   and requirements," RFC 2824, Internet Engineering Task Force, May
   2000.


   Full Copyright Statement

   Copyright (c) The Internet Society (2003). 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



J. Rosenberg et. al.                                         [Page 23]

Internet Draft         Caller Preferences Usages        January 30, 2003


   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 assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.































J. Rosenberg et. al.                                         [Page 24]

                           Table of Contents



   1          Introduction ........................................    4
   2          Routing of INVITE and MESSAGE to different UA .......    4
   2.1        Desired Behavior ....................................    4
   2.2        Solution ............................................    4
   3          Single Contact Not Matching Implicit Preferences ....    5
   3.1        Desired Behavior ....................................    5
   3.2        Solution ............................................    6
   4          Package-Based Routing ...............................    6
   4.1        Desired Behavior ....................................    6
   4.2        Solution ............................................    6
   5          Audio/Video vs. Audio Only ..........................    8
   5.1        Desired Behavior ....................................    8
   5.2        Solution ............................................    8
   6          Audio/Video vs. Audio Only: A/V UA Fails ............    9
   6.1        Desired Behavior ....................................    9
   6.2        Solution ............................................    9
   7          Forcing Audio/Video .................................    9
   7.1        Desired Behavior ....................................    9
   7.2        Solution ............................................    9
   8          Third Party Call Control - Forcing Media ............   10
   8.1        Desired Behavior ....................................   10
   8.2        Solution ............................................   10
   9          Maximizing Media Overlaps ...........................   10
   9.1        Desired Behavior ....................................   10
   9.2        Solution ............................................   10
   10         Multilingual Lines ..................................   11
   10.1       Desired Behavior ....................................   11
   10.2       Solution ............................................   11
   11         I Hate Voicemail!  ..................................   13
   11.1       Desired Behavior ....................................   13
   11.2       Solution ............................................   13
   12         I Hate People!  .....................................   14
   12.1       Desired Behavior ....................................   14
   13         Prefer Voicemail ....................................   14
   13.1       Desired Behavior ....................................   15
   13.2       Solution ............................................   15
   14         Routing to an Executive .............................   15
   14.1       Desired Behavior ....................................   15
   14.2       Solution ............................................   15
   15         Speak to the Executive ..............................   16
   15.1       Desired Behavior ....................................   16



J. Rosenberg et. al.                                          [Page 1]

Internet Draft         Caller Preferences Usages        January 30, 2003


   15.2       Solution ............................................   16
   16         Mobile Phone Only ...................................   17
   16.1       Desired Behavior ....................................   17
   16.2       Solution ............................................   17
   17         Simultaneous Languages ..............................   17
   17.1       Desired Behavior ....................................   18
   17.2       Solution ............................................   18
   18         UA Routing ..........................................   18
   18.1       Desired Behavior ....................................   18
   18.2       Solution ............................................   18
   19         The Number you Have Called..  .......................   20
   19.1       Desired Behavior ....................................   20
   19.2       Solution ............................................   20
   20         The Number you Have Called, Take Two ................   21
   20.1       Desired Behavior ....................................   22
   20.2       Solution ............................................   22
   21         Security Considerations .............................   22
   22         IANA Considerations .................................   22
   23         Author's Addresses ..................................   22
   24         Normative References ................................   23
   25         Informative References ..............................   23






























J. Rosenberg et. al.                                          [Page 2]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/