idnits 2.17.1 draft-ietf-sipping-callerprefs-usecases-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1755. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1732. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1739. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1745. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([3]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 5, 2005) is 6740 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 3427 (ref. '4') (Obsoleted by RFC 5727) == Outdated reference: A later version (-19) exists of draft-ietf-simple-message-sessions-11 Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING J. Rosenberg 3 Internet-Draft P. Kyzivat 4 Expires: April 8, 2006 Cisco Systems 5 October 5, 2005 7 Guidelines for Usage of the Session Initiation Protocol (SIP) Caller 8 Preferences Extension 9 draft-ietf-sipping-callerprefs-usecases-05 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on April 8, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 This document contains guidelines for usage of the Caller Preferences 43 Extension to the Session Initiation Protocol (SIP). It demonstrates 44 the benefits of caller preferences with specific example 45 applications, provides use cases to show proper operation, provides 46 guidance on the applicability of the registered feature tags, and 47 describes a straightforward implementation of the preference and 48 capability matching algorithm specified in section 7.2 of RFC3841 50 [3]. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 2. Motivations for Caller Preferences . . . . . . . . . . . . . . 5 56 2.1. One-Number . . . . . . . . . . . . . . . . . . . . . . . . 7 57 2.2. Direct-to-Voicemail . . . . . . . . . . . . . . . . . . . 7 58 3. Caller Preference Use Cases . . . . . . . . . . . . . . . . . 8 59 3.1. Routing of INVITE and MESSAGE to different UA . . . . . . 8 60 3.1.1. Desired Behavior . . . . . . . . . . . . . . . . . . . 8 61 3.1.2. Solution . . . . . . . . . . . . . . . . . . . . . . . 8 62 3.2. Single Contact Not Matching Implicit Preferences . . . . . 10 63 3.2.1. Desired Behavior . . . . . . . . . . . . . . . . . . . 10 64 3.2.2. Solution . . . . . . . . . . . . . . . . . . . . . . . 10 65 3.3. Package-Based Routing . . . . . . . . . . . . . . . . . . 10 66 3.3.1. Desired Behavior . . . . . . . . . . . . . . . . . . . 11 67 3.3.2. Solution . . . . . . . . . . . . . . . . . . . . . . . 11 68 3.4. Package Routing II . . . . . . . . . . . . . . . . . . . . 12 69 3.4.1. Desired Behavior . . . . . . . . . . . . . . . . . . . 12 70 3.4.2. Solution . . . . . . . . . . . . . . . . . . . . . . . 12 71 3.5. Audio/Video vs. Audio Only . . . . . . . . . . . . . . . . 13 72 3.5.1. Desired Behavior . . . . . . . . . . . . . . . . . . . 13 73 3.5.2. Solution . . . . . . . . . . . . . . . . . . . . . . . 13 74 3.6. Forcing Audio/Video . . . . . . . . . . . . . . . . . . . 15 75 3.6.1. Desired Behavior . . . . . . . . . . . . . . . . . . . 15 76 3.6.2. Solution . . . . . . . . . . . . . . . . . . . . . . . 15 77 3.7. Third Party Call Control - Forcing Media . . . . . . . . . 15 78 3.7.1. Desired Behavior . . . . . . . . . . . . . . . . . . . 16 79 3.7.2. Solution . . . . . . . . . . . . . . . . . . . . . . . 16 80 3.8. Maximizing Media Overlaps . . . . . . . . . . . . . . . . 17 81 3.8.1. Desired Behavior . . . . . . . . . . . . . . . . . . . 17 82 3.8.2. Solution . . . . . . . . . . . . . . . . . . . . . . . 17 83 3.9. Multilingual Lines . . . . . . . . . . . . . . . . . . . . 18 84 3.9.1. Desired Behavior . . . . . . . . . . . . . . . . . . . 18 85 3.9.2. Solution . . . . . . . . . . . . . . . . . . . . . . . 18 86 3.10. I Hate Voicemail! . . . . . . . . . . . . . . . . . . . . 20 87 3.10.1. Desired Behavior . . . . . . . . . . . . . . . . . . . 20 88 3.10.2. Solution . . . . . . . . . . . . . . . . . . . . . . . 20 89 3.11. I Hate People! . . . . . . . . . . . . . . . . . . . . . . 21 90 3.11.1. Desired Behavior . . . . . . . . . . . . . . . . . . . 21 91 3.11.2. Solution . . . . . . . . . . . . . . . . . . . . . . . 21 92 3.12. Prefer Voicemail . . . . . . . . . . . . . . . . . . . . . 22 93 3.12.1. Desired Behavior . . . . . . . . . . . . . . . . . . . 22 94 3.12.2. Solution . . . . . . . . . . . . . . . . . . . . . . . 22 95 3.13. Routing to an Executive . . . . . . . . . . . . . . . . . 22 96 3.13.1. Desired Behavior . . . . . . . . . . . . . . . . . . . 22 97 3.13.2. Solution . . . . . . . . . . . . . . . . . . . . . . . 22 98 3.14. Speak to the Executive . . . . . . . . . . . . . . . . . . 23 99 3.14.1. Desired Behavior . . . . . . . . . . . . . . . . . . . 23 100 3.14.2. Solution . . . . . . . . . . . . . . . . . . . . . . . 23 101 3.15. Mobile Phone Only . . . . . . . . . . . . . . . . . . . . 24 102 3.15.1. Desired Behavior . . . . . . . . . . . . . . . . . . . 24 103 3.15.2. Solution . . . . . . . . . . . . . . . . . . . . . . . 24 104 3.16. Simultaneous Languages . . . . . . . . . . . . . . . . . . 25 105 3.16.1. Desired Behavior . . . . . . . . . . . . . . . . . . . 25 106 3.16.2. Solution . . . . . . . . . . . . . . . . . . . . . . . 25 107 3.17. The Number you Have Called.. . . . . . . . . . . . . . . . 25 108 3.17.1. Desired Behavior . . . . . . . . . . . . . . . . . . . 26 109 3.17.2. Solution . . . . . . . . . . . . . . . . . . . . . . . 26 110 3.18. The Number you Have Called, Take Two . . . . . . . . . . . 27 111 3.18.1. Desired Behavior . . . . . . . . . . . . . . . . . . . 27 112 3.18.2. Solution . . . . . . . . . . . . . . . . . . . . . . . 27 113 3.19. Forwarding to a Colleague . . . . . . . . . . . . . . . . 28 114 3.19.1. Desired Behavior . . . . . . . . . . . . . . . . . . . 28 115 3.19.2. Solution . . . . . . . . . . . . . . . . . . . . . . . 28 116 4. Capability Use Cases . . . . . . . . . . . . . . . . . . . . . 29 117 4.1. Web Redirect . . . . . . . . . . . . . . . . . . . . . . . 30 118 4.2. Voicemail Icon . . . . . . . . . . . . . . . . . . . . . . 30 119 5. Usage of the Feature Tags . . . . . . . . . . . . . . . . . . 31 120 5.1. Traditional Cell Phone . . . . . . . . . . . . . . . . . . 31 121 5.2. Traditional Work Phone . . . . . . . . . . . . . . . . . . 32 122 5.3. PC Messenging Application . . . . . . . . . . . . . . . . 32 123 5.4. Standalone Videophone . . . . . . . . . . . . . . . . . . 32 124 6. Example Implementation of Preference and Capability 125 Matching . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 126 6.1. Extracting a Feature Set from a Header . . . . . . . . . . 33 127 6.2. Extracting Values from a Feature Parameter . . . . . . . . 34 128 6.3. Comparing Two Value-Ranges . . . . . . . . . . . . . . . . 35 129 6.4. Feature Set to Feature Set Matching . . . . . . . . . . . 35 130 6.5. Selecting and Ordering Contacts Based on Caller 131 Preferences . . . . . . . . . . . . . . . . . . . . . . . 36 132 6.5.1. Reject-Contact Processing . . . . . . . . . . . . . . 36 133 6.5.2. Accept-Contact Processing . . . . . . . . . . . . . . 36 134 7. Security Considerations . . . . . . . . . . . . . . . . . . . 37 135 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 136 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 37 137 10. Informative References . . . . . . . . . . . . . . . . . . . . 37 138 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39 139 Intellectual Property and Copyright Statements . . . . . . . . . . 40 141 1. Introduction 143 The Session Initiation Protocol (SIP) [1] extension for Callee 144 Capabilities [2] describes mechanisms that allow a UA (User Agent) to 145 register its capabilities in a REGISTER request. A caller can 146 express preferences, either explicitly or implicitly, about how that 147 request is to be handled. This is accomplished with the Accept- 148 Contact and Reject-Contact header fields described in Caller 149 Preferences for the Session Initiation Protocol[3]. 151 The caller preferences extension can serve as a useful tool for 152 supporting many applications. However, its generality makes it 153 difficult to correctly and effectively use in any one situation. To 154 remedy that, this document serves as a compendium of examples of the 155 usage of the caller preferences extension. 157 NOTE: This document is intended to assist the reader in 158 understanding RFC3840 and RFC3841. It is not intended to serve as 159 a substitute for reading those documents. The examples presented 160 in this document cannot be fully understood without awareness of 161 the mechanisms defined in RFCs 3840 and 3841. 163 First, Section 2 demonstrates the benefits of using caller 164 preferences by describing several concrete applications which are 165 enabled by the extension. Section 3 describes a set of detailed use 166 cases for expressing caller preferences. Each use case presents a 167 situation, describes how caller preferences can be used to handle the 168 requirements for the situation, and verifies that the desired 169 behavior occurs by showing the results of the matching operation. 170 These use cases validate that the caller preferences specification is 171 complete, and capable of meeting a specific set of requirements. 172 Since the caller preferences specification pre-dates the SIP change 173 process [4], no requirements document was ever published for it. To 174 some degree, this document "backfills" requirements. However, this 175 is not an academic exercise only, since the use cases described here 176 did result in changes in the caller preferences document as it 177 evolved. These use cases also help implementors figure out how to 178 use caller preferences in their own applications. 180 Section 4 discusses applications for the callee capabilities 181 specification. Section 5 discusses the example registrations of the 182 feature tags described in [2]. Proper usage of the caller 183 preferences extension depends on proper interpretation of the 184 semantics of these tags. More detail is provided on the tags, and 185 example registrations are included that show typical usage. 187 Section 6 outlines an implementation approach to the matching 188 algorithm that doesn't require RFC2533 [6] to be implemented in all 189 its generality. 191 2. Motivations for Caller Preferences 193 At its core, SIP is a protocol that facilitates rendezvous of users. 194 The caller and callee need to meet up in order to exchange session 195 information, so that they may communicate. The rendezvous process is 196 complicated by the fact that a user has multiple points of attachment 197 to the network. A called user (callee) can have a cell phone, a PDA, 198 a work phone, a home phone, and one of several PC-based 199 communications applications. When someone calls that user, to which 200 of these devices is the call routed? 202 Certainly, the call can be routed to all of them at the same time, a 203 process known as parallel forking. However, that is not always the 204 desired behavior. Users may prefer that their registered devices be 205 tried in a particular order. As an example, a user might prefer that 206 his cell phone ring first, and if no one answers, the call rings his 207 work phone next. Another user might prefer that her cell phone ring 208 first, and then her home and work phones ring at the same time, and 209 then, if no one answers either of those, that the call be forwarded 210 to voicemail. These variations are all referred to as as find-me/ 211 follow-me features. 213 SIP supports find-me/follow-me features in many ways. The most basic 214 is through the SIP registration process. Each device at which a user 215 can be contacted registers to the network. This registration 216 associates the device with the canonical name of the user - called 217 the address-of-record (AOR), which is a SIP URI. Each registration 218 can include a preference value, indicating the relative preference 219 for receiving calls at that device, compared to other devices. When 220 someone makes a call to the AOR, proxies compliant to RFC 3261 will 221 try the registered devices in order of preference, unless 222 administrative policy overrides user preferences. 224 Preference values in SIP registrations can only provide basic find- 225 me/follow-me features. To support more complex features, the Call 226 Processing Language (CPL) [5] has been specified. It is an XML 227 script that provides specific call routing instructions. Users can 228 upload these scripts to the network, instructing the servers how 229 calls should be routed. As an example, a CPL script can instruct a 230 proxy to route a call to the work phone during work hours (9am - 5pm) 231 and then to the cell phone after hours, unless the call is from a 232 family member, in which case it always goes to the cell phone. 234 It is important to note that both CPL scripts and preference values 235 in registrations describe operation of a service from the perspective 236 of the called party. That is, they describe how a call made to them 237 should be routed by the network. However, the called party is not 238 the only one with preferences. A caller will also have preferences 239 for how they want their call to be routed. As an example, a caller 240 will often want to reach a user on their cell phone. In the current 241 telephone network, this is accomplished by requiring a user to have a 242 separate number for each device. This way, when a caller wishes to 243 reach the cell phone, they dial the number for the cell phone. This 244 requires users to maintain lists of potential reach numbers for a 245 user, and then select the appropriate one. A far better approach is 246 for a user to maintain a single address-of-record. When someone 247 wishes to reach them on their cell phone, they call the AOR, but 248 indicate a preference for the call to be routed to the cell phone. 250 A caller may actually have a wide variety of preferences for how a 251 call should be routed. They may prefer to go right to voicemail. 252 They may prefer to never reach voicemail. The may prefer to reach 253 the user on a device which supports video (because a video-conference 254 is desired). They may wish to reach a device that has an attendant 255 who can answer if the user is not there. 257 The SIP caller preferences extension allows a caller to express these 258 preferences for the way in which their calls are handled. These 259 preferences are expressed in terms of properties of the desired 260 device. These properties are name-value pairs that convey some kind 261 of information about a device. One example is the property 262 "mobility" which can have the values "mobile" or "fixed". When a 263 caller wishes to reach a cell phone, they include information in 264 their call setup request (the INVITE method) which indicates that the 265 call should be routed to a device that has the property "mobility" 266 set to "mobile". When devices register to the network, they include 267 their properties - also known as callee capabilities - as part of the 268 registration. In this way, a proxy can match the caller's 269 preferences against the capabilities of the various devices 270 registered to the user, and route the call appropriately. 272 While this document addresses the preferences of a caller, it does so 273 from the perspective of a SIP User Agent representing the caller. 274 Caller preferences are herein represented via syntactic elements 275 placed in a SIP request. This document does not attempt to address 276 how preferences might be conveyed by a human user to the User Agent. 277 Thus this document is likely to be of most value to the developer of 278 a User Agent. 280 The caller preferences extension can support a wide variety of call 281 routing applications and features. Two particularly important 282 examples are "one-number" and ``direct-to-voicemail''. 284 2.1. One-Number 286 In today's circuit-switched telephony networks, users have multiple 287 devices, and each device is associated with its own phone number. A 288 user will typically list all of these numbers on a business card - 289 cell phone, work phone, home office phone, and so on. Other users 290 need to store and manage all of these numbers. It is difficult to 291 keep these numbers complete and up-to-date. Worse, when you want to 292 call someone, you need to pick a number to try. Sometimes, you want 293 a specific device (the cell phone), and other times, you just want to 294 reach them wherever they are. In the latter case, a user is forced 295 to try each number, one at a time. This is inefficient, and 296 difficult to do while driving, for example. 298 As an alternative, a user can have a single address. This is the one 299 and only address they give out to other users on their business 300 cards. If a caller wishes to reach that user on their cell phone, 301 they select that one address, and then access a pull-down menu of 302 device types. This menu would include home phone, work phone, and 303 cell phone. The caller can select cell-phone, and then the call is 304 placed to the cell phone. There is no need to manage or maintain 305 more than one number for the user - a single number will suffice. 307 If, on the other hand, the caller wishes to reach the user wherever 308 they are, they make a call to that one number without a selection of 309 a preferred device. The network will ring all devices at the same 310 time, and therefore reach the user as fast as possible. 312 This one-number service makes use of caller preferences. To express 313 a preference for the cell phone, the caller's device would include a 314 header in the SIP INVITE request indicating a desire to reach a 315 device with "mobility" equal to "mobile". 317 2.2. Direct-to-Voicemail 319 Frequently, a busy executive on the road wants to quickly pass a 320 message to a colleague by voice. As an example, a boss might want to 321 instruct an employee to call a specific customer and resolve a 322 pending issue. In such a case, the user doesn't actually want to 323 talk to the person; they just want to leave them a voice message. 324 Having a phone conversation may require too much time, whereas a 325 voice message can be quick and to the point. The voice message can 326 also serve as a record of exactly what is desired, whereas a fleeting 327 voice conversation can be forgotten or misremembered. 329 In today's circuit-switched telephone networks, there is often no way 330 to go directly to someones voicemail and leave a message. Sometimes, 331 you can dial the main number for the voicemail system, enter in the 332 extension of the desired party, and leave a message by entering a 333 specific prompt. This is time consuming, and requires the caller to 334 know the main voicemail number. 336 Instead, an address book in a cell phone can have an option called 337 "leave voice message", available for each entry in the address book. 338 When this option is selected, a call is made directly to the 339 voicemail for that user, which immediately picks up and prompts for a 340 message. In fact, a rapid greeting is played, so that the caller can 341 go directly to the recording procedure. 343 This saves time for the caller, making it very easy to quickly leave 344 recorded messages for a large number of people. 346 This feature is possible using the caller preferences extension. 347 When the user selects the "leave voice message" option, the phone 348 sends a SIP INVITE request, and includes a caller preferences header 349 field that indicates a preference for devices whose "msgserver" 350 attribute has a value of "true". This will cause the proxy to route 351 the call directly to a registered voicemail service. Furthermore, 352 the voicemail server will see that the caller asked to go directly to 353 voicemail, and can therefore play an abbreviated greeting explicitly 354 designed for this case. 356 3. Caller Preference Use Cases 358 Each use case is described as a situation along with a desired 359 behavior. Then, it demonstrates how the various caller preferences 360 headers and the proxy processing logic would result in the 361 appropriate decision being made. 363 3.1. Routing of INVITE and MESSAGE to different UA 365 3.1.1. Desired Behavior 367 Address of Record (AOR) Y has two contacts Y1 and Y2. Y1 is a phone, 368 and supports the standard operations INVITE, ACK, OPTIONS, BYE, and 369 CANCEL but not MESSAGE, while Y2 is a pager and supports only OPTIONS 370 and MESSAGE. Caller X wants to send pages to Y. There is a lot of 371 traffic in the network of both calls and pages, so there is a goal 372 not to unnecessarily fork messages to devices that can't support 373 them. So, ensure that INVITEs of Y are delivered only to Y1, while 374 MESSAGEs to Y are delivered only to Y2. 376 3.1.2. Solution 378 Y1 will create a registration which looks like, in part: 380 REGISTER sip:example.com SIP/2.0 381 To: sip:Y@example.com 382 Contact: 383 ;methods="INVITE,ACK,OPTIONS,BYE,CANCEL" 384 ;uri-user="" 385 ;uri-domain="example.com" 386 ;audio 387 ;schemes="sip" 388 ;mobility="mobile" 390 Y2 will create a registration which looks like, in part: 392 REGISTER sip:example.com SIP/2.0 393 To: sip:Y@example.com 394 Contact: 395 ;methods="OPTIONS,MESSAGE" 396 ;uri-user="" 397 ;uri-domain="example.com" 398 ;+sip.message 399 ;schemes="sip,im" 400 ;mobility="mobile" 402 When a UAC (User Agent Client) sends an INVITE, it will arrive at the 403 proxy for example.com. There are no caller preferences in the 404 request. However, per Section 7.2.2 of [3], the proxy will construct 405 an implicit require-flagged Accept-Contact preference that looks 406 like: 408 (& (sip.methods="INVITE")) 410 Applying the matching algorithm of RFC 2533 [6] to this feature set 411 and those registered by Y1 and Y2, the feature set of Y1 alone 412 matches. Because the Accept-Contact predicate has its require flag 413 set, Y2 is discarded and the INVITE is routed to Y1. 415 If the request was MESSAGE, the proxy constructs an implicit Accept- 416 Contact preference with its require flag set (require-flagged) that 417 looks like: 419 (& (sip.methods="MESSAGE")) 421 which matches the feature set of Y2, but not Y1. Thus, Y1 is 422 discarded, and the request is routed to Y2. 424 3.2. Single Contact Not Matching Implicit Preferences 426 3.2.1. Desired Behavior 428 AOR Y has a single contact Y1. It's a phone, and therefore supports 429 the standard operations INVITE, ACK, OPTIONS, BYE, and CANCEL but not 430 MESSAGE. A caller X sends a MESSAGE request. The desired behavior 431 is that the request is still routed to the solitary contact so that 432 it can generate a 405 response. 434 3.2.2. Solution 436 The single contact Y1 will generate a registration which looks like, 437 in part: 439 REGISTER sip:example.com SIP/2.0 440 To: sip:Y@example.com 441 Contact: 442 ;methods="INVITE,ACK,OPTIONS,BYE,CANCEL" 443 ;uri-user="" 444 ;uri-domain="example.com" 445 ;audio 446 ;schemes="sip" 447 ;mobility="fixed" 448 ;class="personal" 450 X sends a MESSAGE request. There are no explicit caller preferences. 451 This results in an implicit require-flagged Accept-Contact 452 preference: 454 (& (sip.methods="MESSAGE")) 456 Since Y1 doesn't match and the Accept-Contact predicate is require- 457 flagged, it is discarded. However, according to section 7.2.4 of 458 RFC3841, if there are no matching targets, the original target set is 459 used. Thus, the request is sent to the one original target, Y1, as 460 desired. Y1 then responds with a 405. 462 If there were multiple contacts, and none of them matched the Accept- 463 Contact predicate, then the original target set including all of the 464 contacts would be restored. Then all the contacts would be processed 465 according to section 16.6 of RFC3261. 467 3.3. Package-Based Routing 468 3.3.1. Desired Behavior 470 AOR Y has a number of contacts, Y1, Y2, ..., Yn that can each support 471 the standard operations INVITE, ACK, OPTIONS, BYE, and CANCEL and can 472 also support SUBSCRIBE for the "dialog" event package [7]. Y also 473 has another contact Yp that is a presence agent (PA) [8] - it can 474 accept only SUBSCRIBE requests for the "presence" event package. The 475 goal is for SUBSCRIBE requests for presence to be routed to Yp while 476 INVITEs and SUBSCRIBEs for the dialog package are forked to Y1...Yn. 478 3.3.2. Solution 480 Y1..Yn will generate REGISTER requests which look like, in part: 482 REGISTER sip:example.com SIP/2.0 483 To: sip:Y@example.com 484 Contact: 485 ;methods="INVITE,BYE,OPTIONS,ACK,CANCEL,SUBSCRIBE" 486 ;events="dialog" 487 ;uri-user="" 488 ;uri-domain="example.com" 489 ;audio 490 ;schemes="sip" 491 ;mobility="fixed" 492 ;class="personal" 494 and Yp will generate a REGISTER request which looks like, in part: 496 REGISTER sip:example.com SIP/2.0 497 To: sip:Y@example.com 498 Contact: ;methods="SUBSCRIBE" 499 ;events="presence" 500 ;uri-user="" 501 ;uri-domain="example.com" 502 ;schemes="sip,pres" 503 ;mobility="fixed" 504 ;class="business" 506 A SUBSCRIBE request for presence will arrive at the proxy for 507 example.com. Since there are no explicit preferences, it constructs 508 an implicit require-flagged Accept-Contact preference from the 509 request: 511 (& (sip.methods="SUBSCRIBE") (sip.events="presence")) 512 Following section 7.2.4 of RFC3841, this feature set only matches the 513 one registered by Yp. Because the require flag is set, the contacts 514 which do not match are removed from the target set. Therefore, 515 Y1..Yn are discarded. The request is sent to the remaining contact, 516 Yp, representing the PA. 518 An INVITE request without explicit preferences results in an implicit 519 require-flagged Accept-Contact preference: 521 (& (sip.methods="INVITE")) 523 The implicit Accept-Contact feature set matches Y1..Yn, but not Yp. 524 Using the scoring algorithm from section 7.2.4 of RFC381, the score 525 for Y1..Yn against this predicate is 1.0. As a result, the caller 526 preference Qa for each contact is 1.0. The registrations did not 527 contain q-values, so the default q-value of 1.0 is applied to each 528 Contact URI. Since the caller and callee preferences are the same, 529 and all equal to 1.0, there is no reordering of contacts. The result 530 is that the proxy will consider Y1..Yn each as equally good targets 531 for the request, and possibly fork the request to each. 533 A SUBSCRIBE request for the dialog event package without explicit 534 preferences will result in an implicit require-flagged Accept-Contact 535 preference: 537 (& (sip.methods="SUBSCRIBE") (sip.events="dialog")) 539 This only matches Y1..Yn, so Yp is discarded, and the request is 540 routed to the remaining contacts just as the INVITE was. 542 3.4. Package Routing II 544 3.4.1. Desired Behavior 546 This case is nearly identical to that of Section Section 3.3. 547 However, Y1..Yn omit the "events" feature tag from their 548 registration. Yp registers as in Section Section 3.3. A SUBSCRIBE 549 for the presence event package should still preferentially route to 550 Yp. 552 3.4.2. Solution 554 The registration from Y1..Yn will look like: 556 REGISTER sip:example.com SIP/2.0 557 To: sip:Y@example.com 558 Contact: 559 ;methods="INVITE,BYE,OPTIONS,ACK,CANCEL,SUBSCRIBE" 560 ;uri-user="" 561 ;uri-domain="example.com" 562 ;audio 563 ;schemes="sip" 564 ;mobility="fixed" 565 ;class="personal" 567 When the caller sends a SUBSCRIBE for the presence event package 568 (without explicit preferences), the proxy computes an implicit 569 preference: 571 (& (sip.methods="SUBSCRIBE") (sip.events="presence")) 573 This predicate matches Y1..Yn and Yp. However, the score for Y1..Yn 574 against this predicate is 0.5, and the score of Yp is 1.0. The 575 result is a caller preference Qa of 0.5 for Y1..Yn, and a caller 576 preference Qa of 1.0 for Yp. Since the callee provided no q-values, 577 the proxy will assume a default of 1.0. Thus, all contacts are in 578 the same equivalence class. They are then sorted by Qa, so that Yp 579 is first, followed by Y1 through Yn. It will therefore route the 580 request first to Yp, and if that should fail, to Y1..Yn. 582 3.5. Audio/Video vs. Audio Only 584 3.5.1. Desired Behavior 586 X sends an invitation to Y to initiate an audio/video call, including 587 both m=audio and m=video lines in the SDP. AOR Y has two contacts, 588 Y1 and Y2. Y1 represents a normal audio phone, where Y prefers to 589 receive their calls. It will answer an audio/video call, refusing 590 the video. Y2 represents an audio/video phone that should only used 591 when needed. The caller really wants the call answered by a device 592 that supports video, but will accept an audio-only call as a second 593 choice. 595 3.5.2. Solution 597 Y1 will generate a registration which looks like, in part: 599 REGISTER sip:example.com SIP/2.0 600 To: sip:Y@example.com 601 Contact: ;q=1.0 602 ;methods="INVITE,BYE,OPTIONS,ACK,CANCEL" 603 ;uri-user="" 604 ;uri-domain="example.com" 605 ;audio 606 ;schemes="sip,tel" 607 ;mobility="fixed" 608 ;class="business" 610 Y2 will generate a registration which looks like, in part: 612 REGISTER sip:example.com SIP/2.0 613 To: sip:Y@example.com 614 Contact: ;q=0.6 615 ;methods="INVITE,BYE,OPTIONS,ACK,CANCEL" 616 ;uri-user="" 617 ;uri-domain="example.com" 618 ;audio 619 ;video 620 ;schemes="sip,tel" 621 ;mobility="fixed" 622 ;class="business" 624 Note the different q-values, allowing Y2 to be selected as a device 625 of "last resort". 627 To have the call preferentially routed to a device that supports 628 video, the caller X sends an INVITE that looks like, in part: 630 INVITE sip:Y@example.com SIP/2.0 631 Accept-Contact: * 632 ;methods="INVITE" 633 ;video 635 The proxy will convert this to a feature set. This feature set 636 matches Y2 and Y1. However, the score for Y2 is 1.0, and 0.5 for Y1. 637 The two contacts are then ordered by q-value, and broken into 638 equivalence classes. There are two equivalence classes, each with 639 one contact. As a result, the caller preference values have no 640 impact on the ordering. The call will first try the higher priority 641 Y1, which will answer the call and reject the video stream. Thus, 642 the desired behavior is not achieved. 644 The desired behavior could be achieved by adding the "explicit" and 645 "require" tags to the Accept-Contact header field in the INVITE, as 646 is done in Section 3.6. However, doing so may result in calls 647 failing when they could occur, but without video. As discussed in 648 [3], both the "require" and "explicit" tags are generally used only 649 when the request cannot be serviced in any way unless the preferences 650 are met. That is not the case here. 652 3.6. Forcing Audio/Video 654 3.6.1. Desired Behavior 656 This case is similar to that of Section 3.5. However, X requires an 657 audio/video call, and would like the call to fail if this is not 658 possible, rather than succeeding with audio only. 660 3.6.2. Solution 662 The solution is similar to that of Section 3.5, however the Accept- 663 Contact header field now includes the explicit and require tags, 664 guaranteeing that the call is never established to any UA that had 665 not explicitly indicated support for video: 667 INVITE sip:Y@example.com SIP/2.0 668 Accept-Contact: *;video;require;explicit 670 This arrives at the example.com proxy. This explicit feature set 671 matches the feature set for Y2 and Y1. However, the match for Y1 did 672 not have a score of 1. Since the explicit and require tags are 673 present, the contact is discarded. That leaves Y2 only. The call 674 will therefore get routed to the videophone, and if the user is not 675 there, the audio phone will never ring. 677 Because both the "require" and "explicit" flags are present, a 678 contact will also be discarded if it does not include a feature tag 679 indicating support for video. Thus, a UA that can do video, but 680 neglected to indicate it, would not be reached in this case. This is 681 why it is important for a UA to indicate all of its capabilities. 682 Note that this is only true for a contact that indicated other 683 capabilities, just not video. Contacts which don't indicate any 684 capabilities are "immune" from caller preferences filtering, and 685 would not be discarded. 687 3.7. Third Party Call Control - Forcing Media 688 3.7.1. Desired Behavior 690 Z is a third party call control controller (3pcc) [9] trying to 691 establish an audio/video call from X to Y. X has contacts X1 and X2, 692 and Y has contacts Y1 and Y2. X1 and X2 have capabilities identical 693 to Y1 and Y2, respectively. Z needs to send an offerless invite to X 694 and use the offer proposed by X to send an invite to Y. When sending 695 the offerless invite to X the 3pcc controller must ensure that an 696 audio/video contact (X2) is chosen over an audio only contact (X1). 698 3.7.2. Solution 700 X1 will generate a registration which looks like, in part: 702 REGISTER sip:example.com SIP/2.0 703 To: sip:X@example.com 704 Contact: ;q=1.0 705 ;methods="INVITE,BYE,OPTIONS,ACK,CANCEL" 706 ;uri-user="" 707 ;uri-domain="example.com" 708 ;audio 709 ;schemes="sip,tel" 710 ;mobility="fixed" 711 ;class="business" 713 X2 will generate a registration which looks like, in part: 715 REGISTER sip:example.com SIP/2.0 716 To: sip:X@example.com 717 Contact: ;q=0.6 718 ;methods="INVITE,BYE,OPTIONS,ACK,CANCEL" 719 ;uri-user="" 720 ;uri-domain="example.com" 721 ;audio 722 ;video 723 ;schemes="sip,tel" 724 ;mobility="fixed" 725 ;class="business" 727 Z would include, in its INVITE, an Accept-Contact header field: 729 INVITE sip:X@example.com SIP/2.0 730 Accept-Contact: *;audio;video;require;explicit 732 This caller preference matches both X1 and X2. However, it matches 733 X1 with a score of .5 and X2 with a score of 1. Because of the 734 require and explicit tags, X1 is discarded despite X's preference for 735 it. Thus, the call is routed to X2. 737 The same caveats apply here as do in Section 3.6. Generally, it is 738 not advisable to mandate support for features (such as video), which 739 are not strictly neccesary for the request to proceed. 741 3.8. Maximizing Media Overlaps 743 3.8.1. Desired Behavior 745 AOR Y has two contacts, Y1 that is a regular audio phone, and Y2 that 746 is a PC capable of supporting both audio and session oriented IM 747 [10]. X is a PC with capability to support audio, video and session 748 oriented IM. X calls Y for the purpose of establishing a voice call. 749 However, X wishes to connect to the device which has the maximal 750 overlap with its media capabilities, in order to maximize the 751 functionality available to the caller. 753 3.8.2. Solution 755 Y1 will generate a registration which looks like, in part: 757 REGISTER sip:example.com SIP/2.0 758 To: sip:Y@example.com 759 Contact: 760 ;methods="INVITE,BYE,OPTIONS,ACK,CANCEL" 761 ;uri-user="" 762 ;uri-domain="example.com" 763 ;audio 764 ;schemes="sip,tel" 765 ;mobility="fixed" 766 ;class="business" 768 Y2 will generate a registration which looks like, in part: 770 REGISTER sip:example.com SIP/2.0 771 To: sip:Y@example.com 772 Contact: 773 ;methods="INVITE,BYE,OPTIONS,ACK,CANCEL,MESSAGE" 774 ;uri-user="" 775 ;uri-domain="example.com" 776 ;audio 777 ;+sip.message 778 ;schemes="sip,tel" 779 ;mobility="fixed" 780 ;class="business" 782 The solution requires the caller to support caller preferences. They 783 would include, in their INVITE, an Accept-Contact header field that 784 lists all the media types they support. In this case: 786 INVITE sip:Y@example.com SIP/2.0 787 Accept-Contact: *;audio;video;+sip.message 789 Both Y1 and Y2 match the predicate. Y1 matches with a score of 0.33, 790 and Y2 matches with a score of 0.66. Since there is only one Accept- 791 Contact predicate, the Qa for each contact is equal to the score. 792 The registered contacts are then sorted by q-value, and broken into 793 equivalence classes. There is a single equivalence class with 794 q-value of 1.0. The two contacts in that class are then re-ordered 795 based on the values of Qa. Y2 has a higher Qa, so it is used first, 796 followed by Y1. The result is that the call is routed to the device 797 with the maximum overlap in media capabilities, as desired. 799 Note that neither require nor explicit tags are used because there is 800 no intent to exclude contacts, only to order them. 802 3.9. Multilingual Lines 804 3.9.1. Desired Behavior 806 AOR Y represents a shared line in an office. Several employees in 807 the office have phones registered for Y. Some of the employees speak 808 only English, some speak Spanish fluently and have some limited 809 capability for English, and some speak both English and Spanish 810 fluently. Calls from callers that speak only English should be 811 parallel forked to all office workers that speak fluent English. If 812 the call isn't picked up, then the phones of workers that speak 813 English marginally should be rung. Calls from callers that speak 814 only Spanish should be forked only to workers that speak Spanish. 816 3.9.2. Solution 818 A user at phone Y1 that speaks English only would generate a REGISTER 819 which looks like, in part: 821 REGISTER sip:example.com SIP/2.0 822 To: sip:Y@example.com 823 Contact: ;languages="en" 824 A user at a phone Y2 that speaks Spanish and a little bit of English 825 would generate a REGISTER that looks like, in part: 827 REGISTER sip:example.com SIP/2.0 828 To: sip:Y@example.com 829 Contact: ;languages="es" 830 Contact: ;languages="en";q=0.2 832 Y2 has registered two contacts. Both of them route to the same 833 device (pc2.example.com), but they differ in their language support 834 and relative q-values. Multiple contacts are needed whenever a UA 835 wishes to express differing preferences for being reached for 836 different feature collections. 838 A user at phone Y3 that speaks English and Spanish fluently would 839 generate a REGISTER that looks like, in part: 841 REGISTER sip:example.com SIP/2.0 842 To: sip:Y@example.com 843 Contact: ;languages="es,en" 845 Notice that only a single contact is needed because the same q-value 846 is applied across all feature collections. 848 For the language based routing to occur, the caller must indicate its 849 language preferences explicitly: 851 INVITE sip:Y@example.com SIP/2.0 852 Accept-Contact: *;languages="en";require 854 The predicate derived from this looks like: 856 (& (languages="en")) 858 This matches the one contact for Y1, the second contact registered 859 for Y2, and the one contact for Y3, all with a score of 1.0. The 860 first contact registered by Y2 does not match, and because of the 861 "require" flag, is discarded. The remaining contacts are sorted by 862 q-value, and divided into equivalence classes. There are two 863 equivalence classes. The first contains Y1 and Y3 with a q-value of 864 1.0, and the second contains Y2-en with a q-value of 0.2. The 865 contacts in the first class are ordered by Qa. However, since all 866 contacts have the same value of Qa (1.0), there is no change in 867 ordering. Thus, Y1 and Y3 are tried first, followed by Y2-en. This 868 is the desired behavior. 870 An explicit tag is not used because that would cause the exclusion of 871 a contact that does not mention language. 873 A caller that speaks Spanish only would specify their preference 874 thusly: 876 INVITE sip:Y@example.com SIP/2.0 877 Accept-Contact: *;languages="es";require 879 This matches the first contact of Y2 phones, and Y3 phones, all with 880 a score of 1.0. The English contact of Y2, Y2-en, doesn't match, and 881 is discarded because of the "require" flag. The remaining contacts 882 are sorted by q-values (Y3, Y2-es), and broken into a single 883 equivalence class containing both contacts. Since the Qa for both 884 contacts is the same - 1.0 - there is no reordering. The result is 885 that the call is routed to either Y3 or Y2-es. 887 3.10. I Hate Voicemail! 889 3.10.1. Desired Behavior 891 AOR Y has two contacts, a phone Y1 and a voicemail service Y2. X 892 wishes to call Y and talk in person. X does not want to be sent to 893 voicemail under any circumstance. 895 3.10.2. Solution 897 The phone would register with a Contact that looks like, in part: 899 REGISTER sip:example.com SIP/2.0 900 To: sip:Y@example.com 901 Contact: 902 ;audio 903 ;mobility="fixed" 905 and the voicemail server would register with a Contact that looks 906 like, in part: 908 REGISTER sip:example.com SIP/2.0 909 To: sip:Y@example.com 910 Contact: 911 ;msgserver 912 ;automata 913 ;attendant 914 ;audio 915 ;q=0.2 917 The voicemail server registers with a lower q-value so that it is 918 used only after the phone itself is rung. Note that the voicemail 919 server need not actually register. There can be a configured contact 920 and feature set defined for it instead. 922 A caller that wishes to avoid voicemail can include an explicit 923 preference to avoid it. It would do this with the Reject-Contact 924 header field: 926 INVITE sip:Y@example.com SIP/2.0 927 Reject-Contact: *;msgserver 929 Since this feature set contains a feature tag that is not contained 930 in the registration for Y1, the feature set is discarded when 931 examining Y1. However, the registration for Y2 contains all feature 932 tags listed in the feature set, and so the rule is considered. There 933 is a match, and therefore, Y2 is discarded. The result is that the 934 user is never routed to voicemail. 936 3.11. I Hate People! 938 3.11.1. Desired Behavior 940 The situation is similar to Section 3.10, except the caller wishes to 941 only leave a message, not actually speak to the person. 943 3.11.2. Solution 945 The caller would send an INVITE which looks like, in part: 947 INVITE sip:Y@example.com SIP/2.0 948 Accept-Contact: *;msgserver;require;explicit 950 This caller preference matches both Y1 and Y2. Y1 matches, but with 951 a score of zero. Y2 matches with a score of 1. Since both the 952 require and explicit flags are set, Y1 is discarded. Therefore, the 953 call is routed to Y2, the voicemail server, as desired. 955 Because of the presence of the require and explicit tags, if these 956 preferences are used with a user that doesn't have voicemail, or 957 fails to indicate it with a msgserver capability, the call will fail 958 completely with a 480 Temporarily Unavailable error, rather than 959 connecting to the user. 961 3.12. Prefer Voicemail 963 3.12.1. Desired Behavior 965 The situation is similar to that of Section 3.10. However, the 966 caller prefers to leave a message. If voicemail is not available, 967 they are willing to talk to a person. 969 3.12.2. Solution 971 It had been hoped that RFC3841 could provide a solution for this 972 case, but it does not, because doing so would require a re-ordering 973 of the callee contacts, which is not done. The caller may achieve 974 the intended effect by making two call attempts: 975 o First make an attempt requiring voicemail, as described in section 976 Section 3.11. 977 o If that fails with a 480 error, send an invitation with no Accept- 978 Contact or Reject-Contact headers. 980 3.13. Routing to an Executive 982 3.13.1. Desired Behavior 984 Y is the AOR of an executive. It has three contacts. Y1 is the 985 phone on the executive's desk. Y2 is the phone on the desk of the 986 executive's assistant. Y3 is the address of an auto-attendant system 987 that can answer general questions, route calls to other parties, etc. 988 By default, calls to Y should be directed to Y2, and if that fails, 989 to Y3. If Y3 doesn't answer then Y1 should ring. 991 3.13.2. Solution 993 This is primarily a called party feature, and is best accomplished 994 with a CPL (Call Processing Language) script [5]. However, it can be 995 accomplished with caller preferences alone by properly setting the 996 q-values across the three devices. Assuming this coordination is 997 possible, here are the settings that would be made: 999 Y1 would generate a REGISTER that looks like, in part: 1001 REGISTER sip:example.com SIP/2.0 1002 To: sip:Y@example.com 1003 Contact: ;q=0.1 1005 Y2 would generate a REGISTER that looks like, in part: 1007 REGISTER sip:example.com SIP/2.0 1008 To: sip:Y@example.com 1009 Contact: ;attendant;q=1.0 1011 Y3 would generate a REGISTER that looks like, in part: 1013 REGISTER sip:example.com SIP/2.0 1014 To: sip:Y@example.com 1015 Contact: ;attendant;automata;q=0.5 1017 Note that, in reality, the automated attendant would probably not use 1018 REGISTER. Since the attendant would be used for every employee in 1019 the company, a static contact would probably be added 1020 administratively for each user in the enterprise. However, the 1021 information in that static contact would be identical to the 1022 information in the registration above. 1024 When X makes a call to the executive, Y, and expresses no preference, 1025 the proxy computes an implicit preference to support INVITE. All 1026 three contacts match such a preference, even though they have not 1027 indicated explicit support for INVITE. Thus, no contacts are 1028 discarded. Since the contacts each have a different q-value, the 1029 caller preferences do not cause any reordering. The result is that 1030 the call is first routed to Y2, then Y3, then Y1, all as a result of 1031 the proper setting of the q-values. 1033 3.14. Speak to the Executive 1035 3.14.1. Desired Behavior 1037 This case is similar to that of Section 3.13, but this time the 1038 caller, X, has a preference. X calls Y, but wants to speak directly 1039 to the executive. X doesn't want the call to ring either the 1040 assistant or the auto attendant (automaton). 1042 3.14.2. Solution 1044 X's INVITE would look like, in part: 1046 INVITE sip:Y@example.com SIP/2.0 1047 Reject-Contact: *;attendant 1048 Reject-Contact: *;automata 1050 Note that the caller uses two separate Reject-Contact header field 1051 values, rather than a single one with two separate feature 1052 parameters. The distinction is important. If X had use a single 1053 value with two parameters, a matching UA would need to declare that 1054 it was BOTH an attendant and an automaton. If it only declared that 1055 it was one of these, based on the matching rules in the caller 1056 preferences specification, it would not be rejected. 1058 The above request would result in the elimination of both Y2 and Y3 1059 as contacts. The call would then be routed to Y1, as desired. 1061 This case indicates why a CPL script, or some other programmed 1062 version of the feature, is preferrable. With caller preferences, a 1063 caller can override the desired ring sequence, and disturb the 1064 executive without any kind of authorization. A proper version of 1065 this service would simply not permit caller preferences to force the 1066 call to go directly to the executive. 1068 3.15. Mobile Phone Only 1070 3.15.1. Desired Behavior 1072 The situation is similar to that in Section 3.13. However, the 1073 executive also has a mobile phone which they have registered. Caller 1074 X knows that the owner of Y is traveling, and that an assistant is 1075 covering the office phone. X wants to call Y and ring only the 1076 mobile phone. 1078 3.15.2. Solution 1080 The mobile phone would generate a registration which looks like, in 1081 part: 1083 REGISTER sip:example.com SIP/2.0 1084 To: sip:Y@example.com 1085 Contact: ;mobility="mobile";q=0.1 1087 The caller would express their preference by generating an INVITE 1088 which looks like, in part: 1090 INVITE sip:Y@example.com SIP/2.0 1091 Accept-Contact: *;mobility="mobile";require;explicit 1092 All four contacts match. However, Y1 through Y3 match with a score 1093 of zero. Y4 matches with a score of 1. Because of the require and 1094 explicit tags, Y1 through Y3 are discarded, and only Y4 is used, as 1095 desired. 1097 Note that this only works if the mobile phone specifies the mobility 1098 feature in its registration. 1100 3.16. Simultaneous Languages 1102 3.16.1. Desired Behavior 1104 AOR Y is as in Section 3.9. Caller X, fluent in both English and 1105 Spanish, has discovered that company's Spanish language documentation 1106 is inconsistent with the English language documentation, and wants to 1107 discuss the differences between the two. So X wants to speak with 1108 one of the workers that is fluent in both English and Spanish. 1110 3.16.2. Solution 1112 The caller would generate an INVITE which looks like, in part: 1114 INVITE sip:Y@example.com SIP/2.0 1115 Accept-Contact: *;language="en";require 1116 Accept-Contact: *;language="es";require 1118 This will require a Contact URI to match both constraints. That 1119 means it needs to support English and Spanish. This will achieve the 1120 desired property. 1122 Note that there are two separate Accept-Contact header fields. If 1123 the caller had instead used this INVITE: 1125 INVITE sip:Y@example.com SIP/2.0 1126 Accept-Contact: *;language="en,es";require 1128 It would have connected them to a UA that speaks either English or 1129 Spanish, which is not what is desired here. 1131 An explicit option is not used, because it would bypass contacts that 1132 do not include a language tag. 1134 3.17. The Number you Have Called.. 1136 3.17.1. Desired Behavior 1138 Consider once more the case of the executive, where the caller wishes 1139 to reach only their mobile phone (Section 3.15). However, there is a 1140 twist. The callee Y has moved to new address YY, and all the 1141 configuration described for the callee now applies to YY. The old 1142 address Y remains with a pair of statically assigned contacts. One 1143 contact is YY. The other is M referencing an automaton that 1144 generates a voice message reporting that the number has been changed. 1145 The caller is unaware of the move and calls Y, requesting to reach 1146 the mobile phone in exactly the same way they did in Section 3.15. 1147 The call should connect to the mobile. 1149 3.17.2. Solution 1151 There would be four registrations against YY: 1153 YY1, the executive, would generate a REGISTER that looks like, in 1154 part: 1156 REGISTER sip:example.com SIP/2.0 1157 To: sip:YY@example.com 1158 Contact: ;q=0.1 1160 YY2, the attendant, would generate a REGISTER that looks like, in 1161 part: 1163 REGISTER sip:example.com SIP/2.0 1164 To: sip:YY@example.com 1165 Contact: ;attendant;q=1.0 1167 YY3, the answering service, would generate a REGISTER that looks 1168 like, in part: 1170 REGISTER sip:example.com SIP/2.0 1171 To: sip:YY@example.com 1172 Contact: ;attendant;automata;q=0.5 1174 YY4, the mobile, would generate a REGISTER that looks like, in part: 1176 REGISTER sip:example.com SIP/2.0 1177 To: sip:YY@example.com 1178 Contact: ;mobility="mobile";q=0.5 1179 Athough it would be configured administratively, there are two 1180 registered contacts for Y. The first is for the forwarding: 1182 REGISTER sip:example.com SIP/2.0 1183 To: sip:Y@example.com 1184 Contact: ;q=1.0 1186 and the second for the automated answering service: 1188 REGISTER sip:example.com SIP/2.0 1189 To: sip:Y@example.com 1190 Contact: ;automata;q=0.5 1192 The caller, not knowing that Y has moved, calls Y and asks for their 1193 mobile phone: 1195 INVITE sip:Y@example.com SIP/2.0 1196 Accept-Contact: *;mobility="mobile";require;explicit 1198 This reaches the example.com proxy, which finds two registrations. 1199 Only one of these (the automaton) is associated with feature 1200 parameters. The other has no feature parameters, and is therefore 1201 immune from caller preferences processing. The caller preferences 1202 are applied to the the automaton's contact. The feature sets match, 1203 but have a score of zero. Since the require and explicit tags are 1204 present, the contact for the automaton is dropped. The other 1205 contact, YY@example.com, is then added back in as the sole contact. 1206 The proxy therefore sends the call to sip:YY@example.com. There, 1207 there are four registrations, all of which are associated with 1208 feature parameters. The caller preferences are applied. Only YY4 1209 matches explicitly, however. Because of the presence of the require 1210 and explicit flags, all other contacts are dropped. As such, the 1211 call is forwarded to YY4, and the mobile phone rings. 1213 3.18. The Number you Have Called, Take Two 1215 3.18.1. Desired Behavior 1217 This use case is nearly identical to that of Section 3.17. However, 1218 this time, the caller wishes to contact the personal phone of Y. They 1219 don't feel strongly about it, and will accept other devices. 1221 3.18.2. Solution 1223 The INVITE generated by the caller in this case will look like: 1225 INVITE sip:Y@example.com SIP/2.0 1226 Accept-Contact: *;class="personal" 1228 This reaches the example.com proxy. Once more, the first 1229 registration (which forwards to the address-of-record for YY) is 1230 unaffected by the caller preferences computation. The other contact, 1231 for the automaton, is a match, but its score is zero. Its caller 1232 preference Qa equals zero. The other contact is added back in with a 1233 Qa of 1.0. The contacts are sorted based on q-value, resulting in YY 1234 (q=1.0) followed by machine (q=0.5). These are broken into 1235 equivalence classes. There are two classes, one for each contact. 1236 As a result, the caller's preferences have no impact on the ordering, 1237 and the call is routed to YY. 1239 When processing the request for YY@example.com, all four contacts 1240 match. However, the score for all of them is zero (none are the 1241 personal phone). As such, the contacts are ordered based on q-value. 1242 Each contact has a different q-value, so no reordering based on 1243 caller preference is possible (not that the caller preference would 1244 cause a reordering - all contacts have a Qa of 0.0). Thus, the 1245 highest q-value contact is tried, which is the executive assistant. 1247 3.19. Forwarding to a Colleague 1249 3.19.1. Desired Behavior 1251 Alice wants to forward her phone to Bob, but doesn't want folks 1252 calling her to get Bob's voicemail if he doesn't answer. She wants 1253 her callers to get her voicemail. 1255 3.19.2. Solution 1257 Alice would create three registrations. The first, Y1, represents 1258 Alice's phone. The second is Bob's AOR. The third is a voicemail 1259 server. The three contacts have decreasing q-values. The 1260 registration for Bob's AOR contains an embedded Reject-Contact header 1261 field, which rejects message servers. 1263 REGISTER sip:example.com 1264 To: 1265 Contact: ;q=1.0 1267 REGISTER sip:example.com 1268 To: 1269 Contact: ;q=0.3 1270 REGISTER sip:example.com 1271 To: 1272 Contact: 1273 ;msgserver; 1274 ;automata 1275 ;attendant 1276 ;q=0.1 1278 Meanwhile, Bob is registered as follows: 1280 REGISTER sip:example.com 1281 To: 1282 Contact: ;q=0.8 1284 REGISTER sip:example.com 1285 To: 1286 Contact: 1287 ;msgserver 1288 ;automata 1289 ;attendant 1290 ;q=0.2 1292 Carol calls Alice, and doesn't include any caller preference 1293 parameters. As such, the example.com proxy constructs an implicit 1294 preference for INVITE. This preference matches all three registered 1295 contacts, with a score of zero. Because each contact has a different 1296 q-value, there is no reordering of contacts. So, the proxy tries the 1297 highest q-value Contact, Alice's desk phone (Y1). The proxy cancels 1298 after a few seconds (no answer). The proxy then tries the next 1299 Contact, which is Bob's AOR. When constructing the request for this 1300 Contact, the proxy includes the embedded Reject-Contact header field 1301 in the INVITE. This INVITE undergoes caller preferences processing 1302 based on Bob's registered Contacts. 1304 Bob has two registered Contacts. The second is a message server, and 1305 it matches the Reject-Contact in the INVITE. Thus, this contact is 1306 discarded. The other remaining Contact, Bob's phone, is tried. Bob 1307 is not around, and so his phone rings for a while. Upon timeout, the 1308 proxy determines it is unable to reach Bob's AOR. So, the proxy 1309 handling Alice tries the final remaining contact, which is Alice's 1310 message server. 1312 4. Capability Use Cases 1314 The callee capabilities spec [2] allows the Contact header field in 1315 OPTIONS responses and dialog initiating messages to contain 1316 capabilities of the UA. These capabilities can be very useful for 1317 developing new applications. In the subsections below, several 1318 usages are outlined. 1320 4.1. Web Redirect 1322 A caller sends an INVITE to the called party. However, the called 1323 party is not present. The proxy server representing the called party 1324 would like to redirect the caller to a web page, where they can find 1325 out more information on how to reach the called party. However, the 1326 proxy needs to know whether or not the caller supports redirects to 1327 web pages. If it doesn't, the proxy would connect the user to an 1328 IVR, which would execute an answering machine application. 1330 The proxy could make such a determination if the caller included the 1331 "schemes" feature tag in the Contact header field of its INVITE: 1333 INVITE sip:callee@example.com SIP/2.0 1334 Contact: ;schemes="http,sip,sips,tel" 1336 This tells the proxy that the UAC can be redirected to an http URI. 1337 The INVITE from a normal "black phone" which lacked this capability 1338 would look like: 1340 INVITE sip:callee@example.com SIP/2.0 1341 Contact: ;schemes="sip,sips,tel" 1343 which indicates that it needs to be connected to the IVR. 1345 4.2. Voicemail Icon 1347 On the circuit network, when a user makes a call, and an answering 1348 machine picks up, the caller usually requires several seconds to make 1349 the determination that they are speaking to an answering machine. It 1350 would be helpful if a phone could display an icon immediately on call 1351 completion that indicated that an answering machine was reached. 1353 This indication can be provided by the "msgserver" feature parameter. 1354 When the answering machine picks up, its 200 OK looks like, in part: 1356 SIP/2.0 200 OK 1357 Contact: ;msgserver;automata;attendant 1359 This tells the caller that its an answering machine. 1361 5. Usage of the Feature Tags 1363 The caller preferences extension briefly enumerates a list of media 1364 feature tags which can be registered by a device, and included in the 1365 Accept-Contact and Reject-Contact header fields in a request. Proper 1366 operation of caller preferences depends strongly on consistent 1367 interpretation of these feature tags by the caller and the callee. 1368 In this section, we provide some guidelines on the usage of these 1369 feature tags. 1371 Generally speaking, the more information a device provides when it 1372 registers, the more effective the caller preferences extension is. 1373 This is why the callee capabilities extension recommends that a 1374 device register as much information as it can. This point cannot be 1375 overstated. 1377 If devices explicitly registered features that they don't support, 1378 such as 'video="false"', the operation of RFC3841 would be improved. 1379 However, given the open ended nature of capabilities it will never be 1380 possible to ensure the registration of negative values for all 1381 capabilities of interest to a caller. And attempting to do so would 1382 significantly bloat registrations. Instead, it is recommended that 1383 all "unusual" capabilities be explicitly registered. 1385 The subsections below show example registrations from typical 1386 devices. 1388 5.1. Traditional Cell Phone 1390 A VoIP cell phone capable of making voice calls would generate a 1391 registration that looks like, in part: 1393 REGISTER sip:example.com SIP/2.0 1394 To: sip:user@example.com 1395 Contact: 1396 ;audio 1397 ;class="business" 1398 ;duplex="full" 1399 ;+sip.extensions="100rel,path" 1400 ;mobility="mobile" 1401 ;methods="INVITE,BYE,OPTIONS,CANCEL,ACK" 1402 ;schemes="sip,sips,tel" 1403 ;uri-user="" 1404 ;uri-domain="example.com" 1406 5.2. Traditional Work Phone 1408 A traditional landline IP PBX phone would generate a registration 1409 that looks like: 1411 REGISTER sip:example.com SIP/2.0 1412 To: sip:user@example.com 1413 Contact: 1414 ;audio 1415 ;class="business" 1416 ;duplex="full" 1417 ;events="dialog" 1418 ;+sip.extensions="100rel,privacy" 1419 ;mobility="fixed" 1420 ;methods="INVITE,BYE,OPTIONS,CANCEL,ACK,SUBSCRIBE" 1421 ;schemes="sip,sips,tel" 1422 ;uri-user="" 1423 ;uri-domain="example.com" 1425 This device also supports the dialog event package and several SIP 1426 extension that would be typical in an IP PBX phone. 1428 5.3. PC Messenging Application 1430 A PC messenger client, capable of just doing presence and IM (no 1431 voice) would generate a registration that looks like: 1433 REGISTER sip:example.com SIP/2.0 1434 To: sip:user@example.com 1435 Contact: 1436 ;class="personal" 1437 ;mobility="fixed" 1438 ;methods="OPTIONS,MESSAGE,NOTIFY" 1439 ;schemes="sip,sips,im,pres" 1440 ;uri-user="" 1441 ;uri-domain="example.com" 1443 5.4. Standalone Videophone 1445 A standalone IP videophone, capable of audio and video would generate 1446 a registration that looks like, in part 1447 REGISTER sip:example.com SIP/2.0 1448 To: sip:user@example.com 1449 Contact: 1450 ;audio 1451 ;video 1452 ;class="business" 1453 ;duplex="full" 1454 ;mobility="fixed" 1455 ;methods="INVITE,BYE,OPTIONS,CANCEL,ACK" 1456 ;schemes="sip,sips,tel" 1457 ;uri-user="" 1458 ;uri-domain="example.com" 1460 6. Example Implementation of Preference and Capability Matching 1462 RFC3841 [3] utilizes the definitions and feature matching algorithm 1463 defined in RFC2533 [6]. That provides a precise normative 1464 specification of the algorithm. However that specification isn't 1465 ideal as a guideline for implementation, because it is more complex 1466 than is required for the restricted use employed by RFC3841. (The 1467 simplification is primarily because a particular feature tag may only 1468 appear once in each Contact, Accept-Contact, or Reject-Contact 1469 header.) 1471 This section provides a sample approach to implementing the matching 1472 of caller preferences to callee capabilities, that does not require 1473 the use of the notation and techniques of RFC2533. It is not 1474 normative, but is believed to be consistent with that definition. It 1475 may be considered an alternative for that portion of RFC3841 1476 beginning with section 7.2.3 and extending to the end of page 13 in 1477 the middle of section 7.2.4. 1479 In this section there are frequent references to syntactic elements 1480 defined by ABNF in RFC 3840 section 9 and RFC 3841 section 10. Here, 1481 ABNF elements are enclosed to single quotes - for example 'feature- 1482 param'. Such a reference identifies a sequence of octets within a 1483 SIP request that match the corresponding ABNF element when the sip 1484 request is parsed according to RFCs 3261, 3840, and 3841. 1486 6.1. Extracting a Feature Set from a Header 1488 Contact header fields, Accept-Contact header fields and Reject- 1489 Contact header fields each contain zero or more 'feature-param's, 1490 each in turn may contain one or more 'tag-value's, or a 'string- 1491 value'. The first step is to extract from each header field a more 1492 useful representation as a feature set, herein called an FS. (This 1493 FS representation of a feature set representation differs from that 1494 in RFC2533.) This process is the same for each type of header. 1496 An FS consists of a set of one or more feature params denoted by FP. 1497 Each FP has a name, denoted FP.NAME, and a set of one or more value 1498 ranges denoted by VR. Each VR consists of: 1499 o A type (VR.TYPE): either token (TOKEN-TYPE), string (STRING-TYPE), 1500 or number-range (RANGE-TYPE) 1501 o A negation flag (VR.NEGATION): either NEGATED, or NON-NEGATED 1502 o The actual value, differing by type: 1503 * For TOKEN-TYPE and STRING-TYPE, a sequence of octets 1504 (VR.OCTETS) 1505 * For RANGE-TYPE, a pair of signed real numbers (VR.LB and VR.UB) 1506 representing the lower and upper bounds on the range, 1507 inclusive. 1509 A single FS is created to represent the features of one header. 1510 (Contact, Accept-Contact, Reject-Contact.) Within the FS an FP is 1511 created for each 'feature-param' in the header. To create an FP, a 1512 'feature-param' is examined as follows: 1513 o If the 'feature-param' contains an instance of 'other-tags', then 1514 FP.NAME is the value matched by 'ftag-name'. 1515 o Otherwise the 'feature-param' contains an instance of 'base-tags'. 1516 If the value matched by 'base-tags' is "language" or "type", then 1517 FP.NAME is just the value matched by 'base-tags'. If not, then 1518 FP.NAME is the value matched by 'base-tags' prefixed with "sip.". 1519 o The value of the 'feature-param', if any, is processed (according 1520 to the rules in the next section) to extract a set of one or more 1521 VRs which are associated with the FP. 1523 6.2. Extracting Values from a Feature Parameter 1525 The value of a 'feature-param' is an encoded representation (as 1526 specified in RFC3840) of one or more value ranges of the 1527 corresponding feature. There are several data types that these 1528 values may take on: boolean, token, string, number or numeric range. 1529 The type is determined by the encoded form of the value. (These 1530 types and their representations are specific to this implementation.) 1532 (Note: numeric values can explicitly represent a range of values. 1533 The other types only represent single value - a degenerate range. 1534 The term value range is used to encompass all of these.) 1536 The value of the 'feature-param', ('string-value', 'tag-value-list', 1537 or none) is converted to VR form as follows: 1538 o If there is no value, then a single new VR is created with VR.TYPE 1539 = TOKEN-TYPE, VR.NEGATION = NON-NEGATED, and VR.OCTETS set to 1540 "true". 1542 o If the 'feature-param' contains a 'string-value', then a single 1543 new VR is created with VR.TYPE = STRING-TYPE, VR.NEGATION = NON- 1544 NEGATED, and VR.OCTETS is set to the octets matching 'qdtext'. 1545 o Otherwise the 'feature-param' contains a 'tag-value-list', and a 1546 new VR is created for each 'tag-value' in the 'tag-value-list', as 1547 follows: 1548 o If the 'tag-value' begins with "!", VR.NEGATION = NEGATED, 1549 otherwise VR.NEGATION = NON-NEGATED. 1550 o If the 'tag-value' contains a 'boolean' or 'token-nobang', then 1551 VR.TYPE = TOKEN-TYPE, and VR.OCTETS is set to the octets matched 1552 by 'boolean' or 'token-nobang'. 1553 o If the 'tag-value' contains a 'numeric', VR.TYPE = RANGE-TYPE and: 1554 * If 'numeric-relation' is "<=" VR.UB is set to the numeric value 1555 matching 'number'. VR.LB is set to MIN-REAL (a negative number 1556 with the largest expressible magnitude.) 1557 * If 'numeric-relation' is "=" both VR.LB and VR.UB are set to 1558 the numeric value matching 'number'. 1559 * If 'numeric-relation' is ">=" VR.LB is set to the numeric value 1560 matching 'number' plus a small epsilon. VR.UB is set to MAX- 1561 REAL (a positive number with the largest expressible 1562 magnitude.) 1563 * Else the 'numeric-relation' consists of two 'number's separated 1564 by a colon. In this case, VR.LB is set to the numeric value of 1565 the smaller of the two numbers, and VR.UB is set to the numeric 1566 value of the larger of the two numbers. 1568 6.3. Comparing Two Value-Ranges 1570 Two VRs match if their ranges overlap. The comparison is done 1571 according to type and only comparisons between like types is defined. 1572 When two VRs of differing types are compared they are considered not 1573 to overlap. Either or both of the VRs may be NEGATED. Comparison 1574 proceeds as follows: 1575 o If the VRs are of different types, the match is false. 1576 o Otherwise: 1577 * Two VRs with VR.TYPE = RANGE-TYPE match if max(VR1.LB, VR2.LB) 1578 <= min(VR1.UB, VR2.UB) 1579 * Two VRs with VR.TYPE = TOKEN-TYPE match if their respective 1580 VR.OCTETS values compare equal by case insensitive comparison 1581 * Two VRs with VR.TYPE = STRING-TYPE match if their respective 1582 VR.OCTETS values compare equal by case sensitive comparison 1583 o The result (true/false) is then negated if VR1.NEGATION = NEGATED, 1584 and negated again if VR2.NEGATION = NEGATED. 1586 6.4. Feature Set to Feature Set Matching 1588 In RFC2533 the matching of two feature sets is commutative, but as 1589 applied to caller preferences matching it is not. In this 1590 application one feature set comes from an Accept-Contact or Reject- 1591 Contact header, and the other comes from a Contact header. For 1592 purposes of this description these will be termed the preferred- 1593 features (FSp) and the capability-features (FSc) respectively. Non- 1594 commutativity arises from explicit tests for the presence among 1595 capability-params of feature param names used in preferred-features. 1597 A preferred-features feature set FSp may be matched to one 1598 capability-features feature set FSc, and yields the following 1599 metrics: 1600 o NPF - The number of preferred-features 1601 o NCF - The number of preferred-features for which there is a 1602 capability-feature of the same name 1603 o NVM - The number of value matches between corresponding features 1604 of the two feature sets 1606 For a particular pair of FPp and FPc, these metrics are computed as 1607 follows: 1608 o All the metrics are set to zero 1609 o The following steps are applied for each feature param (FPp) of 1610 the FSp: 1611 * NPF is incremented 1612 * A corresponding FP with the same name is sought (using case- 1613 insensitive comparison) in the FSc. 1614 * If a corresponding feature param (FPc) is found: 1615 + NCF is incremented. 1616 + Every VR of FPp is matched to every VR of FPc. 1617 + If any of those matches succeed, NVM is incremented 1619 6.5. Selecting and Ordering Contacts Based on Caller Preferences 1621 6.5.1. Reject-Contact Processing 1623 The reject processing specified in section 7.4.2 of RFC3841 may be 1624 performed as follows: 1625 o For each candidate Contact in the target set, match the feature 1626 set of each Reject-Contact to it. 1627 o If (NVM == NPF) & (NCF == NPF), remove the contact URI from the 1628 target set. 1630 6.5.2. Accept-Contact Processing 1632 The matching of an Accept-Contact against a Contact and subsequent 1633 scoring of the match specified in section 7.4.2 of RFC3841 may be 1634 performed as follows: 1635 o Match the feature set of the Accept-Contact to that of the Contact 1636 as specified in Section 6.4. 1638 o If (NVM < NCF) then the match failed. If the Accept-Contact had 1639 its require flag set then discard the corresponding contact URI 1640 from the target set. 1641 o Compute the score as NVM/NPF 1642 o Apply the require and explicit flags as specified in the text and 1643 Figure 7 of RFC3841. 1645 7. Security Considerations 1647 This document provides explanation and examples of the use and 1648 implementation of RFC3840 and RFC3841. The security considerations 1649 sections of those documents apply to the material presented here. 1651 8. IANA Considerations 1653 There are no IANA considerations associated with this specification. 1655 9. Acknowledgements 1657 The authors would like to thank Rohan Mahy for his input in this 1658 specification. 1660 10. Informative References 1662 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1663 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 1664 Session Initiation Protocol", RFC 3261, June 2002. 1666 [2] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating 1667 User Agent Capabilities in the Session Initiation Protocol 1668 (SIP)", RFC 3840, August 2004. 1670 [3] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller 1671 Preferences for the Session Initiation Protocol (SIP)", 1672 RFC 3841, August 2004. 1674 [4] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J., and B. 1675 Rosen, "Change Process for the Session Initiation Protocol 1676 (SIP)", BCP 67, RFC 3427, December 2002. 1678 [5] Lennox, J. and H. Schulzrinne, "Call Processing Language 1679 Framework and Requirements", RFC 2824, May 2000. 1681 [6] Klyne, G., "A Syntax for Describing Media Feature Sets", 1682 RFC 2533, March 1999. 1684 [7] Rosenberg, J., "An INVITE Inititiated Dialog Event Package for 1685 the Session Initiation Protocol (SIP)", 1686 draft-ietf-sipping-dialog-package-06 (work in progress), 1687 April 2005. 1689 [8] Rosenberg, J., "A Presence Event Package for the Session 1690 Initiation Protocol (SIP)", draft-ietf-simple-presence-10 (work 1691 in progress), January 2003. 1693 [9] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, 1694 "Best Current Practices for Third Party Call Control in the 1695 Session Initiation Protocol", draft-ietf-sipping-3pcc-06 (work 1696 in progress), January 2004. 1698 [10] Campbell, B., "The Message Session Relay Protocol", 1699 draft-ietf-simple-message-sessions-11 (work in progress), 1700 July 2005. 1702 Authors' Addresses 1704 Jonathan Rosenberg 1705 Cisco Systems 1706 600 Lanidex Plaza 1707 Parsippany, NJ 07054 1708 US 1710 Phone: +1 973 952-5000 1711 Email: jdrosen@cisco.com 1712 URI: http://www.jdrosen.net 1714 Paul Kyzivat 1715 Cisco Systems 1716 1414 Massachusetts Avenue 1717 Boxborough, MA 01719 1718 US 1720 Phone: +1 978 936-1881 1721 Email: pkyzivat@cisco.com 1723 Intellectual Property Statement 1725 The IETF takes no position regarding the validity or scope of any 1726 Intellectual Property Rights or other rights that might be claimed to 1727 pertain to the implementation or use of the technology described in 1728 this document or the extent to which any license under such rights 1729 might or might not be available; nor does it represent that it has 1730 made any independent effort to identify any such rights. Information 1731 on the procedures with respect to rights in RFC documents can be 1732 found in BCP 78 and BCP 79. 1734 Copies of IPR disclosures made to the IETF Secretariat and any 1735 assurances of licenses to be made available, or the result of an 1736 attempt made to obtain a general license or permission for the use of 1737 such proprietary rights by implementers or users of this 1738 specification can be obtained from the IETF on-line IPR repository at 1739 http://www.ietf.org/ipr. 1741 The IETF invites any interested party to bring to its attention any 1742 copyrights, patents or patent applications, or other proprietary 1743 rights that may cover technology that may be required to implement 1744 this standard. Please address the information to the IETF at 1745 ietf-ipr@ietf.org. 1747 Disclaimer of Validity 1749 This document and the information contained herein are provided on an 1750 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1751 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1752 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1753 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1754 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1755 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1757 Copyright Statement 1759 Copyright (C) The Internet Society (2005). This document is subject 1760 to the rights, licenses and restrictions contained in BCP 78, and 1761 except as set forth therein, the authors retain all their rights. 1763 Acknowledgment 1765 Funding for the RFC Editor function is currently provided by the 1766 Internet Society.