From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc4596.txt | 2243 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 2243 insertions(+) create mode 100644 doc/rfc/rfc4596.txt (limited to 'doc/rfc/rfc4596.txt') diff --git a/doc/rfc/rfc4596.txt b/doc/rfc/rfc4596.txt new file mode 100644 index 0000000..542870f --- /dev/null +++ b/doc/rfc/rfc4596.txt @@ -0,0 +1,2243 @@ + + + + + + +Network Working Group J. Rosenberg +Request for Comments: 4596 P. Kyzivat +Category: Informational Cisco Systems + July 2006 + + + Guidelines for Usage of the Session Initiation Protocol (SIP) + Caller Preferences Extension + +Status of This Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2006). + +Abstract + + This document contains guidelines for usage of the Caller Preferences + Extension to the Session Initiation Protocol (SIP). It demonstrates + the benefits of caller preferences with specific example + applications, provides use cases to show proper operation, provides + guidance on the applicability of the registered feature tags, and + describes a straightforward implementation of the preference and + capability matching algorithm specified in Section 7.2 of RFC 3841. + + + + + + + + + + + + + + + + + + + + + + + +Rosenberg & Kyzivat Informational [Page 1] + +RFC 4596 Caller Preferences Uses July 2006 + + +Table of Contents + + 1. Introduction ....................................................4 + 2. Motivations for Caller Preferences ..............................5 + 2.1. One-Number .................................................7 + 2.2. Direct-to-Voicemail ........................................7 + 3. Caller Preference Use Cases .....................................8 + 3.1. Routing of INVITE and MESSAGE to Different UA ..............8 + 3.1.1. Desired Behavior ....................................8 + 3.1.2. Solution ............................................9 + 3.2. Single Contact Not Matching Implicit Preferences ..........10 + 3.2.1. Desired Behavior ...................................10 + 3.2.2. Solution ...........................................10 + 3.3. Package-Based Routing .....................................11 + 3.3.1. Desired Behavior ...................................11 + 3.3.2. Solution ...........................................11 + 3.4. Package Routing II ........................................12 + 3.4.1. Desired Behavior ...................................12 + 3.4.2. Solution ...........................................13 + 3.5. Audio/Video vs. Audio Only ................................13 + 3.5.1. Desired Behavior ...................................13 + 3.5.2. Solution ...........................................14 + 3.6. Forcing Audio/Video .......................................15 + 3.6.1. Desired Behavior ...................................15 + 3.6.2. Solution ...........................................15 + 3.7. Third-Party Call Control: Forcing Media ...................16 + 3.7.1. Desired Behavior ...................................16 + 3.7.2. Solution ...........................................16 + 3.8. Maximizing Media Overlaps .................................17 + 3.8.1. Desired Behavior ...................................17 + 3.8.2. Solution ...........................................17 + 3.9. Multilingual Lines ........................................18 + 3.9.1. Desired Behavior ...................................18 + 3.9.2. Solution ...........................................19 + 3.10. I Hate Voicemail! ........................................20 + 3.10.1. Desired Behavior ..................................20 + 3.10.2. Solution ..........................................20 + 3.11. I Hate People! ...........................................21 + 3.11.1. Desired Behavior ..................................21 + 3.11.2. Solution ..........................................21 + 3.12. Prefer Voicemail .........................................22 + 3.12.1. Desired Behavior ..................................22 + 3.12.2. Solution ..........................................22 + 3.13. Routing to an Executive ..................................22 + 3.13.1. Desired Behavior ..................................22 + 3.13.2. Solution ..........................................22 + + + + + +Rosenberg & Kyzivat Informational [Page 2] + +RFC 4596 Caller Preferences Uses July 2006 + + + 3.14. Speak to the Executive ...................................23 + 3.14.1. Desired Behavior ..................................23 + 3.14.2. Solution ..........................................24 + 3.15. Mobile Phone Only ........................................24 + 3.15.1. Desired Behavior ..................................24 + 3.15.2. Solution ..........................................24 + 3.16. Simultaneous Languages ...................................25 + 3.16.1. Desired Behavior ..................................25 + 3.16.2. Solution ..........................................25 + 3.17. The Number You Have Called... ............................26 + 3.17.1. Desired Behavior ..................................26 + 3.17.2. Solution ..........................................26 + 3.18. The Number You Have Called, Take Two .....................27 + 3.18.1. Desired Behavior ..................................27 + 3.18.2. Solution ..........................................27 + 3.19. Forwarding to a Colleague ................................28 + 3.19.1. Desired Behavior ..................................28 + 3.19.2. Solution ..........................................28 + 4. Capability Use Cases ...........................................30 + 4.1. Web Redirect ..............................................30 + 4.2. Voicemail Icon ............................................30 + 5. Usage of the Feature Tags ......................................31 + 5.1. Traditional Cell Phone ....................................31 + 5.2. Traditional Work Phone ....................................32 + 5.3. PC Messaging Application ..................................32 + 5.4. Standalone Videophone .....................................33 + 6. Example of Implementation of Preference and Capability + Matching .......................................................33 + 6.1. Extracting a Feature Set from a Header ....................34 + 6.2. Extracting Values from a Feature Parameter ................35 + 6.3. Comparing Two Value-Ranges ................................36 + 6.4. Feature Set to Feature Set Matching .......................36 + 6.5. Selecting and Ordering Contacts Based on Caller + Preferences ...............................................37 + 6.5.1. Reject-Contact Processing ..........................37 + 6.5.2. Accept-Contact Processing ..........................37 + 7. Security Considerations ........................................38 + 8. Acknowledgements ...............................................38 + 9. Informative References .........................................38 + + + + + + + + + + + + +Rosenberg & Kyzivat Informational [Page 3] + +RFC 4596 Caller Preferences Uses July 2006 + + +1. Introduction + + The Session Initiation Protocol (SIP) [1] extension for Callee + Capabilities [2] describes mechanisms that allow a UA (User Agent) to + register its capabilities in a REGISTER request. A caller can + express preferences, either explicitly or implicitly, about how that + request is to be handled. This is accomplished with the Accept- + Contact and Reject-Contact header fields described in Caller + Preferences for the Session Initiation Protocol[3]. + + The caller preferences extension can serve as a useful tool for + supporting many applications. However, its generality makes it + difficult to use correctly and effectively in any one situation. To + remedy that, this document serves as a compendium of examples of the + usage of the caller preferences extension. + + NOTE: This document is intended to assist the reader in + understanding RFCs 3840 and 3841. It is not intended to serve as + a substitute for reading those documents. The examples presented + in this document cannot be fully understood without awareness of + the mechanisms defined in RFCs 3840 and 3841. + + First, Section 2 demonstrates the benefits of using caller + preferences by describing several concrete applications that are + enabled by the extension. Section 3 describes a set of detailed use + cases for expressing caller preferences. Each use case presents a + situation, describes how caller preferences can be used to handle the + requirements for the situation, and verifies that the desired + behavior occurs by showing the results of the matching operation. + These use cases validate that the caller preferences specification is + complete and capable of meeting a specific set of requirements. + Since the caller preferences specification predates the SIP change + process [4], no requirements document was ever published for it. To + some degree, this document "backfills" requirements. However, this + is not an academic exercise only, since the use cases described here + did result in changes in the caller preferences document as it + evolved. These use cases also help implementors figure out how to + use caller preferences in their own applications. + + Section 4 discusses applications for the callee capabilities + specification. Section 5 discusses the example registrations of the + feature tags described in [2]. Proper usage of the caller + preferences extension depends on proper interpretation of the + semantics of these tags. More detail is provided on the tags, and + example registrations are included that show typical usage. + + + + + + +Rosenberg & Kyzivat Informational [Page 4] + +RFC 4596 Caller Preferences Uses July 2006 + + + Section 6 outlines an implementation approach to the matching + algorithm that doesn't require RFC 2533 [6] to be implemented in all + its generality. + +2. Motivations for Caller Preferences + + At its core, SIP is a protocol that facilitates rendezvous of users. + The caller and callee need to meet up in order to exchange session + information, so that they may communicate. The rendezvous process is + complicated by the fact that a user has multiple points of attachment + to the network. A called user (callee) can have a cell phone, a PDA, + a work phone, a home phone, and one of several PC-based + communications applications. When someone calls that user, to which + of these devices is the call routed? + + Certainly, the call can be routed to all of them at the same time, a + process known as parallel forking. However, that is not always the + desired behavior. Users may prefer that their registered devices be + tried in a particular order. As an example, a user might prefer that + his cell phone ring first, and if no one answers, that his work phone + ring next. Another user might prefer that her cell phone ring first, + and then her home and work phones ring at the same time, and then, if + no one answers either of those, that the call be forwarded to + voicemail. These variations are all referred to as find-me/ + follow-me features. + + SIP supports find-me/follow-me features in many ways. The most basic + is through the SIP registration process. Each device at which a user + can be contacted registers to the network. This registration + associates the device with the canonical name of the user, called the + address-of-record (AOR), which is a SIP URI. Each registration can + include a preference value, indicating the relative preference for + receiving calls at that device, compared to other devices. When + someone makes a call to the AOR, proxies compliant to RFC 3261 will + try the registered devices in order of preference, unless + administrative policy overrides user preferences. + + Preference values in SIP registrations can only provide basic find- + me/follow-me features. To support more complex features, the Call + Processing Language (CPL) [5] has been specified. It is an XML + script that provides specific call routing instructions. Users can + upload these scripts to the network, instructing the servers how + calls should be routed. As an example, a CPL script can instruct a + proxy to route a call to the work phone during work hours (9 am - + 5 pm) and then to the cell phone after hours, unless the call is from + a family member, in which case it always goes to the cell phone. + + + + + +Rosenberg & Kyzivat Informational [Page 5] + +RFC 4596 Caller Preferences Uses July 2006 + + + It is important to note that both CPL scripts and preference values + in registrations describe operation of a service from the perspective + of the called party. That is, they describe how a call made to the + called party should be routed by the network. However, the called + party is not the only one with preferences. A caller will also have + preferences for how they want their call to be routed. As an + example, a caller will often want to reach a user on their cell + phone. In the current telephone network, this is accomplished by + requiring a user to have a separate number for each device. This + way, when a caller wishes to reach the cell phone, they dial the + number for the cell phone. This requires users to maintain lists of + potential reach numbers for a user, and then select the appropriate + one. A far better approach is for a user to maintain a single + address-of-record. When someone wishes to reach them on their cell + phone, they call the AOR, but indicate a preference for the call to + be routed to the cell phone. + + A caller may actually have a wide variety of preferences for how a + call should be routed. They may prefer to go right to voicemail. + They may prefer never to reach voicemail. The may prefer to reach + the user on a device that supports video (because a video-conference + is desired). They may wish to reach a device that has an attendant + who can answer if the user is not there. + + The SIP caller preferences extension allows a caller to express these + preferences for the way in which their calls are handled. These + preferences are expressed in terms of properties of the desired + device. These properties are name-value pairs that convey some kind + of information about a device. One example is the property + "mobility", which can have the values "mobile" or "fixed". When a + caller wishes to reach a cell phone, they include information in + their call setup request (the INVITE method) which indicates that the + call should be routed to a device that has the property "mobility" + set to "mobile". When devices register to the network, they include + their properties (also known as callee capabilities) as part of the + registration. In this way, a proxy can match the caller's + preferences against the capabilities of the various devices + registered to the user and route the call appropriately. + + While this document addresses the preferences of a caller, it does so + from the perspective of a SIP User Agent representing the caller. + Caller preferences are herein represented via syntactic elements + placed in a SIP request. This document does not attempt to address + how preferences might be conveyed by a human user to the User Agent. + Thus this document is likely to be of most value to the developer of + a User Agent. + + + + + +Rosenberg & Kyzivat Informational [Page 6] + +RFC 4596 Caller Preferences Uses July 2006 + + + The caller preferences extension can support a wide variety of call + routing applications and features. Two particularly important + examples are "one-number" and "direct-to-voicemail". + +2.1. One-Number + + In today's circuit-switched telephony networks, users have multiple + devices, and each device is associated with its own phone number. A + user will typically list all of these numbers on a business card: + cell phone, work phone, home office phone, and so on. Other users + need to store and manage all of these numbers. It is difficult to + keep these numbers complete and up-to-date. Worse, when you want to + call someone, you need to pick a number to try. Sometimes, you want + a specific device (the cell phone); and other times, you just want to + reach them wherever they are. In the latter case, a user is forced + to try each number, one at a time. This is inefficient, and + difficult to do while driving, for example. + + As an alternative, a user can have a single address. This is the one + and only address they give out to other users on their business + cards. If a caller wishes to reach that user on their cell phone, + they select that one address, and then access a pull-down menu of + device types. This menu would include home phone, work phone, and + cell phone. The caller can select cell-phone, and then the call is + placed to the cell phone. There is no need to manage or maintain + more than one number for the user -- a single number will suffice. + + If, on the other hand, the caller wishes to reach the user wherever + they are, they make a call to that one number without a selection of + a preferred device. The network will ring all devices at the same + time, and therefore reach the user as fast as possible. + + This one-number service makes use of caller preferences. To express + a preference for the cell phone, the caller's device would include a + header in the SIP INVITE request, indicating a desire to reach a + device with "mobility" equal to "mobile". + +2.2. Direct-to-Voicemail + + Frequently, a busy executive on the road wants to quickly pass a + message to a colleague by voice. As an example, a boss might want to + instruct an employee to call a specific customer and resolve a + pending issue. In such a case, the user doesn't actually want to + talk to the person; they just want to leave a voice message. Having + a phone conversation may require too much time, whereas a voice + message can be quick and to the point. The voice message can also + serve as a record of exactly what is desired, whereas a fleeting + voice conversation can be forgotten or misremembered. + + + +Rosenberg & Kyzivat Informational [Page 7] + +RFC 4596 Caller Preferences Uses July 2006 + + + In today's circuit-switched telephone networks, there is often no way + to go directly to someone's voicemail and leave a message. + Sometimes, you can dial the main number for the voicemail system, + enter in the extension of the desired party, and leave a message by + entering a specific prompt. This is time consuming, and requires the + caller to know the main voicemail number. + + Instead, an address book in a cell phone can have an option called + "leave voice message", available for each entry in the address book. + When this option is selected, a call is made directly to the + voicemail for that user, which immediately picks up and prompts for a + message. In fact, a rapid greeting is played, so that the caller can + go directly to the recording procedure. + + This saves time for the caller, making it very easy to quickly leave + recorded messages for a large number of people. + + This feature is possible using the caller preferences extension. + When the user selects the "leave voice message" option, the phone + sends a SIP INVITE request, and includes a caller preferences header + field that indicates a preference for devices whose "msgserver" + attribute has a value of "true". This will cause the proxy to route + the call directly to a registered voicemail service. Furthermore, + the voicemail server will see that the caller asked to go directly to + voicemail, and can therefore play an abbreviated greeting explicitly + designed for this case. + +3. Caller Preference Use Cases + + Each use case is described as a situation along with a desired + behavior. Then, it demonstrates how the various caller preferences + headers and the proxy processing logic would result in the + appropriate decision. + +3.1. Routing of INVITE and MESSAGE to Different UA + +3.1.1. Desired Behavior + + Address of Record (AOR) Y has two contacts, Y1 and Y2. Y1 is a phone + and supports the standard operations INVITE, ACK, OPTIONS, BYE, and + CANCEL but does not support MESSAGE, whereas Y2 is a pager and + supports only OPTIONS and MESSAGE. Caller X wants to send pages to + Y. There is a lot of traffic in the network of both calls and pages, + so there is a goal not to unnecessarily fork messages to devices that + can't support them. So, this is done by ensuring that INVITEs of Y + are delivered only to Y1, while MESSAGEs to Y are delivered only to + Y2. + + + + +Rosenberg & Kyzivat Informational [Page 8] + +RFC 4596 Caller Preferences Uses July 2006 + + +3.1.2. Solution + + Y1 will create a registration that looks like, in part: + + REGISTER sip:example.com SIP/2.0 + To: sip:Y@example.com + Contact: + ;methods="INVITE,ACK,OPTIONS,BYE,CANCEL" + ;uri-user="" + ;uri-domain="example.com" + ;audio + ;schemes="sip" + ;mobility="mobile" + + Y2 will create a registration that looks like, in part: + + REGISTER sip:example.com SIP/2.0 + To: sip:Y@example.com + Contact: + ;methods="OPTIONS,MESSAGE" + ;uri-user="" + ;uri-domain="example.com" + ;+sip.message + ;schemes="sip,im" + ;mobility="mobile" + + When a UAC (User Agent Client) sends an INVITE, it will arrive at the + proxy for example.com. There are no caller preferences in the + request. However, per Section 7.2.2 of [3], the proxy will construct + an implicit require-flagged Accept-Contact preference that looks + like: + + (& (sip.methods="INVITE")) + + Applying the matching algorithm of RFC 2533 [6] to this feature set + and those registered by Y1 and Y2, the feature set of Y1 alone + matches. Because the Accept-Contact predicate has its require flag + set, Y2 is discarded, and the INVITE is routed to Y1. + + If the request was MESSAGE, the proxy constructs an implicit Accept- + Contact preference with its require flag set (require-flagged) that + looks like: + + (& (sip.methods="MESSAGE")) + + which matches the feature set of Y2, but not Y1. Thus, Y1 is + discarded, and the request is routed to Y2. + + + + +Rosenberg & Kyzivat Informational [Page 9] + +RFC 4596 Caller Preferences Uses July 2006 + + +3.2. Single Contact Not Matching Implicit Preferences + +3.2.1. Desired Behavior + + AOR Y has a single contact, Y1. It's a phone, and therefore supports + the standard operations INVITE, ACK, OPTIONS, BYE, and CANCEL but + does not support MESSAGE. A caller X sends a MESSAGE request. The + desired behavior is that the request is still routed to the solitary + contact so that it can generate a 405 response. + +3.2.2. Solution + + The single contact Y1 will generate a registration that looks like, + in part: + + REGISTER sip:example.com SIP/2.0 + To: sip:Y@example.com + Contact: + ;methods="INVITE,ACK,OPTIONS,BYE,CANCEL" + ;uri-user="" + ;uri-domain="example.com" + ;audio + ;schemes="sip" + ;mobility="fixed" + ;class="personal" + + X sends a MESSAGE request. There are no explicit caller preferences. + This results in an implicit require-flagged Accept-Contact + preference: + + (& (sip.methods="MESSAGE")) + + Since Y1 doesn't match and the Accept-Contact predicate is require- + flagged, it is discarded. However, according to section 7.2.4 of RFC + 3841, if there are no matching targets, the original target set is + used. Thus, the request is sent to the one original target, Y1, as + desired. Y1 then responds with a 405. + + If there were multiple contacts, and none of them matched the Accept- + Contact predicate, then the original target set including all of the + contacts would be restored. Then all the contacts would be processed + according to Section 16.6 of RFC 3261. + + + + + + + + + +Rosenberg & Kyzivat Informational [Page 10] + +RFC 4596 Caller Preferences Uses July 2006 + + +3.3. Package-Based Routing + +3.3.1. Desired Behavior + + AOR Y has a number of contacts, Y1, Y2, ..., Yn, that can each + support the standard operations INVITE, ACK, OPTIONS, BYE, and CANCEL + and can also support SUBSCRIBE for the "dialog" event package [7]. Y + also has another contact, Yp, that is a presence agent (PA) [8]: it + can accept only SUBSCRIBE requests for the "presence" event package. + The goal is for SUBSCRIBE requests for presence to be routed to Yp + while INVITEs and SUBSCRIBEs for the dialog package are forked to + Y1...Yn. + +3.3.2. Solution + + Y1..Yn will generate REGISTER requests that look like, in part: + + REGISTER sip:example.com SIP/2.0 + To: sip:Y@example.com + Contact: + ;methods="INVITE,BYE,OPTIONS,ACK,CANCEL,SUBSCRIBE" + ;events="dialog" + ;uri-user="" + ;uri-domain="example.com" + ;audio + ;schemes="sip" + ;mobility="fixed" + ;class="personal" + + and Yp will generate a REGISTER request that looks like, in part: + + REGISTER sip:example.com SIP/2.0 + To: sip:Y@example.com + Contact: ;methods="SUBSCRIBE" + ;events="presence" + ;uri-user="" + ;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-flagged Accept-Contact preference from the + request: + + (& (sip.methods="SUBSCRIBE") (sip.events="presence")) + + + + +Rosenberg & Kyzivat Informational [Page 11] + +RFC 4596 Caller Preferences Uses July 2006 + + + Following Section 7.2.4 of RFC 3841, 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 discarded. 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: + + (& (sip.methods="INVITE")) + + The implicit Accept-Contact feature set matches Y1..Yn, but does not + match Yp. Using the scoring algorithm from Section 7.2.4 of RFC + 3841, 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: + + (& (sip.methods="SUBSCRIBE") (sip.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. + +3.4. Package Routing II + +3.4.1. Desired Behavior + + This case is nearly identical to that of Section 3.3. However, + Y1..Yn omit the "events" feature tag from their registration. Yp + registers as in Section 3.3. A SUBSCRIBE for the presence event + package should still preferentially route to Yp. + + + + + + + + + + + + +Rosenberg & Kyzivat Informational [Page 12] + +RFC 4596 Caller Preferences Uses July 2006 + + +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: + ;methods="INVITE,BYE,OPTIONS,ACK,CANCEL,SUBSCRIBE" + ;uri-user="" + ;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: + + (& (sip.methods="SUBSCRIBE") (sip.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 + 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 call answered by a device + that supports video, but will accept an audio-only call as a second + choice. + + + + + + + + + +Rosenberg & Kyzivat Informational [Page 13] + +RFC 4596 Caller Preferences Uses July 2006 + + +3.5.2. Solution + + Y1 will generate a registration that looks like, in part: + + REGISTER sip:example.com SIP/2.0 + To: sip:Y@example.com + Contact: ;q=1.0 + ;methods="INVITE,BYE,OPTIONS,ACK,CANCEL" + ;uri-user="" + ;uri-domain="example.com" + ;audio + ;schemes="sip,tel" + ;mobility="fixed" + ;class="business" + + Y2 will generate a registration that looks like, in part: + + REGISTER sip:example.com SIP/2.0 + To: sip:Y@example.com + Contact: ;q=0.6 + ;methods="INVITE,BYE,OPTIONS,ACK,CANCEL" + ;uri-user="" + ;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 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 + + 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. + + + +Rosenberg & Kyzivat Informational [Page 14] + +RFC 4596 Caller Preferences Uses July 2006 + + + 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 + [3], 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. + +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 succeed 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, the audio phone will never ring. + + Because both the "require" and "explicit" flags are present, a + contact will also be discarded if it does not include a feature tag + indicating 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 some + capabilities but not the video capability. Contacts that don't + indicate any capabilities are "immune" from caller preferences + filtering and would not be discarded. + + + + + + + + + +Rosenberg & Kyzivat Informational [Page 15] + +RFC 4596 Caller Preferences Uses July 2006 + + +3.7. Third-Party Call Control: Forcing Media + +3.7.1. Desired Behavior + + Z is a third-party call control controller (3pcc) [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 that looks like, in part: + + REGISTER sip:example.com SIP/2.0 + To: sip:X@example.com + Contact: ;q=1.0 + ;methods="INVITE,BYE,OPTIONS,ACK,CANCEL" + ;uri-user="" + ;uri-domain="example.com" + ;audio + ;schemes="sip,tel" + ;mobility="fixed" + ;class="business" + + X2 will generate a registration that looks like, in part: + + REGISTER sip:example.com SIP/2.0 + To: sip:X@example.com + Contact: ;q=0.6 + ;methods="INVITE,BYE,OPTIONS,ACK,CANCEL" + ;uri-user="" + ;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 + + + + + + +Rosenberg & Kyzivat Informational [Page 16] + +RFC 4596 Caller Preferences Uses July 2006 + + + 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) that + are not strictly necessary for the request to proceed. + +3.8. Maximizing Media Overlaps + +3.8.1. Desired Behavior + + AOR Y has two contacts: Y1, which is a regular audio phone, and Y2, + which 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 that 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 that looks like, in part: + + REGISTER sip:example.com SIP/2.0 + To: sip:Y@example.com + Contact: + ;methods="INVITE,BYE,OPTIONS,ACK,CANCEL" + ;uri-user="" + ;uri-domain="example.com" + ;audio + ;schemes="sip,tel" + ;mobility="fixed" + ;class="business" + + + + + + + + + + + + + + + + +Rosenberg & Kyzivat Informational [Page 17] + +RFC 4596 Caller Preferences Uses July 2006 + + + Y2 will generate a registration that looks like, in part: + + REGISTER sip:example.com SIP/2.0 + To: sip:Y@example.com + Contact: + ;methods="INVITE,BYE,OPTIONS,ACK,CANCEL,MESSAGE" + ;uri-user="" + ;uri-domain="example.com" + ;audio + ;+sip.message + ;schemes="sip,tel" + ;mobility="fixed" + ;class="business" + + The solution requires the caller to support caller preferences. The + caller 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;+sip.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. + + Note that neither "require" nor "explicit" tags are used because + there is no intent to exclude contacts, only to order them. + +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. + + + + +Rosenberg & Kyzivat Informational [Page 18] + +RFC 4596 Caller Preferences Uses July 2006 + + +3.9.2. Solution + + A user at phone Y1 that speaks English only would generate a REGISTER + that looks like, in part: + + REGISTER sip:example.com SIP/2.0 + To: sip:Y@example.com + Contact: ;languages="en" + + A user at a phone Y2 that speaks 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: ;languages="es" + Contact: ;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: ;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";require + + The predicate derived from this looks like: + + (& (languages="en")) + + This matches the one contact for Y1, the second contact registered + for Y2, and the one contact for Y3, 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 + + + +Rosenberg & Kyzivat Informational [Page 19] + +RFC 4596 Caller Preferences Uses July 2006 + + + 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. + + An "explicit" tag is not used because that would cause the exclusion + of a contact that does not mention language. + + 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 circumstances. + +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: + ;audio + ;mobility="fixed" + + + + + + + + + + +Rosenberg & Kyzivat Informational [Page 20] + +RFC 4596 Caller Preferences Uses July 2006 + + + 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: + ;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. A caller 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! + +3.11.1. Desired Behavior + + The situation is similar to Section 3.10, except the caller wishes + only to leave a message, not actually speak to the person. + +3.11.2. Solution + + The caller would send an INVITE that 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 + + + + +Rosenberg & Kyzivat Informational [Page 21] + +RFC 4596 Caller Preferences Uses July 2006 + + + "require" and "explicit" flags are set, Y1 is discarded. Therefore, + the call is routed to Y2, the voicemail server, as desired. + + Because of the presence of the "require" and "explicit" tags, if + these preferences are used with a user that doesn't have voicemail or + that fails to indicate it with a msgserver capability, the call will + fail completely with a 480 Temporarily Unavailable error, rather than + connect 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 + + It had been hoped that RFC 3841 could provide a solution for this + case, but it does not, because doing so would require a re-ordering + of the callee contacts, which is not done. The caller may achieve + the intended effect by making two call attempts: + + o First, make an attempt requiring voicemail, as described in + Section 3.11. + + o If that fails with a 480 error, send an invitation with no Accept- + Contact or Reject-Contact headers. + +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, + 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 (Call Processing Language) 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: + + + +Rosenberg & Kyzivat Informational [Page 22] + +RFC 4596 Caller Preferences Uses July 2006 + + + Y1 would generate a REGISTER that looks like, in part: + + REGISTER sip:example.com SIP/2.0 + To: sip:Y@example.com + Contact: ;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: ;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: ;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 each contact has 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. + +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 (automaton). + + + + + + + + + +Rosenberg & Kyzivat Informational [Page 23] + +RFC 4596 Caller Preferences Uses July 2006 + + +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 to use a single + value with two parameters, a matching UA would need to declare that + it was BOTH an attendant and an automaton. 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 preferable. 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. + +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 that 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. + +3.15.2. Solution + + The mobile phone would generate a registration that looks like, in + part: + + REGISTER sip:example.com SIP/2.0 + To: sip:Y@example.com + Contact: ;mobility="mobile";q=0.1 + + + + + + + +Rosenberg & Kyzivat Informational [Page 24] + +RFC 4596 Caller Preferences Uses July 2006 + + + The caller would express their preference by generating an INVITE + that 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. + + Note that this only works if the mobile phone specifies the mobility + feature in its registration. + +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 the 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 that 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. + + An "explicit" option is not used, because it would bypass contacts + that do not include a language tag. + + + +Rosenberg & Kyzivat Informational [Page 25] + +RFC 4596 Caller Preferences Uses July 2006 + + +3.17. The Number You Have Called... + +3.17.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.17.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: ;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: ;attendant;q=1.0 + + YY3, the answering service, would generate a REGISTER that looks + like, in part: + + REGISTER sip:example.com SIP/2.0 + To: sip:YY@example.com + Contact: ;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: ;mobility="mobile";q=0.5 + + + + + + +Rosenberg & Kyzivat Informational [Page 26] + +RFC 4596 Caller Preferences Uses July 2006 + + + Although 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: ;q=1.0 + + and the second for the automated answering service: + + REGISTER sip:example.com SIP/2.0 + To: sip:Y@example.com + Contact: ;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 (the automaton) is associated with feature + parameters. The other has no feature parameters and is therefore + immune to caller preferences processing. The caller preferences are + applied to the automaton's contact. The feature sets match, but have + a score of zero. Since the "require" and "explicit" tags are + present, the contact for the automaton 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. + +3.18. The Number You Have Called, Take Two + +3.18.1. Desired Behavior + + This use case is nearly identical to that of Section 3.17. 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.18.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" + + + +Rosenberg & Kyzivat Informational [Page 27] + +RFC 4596 Caller Preferences Uses July 2006 + + + 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 automaton, 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 the request for YY@example.com is processed, 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.19. Forwarding to a Colleague + +3.19.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.19.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 for Bob's AOR contains an embedded Reject-Contact header + field, which rejects message servers. + + REGISTER sip:example.com + To: + Contact: ;q=1.0 + + REGISTER sip:example.com + To: + Contact: ;q=0.3 + + + + + + + + + +Rosenberg & Kyzivat Informational [Page 28] + +RFC 4596 Caller Preferences Uses July 2006 + + + REGISTER sip:example.com + To: + Contact: + ;msgserver; + ;automata + ;attendant + ;q=0.1 + + Meanwhile, Bob is registered as follows: + + REGISTER sip:example.com + To: + Contact: ;q=0.8 + + REGISTER sip:example.com + To: + Contact: + ;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 + 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, 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 Informational [Page 29] + +RFC 4596 Caller Preferences Uses July 2006 + + +4. Capability Use Cases + + The callee capabilities spec [2] 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 + interactive voice response (IVR) device, 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: ;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" that lacked this capability + would look like: + + INVITE sip:callee@example.com SIP/2.0 + Contact: ;schemes="sip,sips,tel" + + This 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 + determine 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 + Contact: ;msgserver;automata;attendant + + + + +Rosenberg & Kyzivat Informational [Page 30] + +RFC 4596 Caller Preferences Uses July 2006 + + + This tells the caller that it's an answering machine. + +5. Usage of the Feature Tags + + The caller preferences extension briefly enumerates a list of media + feature tags that 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 + overstated. + + If devices explicitly registered features that they don't support, + such as 'video="false"', the operation of RFC 3841 would be improved. + However, given the open-ended nature of capabilities, it will never + be possible to ensure the registration of negative values for all + capabilities of interest to a caller. Furthermore, attempting to do + so would significantly bloat registrations. Instead, it is + recommended that all "unusual" capabilities be explicitly registered. + + 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: + ;audio + ;class="business" + ;duplex="full" + ;+sip.extensions="100rel,path" + ;mobility="mobile" + ;methods="INVITE,BYE,OPTIONS,CANCEL,ACK" + ;schemes="sip,sips,tel" + ;uri-user="" + ;uri-domain="example.com" + + + + + +Rosenberg & Kyzivat Informational [Page 31] + +RFC 4596 Caller Preferences Uses July 2006 + + +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: + ;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="" + ;uri-domain="example.com" + + This device also supports the dialog event package and several SIP + extensions that would be typical in an IP PBX phone. + +5.3. PC Messaging 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: + ;class="personal" + ;mobility="fixed" + ;methods="OPTIONS,MESSAGE,NOTIFY" + ;schemes="sip,sips,im,pres" + ;uri-user="" + ;uri-domain="example.com" + + + + + + + + + + + + + + + +Rosenberg & Kyzivat Informational [Page 32] + +RFC 4596 Caller Preferences Uses July 2006 + + +5.4. Standalone Videophone + + A standalone IP videophone, capable of audio and video, would + generate a registration that looks like, in part + + REGISTER sip:example.com SIP/2.0 + To: sip:user@example.com + Contact: + ;audio + ;video + ;class="business" + ;duplex="full" + ;mobility="fixed" + ;methods="INVITE,BYE,OPTIONS,CANCEL,ACK" + ;schemes="sip,sips,tel" + ;uri-user="" + ;uri-domain="example.com" + +6. Example of Implementation of Preference and Capability Matching + + RFC 3841 [3] utilizes the definitions and feature matching algorithm + defined in RFC 2533 [6]. This provides a precise normative + specification of the algorithm. However, that specification isn't + ideal as a guideline for implementation because it is more complex + than is required for the restricted use employed by RFC 3841. (The + simplification is primarily because a particular feature tag may only + appear once in each Contact, Accept-Contact, or Reject-Contact + header.) + + This section provides a sample approach to implementing the matching + of caller preferences to callee capabilities; it does not require the + use of the notation and techniques of RFC 2533. It is not normative, + but is believed to be consistent with that definition. It may be + considered an alternative for that portion of RFC 3841 beginning with + Section 7.2.3 and extending to the end of page 13 in the middle of + Section 7.2.4. + + In this section, there are frequent references to syntactic elements + defined by ABNF in RFC 3840, Section 9, and RFC 3841, Section 10. + Here, ABNF elements are enclosed to single quotes -- for example, + 'feature-param'. Such a reference identifies a sequence of octets + within a SIP request that match the corresponding ABNF element when + the sip request is parsed according to RFCs 3261, 3840, and 3841. + + + + + + + + +Rosenberg & Kyzivat Informational [Page 33] + +RFC 4596 Caller Preferences Uses July 2006 + + +6.1. Extracting a Feature Set from a Header + + Contact header fields, Accept-Contact header fields, and Reject- + Contact header fields each contain zero or more 'feature-param's, + each in turn may contain one or more 'tag-value's, or a 'string- + value'. The first step is to extract from each header field a more + useful representation as a feature set, herein called an FS. (This + FS representation of a feature set representation differs from that + in RFC 2533.) This process is the same for each type of header. + + An FS consists of a set of one or more feature params denoted by FP. + Each FP has a name, denoted FP.NAME, and a set of one or more value + ranges denoted by VR. Each VR consists of: + + o A type (VR.TYPE): either token (TOKEN-TYPE), string (STRING-TYPE), + or number-range (RANGE-TYPE) + + o A negation flag (VR.NEGATION): either NEGATED, or NON-NEGATED + + o The actual value, differing by type: + + * For TOKEN-TYPE and STRING-TYPE, a sequence of octets + (VR.OCTETS) + + * For RANGE-TYPE, a pair of signed real numbers (VR.LB and VR.UB) + representing the lower and upper bounds on the range, + inclusive. + + A single FS is created to represent the features of one header. + (Contact, Accept-Contact, Reject-Contact.) Within the FS, an FP is + created for each 'feature-param' in the header. To create an FP, a + 'feature-param' is examined as follows: + + o If the 'feature-param' contains an instance of 'other-tags', then + FP.NAME is the value matched by 'ftag-name'. + + o Otherwise, the 'feature-param' contains an instance of 'base- + tags'. If the value matched by 'base-tags' is "language" or + "type", then FP.NAME is just the value matched by 'base-tags'. If + not, then FP.NAME is the value matched by 'base-tags' and prefixed + with "sip.". + + o The value of the 'feature-param', if any, is processed (according + to the rules in the next section) to extract a set of one or more + VRs that are associated with the FP. + + + + + + +Rosenberg & Kyzivat Informational [Page 34] + +RFC 4596 Caller Preferences Uses July 2006 + + +6.2. Extracting Values from a Feature Parameter + + The value of a 'feature-param' is an encoded representation (as + specified in RFC 3840) of one or more value ranges of the + corresponding feature. There are several data types that these + values may take on: boolean, token, string, number, or numeric range. + The type is determined by the encoded form of the value. (These + types and their representations are specific to this implementation.) + + (Note: numeric values can explicitly represent a range of values. + The other types only represent single value: a degenerate range. The + term value range is used to encompass all of these.) + + The value of the 'feature-param' ('string-value', 'tag-value-list', + or none) is converted to VR form as follows: + + o If there is no value, then a single new VR is created with VR.TYPE + = TOKEN-TYPE, VR.NEGATION = NON-NEGATED, and VR.OCTETS set to + "true". + + o If the 'feature-param' contains a 'string-value', then a single + new VR is created with VR.TYPE = STRING-TYPE, VR.NEGATION = + NON-NEGATED, and VR.OCTETS is set to the octets matching 'qdtext'. + + o Otherwise the 'feature-param' contains a 'tag-value-list', and a + new VR is created for each 'tag-value' in the 'tag-value-list', as + follows: + + o If the 'tag-value' begins with "!", VR.NEGATION = NEGATED; + otherwise, VR.NEGATION = NON-NEGATED. + + o If the 'tag-value' contains a 'boolean' or 'token-nobang', then + VR.TYPE = TOKEN-TYPE, and VR.OCTETS is set to the octets matched + by 'boolean' or 'token-nobang'. + + o If the 'tag-value' contains a 'numeric', VR.TYPE = RANGE-TYPE and: + + * If 'numeric-relation' is "<=", VR.UB is set to the numeric + value matching 'number'. VR.LB is set to MIN-REAL (a negative + number with the largest expressible magnitude.) + + * If 'numeric-relation' is "=", both VR.LB and VR.UB are set to + the numeric value matching 'number'. + + * If 'numeric-relation' is ">=", VR.LB is set to the numeric + value matching 'number' plus a small epsilon. VR.UB is set to + MAX-REAL (a positive number with the largest expressible + magnitude). + + + +Rosenberg & Kyzivat Informational [Page 35] + +RFC 4596 Caller Preferences Uses July 2006 + + + * Else the 'numeric-relation' consists of two 'number's separated + by a colon. In this case, VR.LB is set to the numeric value of + the smaller of the two numbers, and VR.UB is set to the numeric + value of the larger of the two numbers. + +6.3. Comparing Two Value-Ranges + + Two VRs match if their ranges overlap. The comparison is done + according to type, and only comparisons between like types are + defined. When two VRs of differing types are compared, they are + considered not to overlap. Either or both of the VRs may be NEGATED. + Comparison proceeds as follows: + + o If the VRs are of different types, the match is false. + + o Otherwise: + + * Two VRs with VR.TYPE = RANGE-TYPE match if max(VR1.LB, VR2.LB) + <= min(VR1.UB, VR2.UB). + + * Two VRs with VR.TYPE = TOKEN-TYPE match if their respective + VR.OCTETS values compare equal by case-insensitive comparison. + + * Two VRs with VR.TYPE = STRING-TYPE match if their respective + VR.OCTETS values compare equal by case-sensitive comparison. + + o The result (true/false) is then negated if VR1.NEGATION = NEGATED, + and negated again if VR2.NEGATION = NEGATED. + +6.4. Feature Set to Feature Set Matching + + In RFC 2533, the matching of two feature sets is commutative, but as + applied to caller preferences matching it is not. In this + application, one feature set comes from an Accept-Contact or Reject- + Contact header, and the other comes from a Contact header. For + purposes of this description, these will be termed the preferred- + features (FSp) and the capability-features (FSc), respectively. + Non-commutativity arises from explicit tests for the presence among + capability-params of feature param names used in preferred-features. + + A preferred-features feature set FSp may be matched to one + capability-features feature set FSc, and this yields the following + metrics: + + o NPF - The number of preferred-features. + + o NCF - The number of preferred-features for which there is a + capability-feature of the same name. + + + +Rosenberg & Kyzivat Informational [Page 36] + +RFC 4596 Caller Preferences Uses July 2006 + + + o NVM - The number of value matches between corresponding features + of the two feature sets. + + For a particular pair of FPp and FPc, these metrics are computed as + follows: + + o All the metrics are set to zero. + + o The following steps are applied for each feature param (FPp) of + the FSp: + + * NPF is incremented. + + * A corresponding FP with the same name is sought (using case- + insensitive comparison) in the FSc. + + * If a corresponding feature param (FPc) is found: + + + NCF is incremented. + + + Every VR of FPp is matched to every VR of FPc. + + + If any of those matches succeed, NVM is incremented. + +6.5. Selecting and Ordering Contacts Based on Caller Preferences + +6.5.1. Reject-Contact Processing + + The reject processing specified in Section 7.4.2 of RFC 3841 may be + performed as follows: + + o For each candidate Contact in the target set, match the feature + set of each Reject-Contact to it. + + o If (NVM == NPF) & (NCF == NPF), remove the contact URI from the + target set. + +6.5.2. Accept-Contact Processing + + The matching of an Accept-Contact against a Contact and subsequent + scoring of the match specified in Section 7.4.2 of RFC 3841 may be + performed as follows: + + o Match the feature set of the Accept-Contact to that of the Contact + as specified in Section 6.4. + + + + + + +Rosenberg & Kyzivat Informational [Page 37] + +RFC 4596 Caller Preferences Uses July 2006 + + + o If (NVM < NCF), then the match failed. If the Accept-Contact had + its "require" flag set, then discard the corresponding contact URI + from the target set. + + o Compute the score as NVM/NPF. + + o Apply the "require" and "explicit" flags as specified in the text + and Figure 7 of RFC 3841. + +7. Security Considerations + + This document provides explanation and examples of the use and + implementation of RFCs 3840 and 3841. The security considerations + sections of those documents apply to the material presented here. + +8. Acknowledgements + + The authors would like to thank Rohan Mahy for his input in this + specification. + +9. 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, "Indicating + User Agent Capabilities in the Session Initiation Protocol + (SIP)", RFC 3840, August 2004. + + [3] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller + Preferences for the Session Initiation Protocol (SIP)", + RFC 3841, August 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., Schulzrinne, H., and R. Mahy, "An INVITE- + Initiated Dialog Event Package for the Session Initiation + Protocol (SIP)", RFC 4235, November 2005. + + + + +Rosenberg & Kyzivat Informational [Page 38] + +RFC 4596 Caller Preferences Uses July 2006 + + + [8] Rosenberg, J., "A Presence Event Package for the Session + Initiation Protocol (SIP)", RFC 3856, August 2004. + + [9] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, + "Best Current Practices for Third Party Call Control (3pcc) in + the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, + April 2004. + + [10] Campbell, B., "The Message Session Relay Protocol", Work in + Progress, July 2006. + +Authors' Addresses + + Jonathan Rosenberg + Cisco Systems + 600 Lanidex Plaza + Parsippany, NJ 07054 + US + + Phone: +1 973 952-5000 + EMail: jdrosen@cisco.com + URI: http://www.jdrosen.net + + + Paul Kyzivat + Cisco Systems + 1414 Massachusetts Avenue + Boxborough, MA 01719 + US + + Phone: +1 978 936-1881 + EMail: pkyzivat@cisco.com + + + + + + + + + + + + + + + + + + + +Rosenberg & Kyzivat Informational [Page 39] + +RFC 4596 Caller Preferences Uses July 2006 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2006). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM 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. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights 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; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). + + + + + + + +Rosenberg & Kyzivat Informational [Page 40] + -- cgit v1.2.3