idnits 2.17.1 draft-ietf-sipcore-rfc4244bis-06.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 == Line 438 has weird spacing: '... Alice atla...' == Line 2224 has weird spacing: '... Alice exam...' == Line 2479 has weird spacing: '... Alice atla...' == Line 2620 has weird spacing: '... Alice atla...' == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (Oct 2011) is 4577 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) == Missing Reference: 'RFC XXXX' is mentioned on line 1133, but not defined == Unused Reference: 'RFC3969' is defined on line 1657, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 4244 (Obsoleted by RFC 7044) Summary: 2 errors (**), 0 flaws (~~), 8 warnings (==), 2 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 Obsoletes: 4244 (if approved) F. Audet 5 Intended status: Standards Track Skype 6 Expires: April 3, 2012 S. Schubert 7 NTT 8 J. van Elburg 9 Detecon International Gmbh 10 C. Holmberg 11 Ericsson 12 Oct 2011 14 An Extension to the Session Initiation Protocol (SIP) for Request 15 History Information 16 draft-ietf-sipcore-rfc4244bis-06.txt 18 Abstract 20 This document defines a standard mechanism for capturing the history 21 information associated with a Session Initiation Protocol (SIP) 22 request. This capability enables many enhanced services by providing 23 the information as to how and why a SIP request arrives at a specific 24 application or user. This document defines an optional SIP header 25 field, History-Info, for capturing the history information in 26 requests. The document also defines SIP header field parameters for 27 the History-Info and Contact header fields to tag the method by which 28 the target of a request is determined. In addition, this 29 specification defines a value for the Privacy header field specific 30 to the History-Info header field. This document obsoletes RFC 4244. 32 Status of this Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on April 3, 2012. 49 Copyright Notice 51 Copyright (c) 2011 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 This document may contain material from IETF Documents or IETF 65 Contributions published or made publicly available before November 66 10, 2008. The person(s) controlling the copyright in some of this 67 material may not have granted the IETF Trust the right to allow 68 modifications of such material outside the IETF Standards Process. 69 Without obtaining an adequate license from the person(s) controlling 70 the copyright in such materials, this document may not be modified 71 outside the IETF Standards Process, and derivative works of it may 72 not be created outside the IETF Standards Process, except to format 73 it for publication as an RFC or to translate it into languages other 74 than English. 76 Table of Contents 78 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 79 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 5 80 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 6 81 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 82 5. History-Info Header Field Protocol Structure . . . . . . . . . 8 83 5.1. History-Info Header Field Example Scenario . . . . . . . . 10 84 6. User Agent Handling of the History-Info Header Field . . . . . 13 85 6.1. User Agent Client (UAC) Behavior . . . . . . . . . . . . . 13 86 6.2. User Agent Server (UAS) Behavior . . . . . . . . . . . . . 13 87 7. Proxy/Intermediary Handling of History-Info Header Fields . . 13 88 8. Redirect Server Handling of History-Info Header Fields . . . . 14 89 9. Handling of History-Info Header Fields in Requests and 90 Responses . . . . . . . . . . . . . . . . . . . . . . . . . . 14 91 9.1. Receiving a Request . . . . . . . . . . . . . . . . . . . 14 92 9.2. Sending a Request with History-Info . . . . . . . . . . . 15 93 9.3. Receiving a Response with History-Info or Requet 94 Timeouts . . . . . . . . . . . . . . . . . . . . . . . . . 15 95 9.4. Sending History-Info in Responses . . . . . . . . . . . . 16 96 10. Processing the History-Info Header Field . . . . . . . . . . . 16 97 10.1. Privacy in the History-Info Header Field . . . . . . . . . 17 98 10.1.1. Indicating Privacy . . . . . . . . . . . . . . . . . 17 99 10.1.2. Applying Privacy . . . . . . . . . . . . . . . . . . 18 100 10.2. Reason in the History-info Header Field . . . . . . . . . 19 101 10.3. Indexing in the History-Info Header Field . . . . . . . . 19 102 10.4. Mechanism for Target Determination in the History-Info 103 Header Field . . . . . . . . . . . . . . . . . . . . . . . 21 104 11. Application Considerations . . . . . . . . . . . . . . . . . . 22 105 12. Application Specific Usage . . . . . . . . . . . . . . . . . . 24 106 12.1. PBX Voicemail . . . . . . . . . . . . . . . . . . . . . . 24 107 12.2. Consumer Voicemail . . . . . . . . . . . . . . . . . . . . 24 108 13. Security Considerations . . . . . . . . . . . . . . . . . . . 25 109 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 110 14.1. Registration of New SIP History-Info Header Field . . . . 26 111 14.2. Registration of "history" for SIP Privacy Header Field . . 26 112 14.3. Registration of Header Field Parameters . . . . . . . . . 27 113 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 114 16. Changes from RFC 4244 . . . . . . . . . . . . . . . . . . . . 28 115 16.1. Backwards compatibility . . . . . . . . . . . . . . . . . 29 116 17. Changes since last Version . . . . . . . . . . . . . . . . . . 30 117 18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37 118 18.1. Normative References . . . . . . . . . . . . . . . . . . . 37 119 18.2. Informative References . . . . . . . . . . . . . . . . . . 37 120 Appendix A. Request History Requirements . . . . . . . . . . . . 38 121 A.1. Security Requirements . . . . . . . . . . . . . . . . . . 39 122 A.2. Privacy Requirements . . . . . . . . . . . . . . . . . . . 40 123 Appendix B. Example call flows . . . . . . . . . . . . . . . . . 40 124 B.1. PBX Voicemail call floww . . . . . . . . . . . . . . . . . 40 125 B.2. Consumer Voicemail example call flow . . . . . . . . . . . 45 126 B.3. Sequentially Forking (History-Info in Response) . . . . . 49 127 B.4. History-Info with Privacy Header Field . . . . . . . . . . 56 128 B.5. Privacy for a Specific History-Info Entry . . . . . . . . 60 129 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 64 131 1. Introduction 133 Many services that SIP is anticipated to support require the ability 134 to determine why and how a SIP request arrived at a specific 135 application. Examples of such services include (but are not limited 136 to) sessions initiated to call centers via "click to talk" SIP 137 Uniform Resource Locators (URLs) on a web page, "call history/ 138 logging" style services within intelligent "call management" software 139 for SIP User Agents (UAs), and calls to voicemail servers. Although 140 SIP implicitly provides the retarget capabilities that enable SIP 141 requests to be routed to chosen applications, there is a need for a 142 standard mechanism within SIP for communicating the retargeting 143 history of the requests. This "request history" information allows 144 the receiving application to determine hints about how and why the 145 SIP request arrived at the application/user. 147 This document defines a SIP header field, History-Info, to provide a 148 standard mechanism for capturing the request history information to 149 enable a wide variety of services for networks and end-users. SIP 150 header field parameters are defined for the History-Info and Contact 151 header fields to tag the method by which the target of a request is 152 determined. In addition, this specification defines a value for the 153 Privacy header field specific to the History-Info header. 155 The History-info header field provides a building block for 156 development of SIP based applications and services. The requirements 157 for the solution described in this specification are included in 158 Appendix A. Example scenarios using the History-info header field 159 are included in Appendix B. 161 2. Conventions and Terminology 163 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 164 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 165 document are to be interpreted as described in [RFC2119]. 167 The term "retarget" is used in this specification to refer to the 168 process of a SIP entity changing a Uniform Resource Identifier (URI) 169 in a request based on the rules for determining request targets as 170 described in Section 16.5 of [RFC3261] and of the subsequent 171 forwarding of that request as described in step 2 in section 16.6 of 172 [RFC3261]. This includes changing the Request-URI due to a location 173 service lookup and redirect processing. This also includes internal 174 (to a Proxy/SIP intermediary) changes of the URI prior to forwarding 175 of the request. 177 The terms "location service", "forward", "redirect" and "AOR" are 178 used consistent with the terminology in [RFC3261]. 180 The terms "terget user" is used in this specification as the human 181 user associated with particular AoR or AoRs (in case the human user 182 has multiple alias). 184 The references to "domain for which the SIP entity/Proxy/Intermediary 185 is responsible" are consistent with and intended to convey the same 186 context as the usage of that terminology in [RFC3261]. The 187 applicability of History-Info to architectures or models outside the 188 context of [RFC3261] is outside the scope of this specification. 190 3. Background 192 SIP implicitly provides retargeting capabilities that enable SIP 193 requests to be routed to specific applications as defined in 194 [RFC3261]. The motivation for capturing the request history is that 195 in the process of retargeting a request, old routing information can 196 be forever lost. This lost information may be important history that 197 allows elements to which the request is retargeted to process the 198 request in a locally defined, application-specific manner. This 199 document defines a mechanism for transporting the request history. 200 Application-specific behavior is outside the scope of this 201 specification. 203 Current network applications provide the ability for elements 204 involved with the request to obtain additional information relating 205 to how and why the request was routed to a particular destination. 206 The following are examples of such applications: 208 1. Web "referral" applications, whereby an application residing 209 within a web server determines that a visitor to a website has 210 arrived at the site via an "associate" site that will receive 211 some "referral" commission for generating this traffic 213 2. Email forwarding whereby the forwarded-to user obtains a 214 "history" of who sent the email to whom and at what time 216 3. Traditional telephony services such as voicemail, call-center 217 "automatic call distribution", and "follow-me" style services 219 Several of the aforementioned applications currently define 220 application-specific mechanisms through which it is possible to 221 obtain the necessary history information. 223 In addition, request history information could be used to enhance 224 basic SIP functionality by providing the following: 226 o Some diagnostic information for debugging SIP requests. 228 o Capturing aliases and Globally Routable User Agent URIs (GRUUs) 229 [RFC5627], which can be overwritten by a REGISTRAR or a "home 230 proxy" (a proxy serving as the terminal point for routing an 231 address-of-record) upon receipt of the initial request. 233 o Facilitating the use of limited use addresses (minted on demand) 234 and sub-addressing. 236 o Preserving service specific URIs that can be overwritten by a 237 downstream proxy, such as those defined in [RFC3087], and control 238 of network announcements and IVR with SIP URI [RFC4240]. 240 4. Overview 242 The fundamental functionality provided by the request history 243 information is the ability to inform proxies and UAs involved in 244 processing a request about the history or progress of that request. 245 The solution is to capture the Request-URIs as a request is 246 retargeted, in a SIP header field: History-Info. This allows for the 247 capturing of the history of a request that would be lost with the 248 normal SIP processing involved in the subsequent retargeting of the 249 request. 251 The History-info header field is added to a Request when a new 252 request is created by a UAC or forwarded by a Proxy, or when the 253 target of a request is changed. It is possible for the target of a 254 request to be changed by the same proxy/SIP Intermediary multiple 255 times (referred to as 'internal retargeting'). A SIP entity changing 256 the target of a request in response to a redirect also propagates any 257 History-info header field from the initial request in the new 258 request. The ABNF and detailed description of the History-Info 259 header field parameters, along with examples is provided in 260 Section 5. Section 6, Section 7 and Section 8 provide the detailed 261 handling of the History-Info header field by SIP User Agents, Proxies 262 and Redirect Servers respectively. 264 This specification also defines three new SIP header field 265 parameters, "rc", "mp" and "np", for the History-Info and Contact 266 header fields, to tag the method by which the target of a request is 267 determined. Further detail on the use of these header field 268 parameters is provided in Section 10.4. 270 In addition, this specification defines a priv-value for the Privacy 271 header, "history", that applies to all the History-info header field 272 entries in a Request or to a specific History-info header field hi- 273 entry as described above. Further detail is provided in 274 Section 10.1. 276 5. History-Info Header Field Protocol Structure 278 The History-info header field defined in this specification defines 279 the usage in out-of-dialog requests or initial requests for a dialog 280 (e.g., INVITE, REGISTER, MESSAGE, REFER and OPTIONS, PUBLISH and 281 SUBSCRIBE, etc.) and any non-100 provisional or final responses to 282 these requests (ISSUER-req, see Appendix A). 284 The following provides details for the information that is captured 285 in the History-Info header field entries for each target used for 286 forwarding a request: 288 o hi-targeted-to-uri: A mandatory parameter for capturing the 289 Request-URI for the specific request as it is forwarded. 291 o hi-index: A mandatory parameter for History-Info reflecting the 292 chronological order of the information, indexed to also reflect 293 the forking and nesting of requests. The format for this 294 parameter is a string of digits, separated by dots to indicate the 295 number of forward hops and retargets. This results in a tree 296 representation of the history of the request, with the lowest- 297 level index reflecting a branch of the tree. By adding the new 298 entries in order (i.e., following existing entries per the details 299 in Section 10.3), including the index and sending the messages 300 using a secure transport, the ordering of the History-info header 301 fields in the request is assured. In addition, applications may 302 extract a variety of metrics (total number of retargets, total 303 number of retargets from a specific branch, etc.) based upon the 304 index values. 306 o hi-target-param: An optional parameter reflecting the mechanism by 307 which the Request URI captured in the hi-targeted-to-uri in the 308 History-info header field value (hi-entry) was determined. This 309 parameter contains either an "rc", "mp" or "np" header field 310 parameter, which is interpreted as follows: 312 "rc": The hi-targeted-to-URI represents a change in Request-URI 313 while the target user remains the same. This occurs for 314 example when user has multiple AoRs as an alias. The "rc" 315 header field parameter contains the value of the hi-index in 316 the hi-entry with an hi-targeted-to-uri that reflects the 317 Request-URI that was retargeted 318 "mp": The hi-targeted-to-URI represents a user other than the 319 target user associated with the Request-URI in the incoming 320 request that was retargeted. This occurs when a request is 321 statically or dynamically retargeted to another user 322 represented by an AoR unassociated with the AoR of the original 323 target user. The "mp" header field parameter contains the 324 value which represents the value of the hi-index in the hi- 325 entry with an hi-targeted-to-uri that reflects the Request-URI 326 that was retargeted, thus identifying the "mapped from" target. 328 "np": The hi-targeted-to-URI represents that there was no 329 change in Request-URI. This would apply for example when a 330 proxy merely forwards a request to a next hop proxy and loose 331 routing is used. 333 o Extension (hi-extension): A parameter to allow for future optional 334 extensions. As per [RFC3261], any implementation not 335 understanding an extension MUST ignore it. 337 The ABNF syntax for the History-info header field and header field 338 parameters is as follows: 340 History-Info = "History-Info" HCOLON hi-entry *(COMMA hi-entry) 342 hi-entry = hi-targeted-to-uri *(SEMI hi-param) 344 hi-targeted-to-uri = addr-spec / name-addr 346 hi-param = hi-index / hi-target-param / hi-extension 348 index-val = 1*DIGIT *("." 1*DIGIT) 350 hi-index = "index" EQUAL index-val 352 hi-target-param = rc-param / mp-param / np-param 354 rc-param = "rc" EQUAL index-val 356 mp-param = "mp" EQUAL index-val 358 np-param = "np" EQUAL index-val 360 hi-extension = generic-param 362 The ABNF definitions for "generic-param" and "name-addr" are from 363 [RFC3261]. 365 This document also extends the "contact-params" for the Contact 366 header field as defined in [RFC3261] with the "rc", "mp" and "np" 367 header field parameters defined above. 369 In addition to the parameters defined by the ABNF, an hi-entry may 370 also include a Reason header field and/or a Privacy header field, 371 which are both included in the "headers" component of the hi- 372 targeted-to-uri as described below: 374 o Reason: An optional parameter for History-Info, reflected in the 375 History-info header field by including the Reason header field 376 [RFC3326] included in the hi-targeted-to-uri. A reason is 377 included in the hi-targeted-to-uri of an hi-entry to reflect 378 information received in a response to the request sent to that 379 URI. 381 o Privacy: An optional parameter for History-Info, reflected in the 382 History-Info header field values by including the Privacy Header 383 [RFC3323] included in the hi- targeted-to-uri or by adding the 384 Privacy header field to the request. The latter case indicates 385 that the History-Info entries for the domain MUST be anonymized 386 prior to forwarding, whereas the use of the Privacy header field 387 included in the hi-targeted-to-uri means that a specific hi-entry 388 MUST be anonymized. 390 Note that since both the Reason and Privacy parameters are included 391 in the hi-targeted-to-uri, these fields will not be available in the 392 case that the hi-targeted-to-uri is a Tel-URI [RFC3966]. 394 The following provides examples of the format for the History-info 395 header field. Note that the backslash and CRLF between the fields in 396 the examples below are for readability purposes only. 398 History-Info: ;index=1;foo=bar 400 History-Info: ;index=1.1,\ 402 ;index=1.2;mp=1.1,\ 404 ;index=1.3;rc=1.2 406 5.1. History-Info Header Field Example Scenario 408 The following is an illustrative example of usage of History-Info. 410 In this example, Alice (sip:alice@atlanta.example.com) calls Bob 411 (sip:bob@biloxi.example.com). Alice's proxy in her home domain (sip: 413 atlanta.example.com) forwards the request to Bob's proxy (sip: 414 biloxi.example.com). When the request arrives at sip: 415 biloxi.example.com, it does a location service lookup for 416 bob@biloxi.example.com and changes the target of the request to Bob's 417 Contact URIs provided as part of normal SIP registration. In this 418 example, Bob is simultaneously contacted on a PC client and on a 419 phone, and Bob answers on the PC client. 421 One important thing illustrated by this call flow is that without 422 History-Info, Bob would "lose" the target information, including any 423 parameters in the request URI. Bob can recover that information by 424 locating the last hi-entry with an "rc" header field parameter. This 425 "rc" header field parameter contains the index of the hi-entry 426 containing the lost target information - i.e., the 427 sip:bob@biloxi.example.com hi-entry with index=1.1. Note that an hi- 428 entry is not included for the fork to sip:bob@192.0.2.7 since there 429 was no response at the time the 200 OK is sent to Alice. 431 The formatting in this scenario is for visual purposes; thus, 432 backslash and CRLF are used between the fields for readability. 433 Refer to Section 5.1 for the proper formatting. Additional detailed 434 scenarios are available in Appendix B. 436 Note: This example uses loose routing procedures. 438 Alice atlanta.example.com biloxi.example.com Bob@pc Bob@phone 439 | | | | | 440 | INVITE sip:bob@biloxi.example.com;p=x | | 441 |--------------->| | | | 442 | Supported: histinfo | | | 443 | | | | | 444 | | INVITE sip:bob@biloxi.example.com;p=x | 445 | |--------------->| | | 446 | History-Info: ;index=1 | 447 | History-Info: ;np=1;index=1.1 448 | | | | | 449 | | | INVITE sip:bob@192.0.2.3| 450 | | |--------------->| | 451 | History-Info: ;index=1 452 | History-Info: ;np=1;index=1.1 453 | History-Info: ;index=1.1.1;rc=1.1 454 | | | | | 455 | | | INVITE sip:bob@192.0.2.7| 456 | | |-------------------------->| 457 | History-Info: ;index=1 458 | History-Info: ;np=1;index=1.1 459 | History-Info: ;index=1.1.2;rc=1.1 460 | | | 200 | | 461 | | |<---------------| | 462 | History-Info: ;index=1 463 | History-Info: ;np=1;index=1.1 464 | History-Info: ;index=1.1.1;rc=1.1 465 | | | | | 466 | | 200 | | | 467 | |<---------------| | | 468 | History-Info: ;index=1 469 | History-Info: ;np=1;index=1.1 470 | History-Info: ;index=1.1.1;rc=1.1 471 | | | | | 472 | | | Proxy Cancels INVITE | 473 | | |<=========================>| 474 | | | | | 475 | 200 | | | | 476 |<---------------| | | | 477 | History-Info: ;index=1 478 | History-Info: ;np=1;index=1.1 479 | History-Info: | ACK | | | 483 | |--------------->| ACK | | 484 | | |--------------->| | 485 Figure 1: Basic Call 487 6. User Agent Handling of the History-Info Header Field 489 A B2BUA MAY follow the behavior of a SIP intermediary as an 490 alternative to following the behavior of a UAS per Section 6.2 and a 491 UAC per Section 6.1. In behaving as an intermediary, a B2BUA carries 492 forward hi-entries received in requests at the UAS to requests being 493 forwarded by the UAC, as well as carrying forward hi-entries in 494 responses received at the UAC to the responses forwarded by the UAS, 495 subject to privacy considerations per Section 10.1. 497 6.1. User Agent Client (UAC) Behavior 499 The UAC MUST include the "histinfo" option tag in the Supported 500 header field in any out-of-dialog requests or initial requests for a 501 dialog for which the UAC would like the History-info header field in 502 the response. When issuing a request, the UAC MUST follow the 503 procedures in Section 9.2. In the case of an initial request, except 504 where the UAC is part of a B2BUA, there is no cache of hi- entries 505 with which to populate the History-info header field and the hi-index 506 is set to 1 per Section 10.3. When receiving a response the UAC MUST 507 follow the procedures in Section 9.3. 509 6.2. User Agent Server (UAS) Behavior 511 When receiving a request, a UAS MUST follow the procedures defined in 512 Section 9.2. When sending a response other than a 3xx response, a 513 UAS MUST follows the procedures as defined in Section 9.4. When 514 sending a 3xx response, the UAS MUST follow the procedures defined 515 for a redirect server per Section 8. An application at the UAS can 516 make use of the cached hi-entries as described in Section 11. 518 7. Proxy/Intermediary Handling of History-Info Header Fields 520 This section describes the procedures for proxies and other SIP 521 intermediaries for the handling of the History-Info header fields for 522 each of the following scenarios: 524 Receiving a Request: An intermediary MUST follow the procedures in 525 Section 9.1 for the handling of hi-entries in incoming SIP 526 requests. 528 Sending a Request: For each outgoing request relating to a target in 529 the target set, the intermediary MUST follow the procedures of 530 Section 9.2. 532 Receiving a Response ot Timeout: An intermediary MUST follow the 533 procedures of Section 9.3 when a SIP response is received or a 534 request times out. 536 Sending a Response: An intermediary MUST follow the procedures of 537 Section 9.4 for the handling of the hi-entries when sending a SIP 538 response. 540 In some cases, an intermediary may retarget a request more than once 541 before forwarding - i.e., a request is retargeted to a SIP entity 542 that is "internal" to the intermediary before the same intermediary 543 retargets the request to an external target . A typical example 544 would be a proxy that retargets a request first to a different user 545 (i.e., it maps to a different AOR) and then forwards to a registered 546 contact bound to the same AOR. In this case, the intermediary MUST 547 add a hi-entry for (each of) the internal target(s) per the 548 procedures in Section 9.2. The intermediary MAY include a Reason 549 header field in the hi-entry with the hi-targeted-to-uri that has 550 been retargeted as shown in the INVITE (F6) in the example in 551 Appendix B.3. Figure 1 provides an example of internal retargeting. 553 8. Redirect Server Handling of History-Info Header Fields 555 A redirect server MUST follow the procedures in Section 9.1 when it 556 receives a SIP Request. A redirect server MUST follow the procedures 557 in Section 9.4 when it sends a SIP Response. When generating the 558 Contact header field in a 3xx response, the redirect server MUST add 559 the appropriate "mp", "np" or "rc" header field parameter to each 560 Contact header field as described in Section 10.4, if applicable. 562 9. Handling of History-Info Header Fields in Requests and Responses 564 This section describes the procedures for SIP entities for the 565 handling of the History-Info header field in SIP requests and 566 responses. 568 9.1. Receiving a Request 570 When receiving a request, a SIP entity MUST create a cache containing 571 the hi-entries associated with the request. The hi-entries MUST be 572 added to the cache in the order in which they were received in the 573 request. 575 If the Request-URI of the incoming request does not match the hi- 576 targeted-to-uri in the last hi-entry (i.e., the previous SIP entity 577 that sent the request did not include a History-Info header field), 578 the SIP entity MUST add a hi-entry to end of the cache, on behalf of 579 the previous SIP entity, as follows: 581 The SIP entity MUST set the hi-targeted-to-uri to the value of the 582 Request-URI in the incoming request. If the Request-URI is a Tel- 583 URI, it SHOULD be transformed into a SIP URI per section 19.1.6 of 584 [RFC3261] before being added as a hi-targted-to-uri. 586 If privacy is required, the SIP entity MUST follow the procedures 587 of Section 10.1. 589 The SIP entity MUST set the hi-index parameter as described in 590 Section 10.3. 592 The SIP entity MUST NOT include an "rc", "mp" or "np" header field 593 parameter. 595 9.2. Sending a Request with History-Info 597 When sending a request, a SIP entity MUST include all cached hi- 598 entries in the request. In addition, the SIP entity MUST add a new 599 hi-entry to the outgoing request, but the SIP entity MUST NOT add the 600 hi-entry to the outgoing request(but not the cache) populating the 601 new hi-entry to the cache at this time. The new hi-entry is 602 populated as follows: 604 hi-targeted-to-uri: The hi-targeted-to-uri MUST be set to the value 605 of the Request-URI of the current (outgoing) request. 607 privacy: If privacy is required, the procedures of Section 10.1 MUST 608 be followed. 610 hi-index: The SIP entity MUST include an hi-index for the hi-entry 611 as described in Section 10.3. 613 rc/mp: The SIP entity MUST include an "rc", "mp" or "np" header 614 field parameter in the hi-entry, if applicable, per the procedures 615 in Section 10.4. 617 9.3. Receiving a Response with History-Info or Requet Timeouts 619 When a SIP entity receives a non-100 response or a request times out, 620 the SIP entity performs the following steps: 622 Step 1: Add hi-entry to cache 624 The SIP entity MUST add the hi-entry that was added to the request 625 that received the non-100 response or timed out to the cache, if 626 it was not already cached. The hi-entry MUST be added to the 627 cache in ascending order as indicated by the values in the hi- 628 index parameters of the hi-entries (e.g., 1.2.1 comes after 1.2 629 but before 1.2.2 or 1.3). 631 Step 2: Add Reason header field 633 The SIP entity adds one or more Reason header fields to the hi- 634 targeted-to-uri in the (newly) cached hi-entry reflecting the SIP 635 response code in the non-100 response, per the procedures of 636 Section 10.2. 638 Step 3: Add additional hi-entries 640 The SIP entity MUST also add to the cache any hi-entries received 641 in the response that are not already in the cache. This situation 642 can occur when the entity that generated the non-100 response 643 retargeted the request before generating the response. As per 644 Step 1, the hi-entries MUST be added to the cache in ascending 645 order as indicated by the values in the hi-index parameters of the 646 hi-entries 648 It is important to note that the cache does not contain hi-entries 649 for requests that have not yet received a non-100 response, so there 650 can be gaps in indices (e.g., 1.2 and 1.4 could but present but not 651 1.3). 653 9.4. Sending History-Info in Responses 655 When sending a response other than a 100, a SIP entity MUST include 656 all the cached hi-entries in the response, subject to the privacy 657 consideration in Section 10.1.2 with the following exception: If the 658 received request contained no hi-entries and there is no "histinfo" 659 option tag in the Supported header field, the SIP entity MUST NOT 660 include hi-entries in the response. 662 10. Processing the History-Info Header Field 664 The following sections describe the procedures for processing the 665 History-Info header field. These procedures are applicable to SIP 666 entities such as Proxies/Intermediaries, Redirect Servers or User 667 Agents. 669 10.1. Privacy in the History-Info Header Field 671 The privacy requirements for this document are described in 672 Appendix A.2. Section 10.1.1 describes the insertion of the Privacy 673 header field defined in [RFC3323] to indicate the privacy to be 674 applied to the History-Info header field entries. Section 10.1.2 675 describes how to apply privacy to a request or response that is being 676 forwarded, based on the presence of the Privacy header field. 678 10.1.1. Indicating Privacy 680 As with other SIP headers described in [RFC3323], the hi-targeted-to- 681 uris in the History-info header field can inadvertently reveal 682 information about the initiator of the request. Thus, the UAC needs 683 a mechanism to indicate that the hi-targeted-to-uris in the hi- 684 entries need to be privacy protected. The Privacy header field is 685 used by the UAC to indicate that privacy is to be applied to all the 686 hi-entries in the request as follows: 688 o If the UAC is including a Privacy header field with a priv-value 689 of "header" in the request, then the UAC SHOULD NOT include a 690 priv-value of "history" in the the Privacy header field in the 691 Request. 693 o If the UAC is including any priv-values other than "header" in the 694 Privacy header field, then the UAC MUST also include a priv-value 695 of "history" in the Privacy header field in the Request. 697 o If the UAC is not including any priv-values in the Privacy header 698 field in the request, then the UAC MUST add a Privacy header 699 field, with a priv-value of "history", to the request. The UAC 700 MUST NOT include a priv-value of "critical" in the Privacy header 701 field in the Request in this case. 703 In addition, the History-info header field can reveal general routing 704 and diverting information within an intermediary, which the 705 intermediary wants to privacy protect. In this case, the 706 intermediary MUST set a Privacy header field to a priv-value of 707 "history" and include the Privacy header field in the hi-targeted-to- 708 uri, for each new hi-entry added by the intermediary, as the request 709 is retargeted within the domain for which the SIP entity is 710 responsible. Note, that the hi-entries that are added to a request 711 from the cache are excluded in this case since the appropriate 712 privacy was set for those hi-entries when they were originally added 713 to a request. The intermediary MUST NOT include any other priv- 714 values in this Privacy header field. Note that the priv-value in the 715 Privacy header for the incoming request does not necessarily 716 influence whether the intermediary includes a Privacy header field in 717 the hi-entries. For example, even if the Privacy header for the 718 incoming request contained a priv-value of "none", the Proxy can 719 still set a priv-value of "history" in the Privacy header field 720 included in the hi-targeted-to-uri. 722 Finally, the terminator of the request may not want to reveal the 723 final reached target to the originator. In this case, the terminator 724 MUST include a Privacy header field with a priv-value of "history" in 725 the hi-targeted-to-uri in the last hi-entry, in the response. As 726 noted above, the terminator of the request MUST NOT use any other 727 priv-values in the Privacy header field included in the hi-entry. 729 10.1.2. Applying Privacy 731 When a request is retargeted to a URI associated with a domain for 732 which the SIP intermediary is not responsible or a response is 733 forwarded to a domain for which the SIP intermediary is not 734 responsible, a Privacy Service at the boundary of the domain applies 735 the appropriate privacy based on the value of the Privacy header 736 field in the message header or in the "headers" component of the hi- 737 targeted-to-uri in the individual hi-entries. 739 If there is a Privacy header field in the message header of a request 740 or response, with a priv-value of "header" or "history", then all the 741 hi-targeted-to-uris in the hi-entries, associated with the domain for 742 which a SIP intermediary is responsible, are anonymized by the 743 Privacy Service. The Privacy Service MUST change any hi-targeted-to- 744 uris in the hi-entries that have not been anonymized to anonymous 745 URIs containing a domain of anonymous.invalid (e.g., 746 anonymous@anonymous.invalid). If there is a Privacy header field in 747 the "headers" component of the hi-targeted-to-uri in the hi-entry, 748 then the Privacy header field value MUST be removed from the hi- 749 entry. Once all the appropriate hi-entries have been anonymized, the 750 Privacy Service MUST remove the priv-value of "history" from the 751 Privacy header field in the message header of the request or 752 response. If there are no remaining priv-values in the Privacy 753 header field, the Privacy Service MUST remove the Privacy header 754 field from the request or response per [RFC3323]. 756 If there is not a Privacy header field in the message header of the 757 request or response that is being forwarded, but there is a Privacy 758 header field with a priv-value of "history" in the "headers" 759 component in any of the hi-targeted-uris in the hi-entries associated 760 with the domain for which a SIP intermediary is responsible, then the 761 Privacy Service MUST anonymize those hi-targeted-to-uris. The 762 Privacy Service MUST populate each of the hi-targeted-to-uris with an 763 anonymous URI with a domain of anonymous.invalid (e.g., 764 anonymous@anonymous.invalid). Any other priv-values in the Privacy 765 header field in the "headers" component of the hi-targeted-to-uris in 766 the hi-entries MUST be ignored. In any case, the Privacy Service 767 MUST remove the Privacy header field from the "headers" compenent of 768 the hi-targeted-to-uris in the hi-entries prior to forwarding. 770 10.2. Reason in the History-info Header Field 772 A Reason header field is added to the "headers" component in an hi- 773 targeted-to-uri when the hi-entry is added to the cache based upon 774 the receipt of a non-100 or non-2xx SIP response, as described in 775 Section 9.3. If the Reason header field is being added due to 776 receipt of an explicit SIP response and the response contains any 777 Reason header fields (see [RFC3326]), then the SIP entity MUST 778 include the Reason header fields in the "headers" component of the 779 hi-targeted-to-uri in the last hi-entry added to the cache, unless 780 the hi-targeted-to-uri is a Tel-URI. If the SIP response does not 781 contain a Reason header field, the SIP entity MUST include a Reason 782 header field, containing the SIP Response Code, in the "headers" 783 component of the hi-targeted-to-uri in the last hi-entry added to the 784 cache, unless the hi-targeted-to-uri is a Tel-URI. 786 If a request has timed out (instead of being explicitly rejected), 787 the SIP entity MUST include a Reason header field, containing a SIP 788 error response code of 408 "Request Timeout". 790 A SIP entity MAY also include a Reason header field in the "headers" 791 component of an hi-targeted-to-uri containing the URI of a request 792 that was retargeted as a result of internal retargeting. 794 If additional Reason header field parameters are defined in the 795 future per [RFC3326], the use of these Reason header field parameters 796 for the History-Info header field MUST follow the same rules as 797 described above. 799 10.3. Indexing in the History-Info Header Field 801 In order to maintain ordering and accurately reflect the retargeting 802 of the request, the SIP entity MUST add a hi-index to each hi-entry. 803 Per the syntax in Section 5, the hi-index consists of a series of 804 digits separated by dots (e.g., 1.1.2). Each dot reflects a SIP 805 forwarding hop. The digit following each dot reflects the order in 806 which a request was retargeted at the hop. The highest digit at each 807 hop reflects the number of entities to which the request has been 808 retargeted at the specific hop (i.e., the number of branches). Thus, 809 the indexing results in a logical tree representation for the history 810 of the request. 812 The first index in a series of History-Info entries MUST be set to 1. 814 In the case that a SIP entity (intermediary or UAS) adds an hi-entry 815 on behalf of the previous hop, the hi-index MUST be set to 1. For 816 each forward hop (i.e., each new level of indexing), the hi-index 817 MUST start at 1. An increment of 1 MUST be used for advancing to a 818 new branch. 820 The basic rules for adding the hi-index are summarized as follows: 822 1. Forwarding a request without changing the target: In the case of 823 a request that is being forwarded without changing the target, 824 the hi-index reflects the increasing length of the branch. In 825 this case, the SIP entity MUST read the value from the History- 826 info header field in the received request and MUST add another 827 level of indexing by appending the dot delimiter followed by an 828 initial value of 1 for the new level. For example, if the hi- 829 index in the last History-info header field in the received 830 request is 1.1, a proxy would add a hi-entry with an hi-index of 831 1.1.1 and forward the request. 833 2. Retargeting within a processing entity - 1st instance: For the 834 first instance of retargeting within a processing entity, the SIP 835 entity MUST calculate the hi-index as prescribed for basic 836 forwarding. 838 3. Retargeting within a processing entity - subsequent instance: For 839 each subsequent retargeting of a request by the same SIP entity, 840 the SIP entity MUST calculate and add the hi-index for each new 841 branch by incrementing the rightmost value from the hi-index in 842 the last hi-entry. Per the example above, the hi-index in the 843 next request forwarded by this same SIP entity would be 1.1.2. 845 4. Retargeting based upon a Response: In the case of retargeting due 846 to a specific response (e.g., 302), the SIP entity MUST calculate 847 the hi-index calculated per rule 3. That is, the rightmost value 848 of the hi-index MUST be incremented (i.e., a new branch is 849 created). For example, if the hi-index in the History-Info 850 header field of the sent request is 1.2 and the response to the 851 request is a 302, then the hi-index in the History-Info header 852 field for the new hi-targeted- to-URI would be 1.3. 854 5. Forking requests: If the request forwarding is done in multiple 855 forks (sequentially or in parallel), the SIP entity MUST set the 856 hi-index for each hi-entry for each forked request per the rules 857 above, with each new request having a unique index. Each index 858 MUST be sequentially assigned. For example, if the index in the 859 last History-Info header field in the received request is 1.1, 860 this processing entity would initialize its index to 1.1.1 for 861 the first fork, 1.1.2 for the second, and so forth (see Figure 1 862 for an example). Note, that in the case of parallel forking, 863 only the hi-entry corresponding to the fork is included in the 864 request. 866 6. Missing entity: If the request clearly has a gap in the hi-entry 867 (e.g. by evaluating via header to the existing request history to 868 see if it traversed a domain which doesn't exist in History-Info 869 header field.), the entity adding an hi-entry MUST add an index a 870 digit of "0" to the current index prior to adding appropriate 871 index for the action to be taken. If the index of the last hi- 872 entry in the request received was 1.1.2 and there was a missing 873 hi-entry and the request was being forwarded to the next hop, the 874 resulting index will be 1.1.2.0.1. 876 10.4. Mechanism for Target Determination in the History-Info Header 877 Field 879 This specification defines two header field parameters, "rc", "mp" 880 and "np", indicating two mechanisms by which a new target for a 881 request is determined. Both parameters contain an index whose value 882 is the hi-index of the hi-entry with an hi-targeted-to-uri that 883 represents the Request-URI that was retargeted. 885 The SIP entity MUST determine the specific parameter field to be 886 included in the hi-target-param, in the History-info header field, as 887 the targets are added to the target set per the procedures in section 888 16.5 of [RFC3261] or per section 8.1.3.4 [RFC3261] in the case of 889 retargeting to a contact URI received in a 3xx response. In the 890 latter case, the specific header field parameter in the Contact 891 header field becomes the header field parameter that is used in the 892 hi-entry when the request is retargeted. If the Contact header field 893 does not contain an "rc", "mp" or "np" header field parameter, then 894 the SIP entity MUST NOT include an "rc", "mp" or "np" header field 895 parameter in the hi-target-param in the hi-entry when the request is 896 retargeted to a contact URI received in a 3xx response.. 898 The SIP entity (intermediary or redirect server) determines the 899 specific header field parameter ("rc", "mp" or "np") to be used based 900 on the following criteria: 902 o "rc": The Request-URI has changed while retaining the target user 903 associated with the original Request-URI prior to retargeting. 905 o "mp": The target was determined based on a mapping to a user other 906 than the target user associated with the Request-URI being 907 retargeted. 909 o "np": The target hasn't changed and associated Request-URI 910 remained the same. 912 Note that there are two scenarios by which the "mp" header field 913 parameter can be derived. 915 o The mapping was done by the receiving entity on its own authority, 916 in which case the mp-value is the parent index of the hi-entry's 917 index. 919 o The mapping was done due to receiving a 3xx response, in which 920 case the mp-value is an earlier sibling or descendant of an 921 earlier sibling of the hi-entry's index, that of the downstream 922 request which received the 3xx response. 924 11. Application Considerations 926 History-Info provides a very flexible building block that can be used 927 by intermediaries and UAs for a variety of services. Prior to any 928 application usage of the History-Info header field parameters, the 929 SIP entity that processes the hi-entries MUST evaluate the hi- 930 entries. The SIP entity MUST determine if there are gaps in the 931 indices. Gaps are possible if the request is forwarded through 932 intermediaries that do not support the History-info header field and 933 are reflected by the existence of multiple hi-entries with an digit 934 of "0" e.g. "1.1.0.1". Gaps are also possible in the case of 935 parallel forking if there is an outstanding request at the time the 936 SIP entity sends a response as described in Section 9.4, in which 937 case the gap will not be visible as the branch responsible for the 938 gap wasn't on the path of the request received. Thus, if gaps are 939 detected, the SIP entity MUST NOT treat this as an error, but SHOULD 940 indicate to any applications that there are gaps. The interpretation 941 of the information in the History-info header field depends upon the 942 specific application; an application might need to provide special 943 handling in some cases where there are gaps. 945 The following describes some categories of information that 946 applications can use: 948 1. Complete history information - e.g., for debug or other 949 operational and management aspects, optimization of determining 950 targets to avoid retargeting to the same URI, etc. This 951 information is relevant to proxies, UACs and UASs. 953 2. Hi-entry with the index that matches the value of the "rc" header 954 field parameter in the last hi-entry with a "rc" header field 955 parameter in the Request received by a UAS - i.e., the last AOR 956 that was retargeted to a contact based on an AOR-to-contact 957 binding. 959 3. Hi-entry with the index that matches the value of the "mp" header 960 field parameter in the last hi-entry with a "mp" header field 961 parameter in the hi-target-param in the Request received by a UAS 962 - i.e., the last Request URI that was mapped to reach the 963 destination. 965 4. Hi-entry with the index that matches the value of the "rc" header 966 field parameter in the first hi-entry with a "rc" header field 967 parameter in the Request received by a UAS. Note, this would be 968 the original AoR if all the entities involved support the 969 History-info header field and there is absence of an "mp" header 970 field parameter prior to the "rc" header field parameter in the 971 hi-target-param in the History-info header field. However, there 972 is no guarantee that all entities will support History-Info, thus 973 the hi-entry that matches the value of the "rc" header field 974 parameter of the first hi-entry with an "rc" header field 975 parameter in the hi-target-param within the domain associated 976 with the target URI at the destination is more likely to be 977 useful. 979 5. Hi-entry with the index that matches the value of "mp" header 980 field parameter in the first hi-entry with an "mp" header field 981 parameter in the Request received by a UAS. Note, this would be 982 the original mapped URI if all entities supported the History- 983 info header field. However, there is no guarantee that all 984 entities will support History-Info, thus the hi-entry that 985 matches the value of the "mp" header field parameter of the first 986 hi-entry with an "mp" header field parameter within the domain 987 associated with the target URI at the destination is more likely 988 to be useful. 990 In many cases, applications are most interested in the information 991 within a particular domain(s), thus only a subset of the information 992 is required. 994 Some applications may use multiple types of information. For 995 example, an Automatic Call Distribution (ACD)/Call center application 996 that utilizes the hi-entry which index matches the value of the "mp" 997 header field parameter of the first hi-entry with an "mp" header 998 field parameter, may also display other agents, reflected by other 999 hi-entries prior to entries with hi-target value of "rc" header field 1000 parameter, to whom the call was targeted prior to its arrival at the 1001 current agent. This could allow the agent the ability to decide how 1002 they might forward or reroute the call if necessary (avoiding agents 1003 that were not previously available for whatever reason, etc.). 1005 Since support for History-info header field is optional, a service 1006 MUST define default behavior for requests and responses not 1007 containing History-Info header fields. For example, an entity may 1008 receive an incomplete set of hi-entries or hi-entries which are not 1009 tagged appropriately with an hi-target-param. This may not impact 1010 some applications (e.g., debug), however, it could require some 1011 applications to make some default assumptions in this case. For 1012 example, in an ACD scenario, the application could select the oldest 1013 hi-entry with the domain associated with the ACD system and display 1014 that as the original called party. Depending upon how and where the 1015 request may have been retargeted, the complete list of agents to whom 1016 the call was targeted may not be available. 1018 12. Application Specific Usage 1020 12.1. PBX Voicemail 1022 A voicemail system typically requires the original called party 1023 information to determine the appropriate mailbox so an appropriate 1024 greeting can be provided and the appropriate party notified of the 1025 message. 1027 The original target is determined by finding the first hi-entry 1028 tagged with "rc" and using the hi-entry referenced by the index of 1029 "rc" header field parameter as the target for determining the 1030 appropriate mailbox. This hi-entry is used to populate the "target" 1031 URI parameter as defined in [RFC5246] The VMS can look at the last 1032 hi-entry and find the target of the mailbox by looking at the URI 1033 entry in the "target" URI parameter in the hi-entry. For example 1034 call flow please refer to the Appendix B.1. 1036 This example usage does not work properly in the presence of 1037 forwarding that takes place before the call reaches the company in 1038 that case not the first hi-entry with an rc value, but the first hi- 1039 entry with an rc value following an mp entry needs to be picked. 1041 12.2. Consumer Voicemail 1043 The voicemail system in these environment typically requires the last 1044 called party information to determine the appropriate mailbox so an 1045 appropriate greeting can be provided and the appropriate party 1046 notified of the message. 1048 The last target is determined by finding the hi-entry referenced by 1049 the index of last hi-entry tagged with "rc" for determining the 1050 appropriate mailbox. This hi-entry is used to populate the "target" 1051 URI parameter as defined in [RFC5246]. The VMS can look at the last 1052 hi-entry and find the target of the mailbox by looking for the 1053 "target" URI parameter in the hi-entry. For example call flow please 1054 refer to the Appendix B.2. 1056 13. Security Considerations 1058 The security requirements for this specification are specified in 1059 Appendix A.1. 1061 This document defines a header field for SIP. The use of the 1062 Transport Layer Security (TLS) protocol [RFC5246] as a mechanism to 1063 ensure the overall confidentiality of the History-Info header fields 1064 (SEC-req-4) is strongly RECOMMENDED. This results in History-Info 1065 having at least the same level of security as other headers in SIP 1066 that are inserted by intermediaries. With TLS, History-Info header 1067 fields are no less, nor no more, secure than other SIP header fields, 1068 which generally have even more impact on the subsequent processing of 1069 SIP sessions than the History-info header field. 1071 Note that while using the SIPS scheme (as per [RFC5630]) protects 1072 History-Info from tampering by arbitrary parties outside the SIP 1073 message path, all the intermediaries on the path are trusted 1074 implicitly. A malicious intermediary could arbitrarily delete, 1075 rewrite, or modify History-Info. This specification does not attempt 1076 to prevent or detect attacks by malicious intermediaries. 1078 In terms of ensuring the privacy of hi-entries, the same security 1079 considerations as those described in [RFC3323] apply. Namely if the 1080 entity requesting privacy wants to ensure privacy is applied to the 1081 hi-entries, a Privacy Service that supports both [RFC3323] and this 1082 specification is REQUIRED in the entity's domain, so that the privacy 1083 can be applied, as described in Section 10.1.2, when a request or 1084 response leaves the domain. 1086 14. IANA Considerations 1088 This document requires several IANA registrations detailed in the 1089 following sections. 1091 This document obsoletes [RFC4244] but uses the same SIP header field 1092 name and option tag. The IANA registry needs to update the 1093 references to [RFC4244] with [RFC XXXX]. 1095 14.1. Registration of New SIP History-Info Header Field 1097 This document defines a SIP header field name: History-Info and an 1098 option tag: histinfo. The following changes have been made to 1099 http:///www.iana.org/assignments/sip-parameters The following row has 1100 been added to the header field section:. 1102 The following row has been added to the header field section: 1104 Header Name Compact Form Reference 1105 ----------- ------------ --------- 1106 History-Info none [RFC XXXX] 1108 The following has been added to the Options Tags section: 1110 Name Description Reference 1111 ---- ----------- --------- 1112 histinfo When used with the Supported header field, [RFC XXXX] 1113 this option tag indicates the UAC 1114 supports the History Information to be 1115 captured for requests and returned in 1116 subsequent responses. This tag is not 1117 used in a Proxy-Require or Require 1118 header field since support of 1119 History-Info is optional. 1121 Note to RFC Editor: Please replace RFC XXXX with the RFC number of 1122 this specification. 1124 14.2. Registration of "history" for SIP Privacy Header Field 1126 This document defines a priv-value for the SIP Privacy header field: 1127 history The following changes have been made to 1128 http://www.iana.org/assignments/sip-priv-values The following has 1129 been added to the registration for the SIP Privacy header field: 1131 Name Description Registrant Reference 1132 ---- ----------- ---------- --------- 1133 history Privacy requested for Mary Barnes [RFC XXXX] 1134 History-info header mary.barnes@polycom.com 1135 fields(s) 1137 Note to RFC Editor: Please replace RFC XXXX with the RFC number of 1138 this specification. 1140 14.3. Registration of Header Field Parameters 1142 This specification defines the following new SIP header field 1143 parameters in the SIP Header Field parameter sub-registry in the SIP 1144 Parameter Registry, http:/www.iana.org/assignments/sip-parameters. 1146 Header Field Parameter Name Predefined Reference 1147 Values 1148 _____________________________________________________________________ 1149 History-Info mp No [RFC xxxx] 1150 History-Info rc No [RFC xxxx] 1151 History-Info np No [RFC xxxx] 1152 Contact mp No [RFC xxxx] 1153 Contact rc No [RFC xxxx] 1154 Contact np No [RFC xxxx] 1156 Note to RFC Editor: Please replace RFC XXXX with the RFC number of 1157 this specification. 1159 15. Acknowledgements 1161 Jonathan Rosenberg et al produced the document that provided 1162 additional use cases precipitating the requirement for the new header 1163 parameters to capture the method by which a Request URI is 1164 determined. The authors would like to acknowledge the constructive 1165 feedback provided by Ian Elz, Paul Kyzivat, John Elwell, Hadriel 1166 Kaplan and Dale Worley. John Elwell provided excellent suggestions 1167 in terms of document structure. 1169 Mark Watson, Cullen Jennings and Jon Peterson provided significant 1170 input into the initial work that resulted in the development of of 1171 [RFC4244]. The editor would like to acknowledge the constructive 1172 feedback provided by Robert Sparks, Paul Kyzivat, Scott Orton, John 1173 Elwell, Nir Chen, Palash Jain, Brian Stucker, Norma Ng, Anthony 1174 Brown, Jayshree Bharatia, Jonathan Rosenberg, Eric Burger, Martin 1175 Dolly, Roland Jesske, Takuya Sawada, Sebastien Prouvost, and 1176 Sebastien Garcin in the development of [RFC4244]. 1178 The editor would like to acknowledge the significant input from Rohan 1179 Mahy on some of the normative aspects of the ABNF for [RFC4244], 1180 particularly around the need for and format of the index and around 1181 the security aspects. 1183 16. Changes from RFC 4244 1185 This RFC replaces [RFC4244]. 1187 Deployment experience with [RFC4244] over the years has shown a 1188 number of issues, warranting an update: 1190 o In order to make [RFC4244] work in "real life", one needs to make 1191 "assumptions" on how History-Info is used. For example, many 1192 implementations filter out many entries, and only leave specific 1193 entries corresponding, for example, to first and last redirection. 1194 Since vendors uses different rules, it causes significant 1195 interoperability isssues. 1197 o [RFC4244] is overly permissive and evasive about recording 1198 entries, causing interoperability issues. 1200 o The examples in the call flows had errors, and confusing because 1201 they often assume "loose routing". 1203 o [RFC4244] has lots of repetitive and unclear text due to the 1204 combination of requirements with solution. 1206 o [RFC4244] gratuitously mandates the use of TLS on every hop. No 1207 existing implementation enforces this rule, and instead, the use 1208 of TLS or not is a general SIP issue, not an [RFC4244] issue per 1209 se. 1211 o [RFC4244] does not include clear procedures on how to deliver 1212 current target URI information to the UAS when the Request-URI is 1213 replaced with a contact. 1215 o [RFC4244] does not allow for marking History-Info entries for easy 1216 processing by User Agents. 1218 The following summarizes the functional changes between this 1219 specification and [RFC4244]: 1221 1. Added header field parameters to capture the specific method by 1222 which a target is determined to facilitate processing by users of 1223 the History-info header field entries. A specific header field 1224 parameter is captured for each of the target URIs as the target 1225 set is determined (per section 16.5 of [RFC3261]). The header 1226 field parameter is used in both the History-Info and the Contact 1227 header fields. 1229 2. Rather than recommending that entries be removed in the case of 1230 certain values of the Privacy header field, the entries are 1231 anonymized. 1233 3. Updated the security section to be equivalent to the security 1234 recommendations for other SIP header fields inserted by 1235 intermediaries. 1237 The first 2 changes are intended to facilitate application usage of 1238 the History-info header field and eliminate the need to make 1239 assumptions based upon the order of the entries and ensure that the 1240 most complete set of information is available to the applications. 1242 In addition, editorial changes were done to both condense and clarify 1243 the text, moving the requirements to an appendix and removing the 1244 inline references to the requirements. The examples were simplified 1245 and updated to reflect the protocol changes. Several of the call 1246 flows in the appendix were removed and put into a separate document 1247 that includes additional use cases that require the new header field 1248 parameters. 1250 16.1. Backwards compatibility 1252 This specification is backwards compatible since [RFC4244] allows for 1253 the addition of new optional parameters. This specification adds an 1254 optional SIP header field parameter to the History-Info and Contact 1255 header fields. Entities that have not implemented this specification 1256 will ignore these parameters, however, per [RFC4244] an entity will 1257 not remove this parameter from an hi-entry. 1259 As for the behavior of the entity followings have changed since the 1260 [RFC4244]. 1262 UAC behavior 1264 1. Inclusion of option tag by UAC has changed from SHOULD to MUST. 1266 2. Inclusion of hi-target-entry along with hi-index has changed rom 1267 MAY/RECOMMEND to MUST/MUST. 1269 3. Behavior surrounding the adddition of hi-target-entry based on 1270 3xx response has changed from MAY/SHOULD to MUST. 1272 None of the behavior changes would cause any backward compatibility 1273 issues. 1275 UAS behavior 1276 1. Inclusion of hi-entry in response has changed from SHOULD to 1277 MUST. 1279 As the entity receiving response with hi-entry expected it with 1280 SHOULD, this change will not cause any backward compatibility issues. 1282 Proxy/Redirect Server behavior 1284 1. Inclusion of H-I as forwarding the request has changed from 1285 SHOULD to MUST. 1287 2. Association of Reason with time-out/internal reason has changed 1288 from MAY to MUST. 1290 3. Inclusion of hi-index has changed from RECOMMENDED to MUST. 1292 4. Inclusion of hi-entries in response has changed from SHOULD to 1293 MUST. 1295 None of the behavior changes will cause any backward compatibility 1296 issues as entity interacting with the updated code, expects the 1297 values set by the revised behavior anyway. 1299 17. Changes since last Version 1301 NOTE TO THE RFC-Editor: Please remove this section prior to 1302 publication as an RFC. 1304 Changes from 04 to 05: 1306 1. Lots of editorial corrections/clarifications per John Elwell's 1307 comment. 1309 2. Updated Reason header section 10.2 to be consistent (i.e., 1310 removed references to retargeting) with section 9.3 (Receiving a 1311 response) where the hi-entries and reason header are added to the 1312 cache. 1314 3. Updated section 9.3 (receiving responses) to also include 1315 timeouts and updated to reflect that we don't add the Reason 1316 header in the case of 2xx responses. 1318 4. Added text in Security considerations with regards to needing a 1319 Privacy Service per RFC 3323 to ensure that the privacy is 1320 applied. 1322 Changes from 03 to 04: 1324 1. Reorganization of sections per John Elwell's comments - i.e., a 1325 common section for building HI referenced by the UA, Intermediary 1326 and Redirect server sections. 1328 2. Removing the use of "escape" when describing the handling of the 1329 Privacy and Reason header fields. 1331 3. Clarification of TEL URIs in terms of not having a Privacy or 1332 Reason header field in the hi-targeted-to-uri. 1334 Changes from 02 to 03: 1336 1. Lots of editorial: 1338 2. 1340 A. Reorganized sections similar to the RFC 4244 order - i.e., 1341 introduce header field parameters and syntax first, then 1342 describe how the functional entities use the header field. 1343 This removes redundant (and often inconsistent) text 1344 describing the parameters. 1346 B. Expanded use of "header" to "header field" 1348 C. More precision in terms of "escaping" of the Privacy and 1349 Reason headers in the hi-targeted-to-uri (versus 1350 "adding"/"setting"/etc. them to the hi-entry). 1352 D. Consistent use of parameter names (i.e., hi-entry versus 1353 entry, hi-target versus target, etc.) 1355 E. Moved item 6 in the Index section to the section on Response 1356 handling 1358 F. Removed last remaining vestiges of inline references to 1359 requirements. 1361 3. Clarifications of functionality/applicability including: 1363 4. 1365 A. which messages may contain History-Info 1367 B. removing security text with regards to being able to figure 1368 out if there are missing entries when using TLS (issue #44) 1370 C. More complete information on the new header field parameters 1371 as they relate to the hi-target parameter. 1373 D. Changed wording from passive to active for normative 1374 statements in many cases and removed superfluous normative 1375 language. 1377 5. Rewrite of the Privacy section to address issues and splitting 1378 into the setting of the Privacy header fields and the processing/ 1379 application of the privacy header field priv-values. 1381 6. Rewrite of the Reason header field section - simplifying the text 1382 and adding back the RFC 4244 text with regards to the use of the 1383 Reason header field in cases of internal retargeting. 1385 Changes from 01 to 02: 1387 1. Editorial nits/clarifications. [Issues: 1,6,17,18,21- 1388 23,25,26,30-33,35-37,39,40] 1390 2. Removing extraneous 4244 text - e.g., errors in flows, 1391 "stronger" security, "session" privacy. [Issues: 3,5,7,11 ] 1393 3. Updated definition of "retarget" to be all encompassing - i.e., 1394 also includes internal changes of target URI. Clarified text 1395 for "internal retarging" in proxy section. [Issues: 2,8,9] 1397 4. Clarified that the processing for Proxies is equally applicable 1398 to other SIP intermediaries. [Issue: 9]. 1400 5. Changed more SHOULDs to MUSTs. [Issue: 10] 1402 6. Fixes to Application considerations section. [Issues: 12-15] 1404 7. Changed language in the procedure for Indexing to normative 1405 language. 1407 8. Clarifications for UAC processing: 1409 * MUST add hi-entry. [Issue: 28] 1411 * Clarify applicability to B2BUA. [Issue: 29] 1413 * Fixed text for indexing for UAC in case of 3xx. 1415 9. Changed "hit" URI parameter to header field parameters: [Issues: 1416 4,40] 1418 * Added index to all target header parameters. [Issues: 41] 1419 * Updated all the relevant sections documenting setting and use 1420 of new header parameters. [Issue: 40] 1422 10. Updated/clarified privacy handling. [Issue: 16] 1424 11. Updated Redirect Server section to allow adding History-info 1425 header fields. [Issue: 24 ] 1427 12. Added text around restrictions for Tel-URIs - i.e., no privacy 1428 or reason. [Issues: 4, 12] 1430 13. Updated text for forking - what goes in response. [Issues: 1431 19,20] 1433 Changes from 00 to 01: 1435 1. Moved examples (except first) in appendix to a new 1436 (informational) document. 1438 2. Updated UAS and UAC sections to clarify and expand on the 1439 handling of the History-info header field. 1441 3. Updated the Application considerations section: 1443 o Included more detail with regards to how applications can make use 1444 of the information, in particular based on the new tags. 1446 o Removed privacy consideration (2nd bullet) since privacy is now 1447 accomplished by anonymizing rather than removal of entries. 1449 Changes from (individual) barnes-sipcore-4244bis-03 to (WG) ietf- 1450 sipcore-4244bis-00: 1452 1. Added a new SIP/SIPS URI parameter to tag the URIs as they are 1453 added to the target list and those returned in the contact header 1454 in a 3xx response. 1456 2. Updated description of "target" parameter to use the new URI 1457 parameter value in setting the value for the parameter. 1459 3. Clarified privacy. 1461 4. Changed handling at redirect server to include the use of the new 1462 URI parameter and to remove the functionality of adding the 1463 History-Info entries (basically reverting to core 4244 1464 processing). 1466 5. Additional text to clarify that a service such as voicemail can 1467 be done in multiple ways. 1469 6. Editorial changes including removal of some vestiges of tagging 1470 all entries (including the "aor" tag). 1472 Changes from barnes-sipcore-4244bis-02 to 03: 1474 1. Fixed problem with indices in example in voicemail example. 1476 2. Removed oc and rt from the Hi-target parameter. 1478 3. Removed aor tag 1480 4. Added index parameter to "mp" 1482 5. Added use-cases and call-flows from target-uri into appendix. 1484 Changes from barnes-sipcore-4244bis-01 to 02: 1486 1. Added hi-aor parameter that gets marked on the "incoming" hi- 1487 entry. 1489 2. Hi-target parameter defined to be either rc, oc, mp, rt, and now 1490 gets included when adding an hi-entry. 1492 3. Added section on backwards compatibility, as well as added the 1493 recognition and handling of requests that do not support this 1494 specification in the appropriate sections. 1496 4. Updated redirect server/3xx handling to support the new 1497 parameters - i.e., the redirecting entity must add the new hi- 1498 entry since the proxy does not have access to the information as 1499 to how the Contact was determined. 1501 5. Added section on normative differences between this specification 1502 and RFC 4244. 1504 6. Restructuring of document to be more in line with current IETF 1505 practices. 1507 7. Moved Requirements section into an Appendix. 1509 8. Fixed ABNF to remove unintended ordering requirement on hi-index 1510 that was introduced in attempting to illustrate it was a 1511 mandatory parameter. 1513 Changes from barnes-sipcore-4244bis-00 to 01 : 1515 1. Clarified "retarget" definition. 1517 2. Removed privacy discussion from optionality section - just refer 1518 to privacy section. 1520 3. Removed extraneous text from target-parameter (leftover from sip- 1521 4244bis). Changed the terminology from the "reason" to the 1522 "mechanism" to avoid ambiguity with parameter. 1524 4. Various changes to clarify some of the text around privacy. 1526 5. Reverted proxy response handling text to previous form - just 1527 changing the privacy aspects to anonymize, rather than remove. 1529 6. Other editorial changes to condense and simplify. 1531 7. Moved Privacy examples to Appendix. 1533 8. Added forking to Basic call example. 1535 Changes from barnes-sipcore-4244bis-00 to 01 : 1537 1. Clarified "retarget" definition. 1539 2. Removed privacy discussion from optionality section - just refer 1540 to privacy section. 1542 3. Removed extraneous text from target-parameter (leftover from sip- 1543 4244bis). Changed the terminology from the "reason" to the 1544 "mechanism" to avoid ambiguity with parameter. 1546 4. Various changes to clarify some of the text around privacy. 1548 5. Reverted proxy response handling text to previous form - just 1549 changing the privacy aspects to anonymize, rather than remove. 1551 6. Other editorial changes to condense and simplify. 1553 7. Moved Privacy examples to Appendix. 1555 8. Added forking to Basic call example. 1557 Changes from barnes-sip-4244bis-00 to barnes-sipcore-4244bis-00: 1559 1. Added tags for each type of retargeting including proxy hops, 1560 etc. - i.e., a tag is defined for each specific mechanism by 1561 which the new Request-URI is determined. Note, this is 1562 extremely helpful in terms of backwards compatibility. 1564 2. Fixed all the examples. Made sure loose routing was used in all 1565 of them. 1567 3. Removed example where a proxy using strict routing is using 1568 History-Info for avoiding trying same route twice. 1570 4. Remove redundant Redirect Server example. 1572 5. Index is now mandated to start at "1" instead of recommended. 1574 6. Updated 3xx behavior as the entity sending the 3XX response MUST 1575 add the hi-target attribute to the previous hi-entry to ensure 1576 that it is appropriately tagged (i.e., it's the only one that 1577 knows how the contact in the 3xx was determined.) 1579 7. Removed lots of ambiguity by making many "MAYs" into "SHOULDs" 1580 and some "SHOULDs" into "MUSTs". 1582 8. Privacy is now recommended to be done by anonymizing entries as 1583 per RFC 3323 instead of by removing or omitting hi-entry(s). 1585 9. Requirement for TLS is now same level as per RFC 3261. 1587 10. Clarified behavior for "Privacy" (i.e., that Privacy is for Hi- 1588 entries, not headers). 1590 11. Removed "OPTIONALITY" as specific requirements, since it's 1591 rather superflous. 1593 12. Other editorial changes to remove redundant text/sections. 1595 Changes from RFC4244 to barnes-sip-4244bis-00: 1597 1. Clarified that HI captures both retargeting as well as cases of 1598 just forwarding a request. 1600 2. Added descriptions of the usage of the terms "retarget", 1601 "forward" and "redirect" to the terminology section. 1603 3. Added additional examples for the functionality provided by HI 1604 for core SIP. 1606 4. Added hi-target parameter values to HI header to ABNF and 1607 protocol description, as well as defining proxy, UAC and UAS 1608 behavior for the parameter. 1610 5. Simplified example call flow in section 4.5. Moved previous call 1611 flow to appendix. 1613 6. Fixed ABNF per RFC4244 errata "dot" -> "." and added new 1614 parameter. 1616 18. References 1618 18.1. Normative References 1620 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1621 A., Peterson, J., Sparks, R., Handley, M., and E. 1622 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1623 June 2002. 1625 [RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason 1626 Header Field for the Session Initiation Protocol (SIP)", 1627 RFC 3326, December 2002. 1629 [RFC3323] Peterson, J., "A Privacy Mechanism for the Session 1630 Initiation Protocol (SIP)", RFC 3323, November 2002. 1632 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1633 Requirement Levels", BCP 14, RFC 2119, March 1997. 1635 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1636 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1638 [RFC4244] Barnes, M., "An Extension to the Session Initiation 1639 Protocol (SIP) for Request History Information", RFC 4244, 1640 November 2005. 1642 18.2. Informative References 1644 [RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User 1645 Agent URIs (GRUUs) in the Session Initiation Protocol 1646 (SIP)", RFC 5627, October 2009. 1648 [RFC5630] Audet, F., "The Use of the SIPS URI Scheme in the Session 1649 Initiation Protocol (SIP)", RFC 5630, October 2009. 1651 [RFC3087] Campbell, B. and R. Sparks, "Control of Service Context 1652 using SIP Request-URI", RFC 3087, April 2001. 1654 [RFC4240] Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network 1655 Media Services with SIP", RFC 4240, December 2005. 1657 [RFC3969] Camarillo, G., "The Internet Assigned Number Authority 1658 (IANA) Uniform Resource Identifier (URI) Parameter 1659 Registry for the Session Initiation Protocol (SIP)", 1660 BCP 99, RFC 3969, December 2004. 1662 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", 1663 RFC 3966, December 2004. 1665 [RFC4458] Jennings, C., Audet, F., and J. Elwell, "Session 1666 Initiation Protocol (SIP) URIs for Applications such as 1667 Voicemail and Interactive Voice Response (IVR)", RFC 4458, 1668 April 2006. 1670 Appendix A. Request History Requirements 1672 The following list constitutes a set of requirements for a "Request 1673 History" capability. 1675 1. CAPABILITY-req: The "Request History" capability provides a 1676 capability to inform proxies and UAs involved in processing a 1677 request about the history/progress of that request. Although 1678 this is inherently provided when the retarget is in response to a 1679 SIP redirect, it is deemed useful for non-redirect retargeting 1680 scenarios, as well. 1682 2. GENERATION-req: "Request History" information is generated when 1683 the request is retargeted. 1685 A. In some scenarios, it might be possible for more than one 1686 instance of retargeting to occur within the same proxy. A 1687 proxy MUST also generate Request History information for the 1688 'internal retargeting'. 1690 B. An entity (UA or proxy) retargeting in response to a redirect 1691 or REFER MUST include any Request History information from 1692 the redirect/REFER in the new request. 1694 3. ISSUER-req: "Request History" information can be generated by a 1695 UA or proxy. It can be passed in both requests and responses. 1697 4. CONTENT-req: The "Request History" information for each 1698 occurrence of retargeting shall include the following: 1700 A. The new URI or address to which the request is in the process 1701 of being retargeted, 1703 B. The URI or address from which the request was retargeted, and 1704 wether the retarget URI was an AOR 1706 C. The mechanism by which the new URI or address was determined, 1708 D. The reason for the Request-URI or address modification, 1710 E. Chronological ordering of the Request History information. 1712 5. REQUEST-VALIDITY-req: Request History is applicable to requests 1713 not sent within an early or established dialog (e.g., INVITE, 1714 REGISTER, MESSAGE, and OPTIONS). 1716 6. BACKWARDS-req: Request History information may be passed from the 1717 generating entity backwards towards the UAC. This is needed to 1718 enable services that inform the calling party about the dialog 1719 establishment attempts. 1721 7. FORWARDS-req: Request History information may also be included by 1722 the generating entity in the request, if it is forwarded onwards. 1724 A.1. Security Requirements 1726 The Request History information is being inserted by a network 1727 element retargeting a Request, resulting in a slightly different 1728 problem than the basic SIP header problem, thus requiring specific 1729 consideration. It is recognized that these security requirements can 1730 be generalized to a basic requirement of being able to secure 1731 information that is inserted by proxies. 1733 The potential security problems include the following: 1735 1. A rogue application could insert a bogus Request History-Info 1736 entry either by adding an additional hi-entry as a result of 1737 retargeting or entering invalid information. 1739 2. A rogue application could re-arrange the Request History 1740 information to change the nature of the end application or to 1741 mislead the receiver of the information. 1743 3. A rogue application could delete some or all of the Request 1744 History information. 1746 Thus, a security solution for "Request History" must meet the 1747 following requirements: 1749 1. SEC-req-1: The entity receiving the Request History must be able 1750 to determine whether any of the previously added Request History 1751 content has been altered. 1753 2. SEC-req-2: The ordering of the Request History information must 1754 be preserved at each instance of retargeting. 1756 3. SEC-req-3: The entity receiving the information conveyed by the 1757 Request History must be able to authenticate the entity providing 1758 the request. 1760 4. SEC-req-4: To ensure the confidentiality of the Request History 1761 information, only entities that process the request SHOULD have 1762 visibility to the information. 1764 It should be noted that these security requirements apply to any 1765 entity making use of the Request History information. 1767 A.2. Privacy Requirements 1769 Since the Request-URI that is captured could inadvertently reveal 1770 information about the originator, there are general privacy 1771 requirements that MUST be met: 1773 1. PRIV-req-1: The entity retargeting the Request must ensure that 1774 it maintains the network-provided privacy (as described in 1775 [RFC3323]) associated with the Request as it is retargeted. 1777 2. PRIV-req-2: The entity receiving the Request History must 1778 maintain the privacy associated with the information. In 1779 addition, local policy at a proxy may identify privacy 1780 requirements associated with the Request-URI being captured in 1781 the Request History information. 1783 3. PRIV-req-3: Request History information subject to privacy shall 1784 not be included in ougoing messages unless it is protected as 1785 described in [RFC3323]. 1787 Appendix B. Example call flows 1789 The scenarios in this section provide sample use cases for the 1790 History-info header field for informational purposes only. They are 1791 not intended to be normative. A basic forking use case is included, 1792 along with two use cases illustrating the use of the privacy. 1794 B.1. PBX Voicemail call floww 1796 In this example, Alice calls Bob, whose SIP client is forwarded to 1797 Carol. Carol does not answer the call, thus it is forwarded to a VM 1798 (voicemail) server (VMS). In order to determine the appropriate 1799 mailbox to use for this call, the VMS needs the original target for 1800 the request. The original target is determined by finding the first 1801 hi-entry tagged with "rc" and using the hi-entry referenced by the 1802 index of "rc" header field parameter as the target for determining 1803 the appropriate mailbox. This hi-entry is used to populate the 1804 "target" URI parameter as defined in [RFC4458]. The reason 1805 associated with the first hi-entry tagged with "rc" (i.e., 302) could 1806 be used to provide a customized voicemail greeting and is used to 1807 populate the "cause" URI parameter as defined in [RFC4458]. Note 1808 that some VMSs may also (or instead) use the information available in 1809 the History-Info headers for custom handling of the VM in terms of 1810 how and why the call arrived at the VMS. 1812 Furthermore it is the proxy forwarding the call to VMS that 1813 determines the target of the voicemail, it is the proxy that sets the 1814 target of voicemail which is also the entity that utilizes RFC4244bis 1815 to find the target which is usually based on local policy installed 1816 by the user or an administrator. 1818 Alice example.com Bob Carol VM 1820 | INVITE F1 | | | | 1821 |------------->| | | | 1822 | | INVITE F2 | | | 1823 | |------------->| | | 1824 | | | | | 1825 | 100 Trying | | | | 1826 |<-------------| 302 Moved Temporarily F3 | | 1827 | |<-------------| | | 1828 | | | | | 1829 | | INVITE F4 | | | 1830 | |--------------------------->| | 1831 | | | | | 1832 | | 180 Ringing F5 | | 1833 | |<---------------------------| | 1834 | | | | | 1835 | 180 Ringing | | | | 1836 |<-------------| | | | 1837 | | | | | 1838 | | (timeout) | | 1839 | | | | | 1840 | | INVITE F6 | | | 1841 | |-------------------------------------->| 1842 | | | | | 1843 | | 200 OK F7 | 1844 | |<--------------------------------------| 1845 | 200 OK | | | | 1846 |<-------------| | | | 1847 | | | | | 1848 | ACK | | | | 1849 |------------->| ACK | 1850 | |-------------------------------------->| 1852 F1 INVITE Alice -> Example.com 1854 INVITE sip:bob@example.com 1855 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=232sxxeserg 1856 From: Alice ;tag=kkaz- 1857 To: Bob 1858 Supported: histinfo 1859 Call-Id: 12345600@example.com 1860 CSeq: 1 INVITE 1861 Contact: Alice 1862 Content-Length: 1864 [SDP Not Shown] 1866 F2 INVITE Example.com -> Bob 1868 INVITE sip:bob@192.0.2.5 SIP/2.0 1869 Via: SIP/2.0/TCP proxy.example.com:5060;branch=as2334se 1870 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=232sxxeserg 1871 From: Alice ;tag=kkaz- 1872 To: Bob 1873 Supported: histinfo 1874 Call-Id: 12345600@example.com 1875 CSeq: 1 INVITE 1876 History-Info: ;index=1 1877 History-Info: ;index=1.1;rc=1 1878 Contact: Alice 1879 Content-Type: application/sdp 1880 Content-Length: 1882 [SDP Not Shown] 1884 F3 302 Moved Temporarily Bob -> Example.com 1886 SIP/2.0 302 Moved Temporarily 1887 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=232sxxeserg 1888 From: Alice ;tag=kkaz- 1889 To: Bob 1890 Supported: histinfo 1891 Call-Id: 12345600@example.com 1892 CSeq: 1 INVITE 1893 History-Info: ;index=1 1894 History-Info: ; index=1.1;rc=1 1895 Contact: 1896 Content-Type: application/sdp 1897 Content-Length: 1899 [SDP Not Shown] 1901 F4 INVITE Example.com -> Carol 1903 INVITE sip:carol@192.0.2.4 SIP/2.0 1904 Via: SIP/2.0/TCP proxy.example.com:5060;branch=as2334se 1905 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=232sxxeserg 1906 From: Alice ;tag=kkaz- 1907 To: Bob 1908 Supported: histinfo 1909 Call-Id: 12345600@example.com 1910 CSeq: 1 INVITE 1911 History-Info: ;index=1 1912 History-Info: ;\ 1913 index=1.1;rc=1 1914 History-Info: ;index=1.2;mp=1 1915 History-Info: ;index=1.2.1;rc=1.2 1916 Contact: Alice 1917 Content-Type: application/sdp 1918 Content-Length: 1920 [SDP Not Shown] 1922 F5 180 Ringing Carol -> Example.com 1924 SIP/2.0 180 Ringing 1925 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=232sxxeserg 1926 From: Alice ;tag=kkaz- 1927 To: Bob ;tag=setss3x 1928 Supported: histinfo 1929 Call-Id: 12345600@example.com 1930 CSeq: 1 INVITE 1931 History-Info: ;index=1 1932 History-Info: ;\ 1933 index=1.1;rc=1 1934 History-Info: ;index=1.2;mp=1 1935 History-Info: ;index=1.2.1;rc=1.2 1936 Contact: 1937 Content-Type: application/sdp 1938 Content-Length: 1940 [SDP Not Shown] 1941 F6 INVITE Example.com -> VM 1943 INVITE sip:vm0192.0.2.6;target=sip:bob@example.com;cause=408 1944 Via: SIP/2.0/TCP proxy.example.com:5060;branch=as2334se 1945 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=232sxxeserg 1946 From: Alice ;tag=kkaz- 1947 To: Bob 1948 Supported: histinfo 1949 Call-Id: 12345600@example.com 1950 CSeq: 1 INVITE 1951 History-Info: ;index=1 1952 History-Info: ;\ 1953 index=1.1;rc=1 1954 History-Info: ;index=1.2;mp=1 1955 History-Info: ;\ 1956 index=1.2.1;rc=1.2 1957 History-Info: \ 1959 index=1.3;mp=1.2 1960 History-Info: \ 1962 index=1.3.1;rc=1.3 1963 Contact: Alice 1964 Content-Type: application/sdp 1965 Content-Length: 1967 [SDP Not Shown] 1969 F7 200 OK VM -> Example.com 1971 SIP/2.0 200 OK 1972 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=232sxxeserg 1973 From: Alice ;tag=kkaz- 1974 To: Bob ;tag=3dweggs 1975 Supported: histinfo 1976 Call-Id: 12345600@example.com 1977 CSeq: 1 INVITE 1978 History-Info: ;index=1 1979 History-Info: ;\ 1980 index=1.1;rc=1 1981 History-Info: ;index=1.2;mp=1 1982 History-Info: ;\ 1983 index=1.2.1;rc=1.2 1984 History-Info: \ 1986 index=1.3;mp=1.2 1987 History-Info: \ 1989 index=1.3.1;rc=1.3 1990 Contact: 1991 Content-Type: application/sdp 1992 Content-Length: 1994 [SDP Not Shown] 1996 B.2. Consumer Voicemail example call flow 1998 In this example, Alice calls the Bob but Bob has temporarily 1999 forwarded his phone to Carol because she is his wife. Carol does not 2000 answer the call, thus it is forwarded to a VM (voicemail) server 2001 (VMS). In order to determine the appropriate mailbox to use for this 2002 call, the VMS needs the appropriate target for the request. The last 2003 target is determined by finding the hi-entry referenced by the index 2004 of last hi-entry tagged with "rc" for determining the appropriate 2005 mailbox. This hi-entry is used to populate the "target" URI 2006 parameter as defined in [RFC4458]. Note that some VMSs may also (or 2007 instead) use the information available in the History-Info headers 2008 for custom handling of the VM in terms of how and why the called 2009 arrived at the VMS. 2011 Alice example.com Bob Carol VM 2013 | INVITE F1 | | | | 2014 |------------->| | | | 2015 | | INVITE F2 | | | 2016 | |------------->| | | 2017 | | | | | 2018 | 100 Trying | | | | 2019 |<-------------| 302 Moved Temporarily F3 | | 2020 | |<-------------| | | 2021 | | | | | 2022 | | INVITE F4 | | | 2023 | |--------------------------->| | 2024 | | | | | 2025 | | 180 Ringing F5 | | 2026 | |<---------------------------| | 2027 | | | | | 2028 | 180 Ringing | | | | 2029 |<-------------| | | | 2030 | | | | | 2031 | | (timeout) | | 2032 | | | | | 2033 | | INVITE F6 | | | 2034 | |-------------------------------------->| 2035 | | | | | 2036 | | 200 OK F7 | 2037 | |<--------------------------------------| 2038 | 200 OK | | | | 2039 |<-------------| | | | 2040 | | | | | 2041 | ACK | | | | 2042 |------------->| ACK | 2043 | |-------------------------------------->| 2045 F1 INVITE Alice -> Example.com 2047 INVITE sip:bob@example.com 2048 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=232sxxeserg 2049 From: Alice ;tag=kkaz- 2050 To: Bob 2051 Supported: histinfo 2052 Call-Id: 12345600@example.com 2053 CSeq: 1 INVITE 2054 Contact: Alice 2055 Content-Length: 2057 [SDP Not Shown] 2059 F2 INVITE Example.com -> Bob 2061 INVITE sip:bob@192.0.2.5 SIP/2.0 2062 Via: SIP/2.0/TCP proxy.example.com:5060;branch=as2334se 2063 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=232sxxeserg 2064 From: Alice ;tag=kkaz- 2065 To: Bob 2066 Supported: histinfo 2067 Call-Id: 12345600@example.com 2068 CSeq: 1 INVITE 2069 History-Info: ;index=1 2070 History-Info: ;index=1.1;rc=1 2071 Contact: Alice 2072 Content-Type: application/sdp 2073 Content-Length: 2075 [SDP Not Shown] 2077 F3 302 Moved Temporarily Bob -> Example.com 2079 SIP/2.0 302 Moved Temporarily 2080 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=232sxxeserg 2081 From: Alice ;tag=kkaz- 2082 To: Bob 2083 Supported: histinfo 2084 Call-Id: 12345600@example.com 2085 CSeq: 1 INVITE 2086 History-Info: ;index=1 2087 History-Info: ; index=1.1;rc=1 2088 Contact: 2089 Content-Type: application/sdp 2090 Content-Length: 2092 [SDP Not Shown] 2094 F4 INVITE Example.com -> Carol 2096 INVITE sip:carol@192.0.2.4 SIP/2.0 2097 Via: SIP/2.0/TCP proxy.example.com:5060;branch=as2334se 2098 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=232sxxeserg 2099 From: Alice ;tag=kkaz- 2100 To: Bob 2101 Supported: histinfo 2102 Call-Id: 12345600@example.com 2103 CSeq: 1 INVITE 2104 History-Info: ;index=1 2105 History-Info: ;\ 2106 index=1.1;rc=1 2107 History-Info: ;index=1.2;mp=1 2108 History-Info: ;index=1.2.1;rc=1.2 2109 Contact: Alice 2110 Content-Type: application/sdp 2111 Content-Length: 2113 [SDP Not Shown] 2115 F5 180 Ringing Carol -> Example.com 2117 SIP/2.0 180 Ringing 2118 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=232sxxeserg 2119 From: Alice ;tag=kkaz- 2120 To: Bob ;tag=setss3x 2121 Supported: histinfo 2122 Call-Id: 12345600@example.com 2123 CSeq: 1 INVITE 2124 History-Info: ;index=1 2125 History-Info: ;\ 2126 index=1.1;rc=1 2127 History-Info: ;index=1.2;mp=1 2128 History-Info: ;index=1.2.1;rc=1.2 2129 Contact: 2130 Content-Type: application/sdp 2131 Content-Length: 2133 [SDP Not Shown] 2135 F6 INVITE Example.com -> VM 2137 INVITE sip:vm0192.0.2.6;target=sip:carol@example.com 2138 Via: SIP/2.0/TCP proxy.example.com:5060;branch=as2334se 2139 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=232sxxeserg 2140 From: Alice ;tag=kkaz- 2141 To: Bob 2142 Supported: histinfo 2143 Call-Id: 12345600@example.com 2144 CSeq: 1 INVITE 2145 History-Info: ;index=1 2146 History-Info: ;\ 2147 index=1.1;rc 2148 History-Info: ;\ 2149 index=1.2;mp=1 2150 History-Info: ;index=1.2.1;rc=1.2 2151 History-Info: ;\ 2152 index=1.3;mp=1.2 2153 History-Info: ;\ 2154 index=1.3.1 2155 Contact: Alice 2156 Content-Type: application/sdp 2157 Content-Length: 2159 [SDP Not Shown] 2161 F7 200 OK VM -> Example.com 2163 SIP/2.0 200 OK 2164 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=232sxxeserg 2165 From: Alice ;tag=kkaz- 2166 To: Bob ;tag=3dweggs 2167 Supported: histinfo 2168 Call-Id: 12345600@example.com 2169 CSeq: 1 INVITE 2170 History-Info: ;index=1 2171 History-Info: ;\ 2172 index=1.1;rc 2173 History-Info: ;\ 2174 index=1.2;mp=1 2175 History-Info: ;index=1.2.1;rc=1.2 2176 History-Info: ;\ 2177 index=1.3;mp=1.2 2178 History-Info: ;\ 2179 index=1.3.1 2180 Contact: 2181 Content-Type: application/sdp 2182 Content-Length: 2184 [SDP Not Shown] 2186 The VMS can look at the last hi-entry and find the target of the 2187 mailbox by looking for the "target" URI parameter in the hi-entry. 2189 B.3. Sequentially Forking (History-Info in Response) 2191 This scenario highlights an example where the History-Info in the 2192 response is useful to an application or user that originated the 2193 request. 2195 Alice sends a call to Bob via sip:example.com. The proxy sip: 2196 example.com sequentially tries Bob on a SIP UA that has bound a 2197 contact with the sip:bob@example.com AOR, and then several alternate 2198 addresses (Office and Home) unsuccessfully before sending a response 2199 to Alice. The hi-entry containing the initial contact is the hi- 2200 entry just prior to the first hi-entry tagged with an "rc" header 2201 field parameter. In this example, the Office and Home are not the 2202 same AOR as sip:bob@example.com, but rather different AORs that have 2203 been configured as alternate addresses for Bob in the proxy. In 2204 other words, Office and Bob are not bound through SIP Registration 2205 with Bob's AOR. This type of arrangement is common for example when 2206 a "routing" rule to a PSTN number is manually configured in a proxy. 2207 These hi-entries are identified by the index contained in the hi- 2208 target-param "mp" header field parameter in the hi-entries. 2210 This scenario illustrates that by providing the History-Info to 2211 Alice, the end-user or an application at Alice could make a decision 2212 on how best to attempt finding Bob without sending multiple requests 2213 to the same destination. Upon receipt of the response containing the 2214 History-Info entries, the Request URIs for the History-Info entries 2215 tagged with "mp" header field parameter are extracted. Those 2216 Request-URIs can be compared to other URIs (if any) that might be 2217 attempted in order to establish the session with Bob. Thus, avoiding 2218 another INVITE to Bob's home phone. Without this mechanism, Alice 2219 might well attempt to reach Bob at his office phone, which would then 2220 retarget the request to Bob's home phone. When that attempt failed, 2221 then Alice might attempt to reach Bob directly at his home phone, 2222 unknowingly for a third time. 2224 Alice example.com Bob Office Home 2225 | | | | | 2226 | INVITE F1 | | | | 2227 |----------->| INVITE F2 | | | 2228 | |----------------->| | | 2229 | 100 Trying F3 | | | 2230 |<-----------| 302 Move Temporarily F4 | | 2231 | |<-----------------| | | 2232 | | ACK F5 | | | 2233 | |----------------->| | | 2234 | | INVITE F6 | | 2235 | |-------------------------->| | 2236 | | 180 Ringing F7 | | 2237 | |<--------------------------| | 2238 | 180 Ringing F8 | | 2239 |<-----------| retransmit INVITE | | 2240 | |-------------------------->| | 2241 | | ( timeout ) | | 2242 | | INVITE F9 | 2243 | |----------------------------------->| 2244 | | 100 Trying F10 | 2245 | |<-----------------------------------| 2246 | | 486 Busy Here F11 | 2247 | |<-----------------------------------| 2248 | 486 Busy Here F12 | 2249 |<-----------| ACK F13 | 2250 | |----------------------------------->| 2251 | ACK F14 | | 2252 |----------->| | 2253 Message Details 2255 F1 INVITE alice -> example.com 2257 INVITE sip:bob@example.com SIP/2.0 2258 Via: SIP/2.0/TCP 192.0.2.3:5060 2259 From: Alice 2260 To: Bob 2261 Supported: histinfo 2262 Call-Id: 12345600@example.com 2263 CSeq: 1 INVITE 2264 History-Info: ;index=1 2265 Contact: Alice 2266 Content-Type: application/sdp 2267 Content-Length: 2268 2270 F2 INVITE example.com -> Bob 2272 INVITE sip:bob@192.0.2.4 SIP/2.0 2273 Via: SIP/2.0/TCP proxy.example.com:5060 2274 Via: SIP/2.0/TCP 192.0.2.3:5060 2275 From: Alice 2276 To: Bob 2277 Supported: histinfo 2278 Call-Id: 12345600@example.com 2279 CSeq: 1 INVITE 2280 Record-Route: 2281 History-Info: ;index=1 2282 History-Info: ;index=1.1;rc=1 2283 Contact: Alice 2284 Content-Type: application/sdp 2285 Content-Length: 2286 2288 F3 100 Trying example.com -> alice 2290 SIP/2.0 100 Trying 2291 Via: SIP/2.0/TCP 192.0.2.3:5060 2292 From: Alice 2293 To: Bob 2294 Call-Id: 12345600@example.com 2295 CSeq: 1 INVITE 2296 Content-Length: 0 2297 F4 302 Moved Temporarily Bob -> example.com 2299 SIP/2.0 302 Moved Temporarily 2300 Via: SIP/2.0/TCP proxy.example.com:5060 2301 Via: SIP/2.0/TCP 192.0.2.3:5060 2302 From: Alice 2303 To: Bob ;tag=3 2304 Call-Id: 12345600@example.com 2305 CSeq: 1 INVITE 2306 Record-Route: 2307 History-Info: ;index=1 2308 History-Info: ;index=1.1;rc=1 2309 Contact: ;mp=1 2310 Content-Length: 0 2312 F5 ACK 192.0.2.4 -> Bob 2314 ACK sip:bob@example.com SIP/2.0 2315 Via: SIP/2.0/TCP proxy.example.com:5060 2316 From: Alice 2317 To: Bob 2318 Call-Id: 12345600@example.com 2319 CSeq: 1 ACK 2320 Content-Length: 0 2322 F6 INVITE example.com -> office 2324 INVITE sip:office@192.0.2.5 SIP/2.0 2325 Via: SIP/2.0/TCP proxy.example.com:5060;branch=2 2326 Via: SIP/2.0/TCP 192.0.2.3:5060 2327 From: Alice 2328 To: Bob 2329 Supported: histinfo 2330 Call-Id: 12345600@example.com 2331 Record-Route: 2332 History-Info: ;index=1 2333 History-Info: ;\ 2334 index=1.1;rc=1 2335 History-Info: ;index=1.2;mp=1 2336 History-Info: ;index=1.2.1;rc=1.2 2337 CSeq: 1 INVITE 2338 Contact: Alice 2339 Content-Type: application/sdp 2340 Content-Length: 2341 2343 F7 180 Ringing office -> example.com 2345 SIP/2.0 180 Ringing 2346 Via: SIP/2.0/TCP proxy.example.com:5060;branch=2 2347 Via: SIP/2.0/TCP 192.0.2.3:5060 2348 From: Alice 2349 To: Bob ;tag=5 2350 Supported: histinfo 2351 Call-ID: 12345600@example.com 2352 Record-Route: 2353 History-Info: ;index=1 2354 History-Info: ;\ 2355 index=1.1;rc=1 2356 History-Info: ;index=1.2;mp=1 2357 History-Info: ;index=1.2.1;rc=1.2 2358 CSeq: 1 INVITE 2359 Content-Length: 0 2361 F8 180 Ringing example.com -> alice 2363 SIP/2.0 180 Ringing 2364 Via: SIP/2.0/TCP example.com:5060 2365 From: Alice 2366 To: Bob 2367 Supported: histinfo 2368 Call-Id: 12345600@example.com 2369 History-Info: ;index=1 2370 History-Info: ;\ 2371 index=1.1;rc=1 2372 History-Info: ;index=1.2;mp=1 2373 History-Info: ;index=1.2.1;rc=1.2 2374 CSeq: 1 INVITE 2375 Content-Length: 0 2376 F9 INVITE example.com -> home 2378 INVITE sip:home@192.0.2.6 SIP/2.0 2379 Via: SIP/2.0/TCP proxy.example.com:5060;branch=3 2380 Via: SIP/2.0/TCP 192.0.2.3:5060 2381 From: Alice 2382 To: Bob 2383 Supported: histinfo 2384 Call-Id: 12345600@example.com 2385 Record-Route: 2386 History-Info: ;index=1 2387 History-Info: ;\ 2388 index=1.1;rc=1 2389 History-Info: ;index=1.2;mp=1 2390 History-Info: ;\ 2391 index=1.2.1>;index=1.2.1;rc=1.2 2392 History-Info: ;index=1.3;mp=1 2393 History-Info: ;index=1.3.1;rc=1.3 2394 CSeq: 1 INVITE 2395 Contact: Alice 2396 Content-Type: application/sdp 2397 Content-Length: 2398 2400 F10 100 Trying home -> example.com 2402 SIP/2.0 100 Trying 2403 Via: SIP/2.0/TCP proxy.example.com:5060;branch=3 2404 Via: SIP/2.0/TCP 192.0.2.3:5060 2405 From: Alice 2406 To: Bob 2407 Call-Id: 12345600@example.com 2408 CSeq: 1 INVITE 2409 Content-Length: 0 2410 F11 486 Busy Here home -> example.com 2412 SIP/2.0 486 Busy Here 2413 Via: SIP/2.0/TCP proxy.example.com:5060;branch=3 2414 Via: SIP/2.0/TCP 192.0.2.3:5060 2415 From: Alice 2416 To: Bob 2417 Call-Id: 12345600@example.com 2418 Record-Route: 2419 History-Info: ;index=1 2420 History-Info: ;\ 2421 index=1.1;rc=1 2422 History-Info: ;index=1.2;mp=1 2423 History-Info: ;\ 2424 index=1.2.1>;index=1.2.1;rc=1.2 2425 History-Info: ;index=1.3;mp=1 2426 History-Info: ;index=1.3.1;rc=1.3 2427 CSeq: 1 INVITE 2428 Content-Length: 0 2430 F12 486 Busy Here example.com -> alice 2432 SIP/2.0 486 Busy Here 2433 Via: SIP/2.0/TCP 192.0.2.3:5060 2434 From: Alice 2435 To: Bob 2436 Call-Id: 12345600@example.com 2437 History-Info: ;index=1 2438 History-Info: ;\ 2439 index=1.1;rc=1 2440 History-Info: ;index=1.2;mp=1 2441 History-Info: ;\ 2442 index=1.2.1>;index=1.2.1;rc=1.2 2443 History-Info: ;index=1.3;mp=1 2444 History-Info: ;index=1.3.1;rc=1.3 2445 CSeq: 1 INVITE 2446 Content-Length: 0 2447 F13 ACK example.com -> home 2449 ACK sip:home@192.0.2.6 SIP/2.0 2450 Via: SIP/2.0/TCP proxy.example.com:5060 2451 From: Alice 2452 To: Bob 2453 Call-Id: 12345600@example.com 2454 CSeq: 1 ACK 2455 Content-Length: 0 2457 F14 ACK alice -> example.com 2459 ACK sip:bob@example.com SIP/2.0 2460 Via: SIP/2.0/TCP 192.0.2.3:5060 2461 From: Alice 2462 To: Bob 2463 Call-Id: 12345600@example.com 2464 Route: 2465 CSeq: 1 ACK 2466 Content-Length: 0 2468 B.4. History-Info with Privacy Header Field 2470 This example provides a basic call scenario without forking. Alice 2471 has indicated that she wants Privacy associated with the History-Info 2472 header field entries. In addition, sip:biloxi.example.com adds 2473 Privacy header fields indicating that the History-info header field 2474 information is anonymized outside the biloxi.example.com domain. 2475 Note, that if the atlanta.example.com proxy had added privacy header 2476 fields to all its hi-entries, then all the hi-entries in the response 2477 would be anonymous. 2479 Alice atlanta.example.com biloxi.example.com Bob 2480 | | | | 2481 | INVITE F1 | | | 2482 |--------------->| | | 2483 | | | | 2484 | | INVITE F2 | | 2485 | |--------------->| | 2486 | | | | 2487 | | | INVITE F3 | 2488 | | |--------------->| 2489 | | | | 2490 | | | 200 F4 | 2491 | | |<---------------| 2492 | | | | 2493 | | 200 F5 | | 2494 | |<---------------| | 2495 | | | | 2496 | 200 F6 | | | 2497 |<---------------| | | 2498 | | | | 2499 | ACK | | | 2500 |--------------->| ACK | | 2501 | |--------------->| ACK | 2502 | | |--------------->| 2504 Figure 2: Example with Privacy Header Fields 2506 Message Details 2508 F1 INVITE alice -> atlanta.example.com 2510 INVITE sip:bob@biloxi.example.com;p=x SIP/2.0 2511 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=1 2512 From: Alice ;tag=22 2513 To: Bob 2514 Supported: histinfo 2515 Privacy: History 2516 Call-Id: 12345600@atlanta.example.com 2517 CSeq: 1 INVITE 2518 History-Info: ;index=1 2519 Contact: Alice 2520 Content-Type: application/sdp 2521 Content-Length: 2522 2523 F2 INVITE atlanta.example.com -> biloxi.example.com 2525 INVITE sip:bob@biloxi.example.com;p=x SIP/2.0 2526 Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=3 2527 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=1 2528 From: Alice ;tag=22 2529 To: Bob 2530 Supported: histinfo 2531 Call-Id: 12345600@atlanta.example.com 2532 CSeq: 1 INVITE 2533 History-Info: ;index=1 2534 History-Info: ;index=1.1;rc=1 2535 Contact: Alice 2536 Content-Type: application/sdp 2537 Content-Length: 2538 2540 F3 INVITE biloxi.example.com -> Bob 2542 INVITE sip:bob@192.0.1.11 SIP/2.0 2543 Via: SIP/2.0/TCP proxy.biloxi.example.com:5060;branch=5 2544 Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=3 2545 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=1 2546 From: Alice ;tag=22 2547 To: Bob 2548 Supported: histinfo 2549 Call-Id: 12345600@atlanta.example.com 2550 CSeq: 1 INVITE 2551 History-Info: ;index=1 2552 History-Info: ;index=1.1;rc=1 2553 History-Info: ;index=1.1.1;rc=1.1 2554 Contact: Alice 2555 Content-Type: application/sdp 2556 Content-Length: 2557 2558 F4 200 OK Bob -> biloxi.example.com 2560 SIP/2.0 200 OK 2561 Via: SIP/2.0/TCP proxy.biloxi.example.com:5060;branch=5 2562 Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=3 2563 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=1 2564 From: Alice ;tag=22 2565 To: Bob ;tag=33 2566 Supported: histinfo 2567 Call-Id: 12345600@atlanta.example.com 2568 CSeq: 1 INVITE 2569 History-Info: ;index=1 2570 History-Info: ;index=1.1;rc=1 2571 History-Info: ;index=1.1.1;rc=1.1 2572 Contact: Bob 2573 Content-Type: application/sdp 2574 Content-Length: 2575 2577 F5 200 OK biloxi.example.com -> atlanta.example.com 2579 SIP/2.0 200 OK 2580 Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=3 2581 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=1 2582 From: Alice ;tag=22 2583 To: Bob ;tag=33 2584 Supported: histinfo 2585 Call-Id: 12345600@atlanta.example.com 2586 CSeq: 1 INVITE 2587 History-Info: ;index=1 2588 History-Info: ;index=1.1;rc=1 2589 History-Info: >;index=1.1.1;rc=1.1 2590 Contact: Bob 2591 Content-Type: application/sdp 2592 Content-Length: 2593 2594 F6 200 OK atlanta.example.com -> Alice 2596 SIP/2.0 200 OK 2597 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=1 2598 From: Alice ;tag=22 2599 To: Bob ;tag=33 2600 Supported: histinfo 2601 Call-Id: 12345600@atlanta.example.com 2602 CSeq: 1 INVITE 2603 History-Info: ;index=1 2604 History-Info: ;index=1.1;rc=1 2605 History-Info: >;index=1.1.1;rc=1.1 2606 Contact: Bob 2607 Content-Type: application/sdp 2608 Content-Length: 2609 2611 B.5. Privacy for a Specific History-Info Entry 2613 This example provides a basic call scenario similar to Appendix B.4, 2614 however, due to local policy at sip:biloxi.example.com, only the 2615 final hi-entry in the History-Info, which is Bob's local URI, 2616 contains a privacy header field with a priv-value of "history", thus 2617 providing Alice with some information about the history of the 2618 request, but anonymizing Bob's local URI. 2620 Alice atlanta.example.com biloxi.example.com Bob 2621 | | | | 2622 | INVITE F1 | | | 2623 |--------------->| | | 2624 | | | | 2625 | | INVITE F2 | | 2626 | |--------------->| | 2627 | | | | 2628 | | | INVITE F3 | 2629 | | |--------------->| 2630 | | | | 2631 | | | 200 F4 | 2632 | | |<---------------| 2633 | | | | 2634 | | 200 F5 | | 2635 | |<---------------| | 2636 | | | | 2637 | 200 F6 | | | 2638 |<---------------| | | 2639 | | | | 2640 | ACK | | | 2641 |--------------->| ACK | | 2642 | |--------------->| ACK | 2643 | | |--------------->| 2645 Figure 3: Example with Privacy Header Field for Specific URI 2647 Message Details 2649 F1 INVITE alice -> atlanta.example.com 2651 INVITE sip:bob@biloxi.example.com;p=x SIP/2.0 2652 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=1 2653 From: Alice ;tag=22 2654 To: Bob 2655 Supported: histinfo 2656 Call-Id: 12345600@atlanta.example.com 2657 CSeq: 1 INVITE 2658 History-Info: ;index=1 2659 Contact: Alice 2660 Content-Type: application/sdp 2661 Content-Length: 2662 2663 F2 INVITE atlanta.example.com -> biloxi.example.com 2665 INVITE sip:bob@biloxi.example.com;p=x SIP/2.0 2666 Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=3 2667 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=1 2668 From: Alice ;tag=22 2669 To: Bob 2670 Supported: histinfo 2671 Call-Id: 12345600@atlanta.example.com 2672 CSeq: 1 INVITE 2673 History-Info: ;index=1 2674 History-Info: ;index=1.1;rc=1 2675 Contact: Alice 2676 Content-Type: application/sdp 2677 Content-Length: 2678 2680 F3 INVITE biloxi.example.com -> Bob 2682 INVITE sip:bob@192.0.1.11 SIP/2.0 2683 Via: SIP/2.0/TCP proxy.biloxi.example.com:5060;branch=5 2684 Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=3 2685 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=1 2686 From: Alice ;tag=22 2687 To: Bob 2688 Supported: histinfo 2689 Call-Id: 12345600@atlanta.example.com 2690 CSeq: 1 INVITE 2691 History-Info: ;index=1 2692 History-Info: ;index=1.1;rc=1 2693 History-Info: ;index=1.1.1;rc=1.1 2694 Contact: Alice 2695 Content-Type: application/sdp 2696 Content-Length: 2697 2698 F4 200 OK Bob -> biloxi.example.com 2700 SIP/2.0 200 OK 2701 Via: SIP/2.0/TCP proxy.biloxi.example.com:5060;branch=5 2702 Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=3 2703 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=1 2704 From: Alice ;tag=22 2705 To: Bob ;tag=33 2706 Supported: histinfo 2707 Call-Id: 12345600@atlanta.example.com 2708 CSeq: 1 INVITE 2709 History-Info: ;index=1 2710 History-Info: ;index=1.1;rc=1 2711 History-Info: ;index=1.1.1;rc=1.1 2712 Contact: Bob 2713 Content-Type: application/sdp 2714 Content-Length: 2715 2717 F5 200 OK biloxi.example.com -> atlanta.example.com 2719 SIP/2.0 200 OK 2720 Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=3 2721 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=1 2722 From: Alice ;tag=22 2723 To: Bob ;tag=33 2724 Supported: histinfo 2725 Call-Id: 12345600@atlanta.example.com 2726 CSeq: 1 INVITE 2727 History-Info: ;index=1 2728 History-Info: ;index=1.1;rc=1 2729 History-Info: >;index=1.1.1;rc=1.1 2730 Contact: Bob 2731 Content-Type: application/sdp 2732 Content-Length: 2733 2734 F6 200 OK atlanta.example.com -> Alice 2736 SIP/2.0 200 OK 2737 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=1 2738 From: Alice ;tag=22 2739 To: Bob ;tag=33 2740 Supported: histinfo 2741 Call-Id: 12345600@atlanta.example.com 2742 CSeq: 1 INVITE 2743 History-Info: ;index=1 2744 History-Info: ;index=1.1;rc=1 2745 History-Info: >;index=1.1.1;rc=1.1 2746 Contact: Bob 2747 Content-Type: application/sdp 2748 Content-Length: 2749 2751 Authors' Addresses 2753 Mary Barnes 2754 Polycom 2755 TX 2756 US 2758 Email: mary.ietf.barnes@gmail.com 2760 Francois Audet 2761 Skype 2763 Email: francois.audet@skype.net 2765 Shida Schubert 2766 NTT 2768 Email: shida@ntt-at.com 2769 Hans Erik van Elburg 2770 Detecon International Gmbh 2771 Oberkasseler str. 2 2772 Bonn, 2773 Germany 2775 Email: ietf.hanserik@gmail.com 2777 Christer Holmberg 2778 Ericsson 2779 Hirsalantie 11, Jorvas 2780 Finland 2782 Email: christer.holmberg@ericsson.com