idnits 2.17.1 draft-rosenberg-sipping-callerprefs-usecases-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 4 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (February 24, 2003) is 7731 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. '2') (Obsoleted by RFC 5727) Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force SIPPING WG 3 Internet Draft J. Rosenberg 4 dynamicsoft 5 P. Kyzivat 6 Cisco 7 draft-rosenberg-sipping-callerprefs-usecases-00.txt 8 February 24, 2003 9 Expires: August 2003 11 Use Cases for Session Initiation Protocol (SIP) Caller Preferences 13 STATUS OF THIS MEMO 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 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 To view the list Internet-Draft Shadow Directories, see 32 http://www.ietf.org/shadow.html. 34 Abstract 36 This document describes a set of use cases for the SIP Caller 37 Preferences and Callee Capabilities extension. Each use case is 38 presented as a desired routing decision, followed by the actual 39 headers and processing logic which would result in that decision. 41 1 Introduction 43 The SIP extension for Caller Preferences and Callee Capabilities [1] 44 describes mechanisms that allow a UA to register its capabilities in 45 a REGISTER request. A caller can express preferences, either 46 explicitly or implicitly, about how that request is to be handled. 47 This is accomplished with the Accept-Contact and Reject-Contact 48 header fields. 50 The purpose of this document is to demonstrate the ability of these 51 basic primitives to meet the needs of many different routing 52 problems. To do that, it presents a set of use cases. Each use case 53 is described as a situation along with a desired routing goal. Then, 54 it demonstrates how the various caller preferences headers and the 55 proxy processing logic would result in the appropriate decision being 56 made. 58 Demonstrating the ability of caller preferences to meet the needs of 59 these routing problems serves two higher level goals. The first is to 60 validate that the caller preferences specification is complete, and 61 capable of solving real requirements. Since the caller preferences 62 specification pre-dates the SIP change process [2], no requirements 63 work was ever done for this extension. To some degree, this document 64 "backfills" requirements. However, this is not an academic exercise 65 only, since the use cases described here did result in changes in the 66 specification in later versions. 68 The second goal of the usage cases is to motivate support for the 69 draft. The caller preferences specification has received scant 70 attention from the working group beyond the authors of this document. 71 This is likely because people are not aware of the scope of problems 72 which this extension can solve. 74 2 Routing of INVITE and MESSAGE to different UA 76 2.1 Desired Behavior 78 Address of Record (AOR) Y has two contacts Y1 and Y2. Y1 is a phone, 79 and supports the standard operations INVITE, ACK, OPTIONS, BYE, and 80 so on, while Y2 is a pager and supports only OPTIONS and MESSAGE. 81 Caller X wants to send pages to Y. There is a lot of traffic in the 82 network of both calls and pages, so there is a goal not to 83 unnecessarily fork messages to devices that can't support them. So, 84 ensure that INVITEs of Y are delivered only to Y1, while MESSAGEs to 85 Y are delivered only to Y2. 87 2.2 Solution 88 Y1 will create a registration which looks like, in part: 90 REGISTER sip:example.com SIP/2.0 91 To: sip:Y@example.com 92 Contact: ;methods="INVITE,ACK,OPTIONS,BYE,CANCEL" 94 Y2 will create a registration which looks like, in part: 96 REGISTER sip:example.com SIP/2.0 97 To: sip:Y@example.com 98 Contact: ;methods="OPTIONS,MESSAGE" 100 When a UAC sends an INVITE, it will arrive at the proxy for 101 example.com. There are no caller preferences in the request. However, 102 per Section 7.2.2 of [1], the proxy will construct an implicit 103 require-tagged Accept-Contact preference that looks like: 105 (& (methods="INVITE")) 107 Applying the matching algorithm of RFC 2533 [3] to this feature set 108 and those registered by Y1 and Y2, the feature set of Y1 alone 109 matches. Thus, Y2 is discarded and the INVITE is routed to Y1. 111 If the request was MESSAGE, the proxy constructs an implicit 112 require-tagged Accept-Contact preference that looks like: 114 (& (methods="MESSAGE")) 116 which matches the feature set of Y2, but not Y1. Thus, Y1 is 117 discarded, and the request is routed to Y2. 119 3 Single Contact Not Matching Implicit Preferences 121 3.1 Desired Behavior 123 AOR Y has a single contact Y1. Its a phone, and therefore supports 124 the INVITE, BYE, OPTIONS, CANCEL and ACK methods, but not MESSAGE. A 125 caller X sends a MESSAGE request. The desired behavior is that the 126 request is still routed to the solitary contact so that it can 127 generate a 405 response. 129 3.2 Solution 131 The single contact Y1 will generate a registration which looks like, 132 in part: 134 REGISTER sip:example.com SIP/2.0 135 To: sip:Y@example.com 136 Contact: ;methods="INVITE,ACK,OPTIONS,BYE,CANCEL" 138 X sends a MESSAGE request. This results in an implicit require-tagged 139 Accept-Contact preference: 141 (& (methods="MESSAGE")) 143 Since Y1 doesn't match, it is discarded. However, according to the 144 specifications, if there are no matching targets, the preference 145 operation is re-run without implicit preferences. Since there were no 146 explict preferences, the request is routed without the caller 147 preferences processing at all, and is sent to the single contact Y1 148 as desired. 150 4 Package-Based Routing 152 4.1 Desired Behavior 154 AOR Y has a number of contacts, Y1, Y2, ..., Yn that can each support 155 normal calls - INVITE, ACK, BYE, etc., and that can also support 156 SUBSCRIBE for the "dialog" event package [4]. Y also has another 157 contact YP that is a presence agent [5] - it can accept SUBSCRIBE 158 requests for the "presence" event package. The goal is for subscribe 159 requests for presence to be routed to YP while invites and subscribes 160 for the dialog package are forked to Y1...Yn. 162 4.2 Solution 164 Y1..Yn will generate REGISTER requests which look like, in part: 166 REGISTER sip:example.com SIP/2.0 167 To: sip:Y@example.com 168 Contact: 169 ;methods="INVITE,BYE,OPTIONS,ACK,CANCEL,SUBSCRIBE" 170 ;events="dialog" 172 and Yp will generate a REGISTER request which looks like, in part: 174 REGISTER sip:example.com SIP/2.0 175 To: sip:Y@example.com 176 Contact: ;methods="SUBSCRIBE";events="presence" 178 A SUBSCRIBE request for presence will arrive at the proxy for 179 example.com. It constructs an implicit require-tagged Accept-Contact 180 preference from the request: 182 (& (methods="SUBSCRIBE") (events="presence")) 184 This feature set only matches the one registered by Yp. Therefore, 185 Y1..Yn are eliminated, and the request is properly routed to the PA. 186 Note that, had Y1..Yn not registered the event packages they support, 187 the proxy would have preferentially routed the request to YP, and if 188 that had failed, then forked to Y1..Yn. That is because of the 189 greater score associated with YP. 191 INVITE requests result in an implicit require-tagged Accept-Contact 192 preference: 194 (& (methods="INVITE")) 196 The implicit Accept-Contact feature set matches Y1..Yn, but not Yp. 197 Thus, Yp is discarded and the call is delivered to Y1..Yn only. 199 A SUBSCRIBE for the dialog event package will result in an implicit 200 require-tagged Accept-Contact preference: 202 (& (methods="SUBSCRIBE") (events="dialog")) 204 This only matches Y1..Yn, so Yp is discarded, and the request is 205 routed to the remaining contacts. 207 5 Audio/Video vs. Audio Only 209 5.1 Desired Behavior 211 X sends an invitation to Y to initiate an audio/video call, including 212 both m=audio and m=video lines in the SDP. AOR Y has two contacts, Y1 213 and Y2. Y1 represents a normal audio phone which is preferred for 214 normal audio calls. It will answer an audio/video call, refusing the 215 video. Y2 represents an audio/video phone that should only used when 216 needed. The caller really wants the called answered by a device that 217 supports video. 219 5.2 Solution 221 Y1 will generate a registration which looks like, in part: 223 REGISTER sip:example.com SIP/2.0 224 To: sip:Y@example.com 225 Contact: ;audio;q=1.0 227 Y2 will generate a registration which looks like, in part: 229 REGISTER sip:example.com SIP/2.0 230 To: sip:Y@example.com 231 Contact: ;audio;video;q=0.2 233 Note the different q-values, allowing Y2 to be selected as a device 234 of "last resort". Of course, both Y1 and Y2 need to be configured to 235 express these two q-values. 237 To ensure that the call is preferentially routed to a device that 238 supports video, the caller X sends an INVITE that looks like, in 239 part: 241 INVITE sip:Y@example.com SIP/2.0 242 Accept-Contact: *;video;require 244 The proxy will convert this to a feature predicate and also compute 245 an implicit preference to support INVITE. Since neither contact 246 indicated anything about methods, the implicit preference matches 247 both and has no effect on the relative q-values. 249 The explicit feature set from the Accept-Contact matches Y2 and Y1. 250 However, the score for Y2 is 1, and 0 for Y1. The result is that the 251 audio/video phone (Y2) will receive the call first. 253 6 Audio/Video vs. Audio Only: A/V UA Fails 255 6.1 Desired Behavior 257 This case is identical to that of Section 5. However, for some reason 258 the Audio/Video UA is not available (for example, its in use or 259 offline). The desired behavior is for an audio-only call. 261 6.2 Solution 263 This will happen. Since Y1 didnt say anything about video, it still 264 matched the caller preference, just not explicitly. The caller 265 preference did not include the explicit tag, so Y1 remains as a 266 viable contact, but with a lower q value than Y2. Once the request to 267 Y2 fails, the proy will try Y1. 269 7 Forcing Audio/Video 271 7.1 Desired Behavior 273 This case is similar to that of Section 5. However, X requires an 274 audio/video call, and would like the call to fail if this is not 275 possible rather than succeeding with only audio. 277 7.2 Solution 279 The solution is similar to that of Section 5, however the Accept- 280 Contact header field now includes the explicit and require tags, 281 guaranteeing that the call is never established to any UA that had 282 not explicitly indicated support for video: 284 INVITE sip:Y@example.com SIP/2.0 285 Accept-Contact: *;video;require;explicit 286 This arrives at the example.com proxy. This explicit feature set 287 matches the feature set for Y2 and Y1. However, the match for Y1 did 288 not have a score of 1. Since the explicit and require tags are 289 present, the contact is discarded. 291 8 Third Party Call Control - Forcing Media 293 8.1 Desired Behavior 295 Z is a third party call control controller [6] trying to establish an 296 audio/video call from X to Y. (Both X and Y are configured the way Y 297 is in 5) Z needs to send a offerless invite to X and use the 298 resulting offer to send an invite to Y. When sending the offerless 299 invite to X it must ensure that an audio/video contact (X2) is chosen 300 over an audio only contact (X1). 302 8.2 Solution 304 Z would include, in its INVITE, an Accept-Contact header field: 306 INVITE sip:X@example.com SIP/2.0 307 Accept-Contact: *;audio;video;require;explicit 309 This caller preference matches both X1 and X2. However, it matches X1 310 with a score of .5 and X2 with a score of 1. Because of the require 311 and explicit tags, X1 is discarded despite the callee's preference 312 for it. Thus, the call is routed to X2. 314 9 Maximizing Media Overlaps 316 9.1 Desired Behavior 318 AOR Y has two contacts, Y1 that is a regular audio phone, and Y2 that 319 is a PC capable of supporting both audio and session oriented IM [7]. 320 X is a PC with capability to support audio, video and session 321 oriented IM. X calls Y for the purpose of establishing a voice call. 322 However, X wishes to connect to the device which has the maximal 323 overlap with its media capabilities, in order to maximize the 324 functionality available to the caller. 326 9.2 Solution 328 Y1 will generate a registration which looks like, in part: 330 REGISTER sip:example.com SIP/2.0 331 To: sip:Y@example.com 332 Contact: ;audio 334 Y2 will generate a registration which looks like, in part: 336 REGISTER sip:example.com SIP/2.0 337 To: sip:Y@example.com 338 Contact: ;audio;message 340 The solution requires the caller to support caller preferences. They 341 would include, in their INVITE, an Accept-Contact that lists all the 342 media types they support. In this case: 344 INVITE sip:Y@example.com SIP/2.0 345 Accept-Contact: *;audio;video;message 347 This would prefer a UA that supports all of the same types. Both Y1 348 and Y2 match. However, Y1 matches with a score of .33, and Y2 matches 349 with a score of .66. This would result in the call being routed to Y2 350 first. 352 10 Multilingual Lines 354 10.1 Desired Behavior 356 AOR Y represents a shared line in an office. Several employees in the 357 office have phones registered for Y. Some of the employees speak only 358 English, some speak Spanish fluently and have some limited capability 359 for English, and some speak both English and Spanish fluently. Calls 360 from callers that speak only English should be parallel forked to all 361 office workers that speak fluent English. If the call isn't picked 362 up, then the phones of workers that speak English marginally should 363 be rung. Calls from callers that speak only Spanish should be forked 364 only to workers that speak Spanish. 366 10.2 Solution 368 A user at phone Y1 that speaks English only would generate a REGISTER 369 which looks like, in part: 371 REGISTER sip:example.com SIP/2.0 372 To: sip:Y@example.com 373 Contact: sip:Y1@pc.pc.example.com;languages="en" 375 A user at a phone Y2 that speak Spanish and a little bit of English 376 would generate a REGISTER that looks like, in part: 378 REGISTER sip:example.com SIP/2.0 379 To: sip:Y@example.com 380 Contact: sip:Y2@pc.example.com;languages="es" 381 Contact: ;languages="en";q=0.2 383 Effectively, Y2 has registered two contacts. Both of them route to 384 the same device (pc.example.com), but they differ in their language 385 support and relative q-values. Multiple contacts are needed whenever 386 a UA wishes to express differing preferences for being reached for 387 different feature collections. 389 A user at phone Y3 that speaks English and Spanish fluently would 390 generate a REGISTER that looks like, in part: 392 REGISTER sip:example.com SIP/2.0 393 To: sip:Y@example.com 394 Contact: sip:Y3@pc.example.com;languages="es,en" 396 Notice that only a single contact is needed because the same q-value 397 is applied across all feature collections. 399 For the language based routing to occur, the caller must indicate its 400 language preferences explicitly: 402 INVITE sip:Y@example.com SIP/2.0 403 Accept-Contact: *;languages="en" 405 When a caller makes a call, and indicates that their language is 406 English only, the result is an Accept-Contact feature set that looks 407 like: 409 (& (languages="en")) 411 This matches all Y1 phones, the second contact registered by Y2 412 phones, and Y3 phones. However, the second contact registered by Y2 413 phones has a lower q-value, 0.2, and therefore, will be chosen with 414 lower preference than Y1 and Y3. The call will be routed to Y1 or Y3 415 UAs first, as desired. If neither of those pick up, the call is 416 routed to the English-language contact of Y2, which represents a user 417 with moderate English skills. In fact, the user will know to answer 418 with "Hello" instead of "Hola" because the request-URI will contain 419 Y2-en instead of just Y2. A nice bonus feature. 421 When a caller makes a call, and indicates that their language is 422 Spanish only, the result is an Accept-Contact feature set that looks 423 like: 425 (& (languages="es")) 427 This matches the first contact of Y2 phones, and Y3 phones, all with 428 equal preference. The result is that a call is routed to a user that 429 speaks Spanish. 431 11 I Hate Voicemail! 433 11.1 Desired Behavior 435 AOR Y has two contacts, a phone Y1 and a voicemail service Y2. X 436 wishes to call Y and talk in person. X does not want to be sent to 437 voicemail under any circumstance. 439 11.2 Solution 441 The phone would register with a Contact that looks like, in part: 443 REGISTER sip:example.com SIP/2.0 444 To: sip:Y@example.com 445 Contact: sip:Y1@pc.example.com 447 and the voicemail server would register with a Contact that looks 448 like, in part: 450 REGISTER sip:example.com SIP/2.0 451 To: sip:Y@example.com 452 Contact: sip:Y2@pc.example.com;msgserver;automata;attendant;audio 454 Note that the voicemail server need not actually register. There can 455 be a configured contact and feature set defined for it instead. 457 A caller that wishes to avoid voicemail can include an explicit 458 preference to avoid it. It would do this with the Reject-Contact 459 header field: 461 INVITE sip:Y@example.com SIP/2.0 462 Reject-Contact: *;msgserver 464 Since this feature set contains a feature tag that is not contained 465 in the registration for Y1, the feature set is discarded when 466 examining Y1. However, the registration for Y2 contains all feature 467 tags listed in the feature set, and so the rule is considered. There 468 is a match, and therefore, Y2 is discarded. 470 The result is that the user is never routed to voicemail. 472 12 I Hate People! 474 12.1 Desired Behavior 476 The situation is similar to Section 11, except the caller wishes to 477 only leave a message, not actually speak to the person. Therefore, 478 they would send an INVITE which looks like, in part: 480 INVITE sip:Y@example.com SIP/2.0 481 Accept-Contact: *;msgserver;require;explicit 483 This caller preference matches both Y1 and Y2. Y1 matches, but with a 484 score of zero. Y2 matches with a score of 1. Since both the require 485 and explicit flags are set, Y1 is discarded. Therefore, the call is 486 routed to Y2, the voicemail server, as desired. 488 13 Prefer Voicemail 489 13.1 Desired Behavior 491 The situation is similar to that of Section 11. However, the caller 492 prefers to leave a message. If voicemail is not available, they are 493 willing to talk to a person. 495 13.2 Solution 497 To accomplish this behavior, the caller would generate an INVITE that 498 looks like, in part: 500 INVITE sip:Y@example.com SIP/2.0 501 Accept-Contact: *;voicemail 503 This matches Y1 with a score of zero and Y2 with a score of 1. 504 Therefore, Y2 (the voicemail server) is tried first, and if that 505 fails, the lower priority Y1 (the phone) is tried next. 507 14 Routing to an Executive 509 14.1 Desired Behavior 511 Y is the AOR of an executive. It has three contacts. Y1 is the phone 512 on the executive's desk. Y2 is the phone on the desk of the 513 executive's assistant. Y3 is the address of an auto-attendant system 514 that can answer general questions, route calls to other parties, etc. 515 By default, calls to Y should be directed to Y2, and if that fails, 516 to Y3. If Y3 doesn't answer then Y1 should ring. 518 14.2 Solution 520 This is primarily a called party feature, and is best accomplished 521 with a CPL script [8]. However, it can be accomplished with caller 522 preferences alone by properly setting the q-values across the three 523 devices. Assuming this coordination is possible, here are the 524 settings that would be made: 526 Y1 would generate a REGISTER that looks like, in part: 528 REGISTER sip:example.com SIP/2.0 529 To: sip:Y@example.com 530 Contact: sip:Y1@pc.example.com;q=0.1 531 Y2 would generate a REGISTER that looks like, in part: 533 REGISTER sip:example.com SIP/2.0 534 To: sip:Y@example.com 535 Contact: sip:Y2@pc2.example.com;attendant;q=1.0 537 Y3 would generate a REGISTER that looks like, in part: 539 REGISTER sip:example.com SIP/2.0 540 To: sip:Y@example.com 541 Contact: sip:Y3@pc3.example.com;attendant;automata;q=0.5 543 Note that, in reality, the automated attendant would probably not use 544 REGISTER. Since the attendant would be used for every employee in the 545 company, a static contact would probably be added administratively 546 for each user in the enterprise. However, the information in that 547 static contact would be identical to the information in the 548 registration above. 550 When X makes a call to the executive, Y, and expresses no 551 preferences, the call is first routed to Y2, then Y3, then Y1, all as 552 a result of the proper setting of the q-values. 554 15 Speak to the Executive 556 15.1 Desired Behavior 558 This case is similar to that of Section 14, but this time the caller, 559 X, has a preference. X calls Y, but wants to speak directly to the 560 executive. X doesn't want the call to ring either the assistant or 561 the auto attendant (automata). 563 15.2 Solution 565 X's INVITE would look like, in part: 567 INVITE sip:Y@example.com SIP/2.0 568 Reject-Contact: *;attendant 569 Reject-Contact: *;automata 570 Note that the caller uses two separate Reject-Contact header field 571 values, rather than a single one with two separate feature 572 parameters. The distinction is important. If X had use a single value 573 with two parameters, a matching UA would need to declare that it was 574 BOTH an attendant and an automata. If it only declared that it was 575 one of these, based on the matching rules in the caller preferences 576 specification, it would not be rejected. 578 The above request would result in the elimination of both Y2 and Y3 579 as contacts. The call would then be routed to Y1, as desired. 581 16 Mobile Phone Only 583 16.1 Desired Behavior 585 The situation is similar to that in Section 14. However, the 586 executive also has a mobile phone which they have registered. Caller 587 X knows that the owner of Y is traveling, and that an assistant is 588 covering the office phone. X wants to call Y and ring only the mobile 589 phone. 591 16.2 Solution 593 The mobile phone would generate a registration which looks like, in 594 part: 596 REGISTER sip:example.com SIP/2.0 597 To: sip:Y@example.com 598 Contact: sip:Y4@mobile.example.com;mobility="mobile";q=0.5 600 The caller would express their preference by generating an INVITE 601 which looks like, in part: 603 INVITE sip:Y@example.com SIP/2.0 604 Accept-Contact: *;mobility="mobile";require;explicit 606 All three contacts match. However, Y1 through Y3 match with a score 607 of zero. Y4 matches with a score of 1. Because of the require and 608 explicit tags, Y1 through Y3 are discarded, and only Y4 is used, as 609 desired. 611 17 Simultaneous Languages 612 17.1 Desired Behavior 614 AOR Y is as in Section 10. Caller X, fluent in both English and 615 Spanish, has discovered that company's Spanish language documentation 616 is inconsistent with the English language documentation, and wants to 617 discuss the differences between the two. So X wants to speak with one 618 of the workers that is fluent in both English and Spanish. 620 17.2 Solution 622 The caller would generate an INVITE which looks like, in part: 624 INVITE sip:Y@example.com SIP/2.0 625 Accept-Contact: *;language="en";require 626 Accept-Contact: *;language="es";require 628 This will require a Contact URI to match both constraints. That means 629 it needs to support English and Spanish. This will achieve the 630 desired property. 632 Note that there are two separate Accept-Contact header fields. If the 633 caller had instead used this INVITE: 635 INVITE sip:Y@example.com SIP/2.0 636 Accept-Contact: *;language="en,es";require 638 It would have connected them to a UA that speaks either English or 639 Spanish, which is not what is desired here. 641 18 UA Routing 643 18.1 Desired Behavior 645 AOR Y has contacts Y1 and Y2. The addresses Y1 and Y2 are behind a 646 firewall and are not addressable by all callers. Caller X makes a 647 call to Y and is connected to Y1. The call fails for some reason, and 648 X wants to reestablish it, reaching only Y1. 650 18.2 Solution 652 There is currently no generally workable solution to this problem. 653 The best solution that exists does make use of caller preferences. 655 Lets say that the Contact URI for Y1 was sip:Y1@host.example.com. The 656 caller would generate an INVITE which looks like, in part: 658 INVITE sip:Y@example.com SIP/2.0 659 Accept-Contact: sip:Y1@host.example.com;require 661 or, equivalently: 663 INVITE sip:Y@example.com SIP/2.0 664 Accept-Contact: *;uri-user="";uri-domain="host.example.com";require 666 When this request arrives at the proxy for example.com, it attempts 667 to apply the caller preferences. Following the guidelines in the 668 caller preferences extension, Y1 would have included a uri-user and 669 uri-domain feature tag in its registration: 671 REGISTER sip:example.com SIP/2.0 672 To: sip:Y@example.com 673 Contact: sip:Y1@host.example.com;uri-user="" 674 ;uri-domain="host.example.com" 676 as would have Y2: 678 REGISTER sip:example.com SIP/2.0 679 To: sip:Y@example.com 680 Contact: sip:Y2@pc.example.com;uri-user="" 681 ;uri-domain="pc.example.com" 683 The proxy then applies the caller preferences. Only Y1 is a match. 684 So, Y2 is discarded, and the request is routed to Y1 as desired. 686 The difficulty is that this solution won't always work. In a multi- 687 proxy scenario, it is possible that the routing logic changes, and 688 therefore the request is never even routed to the proxy where Y1 has 689 registered. 691 19 The Number you Have Called.. 693 19.1 Desired Behavior 695 Consider once more the case of the executive, where the caller wishes 696 to reach only their mobile phone (Section 16). However, there is a 697 twist. The callee Y has moved to new address YY, and all the 698 configuration described for the callee now applies to YY. The old 699 address Y remains with a pair of statically assigned contacts. One 700 contact is YY. The other is M referencing an automaton that generates 701 a voice message reporting that the number has been changed. The 702 caller is unaware of the move and calls Y, requesting to reach the 703 mobile phone in exactly the same way they did in Section 16. The call 704 should connect to the mobile. 706 19.2 Solution 708 There would be four registrations against YY: 710 YY1 would generate a REGISTER that looks like, in part: 712 REGISTER sip:example.com SIP/2.0 713 To: sip:YY@example.com 714 Contact: sip:YY1@pc.example.com;q=0.1 716 YY2 would generate a REGISTER that looks like, in part: 718 REGISTER sip:example.com SIP/2.0 719 To: sip:YY@example.com 720 Contact: sip:YY2@pc2.example.com;attendant;q=1.0 722 YY3 would generate a REGISTER that looks like, in part: 724 REGISTER sip:example.com SIP/2.0 725 To: sip:YY@example.com 726 Contact: sip:YY3@pc3.example.com;attendant;automata;q=0.5 728 YY4 would generate a REGISTER that looks like, in part: 730 REGISTER sip:example.com SIP/2.0 731 To: sip:YY@example.com 732 Contact: sip:YY4@mobile.example.com;mobility="mobile";q=0.5 734 Athough it would be configured administratively, there are two 735 registered contacts for Y. The first is for the forwarding: 737 REGISTER sip:example.com SIP/2.0 738 To: sip:Y@example.com 739 Contact: sip:YY@example.com;q=1.0 741 and the second for the automated answering service: 743 REGISTER sip:example.com SIP/2.0 744 To: sip:Y@example.com 745 Contact: sip:machine@example.com;automata;q=0.5 747 The caller, not knowing that Y has moved, calls Y and asks for their 748 mobile phone: 750 INVITE sip:Y@example.com SIP/2.0 751 Accept-Contact: *;mobility="mobile";require;explicit 753 This reaches the example.com proxy, which finds two registrations. 754 Only one of these is associated with feature parameters (the 755 automata). Therefore, the caller preferences are applied to it alone. 756 The feature sets match, but not explicitly. Since the require and 757 explicit tags are present, the contact for the automata is dropped. 758 The proxy therefore sends the call to sip:Y@example.com, which 759 remains because it was unfiltered by the caller preferences 760 processing. There, there are four registrations, all of which are 761 associated with feature parameters. The caller preferences are 762 applied. Only YY4 matches explicitly, however. As such, the call is 763 forwarded there, and the mobile phone rings. 765 20 The Number you Have Called, Take Two 766 20.1 Desired Behavior 768 This use case is nearly identical to that of Section 19. However, 769 this time, the caller wishes to contact the personal phone of Y. They 770 don't feel strongly about it, and will accept other devices. 772 20.2 Solution 774 The INVITE generated by the caller in this case will look like: 776 INVITE sip:Y@example.com SIP/2.0 777 Accept-Contact: *;class="personal" 779 This reaches the example.com proxy. Once more, the first registration 780 (which forwards to the address-of-record for YY) is unaffected by the 781 caller preferences computation. The other contact, for the automata, 782 is a match, but its score is zero. Therefore, the first contact is 783 preferred. This causes the call to be routed to sip:YY@example.com. 784 There, all four contacts match, but none explicitly. Indeed, all four 785 have a score of zero against the explicit preference. However, they 786 each match the implicit preference for the INVITE method. The result 787 is that the the q-values are unaffected, and the call is routed to 788 YY2 first. 790 21 Security Considerations 792 There are no security considerations associated with this 793 specification. 795 22 IANA Considerations 797 There are no IANA considerations associated with this specification. 799 23 Author's Addresses 801 Jonathan Rosenberg 802 dynamicsoft 803 72 Eagle Rock Avenue 804 First Floor 805 East Hanover, NJ 07936 806 email: jdrosen@dynamicsoft.com 808 Paul Kyzivat 809 Cisco Systems 810 email: pkyzivat@cisco.com 812 24 Normative References 814 25 Informative References 816 [1] H. Schulzrinne and J. Rosenberg, "Session initiation protocol 817 (SIP) caller preferences and callee capabilities," internet draft, 818 Internet Engineering Task Force, Nov. 2002. Work in progress. 820 [2] A. Mankin, S. Bradner, R. Mahy, D. Willis, J. Ott, and B. Rosen, 821 "Change process for the session initiation protocol (SIP)," RFC 3427, 822 Internet Engineering Task Force, Dec. 2002. 824 [3] G. Klyne, "A syntax for describing media feature sets," RFC 2533, 825 Internet Engineering Task Force, Mar. 1999. 827 [4] J. Rosenberg and H. Schulzrinne, "A session initiation protocol 828 (SIP) event package for dialog state," internet draft, Internet 829 Engineering Task Force, June 2002. Work in progress. 831 [5] J. Rosenberg, "A presence event package for the session 832 initiation protocol (SIP)," internet draft, Internet Engineering Task 833 Force, Dec. 2002. Work in progress. 835 [6] J. Rosenberg, J. Peterson, H. Schulzrinne, and G. Camarillo, 836 "Best current practices for third party call control in the session 837 initiation protocol," internet draft, Internet Engineering Task 838 Force, June 2002. Work in progress. 840 [7] B. Campbell and J. Rosenberg, "Instant message sessions in 841 SIMPLE," internet draft, Internet Engineering Task Force, Oct. 2002. 842 Work in progress. 844 [8] J. Lennox and H. Schulzrinne, "Call processing language framework 845 and requirements," RFC 2824, Internet Engineering Task Force, May 846 2000. 848 Full Copyright Statement 850 Copyright (c) The Internet Society (2003). All Rights Reserved. 852 This document and translations of it may be copied and furnished to 853 others, and derivative works that comment on or otherwise explain it 854 or assist in its implementation may be prepared, copied, published 855 and distributed, in whole or in part, without restriction of any 856 kind, provided that the above copyright notice and this paragraph are 857 included on all such copies and derivative works. However, this 858 document itself may not be modified in any way, such as by removing 859 the copyright notice or references to the Internet Society or other 860 Internet organizations, except as needed for the purpose of 861 developing Internet standards in which case the procedures for 862 copyrights defined in the Internet Standards process must be 863 followed, or as required to translate it into languages other than 864 English. 866 The limited permissions granted above are perpetual and will not be 867 revoked by the Internet Society or its successors or assigns. 869 This document and the information contained herein is provided on an 870 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 871 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 872 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 873 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 874 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 876 Table of Contents 878 1 Introduction ........................................ 4 879 2 Routing of INVITE and MESSAGE to different UA ....... 4 880 2.1 Desired Behavior .................................... 4 881 2.2 Solution ............................................ 4 882 3 Single Contact Not Matching Implicit Preferences .... 5 883 3.1 Desired Behavior .................................... 5 884 3.2 Solution ............................................ 6 885 4 Package-Based Routing ............................... 6 886 4.1 Desired Behavior .................................... 6 887 4.2 Solution ............................................ 6 888 5 Audio/Video vs. Audio Only .......................... 8 889 5.1 Desired Behavior .................................... 8 890 5.2 Solution ............................................ 8 891 6 Audio/Video vs. Audio Only: A/V UA Fails ............ 9 892 6.1 Desired Behavior .................................... 9 893 6.2 Solution ............................................ 9 894 7 Forcing Audio/Video ................................. 9 895 7.1 Desired Behavior .................................... 9 896 7.2 Solution ............................................ 9 897 8 Third Party Call Control - Forcing Media ............ 10 898 8.1 Desired Behavior .................................... 10 899 8.2 Solution ............................................ 10 900 9 Maximizing Media Overlaps ........................... 10 901 9.1 Desired Behavior .................................... 10 902 9.2 Solution ............................................ 10 903 10 Multilingual Lines .................................. 11 904 10.1 Desired Behavior .................................... 11 905 10.2 Solution ............................................ 11 906 11 I Hate Voicemail! .................................. 13 907 11.1 Desired Behavior .................................... 13 908 11.2 Solution ............................................ 13 909 12 I Hate People! ..................................... 14 910 12.1 Desired Behavior .................................... 14 911 13 Prefer Voicemail .................................... 14 912 13.1 Desired Behavior .................................... 15 913 13.2 Solution ............................................ 15 914 14 Routing to an Executive ............................. 15 915 14.1 Desired Behavior .................................... 15 916 14.2 Solution ............................................ 15 917 15 Speak to the Executive .............................. 16 918 15.1 Desired Behavior .................................... 16 919 15.2 Solution ............................................ 16 920 16 Mobile Phone Only ................................... 17 921 16.1 Desired Behavior .................................... 17 922 16.2 Solution ............................................ 17 923 17 Simultaneous Languages .............................. 17 924 17.1 Desired Behavior .................................... 18 925 17.2 Solution ............................................ 18 926 18 UA Routing .......................................... 18 927 18.1 Desired Behavior .................................... 18 928 18.2 Solution ............................................ 18 929 19 The Number you Have Called.. ....................... 20 930 19.1 Desired Behavior .................................... 20 931 19.2 Solution ............................................ 20 932 20 The Number you Have Called, Take Two ................ 21 933 20.1 Desired Behavior .................................... 22 934 20.2 Solution ............................................ 22 935 21 Security Considerations ............................. 22 936 22 IANA Considerations ................................. 22 937 23 Author's Addresses .................................. 22 938 24 Normative References ................................ 23 939 25 Informative References .............................. 23