idnits 2.17.1 draft-barnes-sipcore-rfc4244bis-callflows-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (Mar 2012) is 4422 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC3326' is defined on line 1258, but no explicit reference was found in the text == Unused Reference: 'RFC3323' is defined on line 1262, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 1265, but no explicit reference was found in the text == Unused Reference: 'RFC5246' is defined on line 1268, but no explicit reference was found in the text == Unused Reference: 'RFC4244' is defined on line 1271, but no explicit reference was found in the text == Unused Reference: 'RFC5630' is defined on line 1279, but no explicit reference was found in the text == Unused Reference: 'RFC3969' is defined on line 1304, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 4244 (Obsoleted by RFC 7044) -- Obsolete informational reference (is this intentional?): RFC 3761 (Obsoleted by RFC 6116, RFC 6117) == Outdated reference: A later version (-12) exists of draft-ietf-sipcore-rfc4244bis-06 Summary: 0 errors (**), 0 flaws (~~), 9 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Barnes 3 Internet-Draft Polycom 4 Intended status: Informational F. Audet 5 Expires: September 2, 2012 Skype 6 S. Schubert 7 NTT 8 J. van Elburg 9 Detecon International Gmbh 10 C. Holmberg 11 Ericsson 12 Mar 2012 14 Session Initiation Protocol (SIP) History-Info Header Call Flow Examples 15 draft-barnes-sipcore-rfc4244bis-callflows-03.txt 17 Abstract 19 This document describes use cases and documents call flows which 20 require the History-Info header field to capture the Request-URIs as 21 a Session Initiation Protocol (SIP) Request is retargeted. The use 22 cases are described along with the corresponding call flow diagrams 23 and messaging details. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on September 2, 2012. 42 Copyright Notice 44 Copyright (c) 2012 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 61 3. Detailed call flows . . . . . . . . . . . . . . . . . . . . . 3 62 3.1. Automatic Call Distribution . . . . . . . . . . . . . . . 3 63 3.2. Determining the Alias used. . . . . . . . . . . . . . . . 8 64 3.3. PBX Voicemail Example . . . . . . . . . . . . . . . . . . 10 65 3.4. Consumer Voicemail Example . . . . . . . . . . . . . . . . 15 66 3.5. GRUU . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 67 3.6. Limited Use Address . . . . . . . . . . . . . . . . . . . 22 68 3.7. Service Invocation . . . . . . . . . . . . . . . . . . . . 24 69 3.8. Toll Free Number . . . . . . . . . . . . . . . . . . . . . 25 70 4. Security Considerations . . . . . . . . . . . . . . . . . . . 27 71 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 72 5.1. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 27 73 6. Informative References . . . . . . . . . . . . . . . . . . . . 28 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 76 1. Overview 78 Many services that use SIP require the ability to determine why and 79 how the call arrived at a specific application. The use cases 80 provided in this document illustrate the use of the History-Info 81 header [I-D.ietf-sipcore-rfc4244bis] for example applications and 82 common scenarios. The optional "rc" and "mp" header field parameters 83 defined in [I-D.ietf-sipcore-rfc4244bis] are required for several of 84 the use cases. Descriptions of the example use cases, call flow 85 diagrams and messaging details are provided. 87 2. Conventions and Terminology 89 The term "retarget" is used as defined in 90 [I-D.ietf-sipcore-rfc4244bis]. The terms "location service", 91 "redirect", "redirect" and "AOR" are used consistent with the 92 terminology in [RFC3261]. 94 3. Detailed call flows 96 The scenarios in this section provide sample use cases for the 97 History-Info header for informational purposes only. They are not 98 intended to be normative. In many cases, only the relevant messaging 99 details are included in the body of the call flow. 101 3.1. Automatic Call Distribution 103 This scenario highlights an example of an Automatic Call Distribution 104 service, where the agents are divided into groups based upon the type 105 of customers they handle. In this example, the Gold customers are 106 given higher priority than Silver customers, so a Gold call would get 107 serviced even if all the agents servicing the Gold group were busy, 108 by retargeting the request to the Silver Group for delivery to an 109 agent. Upon receipt of the call at the agent assigned to handle the 110 incoming call, based upon the History-Info header in the message, the 111 application at the agent can provide an indication that this is a 112 Gold call by extracting the hi-entry associated with the incoming 113 request which is determined by locating the hi-entry whose index is 114 reflected in the first hi-entry with an hi-target of "mp". In the 115 example this would be the hi-entry referenced by the value of the 116 last "mp" header field parameter -i.e., the hi-entry containing an 117 index of "1". An application can also determine how many groups from 118 which the call may have overflowed before reaching the agent, etc. 119 and present the information to the agent so that the call can be 120 handled appropriately by the agent - i.e., "I'm so sorry for the 121 delay, blah, blah, blah..." 122 For scenarios whereby calls might overflow from the Silver to the 123 Gold, clearly the alternate group identification, internal routing, 124 or actual agent that handles the call should not be sent to UA1. 125 Thus, for this scenario, one would expect that the Proxy would not 126 support the sending of the History-Info in the response, even if 127 requested by Alice. 129 As with the other examples, this is not a complete prescription of 130 how one would do this type of service but an example of a subset of 131 processing that might be associated with such a service. In 132 addition, this example is not addressing any aspects of Agent 133 availability resulting in the call being sent to an agent in another 134 group, which might also be done via a SIP interface. 136 Alice example.com Gold Silver Agent 138 | | | | | 139 | INVITE F1 | | | | 140 |------------->| | | | 141 | | | | | 142 | | INVITE F2 | | | 143 | |------------->| | | 144 | | | | | 145 | | 302 Moved Temporarily F3 | | 146 | |<-------------| | | 147 | | | | | 148 | | INVITE F4 | | | 149 | |--------------------------->| | 150 | | | | | 151 | | | | INVITE F5 | 152 | | | |----------->| 153 | | | | | 154 | | | | 200 OK F6 | 155 | | | |<-----------| 156 | | | | | 157 | | 200 OK F7 | | 158 | |<---------------------------| | 159 | | | | | 160 | 200 OK F8 | | | | 161 |<-------------| | | | 162 | | | | | 163 | ACK | | | | 164 |------------->| ACK | 165 | |---------------------------------------->| 167 F1 INVITE Alice -> Example.com 169 INVITE sip:Gold@example.com SIP/2.0 170 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK42t2 171 From: Alice ;tag=1235 172 To: John 173 Supported: histinfo 174 Call-Id: 12345600@example.com 175 CSeq: 1 INVITE 176 History-Info: ;index=1 177 Contact: Alice 178 Content-Type: application/sdp 179 Content-Length: 181 [SDP Not Shown] 183 F2 INVITE Example.com -> Gold.Example.com 185 INVITE sip:john@192.0.2.1 SIP/2.0 186 Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bK12s4 187 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK42t2 188 From: Alice ;tag=1235 189 To: John 190 Supported: histinfo 191 Call-Id: 12345600@example.com 192 CSeq: 1 INVITE 193 History-Info: ;index=1 194 History-Info: ;rc=1;index=1.1 195 Contact: Alice 196 Content-Type: application/sdp 197 Content-Length: 199 [SDP Not Shown] 201 F3 302 Moved Temporarily Gold.Example.com -> Example.com 203 SIP/2.0 302 Moved Temporarily 204 Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bK12s4 205 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK42t2 206 From: Alice ;tag=1235 207 To: John 208 Supported: histinfo 209 Call-Id: 12345600@example.com 210 CSeq: 1 INVITE 211 History-Info: ;index=1 212 History-Info: ;rc=1;index=1.1 213 Contact: ;mp=1 214 Content-Type: application/sdp 215 Content-Length: 217 [SDP Not Shown] 218 F4 INVITE Example.com -> Silver.Example.com 220 INVITE sip:Silver@example.com SIP/2.0 221 Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bK12s4 222 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK42t2 223 From: Alice ;tag=1235 224 To: John 225 Supported: histinfo 226 Call-Id: 12345600@example.com 227 CSeq: 1 INVITE 228 History-Info: ;index=1 229 History-Info: ;\ 230 rc=1;index=1.1 231 History-Info: ;index=1.2;mp=1 232 History-Info: ;index=1.2.1;rc=1.2 233 Contact: Alice 234 Content-Type: application/sdp 235 Content-Length: 237 [SDP Not Shown] 239 F5 INVITE Silver.Example.com -> Agent 241 INVITE sip:Silver@192.0.2.7 SIP/2.0 242 Via: SIP/2.0/TCP silver.example.com:5060;branch=z9hG4bKerxs 243 Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bK12s4 244 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK42t2 245 From: Alice ;tag=1235 246 To: John 247 Supported: histinfo 248 Call-Id: 12345600@example.com 249 CSeq: 1 INVITE 250 History-Info: ;index=1 251 History-Info: ;\ 252 index=1.1 253 History-Info: ;index=1.2;mp=1 254 History-Info: ;index=1.2.1;rc=1.2 255 History-Info: ;index=1.2.1.1;rc=1.2.1 256 Contact: Alice 257 Content-Type: application/sdp 258 Content-Length: 260 [SDP Not Shown] 262 F6 200 OK Agent -> Silver.Example.com 264 SIP/2.0 200 OK 265 Via: SIP/2.0/TCP silver.example.com:5060;branch=z9hG4bKerxs 266 Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bK12s4 267 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK42t2 268 From: Alice ;tag=1235 269 To: John ;tag=2325 270 Supported: histinfo 271 Call-Id: 12345600@example.com 272 CSeq: 1 INVITE 273 History-Info: ;index=1 274 History-Info: ;\ 275 index=1.1 276 History-Info: ;index=1.2;mp=1 277 History-Info: ;index=1.2.1;rc=1.2 278 History-Info: ;index=1.2.1.1;rc=1.2.1 279 Contact: Silver 280 Content-Type: application/sdp 281 Content-Length: 283 [SDP Not Shown] 285 F7 200 OK Silver.Example.com -> Example.com 287 SIP/2.0 200 OK 288 Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bK12s4 289 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK42t2 290 From: Alice ;tag=1235 291 To: John ;tag=2325 292 Supported: histinfo 293 Call-Id: 12345600@example.com 294 CSeq: 1 INVITE 295 History-Info: ;index=1 296 History-Info: ;\ 297 index=1.1 298 History-Info: ;index=1.2;mp=1 299 History-Info: ;index=1.2.1;rc=1.2 300 History-Info: ;index=1.2.1.1;rc=1.2.1 301 Contact: Silver 302 Content-Type: application/sdp 303 Content-Length: 305 [SDP Not Shown] 307 F8 200 OK Example.com -> Alice 309 SIP/2.0 200 OK 310 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK42t2 311 From: Alice ;tag=1235 312 To: John ;tag=2325 313 Supported: histinfo 314 Call-Id: 12345600@example.com 315 CSeq: 1 INVITE 316 History-Info: ;index=1 317 History-Info: ;\ 318 index=1.1 319 History-Info: ;index=1.2;mp=1 320 History-Info: ;index=1.2.1;rc=1.2 321 History-Info: ;index=1.2.1.1;rc=1.2.1 322 Contact: Silver 323 Content-Type: application/sdp 324 Content-Length: 326 [SDP Not Shown] 328 The last hi-entry with the "mp" header field parameter contains a 329 "mp" header field parameter value of 1 which points to the original- 330 target which allows the operator to identify that the call was from 331 the "Gold" customer. 333 3.2. Determining the Alias used. 335 SIP user agents are associated with an address-of-record (AOR). It 336 is possible for a single UA to actually have multiple AORs associated 337 with it. One common usage for this is aliases. For example, a user 338 might have an AOR of sip:john@example.com but also have the AORs 339 sip:john.smith@example.com and sip:jsmith@example.com. Rather than 340 registering against each of these AORs individually, the user would 341 register against just one of them, and the home proxy would 342 automatically accept incoming calls for any of the aliases, treating 343 them identically and ultimately forwarding them towards the UA. This 344 is common practice in the Internet Multimedia Subsystem (IMS), where 345 it is called implicit registration and each alias is called a public 346 identity. 348 It is a common requirement for a UAS, on receipt of a call, to know 349 which of its aliases was used to reach it. This knowledge can be 350 used to choose ringtones to play, determine call treatment, and so 351 on. For example, a user might give out one alias to friends and 352 family only, resulting in a special ring that alerts the user to the 353 importance of the call. 355 The following call-flow and example messages show how History-Info 356 can be used to find out the alias used to reach the callee. The 357 alias for the call is determined by hi-entry with the index that 358 matches the value of the last hi-entry with a "rc" header field 359 parameter in the Request received. 361 Alice Example.com John 362 | | REGISTER F1 | 363 | |<--------------------| 364 | | 200 OK F2 | 365 | |-------------------->| 366 | INVITE F3 | | 367 |-------------------->| | 368 | | INVITE F4 | 369 | |-------------------->| 370 * Rest of flow not shown * 372 F1 REGISTER John -> Example.com 374 REGISTER sip:example.com SIP/2.0 375 Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bKnashds7 376 Max-Forwards: 70 377 From: John ;tag=a73kszlfl 378 To: John 379 Call-ID: 1j9FpLxk3uxtm8tn@192.0.2.1 380 CSeq: 1 REGISTER 381 Contact: 382 Content-Length: 0 384 F2 200 OK Example.com -> John 386 SIP/2.0 200 OK 387 Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bKnashds7 388 From: John ;tag=a73kszlfl 389 To: John 390 Call-ID: 1j9FpLxk3uxtm8tn@192.0.2.1 391 CSeq: 1 REGISTER 392 Contact: ;expires=3600 393 Content-Length: 0 395 F3 INVITE Alice -> Example.com 397 INVITE sip:john.smith@example.com SIP/2.0 398 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK42t2 399 From: Alice ;tag=a73kszlfl 400 To: John 401 Supported: histinfo 402 Call-Id: 12345600@example.com 403 CSeq: 1 INVITE 404 History-Info: ;index=1 405 Contact: Alice 406 Content-Type: application/sdp 407 Content-Length: 409 [SDP Not Shown] 411 F4 INVITE Example.com -> John 413 INVITE sip:john@192.0.2.1 SIP/2.0 414 Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bK12s4 415 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK42t2 416 From: Alice ;tag=a73kszlfl 417 To: John 418 Supported: histinfo 419 Call-Id: 12345600@example.com 420 CSeq: 1 INVITE 421 Record-Route: 422 History-Info: ;index=1 423 History-Info: ;index=1.1;rc=1 424 Contact: Alice 425 Content-Type: application/sdp 426 Content-Length: 428 [SDP Not Shown] 430 Figure 1: Alias Example 432 The last hi-entry with the "rc" header field parameter references the 433 source of retargeting pointing at the alias AoR, which in the example 434 is "john.smith@example.com". 436 3.3. PBX Voicemail Example 438 A typical use case for voicemail is one whereby the original called 439 party is not reachable and the call arrives at a voicemail system. 440 In some cases multiple alternate destinations may be tried without 441 success. The voicemail system typically requires the original called 442 party information to determine the appropriate mailbox so an 443 appropriate greeting can be provided and the appropriate party 444 notified of the message. 446 In this example, Alice calls Bob, whose SIP client is forwarded to 447 Carol. Carol does not answer the call, thus it is forwarded to a VM 448 (voicemail) server (VMS). In order to determine the appropriate 449 mailbox to use for this call, the VMS needs the original target for 450 the request. The original target is determined by finding the first 451 hi-entry tagged with "rc" and using the hi-entry referenced by the 452 index of "rc" header field parameter as the target for determining 453 the appropriate mailbox. This hi-entry is used to populate the 454 "target" URI parameter as defined in [RFC4458]. The reason 455 associated with the first hi-entry tagged with "rc" (i.e., 302) could 456 be used to provide a customized voicemail greeting and is used to 457 populate the "cause" URI parameter as defined in [RFC4458]. Note 458 that some VMSs may also (or instead) use the information available in 459 the History-Info headers for custom handling of the VM in terms of 460 how and why the call arrived at the VMS. 462 Furthermore it is the proxy forwarding the call to VMS that 463 determines the target of the voicemail, it is the proxy that sets the 464 target of voicemail which is also the entity that utilizes RFC4244bis 465 to find the target which is usually based on local policy installed 466 by the user or an administrator. 468 Alice example.com Bob Carol VM 470 | INVITE F1 | | | | 471 |------------->| | | | 472 | | INVITE F2 | | | 473 | |------------->| | | 474 | | | | | 475 | 100 Trying | | | | 476 |<-------------| 302 Moved Temporarily F3 | | 477 | |<-------------| | | 478 | | | | | 479 | | INVITE F4 | | | 480 | |--------------------------->| | 481 | | | | | 482 | | 180 Ringing F5 | | 483 | |<---------------------------| | 484 | | | | | 485 | 180 Ringing | | | | 486 |<-------------| | | | 487 | | | | | 488 | | (timeout) | | 489 | | | | | 490 | | INVITE F6 | | | 491 | |-------------------------------------->| 492 | | | | | 493 | | 200 OK F7 | 494 | |<--------------------------------------| 495 | 200 OK | | | | 496 |<-------------| | | | 497 | | | | | 498 | ACK | | | | 499 |------------->| ACK | 500 | |-------------------------------------->| 502 F1 INVITE Alice -> Example.com 504 INVITE sip:bob@example.com 505 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK42t2 506 From: Alice ;tag=kkaz- 507 To: Bob 508 Supported: histinfo 509 Call-Id: 12345600@example.com 510 CSeq: 1 INVITE 511 Contact: Alice 512 Content-Length: 514 [SDP Not Shown] 516 F2 INVITE Example.com -> Bob 518 INVITE sip:bob@192.0.2.5 SIP/2.0 519 Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bK12s4 520 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK42t2 521 From: Alice ;tag=kkaz- 522 To: Bob 523 Supported: histinfo 524 Call-Id: 12345600@example.com 525 CSeq: 1 INVITE 526 History-Info: ;index=1 527 History-Info: ;index=1.1;rc=1 528 Contact: Alice 529 Content-Type: application/sdp 530 Content-Length: 532 [SDP Not Shown] 534 F3 302 Moved Temporarily Bob -> Example.com 536 SIP/2.0 302 Moved Temporarily 537 Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bK12s4 538 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK42t2 539 From: Alice ;tag=kkaz- 540 To: Bob 541 Supported: histinfo 542 Call-Id: 12345600@example.com 543 CSeq: 1 INVITE 544 History-Info: ;index=1 545 History-Info: ; index=1.1;rc=1 546 Contact: 547 Content-Type: application/sdp 548 Content-Length: 550 [SDP Not Shown] 552 F4 INVITE Example.com -> Carol 554 INVITE sip:carol@192.0.2.4 SIP/2.0 555 Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bK12s4 556 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK42t2 557 From: Alice ;tag=kkaz- 558 To: Bob 559 Supported: histinfo 560 Call-Id: 12345600@example.com 561 CSeq: 1 INVITE 562 History-Info: ;index=1 563 History-Info: ;\ 564 index=1.1;rc=1 565 History-Info: ;index=1.2;mp=1 566 History-Info: ;index=1.2.1;rc=1.2 567 Contact: Alice 568 Content-Type: application/sdp 569 Content-Length: 571 [SDP Not Shown] 573 F5 180 Ringing Carol -> Example.com 575 SIP/2.0 180 Ringing 576 Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bK12s4 577 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK42t2 578 From: Alice ;tag=kkaz- 579 To: Bob ;tag=setss3x 580 Supported: histinfo 581 Call-Id: 12345600@example.com 582 CSeq: 1 INVITE 583 History-Info: ;index=1 584 History-Info: ;\ 585 index=1.1;rc=1 586 History-Info: ;index=1.2;mp=1 587 History-Info: ;index=1.2.1;rc=1.2 588 Contact: 589 Content-Type: application/sdp 590 Content-Length: 592 [SDP Not Shown] 593 F6 INVITE Example.com -> VM 595 INVITE sip:vm@192.0.2.6;target=sip:bob%40example.com;cause=408 596 Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bK12s4 597 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK42t2 598 From: Alice ;tag=kkaz- 599 To: Bob 600 Supported: histinfo 601 Call-Id: 12345600@example.com 602 CSeq: 1 INVITE 603 History-Info: ;index=1 604 History-Info: ;\ 605 index=1.1;rc=1 606 History-Info: ;index=1.2;mp=1 607 History-Info: ;\ 608 index=1.2.1;rc=1.2 609 History-Info: ;\ 611 index=1.3;mp=1.2 612 History-Info: ;\ 614 index=1.3.1;rc=1.3 615 Contact: Alice 616 Content-Type: application/sdp 617 Content-Length: 619 [SDP Not Shown] 621 F7 200 OK VM -> Example.com 623 SIP/2.0 200 OK 624 Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bK12s4 625 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK42t2 626 From: Alice ;tag=kkaz- 627 To: Bob ;tag=3dweggs 628 Supported: histinfo 629 Call-Id: 12345600@example.com 630 CSeq: 1 INVITE 631 History-Info: ;index=1 632 History-Info: ;\ 633 index=1.1;rc=1 634 History-Info: ;index=1.2;mp=1 635 History-Info: ;\ 636 index=1.2.1;rc=1.2 637 History-Info: ;\ 639 index=1.3;mp=1.2 640 History-Info: ;\ 642 index=1.3.1;rc=1.3 643 Contact: 644 Content-Type: application/sdp 645 Content-Length: 647 [SDP Not Shown] 649 The VMS can look at the last hi-entry and find the target of the 650 mailbox by looking at the URI entry in the "target" URI parameter in 651 the hi-entry. 653 3.4. Consumer Voicemail Example 655 In the case of a consumer, when the call is retargeted, it is usually 656 to another administrative domain. The voicemail system in these 657 environment typically requires the last called party information to 658 determine the appropriate mailbox so an appropriate greeting can be 659 provided and the appropriate party notified of the message. 661 In this example, Alice calls the Bob but Bob has temporarily 662 forwarded his phone to Carol because she is his wife. Carol does not 663 answer the call, thus it is forwarded to a VM (voicemail) server 664 (VMS). In order to determine the appropriate mailbox to use for this 665 call, the VMS needs the appropriate target for the request. The last 666 target is determined by finding the hi-entry referenced by the index 667 of last hi-entry tagged with "rc" for determining the appropriate 668 mailbox. This hi-entry is used to populate the "target" URI 669 parameter as defined in [RFC4458]. Note that some VMSs may also (or 670 instead) use the information available in the History-Info headers 671 for custom handling of the VM in terms of how and why the called 672 arrived at the VMS. 674 Alice example.com Bob Carol VM 676 | INVITE F1 | | | | 677 |------------->| | | | 678 | | INVITE F2 | | | 679 | |------------->| | | 680 | | | | | 681 | 100 Trying | | | | 682 |<-------------| 302 Moved Temporarily F3 | | 683 | |<-------------| | | 684 | | | | | 685 | | INVITE F4 | | | 686 | |--------------------------->| | 687 | | | | | 688 | | 180 Ringing F5 | | 689 | |<---------------------------| | 690 | | | | | 691 | 180 Ringing | | | | 692 |<-------------| | | | 693 | | | | | 694 | | (timeout) | | 695 | | | | | 696 | | INVITE F6 | | | 697 | |-------------------------------------->| 698 | | | | | 699 | | 200 OK F7 | 700 | |<--------------------------------------| 701 | 200 OK | | | | 702 |<-------------| | | | 703 | | | | | 704 | ACK | | | | 705 |------------->| ACK | 706 | |-------------------------------------->| 708 F1 INVITE Alice -> Example.com 710 INVITE sip:bob@example.com 711 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK42t2 712 From: Alice ;tag=kkaz- 713 To: Bob 714 Supported: histinfo 715 Call-Id: 12345600@example.com 716 CSeq: 1 INVITE 717 Contact: Alice 718 Content-Length: 720 [SDP Not Shown] 722 F2 INVITE Example.com -> Bob 724 INVITE sip:bob@192.0.2.5 SIP/2.0 725 Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bK12s4 726 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK42t2 727 From: Alice ;tag=kkaz- 728 To: Bob 729 Supported: histinfo 730 Call-Id: 12345600@example.com 731 CSeq: 1 INVITE 732 History-Info: ;index=1 733 History-Info: ;index=1.1;rc=1 734 Contact: Alice 735 Content-Type: application/sdp 736 Content-Length: 738 [SDP Not Shown] 740 F3 302 Moved Temporarily Bob -> Example.com 742 SIP/2.0 302 Moved Temporarily 743 Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bK12s4 744 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK42t2 745 From: Alice ;tag=kkaz- 746 To: Bob 747 Supported: histinfo 748 Call-Id: 12345600@example.com 749 CSeq: 1 INVITE 750 History-Info: ;index=1 751 History-Info: ; index=1.1;rc=1 752 Contact: 753 Content-Type: application/sdp 754 Content-Length: 756 [SDP Not Shown] 758 F4 INVITE Example.com -> Carol 760 INVITE sip:carol@192.0.2.4 SIP/2.0 761 Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bK12s4 762 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK42t2 763 From: Alice ;tag=kkaz- 764 To: Bob 765 Supported: histinfo 766 Call-Id: 12345600@example.com 767 CSeq: 1 INVITE 768 History-Info: ;index=1 769 History-Info: ;\ 770 index=1.1;rc=1 771 History-Info: ;index=1.2;mp=1 772 History-Info: ;index=1.2.1;rc=1.2 773 Contact: Alice 774 Content-Type: application/sdp 775 Content-Length: 777 [SDP Not Shown] 779 F5 180 Ringing Carol -> Example.com 780 SIP/2.0 180 Ringing 781 Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bK12s4 782 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK42t2 783 From: Alice ;tag=kkaz- 784 To: Bob ;tag=setss3x 785 Supported: histinfo 786 Call-Id: 12345600@example.com 787 CSeq: 1 INVITE 788 History-Info: ;index=1 789 History-Info: ;\ 790 index=1.1;rc=1 791 History-Info: ;index=1.2;mp=1 792 History-Info: ;index=1.2.1;rc=1.2 793 Contact: 794 Content-Type: application/sdp 795 Content-Length: 797 [SDP Not Shown] 799 F6 INVITE Example.com -> VM 801 INVITE sip:vm@192.0.2.6;target=sip:carol%40example.com 802 Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bK12s4 803 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK42t2 804 From: Alice ;tag=kkaz- 805 To: Bob 806 Supported: histinfo 807 Call-Id: 12345600@example.com 808 CSeq: 1 INVITE 809 History-Info: ;index=1 810 History-Info: ;\ 811 index=1.1;rc 812 History-Info: ;\ 813 index=1.2;mp=1 814 History-Info: ;index=1.2.1;rc=1.2 815 History-Info: ;\ 816 index=1.3;mp=1.2 817 History-Info: ;\ 818 index=1.3.1 819 Contact: Alice 820 Content-Type: application/sdp 821 Content-Length: 823 [SDP Not Shown] 825 F7 200 OK VM -> Example.com 827 SIP/2.0 200 OK 828 Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bK12s4 829 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK42t2 830 From: Alice ;tag=kkaz- 831 To: Bob ;tag=3dweggs 832 Supported: histinfo 833 Call-Id: 12345600@example.com 834 CSeq: 1 INVITE 835 History-Info: ;index=1 836 History-Info: ;\ 837 index=1.1;rc 838 History-Info: ;\ 839 index=1.2;mp=1 840 History-Info: ;index=1.2.1;rc=1.2 841 History-Info: ;\ 842 index=1.3;mp=1.2 843 History-Info: ;\ 844 index=1.3.1 845 Contact: 846 Content-Type: application/sdp 847 Content-Length: 849 [SDP Not Shown] 851 The VMS can look at the last hi-entry and find the target of the 852 mailbox by looking for the "target" URI parameter in the hi-entry. 854 3.5. GRUU 856 A variation on the problem in Section 3.2 occurs with Globally 857 Routable User Agent URI (GRUU) [RFC5627]. A GRUU is a URI assigned 858 to a UA instance which has many of the same properties as the AOR, 859 but causes requests to be routed only to that specific instance. It 860 is desirable for a UA to know whether it was reached because a 861 correspondent sent a request to its GRUU or to its AOR. This can be 862 used to drive differing authorization policies on whether the request 863 should be accepted or rejected, for example. However, like the AOR 864 itself, the GRUU is lost in translation at the home proxy. Thus, the 865 UAS cannot know whether it was contacted via the GRUU or its AOR. 867 Following call-flow and example messages show how History-Info can be 868 used to find out the GRUU used to reach the callee. 870 While a GRUU is comprised of an AoR with a URI parameter as defined 871 in [RFC5627] , the GRUU construct itself is not an AoR. Thus, the 872 retargeting of a request based on a GRUU does not result in the 873 addition of an "rc" header field parameter to the hi-entry containing 874 the GRUU. The lack of an "rc" header field parameter in the hi- 875 entries can be a hint that the source of retargeting is a GRUU. 876 However, to ensure this is the case, the UAS needs to search for a 877 "gr" parameter in the hi-entry prior to the last hi-entry. If there 878 is a GRUU, the URI will always be prior to the last hi-entry as GRUU 879 does not allow multiple instance to be mapped to a contact address. 881 Alice Example.com John 882 | | REGISTER F1 | 883 | |<--------------------| 884 | | 200 OK F2 | 885 | |-------------------->| 886 | INVITE F3 | | 887 |-------------------->| | 888 | | INVITE F4 | 889 | |-------------------->| 890 * Rest of flow not shown * 892 F1 REGISTER John -> Example.com 894 REGISTER sip:example.com SIP/2.0 895 Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bKnashds7 896 Max-Forwards: 70 897 From: John ;tag=a73kszlfl 898 Supported: gruu 899 To: John 900 Call-ID: 1j9FpLxk3uxtm8tn@192.0.2.1 901 CSeq: 1 REGISTER 902 Contact: 903 ;+sip.instance="" 904 Content-Length: 0 906 [SDP Not Shown] 908 F2 200 OK Example.com -> John 910 SIP/2.0 200 OK 911 Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bKnashds7 912 From: John ;tag=a73kszlfl 913 To: John ;tag=b88sn 914 Call-ID: 1j9FpLxk3uxtm8tn@192.0.2.1 915 CSeq: 1 REGISTER 916 Contact: 917 ;pub-gruu="sip:john@example.com 918 ;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6" 919 ;temp-gruu= 920 "sip:tgruu.7hs==jd7vnzga5w7fajsc7-ajd6fabz0f8g5@example.com;gr" 922 ;+sip.instance="" 923 ;expires=3600 924 Content-Length: 0 926 [SDP Not Shown] 928 Assuming Alice has a knowledge of a gruu either through 929 prior communication or through other means such as presence 930 places a call to John's gruu. 932 F3 INVITE Alice -> Example.com 934 INVITE sip:john@example.com 935 ;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 SIP/2.0 936 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK42t2 937 From: Alice ;tag=kkaz- 938 To: 940 Supported: gruu, histinfo 941 Call-Id: 12345600@example.com 942 CSeq: 1 INVITE 943 History-Info: ;index=1 945 Contact: Alice 946 Content-Length: 948 [SDP Not Shown] 950 F4 INVITE Example.com -> John 952 INVITE sip:john@192.0.2.1 SIP/2.0 953 Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bK12s4 954 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK42t2 955 From: Alice ;tag=kkaz- 956 To: John 957 Supported: gruu, histinfo 958 Call-Id: 12345600@example.com 959 CSeq: 1 INVITE 960 Record-Route: 961 History-Info: ;index=1 963 History-Info: ;index=1.1;rc=1 964 Contact: Alice 965 Content-Type: application/sdp 966 Content-Length: 968 [SDP Not Shown] 970 Figure 2: GRUU Example 972 By analyzing the entry referenced by the entry with the last "rc", 973 one can realize that the URI used to reach the device was GRUU by 974 finding the "gr" parameter. 976 3.6. Limited Use Address 978 A limited use address is a SIP URI that is minted on-demand, and 979 passed out to a small number (usually one) remote correspondent. 980 Incoming calls targeted to that limited use address are accepted as 981 long as the UA still desires communications from the remote target. 982 Should they no longer wish to be bothered by that remote 983 correspondent, the URI is invalidated so that future requests 984 targeted to it are rejected. 986 Limited use addresses are used in battling voice spam [RFC5039]. The 987 easiest way to provide them would be for a UA to be able to take its 988 AOR, and "mint" a limited use address by appending additional 989 parameters to the URI. It could then give out the URI to a 990 particular correspondent, and remember that URI locally. When an 991 incoming call arrives, the UAS would examine the parameter in the URI 992 and determine whether or not the call should be accepted. 993 Alternatively, the UA could push authorization rules into the 994 network, so that it need not even see incoming requests that are to 995 be rejected. 997 This approach, especially when executed on the UA, requires that 998 parameters attached to the AOR, but not used by the home proxy in 999 processing the request, will survive the translation at the home 1000 proxy and be presented to the UA. This will not be the case with the 1001 logic in RFC 3261, since the Request-URI is replaced by the 1002 registered contact, and any such parameters are lost. 1004 Using the history-info John's UA can easily see if the call was 1005 addressed to its AoR, GRUU or a temp-gruu and treat the call 1006 accordingly by looking for a "gr" tag in the hi-entry prior to the 1007 last hi-entry. 1009 Alice Example.com John 1010 | | REGISTER F1 | 1011 | |<--------------------| 1012 | | 200 OK F2 | 1013 | |-------------------->| 1014 | INVITE F3 | | 1015 |-------------------->| | 1016 | | INVITE F4 | 1017 | |-------------------->| 1018 * Rest of flow not shown * 1020 F1 REGISTER John -> Example.com 1022 REGISTER sip:example.com SIP/2.0 1023 Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bKnashds7 1024 Max-Forwards: 70 1025 From: John ;tag=a73kszlfl 1026 Supported: gruu 1027 To: John 1028 Call-ID: 1j9FpLxk3uxtm8tn@192.0.2.1 1029 CSeq: 1 REGISTER 1030 Contact: 1031 ;+sip.instance="" 1032 Content-Length: 0 1034 F2 200 OK Example.com -> John 1036 SIP/2.0 200 OK 1037 Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bKnashds7 1038 From: John ;tag=a73kszlfl 1039 To: John ;tag=b88sn 1040 Call-ID: 1j9FpLxk3uxtm8tn@192.0.2.1 1041 CSeq: 1 REGISTER 1042 Contact: 1043 ;pub-gruu="sip:john@example.com 1044 ;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6" 1045 ;temp-gruu= 1046 "sip:tgruu.7hs==jd7vnzga5w7fajsc7-ajd6fabz0f8g5@example.com;gr" 1047 ;+sip.instance="" 1048 ;expires=3600 1049 Content-Length: 0 1051 Assuming Alice has a knowledge of a temp-gruu, she places a 1052 call to the temp-gruu. 1054 F3 INVITE Alice -> Example.com 1056 INVITE sip:tgruu.7hs==jd7vnzga5w7fajsc7-ajd6fabz0f8g5@example.com 1057 ;gr SIP/2.0 1058 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK42t2 1059 From: Alice ;tag=kkaz- 1060 To: 1062 Supported: gruu, histinfo 1063 Call-Id: 12345600@example.com 1064 CSeq: 1 INVITE 1065 History-Info: 1066 1067 ;index=1 1068 Contact: Alice 1069 Content-Length: 1071 F4 INVITE Example.com -> John 1073 INVITE sip:john@192.0.2.1 SIP/2.0 1074 Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bK12s4 1075 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK42t2 1076 From: Alice ;tag=kkaz- 1077 To: John 1078 Supported: gruu, histinfo 1079 Call-Id: 12345600@example.com 1080 CSeq: 1 INVITE 1081 Record-Route: 1082 History-Info: 1083 1084 ;index=1 1085 History-Info: ;index=1.1;rc=1 1086 Contact: Alice 1087 Content-Type: application/sdp 1088 Content-Length: 1090 Figure 3: Limited Use Address Example 1092 By analyzing the entry referenced by the entry with the last "rc", 1093 one can realize that the URI used to reach the device was GRUU by 1094 finding the "gr" parameter. 1096 3.7. Service Invocation 1098 Several SIP specifications have been developed which make use of 1099 complex URIs to address services within the network rather than 1100 subscribers. The URIs are complex because they contain numerous 1101 parameters that control the behavior of the service. Examples of 1102 this include the specification which first introduced the concept, 1103 [RFC3087], control of network announcements and IVR with SIP URI 1104 [RFC4240], and control of voicemail access with SIP URI [RFC4458]. 1106 A common problem with all of these mechanisms is that once a proxy 1107 has decided to rewrite the Request-URI to point to the service, it 1108 cannot be sure that the Request-URI will not be destroyed by a 1109 downstream proxy which decides to forward the request in some way, 1110 and does so by rewriting the Request-URI. 1112 Section on voicemail (Section 3.3) shows how History-Info can be used 1113 to invocate a service. 1115 3.8. Toll Free Number 1117 Toll free numbers, also known as 800 or 8xx numbers in the United 1118 States, are telephone numbers that are free for users to call. 1120 In the telephone network, toll free numbers are just aliases to 1121 actual numbers which are used for routing of the call. In order to 1122 process the call in the PSTN, a switch will perform a query (using a 1123 protocol called TCAP), which will return either a phone number or the 1124 identity of a carrier which can handle the call. 1126 There has been recent work on allowing such PSTN translation services 1127 to be accessed by SIP proxy servers through IP querying mechanisms. 1128 ENUM, for example [RFC3761] has already been proposed as a mechanism 1129 for performing Local Number Portability (LNP) queries [RFC4769], and 1130 recently been proposed for performing calling name queries 1131 [I-D.ietf-enum-cnam]. Using it for 8xx number translations is a 1132 logical next-step. 1134 Once such a translation has been performed, the call needs to be 1135 routed towards the target of the request. Normally, this would 1136 happen by selecting a PSTN gateway which is a good route towards the 1137 translated number. However, one can imagine all-IP systems where the 1138 8xx numbers are SIP endpoints on an IP network, in which case the 1139 translation of the 8xx number would actually be a SIP URI and not a 1140 phone number. Assuming for the moment it is a PSTN connected entity, 1141 the call would be routed towards a PSTN gateway. Proper treatment of 1142 the call in the PSTN (and in particular, correct reconciliation of 1143 billing records) requires that the call be marked with both the 1144 original 8xx number AND the target number for the call. However, in 1145 our example here, since the translation was performed by a SIP proxy 1146 upstream from the gateway, the original 8xx number would have been 1147 lost, and the call will not interwork properly with the PSTN. 1149 Furthermore, even if the translation of the 8xx number was a SIP URI, 1150 the enterprise or user who utilize the 8xx service would like to know 1151 whether the call came in via 8xx number in order to treat the call 1152 differently (for example to play a special announcement..) but if the 1153 original R-URI is lost through translation, there is no way to tell 1154 if the call came in via 8xx number. 1156 Similar problems arise with other "special" numbers and services used 1157 in the PSTN, such as operator services, pay/premium numbers (9xx 1158 numbers in the U.S), and short service codes such as 311. 1160 To find the service number, the UAS can extract the hi-entry whose 1161 index matches the value of the first hi-entry with an "mp" tag. 1162 Technically the call can be forwarded to these "special" numbers from 1163 non "special" numbers, however that is uncommon based on the way 1164 these services authorize translations. 1166 Alice Toll Free Service Atlanta.com John 1167 | | | | 1168 | INVITE F1 | | | 1169 |--------------->| INVITE F2 | | 1170 | |------------->| | 1171 | | | INVITE F3 | 1172 | | |------------------>| 1174 * Rest of flow not shown * 1176 F1: INVITE 192.0.2.1 -> Toll Free Service 1178 INVITE sip:+18005551002@example.com;user=phone SIP/2.0 1179 Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK74bf 1180 From: Alice ;tag=9fxced76sl 1181 To: sip:+18005551002@example.com;user=phone 1182 Call-ID: c3x842276298220188511 1183 CSeq: 1 INVITE 1184 Max-Forwards: 70 1185 Contact: 1186 Content-Type: application/sdp 1187 Content-Length: 1189 [SDP Not Shown] 1191 F2: INVITE Toll Free Service -> Atlanta.com 1193 INVITE sip:+15555551002@atlanta.com SIP/2.0 1194 Via: SIP/2.0/TCP 192.0.2.4:5060;branch=z9hG4bK-ik8 1195 Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK74bf 1196 From: Alice ;tag=9fxced76sl 1197 To: sip:+18005551002@example.com;user=phone 1198 Call-ID: c3x842276298220188511 1199 CSeq: 1 INVITE 1200 Max-Forwards: 70 1201 Supported: histinfo 1202 History-Info: ;index=1, 1203 ;index=1.1;mp=1 1205 Contact: 1206 Content-Type: application/sdp 1207 Content-Length: 1209 [SDP Not Shown] 1211 F3: INVITE Atlanta.com -> John 1213 INVITE sip:john@198.51.100.2 SIP/2.0 1214 Via: SIP/2.0/TCP 198.51.100.1:5060;branch=z9hG4bKpxk7g 1215 Via: SIP/2.0/TCP 192.0.2.4:5060;branch=z9hG4bK-ik80 1216 Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK74bf 1217 From: Alice ;tag=9fxced76sl 1218 To: sip:+18005551002@example.com;user=phone 1219 Call-ID: c3x842276298220188511 1220 CSeq: 1 INVITE 1221 Max-Forwards: 70 1222 Supported: histinfo 1223 History-Info: ;index=1, 1224 ;index=1.1;mp=1, 1225 ;index=1.1.1;rc=1.1 1226 ;index=1.1.2;rc=1.1 1227 Contact: 1228 Content-Type: application/sdp 1229 Content-Length: 1231 [SDP Not Shown] 1233 Figure 4: Service Number Example 1235 4. Security Considerations 1237 The security considerations for the History-Info header field are 1238 specified in [I-D.ietf-sipcore-rfc4244bis]. 1240 5. IANA Considerations 1242 This document has no IANA considerations. 1244 5.1. Acknowledgements 1246 Jonathan Rosenberg et al produced the document that provided 1247 additional use cases precipitating the requirement for the new 1248 "target" parameter in the History-Info header field and the new SIP/ 1249 SIPS URI parameter. Hadriel Kaplan provided some comments. 1251 6. Informative References 1253 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1254 A., Peterson, J., Sparks, R., Handley, M., and E. 1255 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1256 June 2002. 1258 [RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason 1259 Header Field for the Session Initiation Protocol (SIP)", 1260 RFC 3326, December 2002. 1262 [RFC3323] Peterson, J., "A Privacy Mechanism for the Session 1263 Initiation Protocol (SIP)", RFC 3323, November 2002. 1265 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1266 Requirement Levels", BCP 14, RFC 2119, March 1997. 1268 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1269 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1271 [RFC4244] Barnes, M., "An Extension to the Session Initiation 1272 Protocol (SIP) for Request History Information", RFC 4244, 1273 November 2005. 1275 [RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User 1276 Agent URIs (GRUUs) in the Session Initiation Protocol 1277 (SIP)", RFC 5627, October 2009. 1279 [RFC5630] Audet, F., "The Use of the SIPS URI Scheme in the Session 1280 Initiation Protocol (SIP)", RFC 5630, October 2009. 1282 [RFC3087] Campbell, B. and R. Sparks, "Control of Service Context 1283 using SIP Request-URI", RFC 3087, April 2001. 1285 [RFC4240] Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network 1286 Media Services with SIP", RFC 4240, December 2005. 1288 [RFC5039] Rosenberg, J. and C. Jennings, "The Session Initiation 1289 Protocol (SIP) and Spam", RFC 5039, January 2008. 1291 [RFC4458] Jennings, C., Audet, F., and J. Elwell, "Session 1292 Initiation Protocol (SIP) URIs for Applications such as 1293 Voicemail and Interactive Voice Response (IVR)", RFC 4458, 1294 April 2006. 1296 [RFC3761] Faltstrom, P. and M. Mealling, "The E.164 to Uniform 1297 Resource Identifiers (URI) Dynamic Delegation Discovery 1298 System (DDDS) Application (ENUM)", RFC 3761, April 2004. 1300 [RFC4769] Livingood, J. and R. Shockey, "IANA Registration for an 1301 Enumservice Containing Public Switched Telephone Network 1302 (PSTN) Signaling Information", RFC 4769, November 2006. 1304 [RFC3969] Camarillo, G., "The Internet Assigned Number Authority 1305 (IANA) Uniform Resource Identifier (URI) Parameter 1306 Registry for the Session Initiation Protocol (SIP)", 1307 BCP 99, RFC 3969, December 2004. 1309 [I-D.ietf-enum-cnam] 1310 Shockey, R., "IANA Registration for an Enumservice Calling 1311 Name Delivery (CNAM) Information and IANA Registration for 1312 URI type 'pstndata'", draft-ietf-enum-cnam-08 (work in 1313 progress), September 2008. 1315 [I-D.ietf-sipcore-rfc4244bis] 1316 Holmberg, C., Audet, F., Barnes, M., Elburg, H., and S. 1317 Schubert, "An Extension to the Session Initiation Protocol 1318 (SIP) for Request History Information", 1319 draft-ietf-sipcore-rfc4244bis-06 (work in progress), 1320 October 2011. 1322 Authors' Addresses 1324 Mary Barnes 1325 Polycom 1326 TX 1327 US 1329 Email: mary.ietf.barnes@gmail.com 1331 Francois Audet 1332 Skype 1334 Email: francois.audet@skype.net 1336 Shida Schubert 1337 NTT 1338 Tokyo 1339 Japan 1341 Email: shida@ntt-at.com 1342 Hans Erik van Elburg 1343 Detecon International Gmbh 1344 Oberkasseler str. 2 1345 Bonn, 1346 Germany 1348 Email: ietf.hanserik@gmail.com 1350 Christer Holmberg 1351 Ericsson 1352 Hirsalantie 11, Jorvas 1353 Finland 1355 Email: christer.holmberg@ericsson.com