idnits 2.17.1 draft-ietf-sipcore-rfc4244bis-08.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. -- 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 451 has weird spacing: '... Alice atla...' == Line 2264 has weird spacing: '... Alice exam...' == Line 2526 has weird spacing: '... Alice atla...' == Line 2672 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 (Apr 2012) is 4387 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 1154, but not defined == Unused Reference: 'RFC3969' is defined on line 1683, 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: 3 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: October 3, 2012 S. Schubert 7 NTT 8 J. van Elburg 9 Detecon International Gmbh 10 C. Holmberg 11 Ericsson 12 Apr 2012 14 An Extension to the Session Initiation Protocol (SIP) for Request 15 History Information 16 draft-ietf-sipcore-rfc4244bis-08.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 that 30 directs the anonymization of values in the History-Info header field 31 This document obsoletes RFC 4244. 33 Status of this Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on October 3, 2012. 50 Copyright Notice 52 Copyright (c) 2012 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 This document may contain material from IETF Documents or IETF 66 Contributions published or made publicly available before November 67 10, 2008. The person(s) controlling the copyright in some of this 68 material may not have granted the IETF Trust the right to allow 69 modifications of such material outside the IETF Standards Process. 70 Without obtaining an adequate license from the person(s) controlling 71 the copyright in such materials, this document may not be modified 72 outside the IETF Standards Process, and derivative works of it may 73 not be created outside the IETF Standards Process, except to format 74 it for publication as an RFC or to translate it into languages other 75 than English. 77 Table of Contents 79 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 80 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 5 81 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 6 82 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 83 5. History-Info Header Field Protocol Structure . . . . . . . . . 8 84 5.1. History-Info Header Field Example Scenario . . . . . . . . 11 85 6. User Agent Handling of the History-Info Header Field . . . . . 14 86 6.1. User Agent Client (UAC) Behavior . . . . . . . . . . . . . 14 87 6.2. User Agent Server (UAS) Behavior . . . . . . . . . . . . . 14 88 7. Proxy/Intermediary Handling of History-Info Header Fields . . 14 89 8. Redirect Server Handling of History-Info Header Fields . . . . 15 90 9. Handling of History-Info Header Fields in Requests and 91 Responses . . . . . . . . . . . . . . . . . . . . . . . . . . 15 92 9.1. Receiving a Request . . . . . . . . . . . . . . . . . . . 16 93 9.2. Sending a Request with History-Info . . . . . . . . . . . 16 94 9.3. Receiving a Response with History-Info or Request 95 Timeouts . . . . . . . . . . . . . . . . . . . . . . . . . 17 96 9.4. Sending History-Info in Responses . . . . . . . . . . . . 17 97 10. Processing the History-Info Header Field . . . . . . . . . . . 18 98 10.1. Privacy in the History-Info Header Field . . . . . . . . . 18 99 10.1.1. Indicating Privacy . . . . . . . . . . . . . . . . . 18 100 10.1.2. Applying Privacy . . . . . . . . . . . . . . . . . . 19 101 10.2. Reason in the History-Info Header Field . . . . . . . . . 20 102 10.3. Indexing in the History-Info Header Field . . . . . . . . 20 103 10.4. Mechanism for Target Determination in the History-Info 104 Header Field . . . . . . . . . . . . . . . . . . . . . . . 22 105 11. Application Considerations . . . . . . . . . . . . . . . . . . 23 106 12. Application Specific Usage . . . . . . . . . . . . . . . . . . 25 107 12.1. PBX Voicemail . . . . . . . . . . . . . . . . . . . . . . 25 108 12.2. Consumer Voicemail . . . . . . . . . . . . . . . . . . . . 26 109 13. Security Considerations . . . . . . . . . . . . . . . . . . . 26 110 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 111 14.1. Registration of New SIP History-Info Header Field . . . . 27 112 14.2. Registration of "history" for SIP Privacy Header Field . . 27 113 14.3. Registration of Header Field Parameters . . . . . . . . . 28 114 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 115 16. Changes from RFC 4244 . . . . . . . . . . . . . . . . . . . . 29 116 16.1. Backwards compatibility . . . . . . . . . . . . . . . . . 30 117 17. Changes since last Version . . . . . . . . . . . . . . . . . . 31 118 18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38 119 18.1. Normative References . . . . . . . . . . . . . . . . . . . 38 120 18.2. Informative References . . . . . . . . . . . . . . . . . . 39 121 Appendix A. Request History Requirements . . . . . . . . . . . . 39 122 A.1. Security Requirements . . . . . . . . . . . . . . . . . . 40 123 A.2. Privacy Requirements . . . . . . . . . . . . . . . . . . . 41 124 Appendix B. Example call flows . . . . . . . . . . . . . . . . . 42 125 B.1. PBX Voicemail call flow . . . . . . . . . . . . . . . . . 42 126 B.2. Consumer Voicemail example call flow . . . . . . . . . . . 46 127 B.3. Sequentially Forking (History-Info in Response) . . . . . 50 128 B.4. History-Info with Privacy Header Field . . . . . . . . . . 58 129 B.5. Privacy for a Specific History-Info Entry . . . . . . . . 62 130 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 66 132 1. Introduction 134 Many services that SIP is anticipated to support require the ability 135 to determine why and how a SIP request arrived at a specific 136 application. Examples of such services include (but are not limited 137 to) sessions initiated to call centers via "click to talk" SIP 138 Uniform Resource Locators (URLs) on a web page, "call history/ 139 logging" style services within intelligent "call management" software 140 for SIP User Agents (UAs), and calls to voicemail servers. Although 141 SIP implicitly provides the retarget capabilities that enable SIP 142 requests to be routed to chosen applications, there is a need for a 143 standard mechanism within SIP for communicating the retargeting 144 history of the requests. This "request history" information allows 145 the receiving application to obtain information about how and why the 146 SIP request arrived at the application/user. 148 This document defines a SIP header field, History-Info, to provide a 149 standard mechanism for capturing the request history information to 150 enable a wide variety of services for networks and end-users. SIP 151 header field parameters are defined for the History-Info and Contact 152 header fields to tag the method by which the target of a request is 153 determined. In addition, this specification defines a value for the 154 Privacy header field specific to the History-Info header. 156 The History-Info header field provides a building block for 157 development of SIP based applications and services. The requirements 158 for the solution described in this specification are included in 159 Appendix A. Example scenarios using the History-Info header field 160 are included in Appendix B. 162 2. Conventions and Terminology 164 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 165 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 166 document are to be interpreted as described in [RFC2119]. 168 The term "retarget" is used in this specification to refer to the 169 process of a SIP entity changing the request-URI [RFC3261, section 170 7.1] in a request based on the rules for determining request targets 171 as described in Section 16.5 of [RFC3261] and of the subsequent 172 forwarding of that request as described in step 2 in section 16.6 of 173 [RFC3261]. This includes changing the Request-URI due to a location 174 service lookup and redirect processing. This also includes internal 175 (to a Proxy/SIP intermediary) changes of the URI prior to forwarding 176 of the request. 178 The terms "location service", "forward", "redirect" and "AOR" are 179 used consistent with the terminology in [RFC3261]. 181 The terms "target user" is used in this specification as the human 182 user associated with particular AoR or AoRs (in case the human user 183 has multiple alias). 185 The references to "domain for which the SIP entity/Proxy/Intermediary 186 is responsible" are consistent with and intended to convey the same 187 context as the usage of that terminology in [RFC3261]. The 188 applicability of History-Info to architectures or models outside the 189 context of [RFC3261] is outside the scope of this specification. 191 3. Background 193 SIP implicitly provides retargeting capabilities that enable SIP 194 requests to be routed to specific applications as defined in 195 [RFC3261]. The motivation for capturing the request history is that 196 in the process of retargeting a request, old routing information can 197 be forever lost. This lost information may be important history that 198 allows elements to which the request is retargeted to process the 199 request in a locally defined, application-specific manner. This 200 document defines a mechanism for transporting the request history. 201 Application-specific behavior is outside the scope of this 202 specification. 204 Current network applications for other protocols provide the ability 205 for elements involved with the request to obtain additional 206 information relating to how and why the request was routed to a 207 particular destination. The following are examples of such 208 applications: 210 1. Web "referral" applications, whereby an application residing 211 within a web server determines that a visitor to a website has 212 arrived at the site via an "associate" site that will receive 213 some "referral" commission for generating this traffic 215 2. Email forwarding whereby the forwarded-to user obtains a detailed 216 "trace of the path" of the message from sender to receiver and at 217 what time 219 3. Traditional telephony services such as voicemail, call-center 220 "automatic call distribution", and "follow-me" style services 222 Several of the aforementioned applications currently define 223 application-specific mechanisms through which it is possible to 224 obtain the necessary history information. 226 In addition, request history information could be used to enhance 227 basic SIP functionality by providing the following: 229 o Some diagnostic information for debugging SIP requests. 231 o Capturing aliases and Globally Routable User Agent URIs (GRUUs) 232 [RFC5627], which can be overwritten by a registrar or a "home 233 proxy" (a proxy serving as the terminal point for routing an 234 address-of-record) upon receipt of the initial request. 236 o Facilitating the use of limited use addresses (minted on demand) 237 and sub-addressing. 239 o Preserving service specific URIs that can be overwritten by a 240 downstream proxy, such as those defined in [RFC3087], and control 241 of network announcements and IVR with SIP URI [RFC4240]. 243 4. Overview 245 The fundamental functionality provided by the request history 246 information is the ability to inform proxies and UAs involved in 247 processing a request about the history or progress of that request. 248 The solution is to capture the Request-URIs as a request is 249 retargeted, in a SIP header field: History-Info. This allows for the 250 capturing of the history of a request that would be lost with the 251 normal SIP processing involved in the subsequent retargeting of the 252 request. 254 The History-Info header field is added to a Request when a new 255 request is created by a UAC or forwarded by a Proxy, or when the 256 target of a request is changed. It is possible for the target of a 257 request to be changed by the same proxy/SIP intermediary multiple 258 times (referred to as 'internal retargeting'). A SIP entity changing 259 the target of a request in response to a redirect also propagates any 260 History-Info header field from the initial request in the new 261 request. The ABNF and detailed description of the History-Info 262 header field parameters along with examples, is provided in 263 Section 5. Section 6, Section 7 and Section 8 provide the detailed 264 handling of the History-Info header field by SIP User Agents, Proxies 265 and Redirect Servers respectively. 267 This specification also defines three new SIP header field 268 parameters, "rc", "mp" and "np", for the History-Info and Contact 269 header fields, to tag the method by which the target of a request is 270 determined. Further detail on the use of these header field 271 parameters is provided in Section 10.4. 273 In addition, this specification defines a priv-value for the Privacy 274 header, "history", that requires anonymization of all the History- 275 Info header field entries in a Request or to a specific History-Info 276 header field hi-entry as described above. Further detail is provided 277 in Section 10.1. 279 5. History-Info Header Field Protocol Structure 281 The History-Info header field defined in this specification defines 282 the usage in out-of-dialog requests or initial requests for a dialog 283 (e.g., INVITE, REGISTER, MESSAGE, REFER and OPTIONS, PUBLISH and 284 SUBSCRIBE, etc.) and any non-100 provisional or final responses to 285 these requests. 287 The following provides details for the information that is captured 288 in the History-Info header field entries for each target used for 289 forwarding a request: 291 o hi-targeted-to-uri: A mandatory parameter for capturing the 292 Request-URI for the specific request as it is forwarded. 294 o hi-index: A mandatory parameter for History-Info reflecting the 295 chronological order of the information, indexed to also reflect 296 the forking and nesting of requests. The format for this 297 parameter is a sequance of nonnegative integers, separated by dots 298 to indicate the number of forward hops and retargets. This 299 results in a tree representation of the history of the request, 300 with the lowest-level index reflecting a leaf. By adding the new 301 entries in order (i.e., following existing entries per the details 302 in Section 10.3), including the index and sending the messages 303 using a secure transport, the ordering of the History-Info header 304 fields in the request is assured. In addition, applications may 305 extract a variety of metrics (total number of retargets, total 306 number of retargets from a specific branch, etc.) based upon the 307 index values. 309 o hi-target-param: An optional parameter reflecting the mechanism by 310 which the Request URI captured in the hi-targeted-to-uri in the 311 History-Info header field value (hi-entry) was determined. This 312 parameter is either an "rc", "mp" or "np" header field parameter, 313 which is interpreted as follows: 315 "rc": The hi-targeted-to-URI represents a change in Request-URI 316 while the target user remains the same. This occurs for 317 example when user has multiple AoRs as an alias. The "rc" 318 header field parameter contains the value of the hi-index in 319 the hi-entry with an hi-targeted-to-uri that reflects the 320 Request-URI that was retargeted 322 "mp": The hi-targeted-to-URI represents a user other than the 323 target user associated with the Request-URI in the incoming 324 request that was retargeted. This occurs when a request is 325 statically or dynamically retargeted to another user 326 represented by an AoR unassociated with the AoR of the original 327 target user. The "mp" header field parameter contains the 328 value of the hi-index in the hi-entry with an hi-targeted-to- 329 uri that reflects the Request-URI that was retargeted, thus 330 identifying the "mapped from" target. 332 "np": The hi-targeted-to-URI represents that there was no 333 change in Request-URI. This would apply for example when a 334 proxy merely forwards a request to a next hop proxy and loose 335 routing is used. The "np" header field parameter contains the 336 value of the hi-index in the hi-entry with an hi-targeted-to- 337 uri that reflects the Request-URI that was copied unchanged 338 into the request represented by this hi-entry. That value will 339 usually be the hi-index of the parent hi-entry of this hi- 340 entry. 342 o Extension (hi-extension): A parameter to allow for future optional 343 extensions. As per [RFC3261], any implementation not 344 understanding an extension MUST ignore it. 346 The ABNF syntax [RFC5234] for the History-Info header field and 347 header field parameters is as follows: 349 History-Info = "History-Info" HCOLON hi-entry *(COMMA hi-entry) 351 hi-entry = hi-targeted-to-uri *(SEMI hi-param) 353 hi-targeted-to-uri = addr-spec / name-addr 355 hi-param = hi-index / hi-target-param / hi-extension 357 hi-index = "index" EQUAL index-val 358 index-val = number *("." number) 360 number = [ %31-39 *DIGIT ] DIGIT 362 hi-target-param = rc-param / mp-param / np-param 364 rc-param = "rc" EQUAL index-val 366 mp-param = "mp" EQUAL index-val 368 np-param = "np" EQUAL index-val 370 hi-extension = generic-param 372 The ABNF definitions for "generic-param" and "name-addr" are from 373 [RFC3261]. 375 This document also extends the "contact-params" for the Contact 376 header field as defined in [RFC3261] with the "rc", "mp" and "np" 377 header field parameters defined above. 379 In addition to the parameters defined by the ABNF, an hi-entry may 380 also include a Reason header field and/or a Privacy header field, 381 which are both included in the "headers" component of the hi- 382 targeted-to-uri as described below: 384 o Reason: An optional parameter for History-Info, reflected in the 385 History-Info header field by including the Reason header field 386 [RFC3326] included in the hi-targeted-to-uri. A reason is 387 included in the hi-targeted-to-uri of an hi-entry to reflect 388 information received in a response to the request sent to that 389 URI. 391 o Privacy: An optional parameter for History-Info, reflected in the 392 History-Info header field values by including the Privacy Header 393 [RFC3323] included in the hi- targeted-to-uri or by adding the 394 Privacy header field to the request. The latter case indicates 395 that the History-Info entries for all History-Info entries whose 396 hi-targeted-to-uri has the same domain as the domain for which the 397 SIP entity processing the message is responsible MUST be 398 anonymized prior to forwarding, whereas the use of the Privacy 399 header field included in the hi-targeted-to-uri means that a 400 specific hi-entry MUST be anonymized. 402 Note that since both the Reason and Privacy parameters are included 403 in the hi-targeted-to-uri, these fields will not be available in the 404 case that the hi-targeted-to-uri is a Tel-URI [RFC3966]. 406 The following provides examples of the format for the History-Info 407 header field. Note that the backslash, CRLF and whitespace between 408 the lines in the examples below are inserted for readability purposes 409 only. (But History-Info can be broken into multiple lines due to the 410 SWS that is part of HCOLON, COMMA and SEMI, and there can be multiple 411 History-Info header fields due to the rule of section 7.3 [RFC3261].) 413 History-Info: ;index=1;foo=bar 415 History-Info: ;index=1.1,\ 417 ;index=1.2;mp=1.1,\ 419 ;index=1.3;rc=1.2 421 5.1. History-Info Header Field Example Scenario 423 The following is an illustrative example of usage of History-Info. 425 In this example, Alice (sip:alice@atlanta.example.com) calls Bob 426 (sip:bob@biloxi.example.com). Alice's proxy in her home domain (sip: 427 atlanta.example.com) forwards the request to Bob's proxy (sip: 428 biloxi.example.com). When the request arrives at sip: 429 biloxi.example.com, it does a location service lookup for 430 bob@biloxi.example.com and changes the target of the request to Bob's 431 Contact URIs provided as part of normal SIP registration. In this 432 example, Bob is simultaneously contacted on a PC client and on a 433 phone, and Bob answers on the PC client. 435 One important thing illustrated by this call flow is that without 436 History-Info, Bob would "lose" the original target information or the 437 initial request-URI, including any parameters in the request URI. 438 Bob can recover that information by locating the last hi-entry with 439 an "rc" header field parameter. This "rc" header field parameter 440 contains the index of the hi-entry containing the lost target 441 information - i.e., the sip:bob@biloxi.example.com hi-entry with 442 index=1.1. Note that in the 200 response to Alice, an hi-entry is 443 not included for the fork to sip:bob@192.0.2.7 (index 1.1.1) since 444 biloxi.example.com had not received a response from that fork at the 445 time it sent the 200 OK that ultimately reached Alice. 447 Additional detailed scenarios are available in Appendix B. 449 Note: This example uses loose routing procedures. 451 Alice atlanta.example.com biloxi.example.com Bob@pc Bob@phone 452 | | | | | 453 | INVITE sip:bob@biloxi.example.com;p=x | | 454 |--------------->| | | | 455 | Supported: histinfo | | | 456 | | | | | 457 | | INVITE sip:bob@biloxi.example.com;p=x | 458 | |--------------->| | | 459 | History-Info: ;index=1 | 460 | History-Info: ;np=1;index=1.1 461 | | | | | 462 | | | INVITE sip:bob@192.0.2.3| 463 | | |--------------->| | 464 | History-Info: ;index=1 465 | History-Info: ;np=1;index=1.1 466 | History-Info: ;index=1.1.1;rc=1.1 467 | | | | | 468 | | | INVITE sip:bob@192.0.2.7| 469 | | |-------------------------->| 470 | History-Info: ;index=1 471 | History-Info: ;np=1;index=1.1 472 | History-Info: ;index=1.1.2;rc=1.1 473 | | | 200 | | 474 | | |<---------------| | 475 | History-Info: ;index=1 476 | History-Info: ;np=1;index=1.1 477 | History-Info: ;index=1.1.1;rc=1.1 478 | | | | | 479 | | 200 | | | 480 | |<---------------| | | 481 | History-Info: ;index=1 482 | History-Info: ;np=1;index=1.1 483 | History-Info: ;index=1.1.1;rc=1.1 484 | | | | | 485 | | | Proxy Cancels INVITE | 486 | | |<=========================>| 487 | | | | | 488 | 200 | | | | 489 |<---------------| | | | 490 | History-Info: ;index=1 491 | History-Info: ;np=1;index=1.1 492 | History-Info: ;index=1.1.1;rc=1.1 493 | | | | | 494 | ACK | | | | 495 |--------------->| ACK | | | 496 | |--------------->| ACK | | 497 | | |--------------->| | 498 Figure 1: Basic Call 500 6. User Agent Handling of the History-Info Header Field 502 A B2BUA MAY follow the behavior of a SIP intermediary as an 503 alternative to following the behavior of a UAS per Section 6.2 and a 504 UAC per Section 6.1. In behaving as an intermediary, a B2BUA carries 505 forward hi-entries received in requests at the UAS to requests being 506 forwarded by the UAC, as well as carrying forward hi-entries in 507 responses received at the UAC to the responses forwarded by the UAS, 508 subject to privacy considerations per Section 10.1. 510 6.1. User Agent Client (UAC) Behavior 512 The UAC MUST include the "histinfo" option tag in the Supported 513 header field in any out-of-dialog requests or initial requests for a 514 dialog for which the UAC would like the History-Info header field in 515 the response. When issuing a request, the UAC MUST follow the 516 procedures in Section 9.2. In the case of an initial request, except 517 where the UAC is part of a B2BUA, there is no cache of hi- entries 518 with which to populate the History-Info header field and the hi-index 519 is set to 1 per Section 10.3. When receiving a response the UAC MUST 520 follow the procedures in Section 9.3. 522 If the UAC generates further forks of the initial request (either due 523 to acting on a 3xx response or internally-directed forking to 524 multiple destinations), the successive requests will add hi-entries 525 with hi-indexes of 2, 3, etc. 527 6.2. User Agent Server (UAS) Behavior 529 When receiving a request, a UAS MUST follow the procedures defined in 530 Section 9.1. When sending a response other than a 3xx response, a 531 UAS MUST follows the procedures in Section 9.4. When sending a 3xx 532 response, the UAS MUST follow the procedures defined for a redirect 533 server per Section 8. An application at the UAS can make use of the 534 cached hi-entries as described in Section 11. 536 7. Proxy/Intermediary Handling of History-Info Header Fields 538 This section describes the procedures for proxies and other SIP 539 intermediaries for the handling of the History-Info header fields for 540 each of the following scenarios: 542 Receiving a Request: An intermediary MUST follow the procedures in 543 Section 9.1 for the handling of hi-entries in incoming SIP 544 requests. 546 Sending a Request: For each outgoing request relating to a target in 547 the target set, the intermediary MUST follow the procedures of 548 Section 9.2. 550 Receiving a Response or Timeout: An intermediary MUST follow the 551 procedures of Section 9.3 when a SIP response is received or a 552 request times out. 554 Sending a Response: An intermediary MUST follow the procedures of 555 Section 9.4 for the handling of the hi-entries when sending a SIP 556 response. 558 In some cases, an intermediary may retarget a request more than once 559 before forwarding - i.e., a request is retargeted to a SIP entity 560 that is "internal" to the intermediary before the same intermediary 561 retargets the request to an external target . A typical example 562 would be a proxy that retargets a request first to a different user 563 (i.e., it maps to a different AOR) and then forwards to a registered 564 contact bound to the same AOR. In this case, the intermediary MUST 565 add a hi-entry for (each of) the internal target(s) per the 566 procedures in Section 9.2. The intermediary MAY include a Reason 567 header field in the hi-entry with the hi-targeted-to-uri that has 568 been retargeted as shown in the INVITE (F6) in the example in 569 Appendix B.3. 571 8. Redirect Server Handling of History-Info Header Fields 573 A redirect server MUST follow the procedures in Section 9.1 when it 574 receives a SIP Request. A redirect server MUST follow the procedures 575 in Section 9.4 when it sends a SIP Response. When generating the 576 Contact header field in a 3xx response, the redirect server MUST add 577 the appropriate "mp", "np" or "rc" header field parameter to each 578 Contact header field as described in Section 10.4, if applicable. 580 9. Handling of History-Info Header Fields in Requests and Responses 582 This section describes the procedures for SIP entities for the 583 handling of the History-Info header field in SIP requests and 584 responses. 586 9.1. Receiving a Request 588 When receiving a request, a SIP entity MUST create a cache containing 589 the hi-entries associated with the request. The hi-entries MUST be 590 added to the cache in the order in which they were received in the 591 request. 593 If the Request-URI of the incoming request does not match the hi- 594 targeted-to-uri in the last hi-entry (i.e., the previous SIP entity 595 that sent the request did not include a History-Info header field), 596 the SIP entity MUST add a hi-entry to end of the cache, on behalf of 597 the previous SIP entity, as follows: 599 The SIP entity MUST set the hi-targeted-to-uri to the value of the 600 Request-URI in the incoming request. If the Request-URI is a Tel- 601 URI, it SHOULD be transformed into a SIP URI per section 19.1.6 of 602 [RFC3261] before being added as a hi-targted-to-uri. 604 If privacy is required, the SIP entity MUST follow the procedures 605 of Section 10.1. 607 The SIP entity MUST set the hi-index parameter as described in 608 Section 10.3. 610 The SIP entity MUST NOT include an "rc", "mp" or "np" header field 611 parameter. 613 9.2. Sending a Request with History-Info 615 When sending a request, a SIP entity MUST include all cached hi- 616 entries in the request. In addition, the SIP entity MUST add a new 617 hi-entry to the outgoing request, but the SIP entity MUST NOT add the 618 hi-entry to the cache at this time. The hi-entries in the outgoing 619 request's History-Info header field is the preorder of the tree of 620 hi-entries, that is, by the lexicographic ordering of the hi-indexes. 621 The new hi-entry is populated as follows: 623 hi-targeted-to-uri: The hi-targeted-to-uri MUST be set to the value 624 of the Request-URI of the current (outgoing) request. 626 privacy: If privacy is required, the procedures of Section 10.1 MUST 627 be followed. 629 hi-index: The SIP entity MUST include an hi-index for the hi-entry 630 as described in Section 10.3. 632 rc/mp/np: The SIP entity MUST include an "rc", "mp" or "np" header 633 field parameter in the hi-entry, if applicable, per the procedures 634 in Section 10.4. 636 9.3. Receiving a Response with History-Info or Request Timeouts 638 When a SIP entity receives a non-100 response or a request times out, 639 the SIP entity performs the following steps: 641 Step 1: Add hi-entry to cache 643 The SIP entity MUST add the hi-entry that was added to the request 644 that received the non-100 response or timed out to the cache, if 645 it was not already cached. The hi-entry MUST be added to the 646 cache in ascending order as indicated by the values in the hi- 647 index parameters of the hi-entries (e.g., 1.2.1 comes after 1.2 648 but before 1.2.2 or 1.3). 650 Step 2: Add Reason header field 652 The SIP entity adds one or more Reason header fields to the hi- 653 targeted-to-uri in the (newly) cached hi-entry reflecting the SIP 654 response code in the non-100 response, per the procedures of 655 Section 10.2. 657 Step 3: Add additional hi-entries 659 The SIP entity MUST also add to the cache any hi-entries received 660 in the response that are not already in the cache. This situation 661 can occur when the entity that generated the non-100 response 662 retargeted the request before generating the response. As per 663 Step 1, the hi-entries MUST be added to the cache in ascending 664 order as indicated by the values in the hi-index parameters of the 665 hi-entries 667 It is important to note that the cache does not contain hi-entries 668 for requests that have not yet received a non-100 response, so there 669 can be gaps in indices (e.g., 1.2 and 1.4 could but present but not 670 1.3). 672 9.4. Sending History-Info in Responses 674 When sending a response other than a 100, a SIP entity MUST include 675 all the cached hi-entries in the response, subject to the privacy 676 consideration in Section 10.1.2, and with the following exception: If 677 the received request contained no hi-entries and there is no 678 "histinfo" option tag in the Supported header field, the SIP entity 679 MUST NOT include History-Info in the response. 681 10. Processing the History-Info Header Field 683 The following sections describe the procedures for processing the 684 History-Info header field. These procedures are applicable to SIP 685 entities such as Proxies/Intermediaries, Redirect Servers or User 686 Agents. 688 10.1. Privacy in the History-Info Header Field 690 The privacy requirements for this document are described in 691 Appendix A.2. Section 10.1.1 describes the insertion of the Privacy 692 header field defined in [RFC3323] to indicate the privacy to be 693 applied to the History-Info header field entries. Section 10.1.2 694 describes how to apply privacy to a request or response that is being 695 forwarded, based on the presence of the Privacy header field. 697 10.1.1. Indicating Privacy 699 As with other SIP headers described in [RFC3323], the hi-targeted-to- 700 uris in the History-Info header field can inadvertently reveal 701 information about the initiator of the request. Thus, the UAC needs 702 a mechanism to indicate that the hi-targeted-to-uris in the hi- 703 entries need to be privacy protected. The Privacy header field is 704 used by the UAC to indicate that privacy is to be applied to all the 705 hi-entries in the request as follows: 707 o If the UAC is including a Privacy header field with a priv-value 708 of "header" in the request, then the UAC SHOULD NOT include a 709 priv-value of "history" in the Privacy header field in the 710 Request. 712 o If the UAC is including any priv-values other than "header" in the 713 Privacy header field, then the UAC MUST also include a priv-value 714 of "history" in the Privacy header field in the Request. 716 o If the UAC is not including any priv-values in the Privacy header 717 field in the request, then the UAC MUST add a Privacy header 718 field, with a priv-value of "history", to the request. The UAC 719 MUST NOT include a priv-value of "critical" in the Privacy header 720 field in the Request in this case. 722 In addition, the History-Info header field can reveal general routing 723 and diverting information within an intermediary, which the 724 intermediary wants to privacy protect. In this case, the 725 intermediary MUST construct a Privacy header field with the single 726 priv-value of "history" and include the Privacy header field in the 727 hi-targeted-to-uri, for each new hi-entry created by the intermediary 728 whose hi-targeted-to-uri it wishes to privacy protect. Note that the 729 priv-value in the Privacy header for the incoming request does not 730 necessarily influence whether the intermediary includes a Privacy 731 header field in the hi-entries. For example, even if the Privacy 732 header for the incoming request contained a priv-value of "none", the 733 Proxy can still set a priv-value of "history" in the Privacy header 734 field included in the hi-targeted-to-uri. 736 Finally, the UAS may not want to reveal the final reached target to 737 the originator. In this case, the UAS MUST include a Privacy header 738 field with a priv-value of "history" in the hi-targeted-to-uri in the 739 last hi-entry, in the response. As noted above, the UAS of the 740 request MUST NOT use any other priv-values in the Privacy header 741 field included in the hi-entry. 743 10.1.2. Applying Privacy 745 When a SIP message is forwarded to a domain for which the SIP 746 intermediary is not responsible, a Privacy Service at the boundary of 747 the domain applies the appropriate privacy based on the value of the 748 Privacy header field in the message header or in the "headers" 749 component of the hi-targeted-to-uri in the individual hi-entries. 751 If there is a Privacy header field in the message header of a request 752 or response, with a priv-value of "header" or "history", then all the 753 hi-targeted-to-uris in the hi-entries, associated with the domain for 754 which the SIP intermediary is responsible, are anonymized by the 755 Privacy Service. The Privacy Service MUST change any hi-targeted-to- 756 uris in these hi-entries that have not been anonymized(evidenced by 757 their domain not being "anonymous.invalid") to anonymous URIs 758 containing a domain of anonymous.invalid (e.g., 759 anonymous@anonymous.invalid). If there is a Privacy header field in 760 the "headers" component of the hi-targeted-to-uri in the hi-entries, 761 then the Privacy header field value MUST be removed from the hi- 762 entry. Once all the appropriate hi-entries have been anonymized, the 763 Privacy Service MUST remove the priv-value of "history" from the 764 Privacy header field in the message header of the request or 765 response. If there are no remaining priv-values in the Privacy 766 header field, the Privacy Service MUST remove the Privacy header 767 field from the request or response per [RFC3323]. 769 If there is not a Privacy header field in the message header of the 770 request or response that is being forwarded, but there is a Privacy 771 header field with a priv-value of "history" in the "headers" 772 component in any of the hi-targeted-uris in the hi-entries associated 773 with the domain for which a SIP intermediary is responsible, then the 774 Privacy Service MUST update those hi-targeted-to-uris as described 775 above. Any other priv-values in the Privacy header field in the 776 "headers" component of the hi-targeted-to-uris in the hi-entries MUST 777 be ignored. In any case, the Privacy Service MUST remove the Privacy 778 header field from the "headers" compenent of the hi-targeted-to-uris 779 in the hi-entries prior to forwarding. 781 10.2. Reason in the History-Info Header Field 783 A Reason header field is added to the "headers" component in an hi- 784 targeted-to-uri when the hi-entry is added to the cache based upon 785 the receipt of a non-100 or non-2xx SIP response, as described in 786 Section 9.3. If the Reason header field is being added due to 787 receipt of an explicit SIP response and the response contains any 788 Reason header fields (see [RFC3326]), then the SIP entity MUST 789 include the Reason header fields in the "headers" component of the 790 hi-targeted-to-uri in the last hi-entry added to the cache, unless 791 the hi-targeted-to-uri is a Tel-URI. If the SIP response does not 792 contain a Reason header field, the SIP entity MUST include a Reason 793 header field, containing the SIP Response Code, in the "headers" 794 component of the hi-targeted-to-uri in the last hi-entry added to the 795 cache, unless the hi-targeted-to-uri is a Tel-URI. 797 If a request has timed out (instead of being explicitly rejected), 798 the SIP entity MUST update the cache as if the request received a SIP 799 error response code of 408 "Request Timeout". 801 A request can receive multiple non-100 non-2xx responses which carry 802 or imply (for responses without Reason headers, and for timeouts) 803 multiple, possibly duplicated, reason-values to be applied to an hi- 804 targeted-to-uri. In these situations, the SIP entity creating 805 History-Info header value would choose the appropriate Reason header 806 field value. 808 A SIP entity MAY also include a Reason header field in the "headers" 809 component of an hi-targeted-to-uri containing the URI of a request 810 that was retargeted as a result of internal retargeting. 812 If additional Reason header field parameters are defined in the 813 future per [RFC3326], the use of these Reason header field parameters 814 for the History-Info header field MUST follow the same rules as 815 described above. 817 10.3. Indexing in the History-Info Header Field 819 In order to maintain ordering and accurately reflect the retargeting 820 of the request, the SIP entity MUST add a hi-index to each hi-entry. 821 Per the syntax in Section 5, the hi-index consists of a series of 822 nonnegative integer separated by dots (e.g., 1.1.2). Each dot 823 reflects a SIP forwarding hop. The nonnegative integer following 824 each dot reflects the order in which a request was retargeted at the 825 hop. The highest nonnegative integer at each hop reflects the number 826 of entities to which the request has been retargeted at the specific 827 hop (i.e., the number of branches) at the time that the request 828 represented by this hi-entry was generated. Thus, the indexing 829 results in a logical tree representation for the history of the 830 request and the hi-entries are given in the preorder of the tree. 832 The first index in a series of History-Info entries MUST be set to 1. 833 In the case that a SIP entity (intermediary or UAS) adds a first hi- 834 entry on behalf of the previous hop, the hi-index MUST be set to 1. 835 For each forward hop (i.e., each new level of indexing), the last 836 integers of the hi-indexes of the new requests MUST be generated 837 starting at 1 and incrementing by 1 for each additional request" 839 The basic rules for adding the hi-index are summarized as follows: 841 1. Forwarding a request without changing the target: In the case of 842 a request that is being forwarded without changing the target, 843 the hi-index reflects the increasing length of the branch. In 844 this case, the SIP entity MUST read the value from the History- 845 Info header field in the received request and MUST add another 846 level of indexing by appending the dot delimiter followed by an 847 initial value of 1 for the new level. For example, if the hi- 848 index in the last History-Info header field in the received 849 request is 1.1, a proxy would add a hi-entry with an hi-index of 850 1.1.1 and forward the request. 852 2. Retargeting within a processing entity - 1st instance: For the 853 first instance of retargeting within a processing entity, the SIP 854 entity MUST calculate the hi-index as prescribed for basic 855 forwarding. 857 3. Retargeting within a processing entity - subsequent instance: For 858 each subsequent retargeting of a request by the same SIP entity, 859 the SIP entity MUST calculate and add the hi-index for each new 860 branch by incrementing the rightmost value from the hi-index in 861 the last hi-entry. Per the example above, the hi-index in the 862 next request forwarded by this same SIP entity would be 1.1.2. 864 4. Retargeting based upon a Response: In the case of retargeting due 865 to a specific response (e.g., 302), the SIP entity MUST calculate 866 the hi-index calculated per rule 3. That is, the rightmost value 867 of the hi-index MUST be incremented (i.e., a new branch is 868 created). For example, if the hi-index in the History-Info 869 header field of the sent request is 1.2 and the response to the 870 request is a 302, then the hi-index in the History-Info header 871 field for the new hi-targeted-to-URI would be 1.3. 873 5. Forking requests: If the request forwarding is done in multiple 874 forks (sequentially or in parallel), the SIP entity MUST set the 875 hi-index for each hi-entry for each forked request per the rules 876 above, with each new request having a unique index. Each index 877 MUST be sequentially assigned. For example, if the index in the 878 last History-Info header field in the received request is 1.1, 879 this processing entity would initialize its index to 1.1.1 for 880 the first fork, 1.1.2 for the second, and so forth (see Figure 1 881 for an example). Note, that in the case of parallel forking, 882 only the hi-entry corresponding to the fork is included in the 883 request because no response can yet have been received for any of 884 the parallel forked requests. 886 6. Missing entity: If the request clearly has a gap in the hi-entry, 887 the entity adding an hi-entry MUST add an index a nonnegative 888 integer of "0" to the current index prior to adding appropriate 889 index for the action to be taken. If the index of the last hi- 890 entry in the request received was 1.1.2 and there was a missing 891 hi-entry and the request was being forwarded to the next hop, the 892 resulting index will be 1.1.2.0.1. 894 10.4. Mechanism for Target Determination in the History-Info Header 895 Field 897 This specification defines two header field parameters, "rc", "mp" 898 and "np", indicating two mechanisms by which a new target for a 899 request is determined. Both parameters contain an index whose value 900 is the hi-index of the hi-entry with an hi-targeted-to-uri that 901 represents the Request-URI that was retargeted. 903 The SIP entity MUST determine the specific parameter field to be 904 included in the hi-target-param, in the History-Info header field, as 905 the targets are added to the target set per the procedures in section 906 16.5 of [RFC3261] or per section 8.1.3.4 [RFC3261] in the case of 907 retargeting to a contact URI received in a 3xx response. In the 908 latter case, the specific header field parameter in the Contact 909 header field becomes the header field parameter that is used in the 910 hi-entry when the request is retargeted. If the Contact header field 911 does not contain an "rc", "mp" or "np" header field parameter, then 912 the SIP entity MUST NOT include an "rc", "mp" or "np" header field 913 parameter in the hi-target-param in the hi-entry when the request is 914 retargeted to a contact URI received in a 3xx response.. 916 The SIP entity (intermediary or redirect server) determines the 917 specific header field parameter ("rc", "mp" or "np") to be used based 918 on the following criteria: 920 o "rc": The Request-URI has changed while retaining the target user 921 associated with the original Request-URI prior to retargeting. 923 o "mp": The target was determined based on a mapping to a user other 924 than the target user associated with the Request-URI being 925 retargeted. 927 o "np": The target hasn't changed and associated Request-URI 928 remained the same. 930 Note that there are two scenarios by which the "mp" header field 931 parameter can be derived. 933 o The mapping was done by the receiving entity on its own authority, 934 in which case the mp-value is the parent index of the hi-entry's 935 index. 937 o The mapping was done due to receiving a 3xx response, in which 938 case the mp-value is an earlier sibling or descendant of an 939 earlier sibling of the hi-entry's index, that of the downstream 940 request which received the 3xx response. 942 11. Application Considerations 944 History-Info provides a very flexible building block that can be used 945 by intermediaries and UAs for a variety of services. Prior to any 946 application usage of the History-Info header field parameters, the 947 SIP entity that processes the hi-entries MUST evaluate the hi- 948 entries. The SIP entity MUST be prepared to process effectively 949 messages whose hi-entries show evidence of "gaps", that is, 950 situations that reveal that not all of the forks of the request have 951 been recorded in the hi-entries. Gaps are possible if the request is 952 forwarded through intermediaries that do not support the History-Info 953 header field and are reflected by the existence of hi-entries with a 954 nonnegative integer of "0" e.g. "1.1.0.1". Gaps are also possible in 955 the case of parallel forking if there is an outstanding request at 956 the time the SIP entity sends a message. Thus, if gaps are detected, 957 the SIP entity MUST NOT treat this as an error, but SHOULD indicate 958 to any applications that there are gaps. The interpretation of the 959 information in the History-Info header field depends upon the 960 specific application; an application might need to provide special 961 handling in some cases where there are gaps. 963 The following describes some categories of information that 964 applications can use: 966 1. Complete history information - e.g., for debug or other 967 operational and management aspects, optimization of determining 968 targets to avoid retargeting to the same URI, etc. This 969 information is relevant to proxies, UACs and UASs. 971 2. Hi-entry with the index that matches the value of the "rc" header 972 field parameter in the last hi-entry with a "rc" header field 973 parameter in the Request received by a UAS - i.e., the last AOR 974 that was retargeted to a contact based on an AOR-to-contact 975 binding. 977 3. Hi-entry with the index that matches the value of the "mp" header 978 field parameter in the last hi-entry with a "mp" header field 979 parameter in the hi-target-param in the Request received by a UAS 980 - i.e., the last Request URI that was mapped to reach the 981 destination. 983 4. Hi-entry with the index that matches the value of the "rc" header 984 field parameter in the first hi-entry with a "rc" header field 985 parameter in the Request received by a UAS. Note, this would be 986 the original AoR if all the entities involved support the 987 History-Info header field and there is absence of an "mp" header 988 field parameter prior to the "rc" header field parameter in the 989 hi-target-param in the History-Info header field. However, there 990 is no guarantee that all entities will support History-Info, thus 991 the hi-entry that matches the value of the "rc" header field 992 parameter of the first hi-entry with an "rc" header field 993 parameter in the hi-target-param within the domain associated 994 with the target URI at the destination is more likely to be 995 useful. 997 5. Hi-entry with the index that matches the value of "mp" header 998 field parameter in the first hi-entry with an "mp" header field 999 parameter in the Request received by a UAS. Note, this would be 1000 the original mapped URI if all entities supported the History- 1001 Info header field. However, there is no guarantee that all 1002 entities will support History-Info, thus the hi-entry that 1003 matches the value of the "mp" header field parameter of the first 1004 hi-entry with an "mp" header field parameter within the domain 1005 associated with the target URI at the destination is more likely 1006 to be useful. 1008 In many cases, applications are most interested in the information 1009 within a particular domain(s), thus only a subset of the information 1010 is required. 1012 Some applications may use multiple types of information. For 1013 example, an Automatic Call Distribution (ACD)/Call center application 1014 that utilizes the hi-entry which index matches the value of the "mp" 1015 header field parameter of the first hi-entry with an "mp" header 1016 field parameter, may also display other agents, reflected by other 1017 hi-entries prior to entries with hi-target value of "rc" header field 1018 parameter, to whom the call was targeted prior to its arrival at the 1019 current agent. This could allow the agent the ability to decide how 1020 they might forward or reroute the call if necessary (avoiding agents 1021 that were not previously available for whatever reason, etc.). 1023 Since support for History-Info header field is optional, a service 1024 MUST define default behavior for requests and responses not 1025 containing History-Info header fields. For example, an entity may 1026 receive an incomplete set of hi-entries or hi-entries which are not 1027 tagged appropriately with an hi-target-param. This may not impact 1028 some applications (e.g., debug), however, it could require some 1029 applications to make some default assumptions in this case. For 1030 example, in an ACD scenario, the application could select the oldest 1031 hi-entry with the domain associated with the ACD system and display 1032 that as the original called party. Depending upon how and where the 1033 request may have been retargeted, the complete list of agents to whom 1034 the call was targeted may not be available. 1036 12. Application Specific Usage 1038 Following are possible (non-normative) application-specific usages of 1039 History-Info. 1041 12.1. PBX Voicemail 1043 A voicemail system typically requires the original called party 1044 information to determine the appropriate mailbox so an appropriate 1045 greeting can be provided and the appropriate party notified of the 1046 message. 1048 The original target is determined by finding the first hi-entry 1049 tagged with "rc" and using the hi-entry referenced by the index of 1050 "rc" header field parameter as the target for determining the 1051 appropriate mailbox. This hi-entry is used to populate the "target" 1052 URI parameter as defined in [RFC4458] The VMS can look at the last 1053 hi-entry and find the target of the mailbox by looking at the URI 1054 entry in the "target" URI parameter in the hi-entry. For example 1055 call flow please refer to the Appendix B.1. 1057 This example usage does not work properly in the presence of 1058 forwarding that takes place before the call reaches the company in 1059 that case not the first hi-entry with an rc value, but the first hi- 1060 entry with an rc value following an mp entry needs to be picked. 1062 12.2. Consumer Voicemail 1064 The voicemail system in these environment typically requires the last 1065 called party information to determine the appropriate mailbox so an 1066 appropriate greeting can be provided and the appropriate party 1067 notified of the message. 1069 The last target is determined by finding the hi-entry referenced by 1070 the index of last hi-entry tagged with "rc" for determining the 1071 appropriate mailbox. This hi-entry is used to populate the "target" 1072 URI parameter as defined in [RFC4458]. The VMS can look at the last 1073 hi-entry and find the target of the mailbox by looking for the 1074 "target" URI parameter in the hi-entry. For example call flow please 1075 refer to the Appendix B.2. 1077 13. Security Considerations 1079 The security requirements for this specification are specified in 1080 Appendix A.1. 1082 This document defines a header field for SIP. The use of the 1083 Transport Layer Security (TLS) protocol [RFC5246] as a mechanism to 1084 ensure the overall confidentiality of the History-Info header fields 1085 (SEC-req-4) is strongly RECOMMENDED. This results in History-Info 1086 having at least the same level of security as other headers in SIP 1087 that are inserted by intermediaries. With TLS, History-Info header 1088 fields are no less, nor no more, secure than other SIP header fields, 1089 which generally have even more impact on the subsequent processing of 1090 SIP sessions than the History-Info header field. 1092 Note that while using the SIPS scheme (as per [RFC5630]) protects 1093 History-Info from tampering by arbitrary parties outside the SIP 1094 message path, all the intermediaries on the path are trusted 1095 implicitly. A malicious intermediary could arbitrarily delete, 1096 rewrite, or modify History-Info. This specification does not attempt 1097 to prevent or detect attacks by malicious intermediaries. 1099 In terms of ensuring the privacy of hi-entries, the same security 1100 considerations as those described in [RFC3323] apply. Namely if the 1101 entity requesting privacy wants to ensure privacy is applied to the 1102 hi-entries, a Privacy Service that supports both [RFC3323] and this 1103 specification is REQUIRED in the entity's domain, so that the privacy 1104 can be applied, as described in Section 10.1.2, when a request or 1105 response leaves the domain. 1107 14. IANA Considerations 1109 This document requires several IANA registrations detailed in the 1110 following sections. 1112 This document obsoletes [RFC4244] but uses the same SIP header field 1113 name and option tag. The IANA registry needs to update the 1114 references to [RFC4244] with [RFC XXXX]. 1116 14.1. Registration of New SIP History-Info Header Field 1118 This document defines a SIP header field name: History-Info and an 1119 option tag: histinfo. The following changes have been made to 1120 http:///www.iana.org/assignments/sip-parameters The following row has 1121 been added to the header field section:. 1123 The following row has been added to the header field section: 1125 Header Name Compact Form Reference 1126 ----------- ------------ --------- 1127 History-Info none [RFC XXXX] 1129 The following has been added to the Options Tags section: 1131 Name Description Reference 1132 ---- ----------- --------- 1133 histinfo When used with the Supported header field, [RFC XXXX] 1134 this option tag indicates the UAC 1135 supports the History Information to be 1136 captured for requests and returned in 1137 subsequent responses. This tag is not 1138 used in a Proxy-Require or Require 1139 header field since support of 1140 History-Info is optional. 1142 Note to RFC Editor: Please replace RFC XXXX with the RFC number of 1143 this specification. 1145 14.2. Registration of "history" for SIP Privacy Header Field 1147 This document defines a priv-value for the SIP Privacy header field: 1148 history The following changes have been made to 1149 http://www.iana.org/assignments/sip-priv-values The following has 1150 been added to the registration for the SIP Privacy header field: 1152 Name Description Registrant Reference 1153 ---- ----------- ---------- --------- 1154 history Privacy requested for Mary Barnes [RFC XXXX] 1155 History-Info header mary.barnes@polycom.com 1156 fields(s) 1158 Note to RFC Editor: Please replace RFC XXXX with the RFC number of 1159 this specification. 1161 14.3. Registration of Header Field Parameters 1163 This specification defines the following new SIP header field 1164 parameters in the SIP Header Field parameter sub-registry in the SIP 1165 Parameter Registry, http:/www.iana.org/assignments/sip-parameters. 1167 Header Field Parameter Name Predefined Reference 1168 Values 1169 _____________________________________________________________________ 1170 History-Info mp No [RFC xxxx] 1171 History-Info rc No [RFC xxxx] 1172 History-Info np No [RFC xxxx] 1173 Contact mp No [RFC xxxx] 1174 Contact rc No [RFC xxxx] 1175 Contact np No [RFC xxxx] 1177 Note to RFC Editor: Please replace RFC XXXX with the RFC number of 1178 this specification. 1180 15. Acknowledgements 1182 Jonathan Rosenberg et al produced the document that provided 1183 additional use cases precipitating the requirement for the new header 1184 parameters to capture the method by which a Request URI is 1185 determined. The authors would like to acknowledge the constructive 1186 feedback provided by Ian Elz, Paul Kyzivat, John Elwell, Hadriel 1187 Kaplan and Dale Worley. John Elwell provided excellent suggestions 1188 in terms of document structure. 1190 Mark Watson, Cullen Jennings and Jon Peterson provided significant 1191 input into the initial work that resulted in the development of of 1192 [RFC4244]. The editor would like to acknowledge the constructive 1193 feedback provided by Robert Sparks, Paul Kyzivat, Scott Orton, John 1194 Elwell, Nir Chen, Palash Jain, Brian Stucker, Norma Ng, Anthony 1195 Brown, Jayshree Bharatia, Jonathan Rosenberg, Eric Burger, Martin 1196 Dolly, Roland Jesske, Takuya Sawada, Sebastien Prouvost, and 1197 Sebastien Garcin in the development of [RFC4244]. 1199 The editor would like to acknowledge the significant input from Rohan 1200 Mahy on some of the normative aspects of the ABNF for [RFC4244], 1201 particularly around the need for and format of the index and around 1202 the security aspects. 1204 16. Changes from RFC 4244 1206 This RFC replaces [RFC4244]. 1208 Deployment experience with [RFC4244] over the years has shown a 1209 number of issues, warranting an update: 1211 o In order to make [RFC4244] work in "real life", one needs to make 1212 "assumptions" on how History-Info is used. For example, many 1213 implementations filter out many entries, and only leave specific 1214 entries corresponding, for example, to first and last redirection. 1215 Since vendors uses different rules, it causes significant 1216 interoperability issues. 1218 o [RFC4244] is overly permissive and evasive about recording 1219 entries, causing interoperability issues. 1221 o The examples in the call flows had errors, and confusing because 1222 they often assume "loose routing". 1224 o [RFC4244] has lots of repetitive and unclear text due to the 1225 combination of requirements with solution. 1227 o [RFC4244] gratuitously mandates the use of TLS on every hop. No 1228 existing implementation enforces this rule, and instead, the use 1229 of TLS or not is a general SIP issue, not an [RFC4244] issue per 1230 se. 1232 o [RFC4244] does not include clear procedures on how to deliver 1233 current target URI information to the UAS when the Request-URI is 1234 replaced with a contact. 1236 o [RFC4244] does not allow for marking History-Info entries for easy 1237 processing by User Agents. 1239 The following summarizes the functional changes between this 1240 specification and [RFC4244]: 1242 1. Added header field parameters to capture the specific method by 1243 which a target is determined to facilitate processing by users of 1244 the History-Info header field entries. A specific header field 1245 parameter is captured for each of the target URIs as the target 1246 set is determined (per section 16.5 of [RFC3261]). The header 1247 field parameter is used in both the History-Info and the Contact 1248 header fields. 1250 2. Rather than recommending that entries be removed in the case of 1251 certain values of the Privacy header field, the entries are 1252 anonymized. 1254 3. Updated the security section to be equivalent to the security 1255 recommendations for other SIP header fields inserted by 1256 intermediaries. 1258 The first 2 changes are intended to facilitate application usage of 1259 the History-Info header field and eliminate the need to make 1260 assumptions based upon the order of the entries and ensure that the 1261 most complete set of information is available to the applications. 1263 In addition, editorial changes were done to both condense and clarify 1264 the text, moving the requirements to an appendix and removing the 1265 inline references to the requirements. The examples were simplified 1266 and updated to reflect the protocol changes. Several of the call 1267 flows in the appendix were removed and put into a separate document 1268 that includes additional use cases that require the new header field 1269 parameters. 1271 16.1. Backwards compatibility 1273 This specification is backwards compatible since [RFC4244] allows for 1274 the addition of new optional parameters. This specification adds an 1275 optional SIP header field parameter to the History-Info and Contact 1276 header fields. Entities that have not implemented this specification 1277 will ignore these parameters, however, per [RFC4244] an entity will 1278 not remove this parameter from an hi-entry. 1280 As for the behavior of the entity followings have changed since the 1281 [RFC4244]. 1283 UAC behavior 1285 1. Inclusion of option tag by UAC has changed from SHOULD to MUST. 1287 2. Inclusion of hi-target-entry along with hi-index has changed from 1288 MAY/RECOMMEND to MUST/MUST. 1290 3. Behavior surrounding the addition of hi-target-entry based on 3xx 1291 response has changed from MAY/SHOULD to MUST. 1293 None of the behavior changes would cause any backward compatibility 1294 issues. 1296 UAS behavior 1298 1. Inclusion of hi-entry in response has changed from SHOULD to 1299 MUST. 1301 As the entity receiving response with hi-entry expected it with 1302 SHOULD, this change will not cause any backward compatibility issues. 1304 Proxy/Redirect Server behavior 1306 1. Inclusion of H-I as forwarding the request has changed from 1307 SHOULD to MUST. 1309 2. Association of Reason with time-out/internal reason has changed 1310 from MAY to MUST. 1312 3. Inclusion of hi-index has changed from RECOMMENDED to MUST. 1314 4. Inclusion of hi-entries in response has changed from SHOULD to 1315 MUST. 1317 None of the behavior changes will cause any backward compatibility 1318 issues as entity interacting with the updated code, expects the 1319 values set by the revised behavior anyway. 1321 17. Changes since last Version 1323 NOTE TO THE RFC-Editor: Please remove this section prior to 1324 publication as an RFC. 1326 Changes from 04 to 05: 1328 1. Lots of editorial corrections/clarifications per John Elwell's 1329 comment. 1331 2. Updated Reason header section 10.2 to be consistent (i.e., 1332 removed references to retargeting) with section 9.3 (Receiving a 1333 response) where the hi-entries and reason header are added to the 1334 cache. 1336 3. Updated section 9.3 (receiving responses) to also include 1337 timeouts and updated to reflect that we don't add the Reason 1338 header in the case of 2xx responses. 1340 4. Added text in Security considerations with regards to needing a 1341 Privacy Service per RFC 3323 to ensure that the privacy is 1342 applied. 1344 Changes from 03 to 04: 1346 1. Reorganization of sections per John Elwell's comments - i.e., a 1347 common section for building HI referenced by the UA, Intermediary 1348 and Redirect server sections. 1350 2. Removing the use of "escape" when describing the handling of the 1351 Privacy and Reason header fields. 1353 3. Clarification of TEL URIs in terms of not having a Privacy or 1354 Reason header field in the hi-targeted-to-uri. 1356 Changes from 02 to 03: 1358 1. Lots of editorial: 1360 2. 1362 A. Reorganized sections similar to the RFC 4244 order - i.e., 1363 introduce header field parameters and syntax first, then 1364 describe how the functional entities use the header field. 1365 This removes redundant (and often inconsistent) text 1366 describing the parameters. 1368 B. Expanded use of "header" to "header field" 1370 C. More precision in terms of "escaping" of the Privacy and 1371 Reason headers in the hi-targeted-to-uri (versus 1372 "adding"/"setting"/etc. them to the hi-entry). 1374 D. Consistent use of parameter names (i.e., hi-entry versus 1375 entry, hi-target versus target, etc.) 1377 E. Moved item 6 in the Index section to the section on Response 1378 handling 1380 F. Removed last remaining vestiges of inline references to 1381 requirements. 1383 3. Clarifications of functionality/applicability including: 1385 4. 1387 A. which messages may contain History-Info 1389 B. removing security text with regards to being able to figure 1390 out if there are missing entries when using TLS (issue #44) 1392 C. More complete information on the new header field parameters 1393 as they relate to the hi-target parameter. 1395 D. Changed wording from passive to active for normative 1396 statements in many cases and removed superfluous normative 1397 language. 1399 5. Rewrite of the Privacy section to address issues and splitting 1400 into the setting of the Privacy header fields and the processing/ 1401 application of the privacy header field priv-values. 1403 6. Rewrite of the Reason header field section - simplifying the text 1404 and adding back the RFC 4244 text with regards to the use of the 1405 Reason header field in cases of internal retargeting. 1407 Changes from 01 to 02: 1409 1. Editorial nits/clarifications. [Issues: 1,6,17,18,21- 1410 23,25,26,30-33,35-37,39,40] 1412 2. Removing extraneous 4244 text - e.g., errors in flows, 1413 "stronger" security, "session" privacy. [Issues: 3,5,7,11 ] 1415 3. Updated definition of "retarget" to be all encompassing - i.e., 1416 also includes internal changes of target URI. Clarified text 1417 for "internal retargeting" in proxy section. [Issues: 2,8,9] 1419 4. Clarified that the processing for Proxies is equally applicable 1420 to other SIP intermediaries. [Issue: 9]. 1422 5. Changed more SHOULDs to MUSTs. [Issue: 10] 1424 6. Fixes to Application considerations section. [Issues: 12-15] 1426 7. Changed language in the procedure for Indexing to normative 1427 language. 1429 8. Clarifications for UAC processing: 1431 * MUST add hi-entry. [Issue: 28] 1433 * Clarify applicability to B2BUA. [Issue: 29] 1435 * Fixed text for indexing for UAC in case of 3xx. 1437 9. Changed "hit" URI parameter to header field parameters: [Issues: 1438 4,40] 1440 * Added index to all target header parameters. [Issues: 41] 1442 * Updated all the relevant sections documenting setting and use 1443 of new header parameters. [Issue: 40] 1445 10. Updated/clarified privacy handling. [Issue: 16] 1447 11. Updated Redirect Server section to allow adding History-Info 1448 header fields. [Issue: 24 ] 1450 12. Added text around restrictions for Tel-URIs - i.e., no privacy 1451 or reason. [Issues: 4, 12] 1453 13. Updated text for forking - what goes in response. [Issues: 1454 19,20] 1456 Changes from 00 to 01: 1458 1. Moved examples (except first) in appendix to a new 1459 (informational) document. 1461 2. Updated UAS and UAC sections to clarify and expand on the 1462 handling of the History-Info header field. 1464 3. Updated the Application considerations section: 1466 o Included more detail with regards to how applications can make use 1467 of the information, in particular based on the new tags. 1469 o Removed privacy consideration (2nd bullet) since privacy is now 1470 accomplished by anonymizing rather than removal of entries. 1472 Changes from (individual) barnes-sipcore-4244bis-03 to (WG) ietf- 1473 sipcore-4244bis-00: 1475 1. Added a new SIP/SIPS URI parameter to tag the URIs as they are 1476 added to the target list and those returned in the contact header 1477 in a 3xx response. 1479 2. Updated description of "target" parameter to use the new URI 1480 parameter value in setting the value for the parameter. 1482 3. Clarified privacy. 1484 4. Changed handling at redirect server to include the use of the new 1485 URI parameter and to remove the functionality of adding the 1486 History-Info entries (basically reverting to core 4244 1487 processing). 1489 5. Additional text to clarify that a service such as voicemail can 1490 be done in multiple ways. 1492 6. Editorial changes including removal of some vestiges of tagging 1493 all entries (including the "aor" tag). 1495 Changes from barnes-sipcore-4244bis-02 to 03: 1497 1. Fixed problem with indices in example in voicemail example. 1499 2. Removed oc and rt from the Hi-target parameter. 1501 3. Removed aor tag 1503 4. Added index parameter to "mp" 1505 5. Added use-cases and call-flows from target-uri into appendix. 1507 Changes from barnes-sipcore-4244bis-01 to 02: 1509 1. Added hi-aor parameter that gets marked on the "incoming" hi- 1510 entry. 1512 2. Hi-target parameter defined to be either rc, oc, mp, rt, and now 1513 gets included when adding an hi-entry. 1515 3. Added section on backwards compatibility, as well as added the 1516 recognition and handling of requests that do not support this 1517 specification in the appropriate sections. 1519 4. Updated redirect server/3xx handling to support the new 1520 parameters - i.e., the redirecting entity must add the new hi- 1521 entry since the proxy does not have access to the information as 1522 to how the Contact was determined. 1524 5. Added section on normative differences between this specification 1525 and RFC 4244. 1527 6. Restructuring of document to be more in line with current IETF 1528 practices. 1530 7. Moved Requirements section into an Appendix. 1532 8. Fixed ABNF to remove unintended ordering requirement on hi-index 1533 that was introduced in attempting to illustrate it was a 1534 mandatory parameter. 1536 Changes from barnes-sipcore-4244bis-00 to 01 : 1538 1. Clarified "retarget" definition. 1540 2. Removed privacy discussion from optionality section - just refer 1541 to privacy section. 1543 3. Removed extraneous text from target-parameter (leftover from sip- 1544 4244bis). Changed the terminology from the "reason" to the 1545 "mechanism" to avoid ambiguity with parameter. 1547 4. Various changes to clarify some of the text around privacy. 1549 5. Reverted proxy response handling text to previous form - just 1550 changing the privacy aspects to anonymize, rather than remove. 1552 6. Other editorial changes to condense and simplify. 1554 7. Moved Privacy examples to Appendix. 1556 8. Added forking to Basic call example. 1558 Changes from barnes-sipcore-4244bis-00 to 01 : 1560 1. Clarified "retarget" definition. 1562 2. Removed privacy discussion from optionality section - just refer 1563 to privacy section. 1565 3. Removed extraneous text from target-parameter (leftover from sip- 1566 4244bis). Changed the terminology from the "reason" to the 1567 "mechanism" to avoid ambiguity with parameter. 1569 4. Various changes to clarify some of the text around privacy. 1571 5. Reverted proxy response handling text to previous form - just 1572 changing the privacy aspects to anonymize, rather than remove. 1574 6. Other editorial changes to condense and simplify. 1576 7. Moved Privacy examples to Appendix. 1578 8. Added forking to Basic call example. 1580 Changes from barnes-sip-4244bis-00 to barnes-sipcore-4244bis-00: 1582 1. Added tags for each type of retargeting including proxy hops, 1583 etc. - i.e., a tag is defined for each specific mechanism by 1584 which the new Request-URI is determined. Note, this is 1585 extremely helpful in terms of backwards compatibility. 1587 2. Fixed all the examples. Made sure loose routing was used in all 1588 of them. 1590 3. Removed example where a proxy using strict routing is using 1591 History-Info for avoiding trying same route twice. 1593 4. Remove redundant Redirect Server example. 1595 5. Index is now mandated to start at "1" instead of recommended. 1597 6. Updated 3xx behavior as the entity sending the 3XX response MUST 1598 add the hi-target attribute to the previous hi-entry to ensure 1599 that it is appropriately tagged (i.e., it's the only one that 1600 knows how the contact in the 3xx was determined.) 1602 7. Removed lots of ambiguity by making many "MAYs" into "SHOULDs" 1603 and some "SHOULDs" into "MUSTs". 1605 8. Privacy is now recommended to be done by anonymizing entries as 1606 per RFC 3323 instead of by removing or omitting hi-entry(s). 1608 9. Requirement for TLS is now same level as per RFC 3261. 1610 10. Clarified behavior for "Privacy" (i.e., that Privacy is for Hi- 1611 entries, not headers). 1613 11. Removed "OPTIONALITY" as specific requirements, since it's 1614 rather superflous. 1616 12. Other editorial changes to remove redundant text/sections. 1618 Changes from RFC4244 to barnes-sip-4244bis-00: 1620 1. Clarified that HI captures both retargeting as well as cases of 1621 just forwarding a request. 1623 2. Added descriptions of the usage of the terms "retarget", 1624 "forward" and "redirect" to the terminology section. 1626 3. Added additional examples for the functionality provided by HI 1627 for core SIP. 1629 4. Added hi-target parameter values to HI header to ABNF and 1630 protocol description, as well as defining proxy, UAC and UAS 1631 behavior for the parameter. 1633 5. Simplified example call flow in section 4.5. Moved previous call 1634 flow to appendix. 1636 6. Fixed ABNF per RFC4244 errata "dot" -> "." and added new 1637 parameter. 1639 18. References 1641 18.1. Normative References 1643 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1644 A., Peterson, J., Sparks, R., Handley, M., and E. 1645 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1646 June 2002. 1648 [RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason 1649 Header Field for the Session Initiation Protocol (SIP)", 1650 RFC 3326, December 2002. 1652 [RFC3323] Peterson, J., "A Privacy Mechanism for the Session 1653 Initiation Protocol (SIP)", RFC 3323, November 2002. 1655 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1656 Requirement Levels", BCP 14, RFC 2119, March 1997. 1658 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1659 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1661 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1662 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1664 [RFC4244] Barnes, M., "An Extension to the Session Initiation 1665 Protocol (SIP) for Request History Information", RFC 4244, 1666 November 2005. 1668 18.2. Informative References 1670 [RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User 1671 Agent URIs (GRUUs) in the Session Initiation Protocol 1672 (SIP)", RFC 5627, October 2009. 1674 [RFC5630] Audet, F., "The Use of the SIPS URI Scheme in the Session 1675 Initiation Protocol (SIP)", RFC 5630, October 2009. 1677 [RFC3087] Campbell, B. and R. Sparks, "Control of Service Context 1678 using SIP Request-URI", RFC 3087, April 2001. 1680 [RFC4240] Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network 1681 Media Services with SIP", RFC 4240, December 2005. 1683 [RFC3969] Camarillo, G., "The Internet Assigned Number Authority 1684 (IANA) Uniform Resource Identifier (URI) Parameter 1685 Registry for the Session Initiation Protocol (SIP)", 1686 BCP 99, RFC 3969, December 2004. 1688 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", 1689 RFC 3966, December 2004. 1691 [RFC4458] Jennings, C., Audet, F., and J. Elwell, "Session 1692 Initiation Protocol (SIP) URIs for Applications such as 1693 Voicemail and Interactive Voice Response (IVR)", RFC 4458, 1694 April 2006. 1696 Appendix A. Request History Requirements 1698 The following list constitutes a set of requirements for a "Request 1699 History" capability. 1701 1. CAPABILITY-req: The "Request History" capability provides a 1702 capability to inform proxies and UAs involved in processing a 1703 request about the history/progress of that request. Although 1704 this is inherently provided when the retarget is in response to a 1705 SIP redirect, it is deemed useful for non-redirect retargeting 1706 scenarios, as well. 1708 2. GENERATION-req: "Request History" information is generated when 1709 the request is retargeted. 1711 A. In some scenarios, it might be possible for more than one 1712 instance of retargeting to occur within the same proxy. A 1713 proxy MUST also generate Request History information for the 1714 'internal retargeting'. 1716 B. An entity (UA or proxy) retargeting in response to a redirect 1717 or REFER MUST include any Request History information from 1718 the redirect/REFER in the new request. 1720 3. ISSUER-req: "Request History" information can be generated by a 1721 UA or proxy. It can be passed in both requests and responses. 1723 4. CONTENT-req: The "Request History" information for each 1724 occurrence of retargeting shall include the following: 1726 A. The new URI or address to which the request is in the process 1727 of being retargeted, 1729 B. The URI or address from which the request was retargeted, and 1730 whether the retarget URI was an AOR 1732 C. The mechanism by which the new URI or address was determined, 1734 D. The reason for the Request-URI or address modification, 1736 E. Chronological ordering of the Request History information. 1738 5. REQUEST-VALIDITY-req: Request History is applicable to requests 1739 not sent within an early or established dialog (e.g., INVITE, 1740 REGISTER, MESSAGE, and OPTIONS). 1742 6. BACKWARDS-req: Request History information may be passed from the 1743 generating entity backwards towards the UAC. This is needed to 1744 enable services that inform the calling party about the dialog 1745 establishment attempts. 1747 7. FORWARDS-req: Request History information may also be included by 1748 the generating entity in the request, if it is forwarded onwards. 1750 A.1. Security Requirements 1752 The Request History information is being inserted by a network 1753 element retargeting a Request, resulting in a slightly different 1754 problem than the basic SIP header problem, thus requiring specific 1755 consideration. It is recognized that these security requirements can 1756 be generalized to a basic requirement of being able to secure 1757 information that is inserted by proxies. 1759 The potential security problems include the following: 1761 1. A rogue application could insert a bogus Request History-Info 1762 entry either by adding an additional hi-entry as a result of 1763 retargeting or entering invalid information. 1765 2. A rogue application could re-arrange the Request History 1766 information to change the nature of the end application or to 1767 mislead the receiver of the information. 1769 3. A rogue application could delete some or all of the Request 1770 History information. 1772 Thus, a security solution for "Request History" must meet the 1773 following requirements: 1775 1. SEC-req-1: The entity receiving the Request History must be able 1776 to determine whether any of the previously added Request History 1777 content has been altered. 1779 2. SEC-req-2: The ordering of the Request History information must 1780 be preserved at each instance of retargeting. 1782 3. SEC-req-3: The entity receiving the information conveyed by the 1783 Request History must be able to authenticate the entity providing 1784 the request. 1786 4. SEC-req-4: To ensure the confidentiality of the Request History 1787 information, only entities that process the request SHOULD have 1788 visibility to the information. 1790 It should be noted that these security requirements apply to any 1791 entity making use of the Request History information. 1793 A.2. Privacy Requirements 1795 Since the Request-URI that is captured could inadvertently reveal 1796 information about the originator, there are general privacy 1797 requirements that MUST be met: 1799 1. PRIV-req-1: The entity retargeting the Request must ensure that 1800 it maintains the network-provided privacy (as described in 1801 [RFC3323]) associated with the Request as it is retargeted. 1803 2. PRIV-req-2: The entity receiving the Request History must 1804 maintain the privacy associated with the information. In 1805 addition, local policy at a proxy may identify privacy 1806 requirements associated with the Request-URI being captured in 1807 the Request History information. 1809 3. PRIV-req-3: Request History information subject to privacy shall 1810 not be included in out going messages unless it is protected as 1811 described in [RFC3323]. 1813 Appendix B. Example call flows 1815 The scenarios in this section provide sample use cases for the 1816 History-Info header field for informational purposes only. They are 1817 not intended to be normative. A basic forking use case is included, 1818 along with two use cases illustrating the use of the privacy. 1820 B.1. PBX Voicemail call flow 1822 In this example, Alice calls Bob, whose SIP client is forwarded to 1823 Carol. Carol does not answer the call, thus it is forwarded to a VM 1824 (voicemail) server (VMS). In order to determine the appropriate 1825 mailbox to use for this call, the VMS needs the original target for 1826 the request. The original target is determined by finding the first 1827 hi-entry tagged with "rc" and using the hi-entry referenced by the 1828 index of "rc" header field parameter as the target for determining 1829 the appropriate mailbox. This hi-entry is used to populate the 1830 "target" URI parameter as defined in [RFC4458]. The reason 1831 associated with the first hi-entry tagged with "rc" (i.e., 302) could 1832 be used to provide a customized voicemail greeting and is used to 1833 populate the "cause" URI parameter as defined in [RFC4458]. Note 1834 that some VMSs may also (or instead) use the information available in 1835 the History-Info headers for custom handling of the VM in terms of 1836 how and why the call arrived at the VMS. 1838 Furthermore it is the proxy forwarding the call to VMS that 1839 determines the target of the voicemail, it is the proxy that sets the 1840 target of voicemail which is also the entity that utilizes RFC4244bis 1841 to find the target which is usually based on local policy installed 1842 by the user or an administrator. 1844 Alice example.com Bob Carol VM 1846 | INVITE F1 | | | | 1847 |------------->| | | | 1848 | | INVITE F2 | | | 1849 | |------------->| | | 1850 | | | | | 1851 | 100 Trying | | | | 1852 |<-------------| 302 Moved Temporarily F3 | | 1853 | |<-------------| | | 1854 | | ACK | | | 1855 | |------------->| | | 1856 | | | | | 1857 | | INVITE F4 | | | 1858 | |--------------------------->| | 1859 | | | | | 1860 | | 180 Ringing F5 | | 1861 | |<---------------------------| | 1862 | | | | | 1863 | 180 Ringing | | | | 1864 |<-------------| | | | 1865 | | | | | 1866 | | (timeout) | | 1867 | | | | | 1868 | | INVITE F6 | | | 1869 | |-------------------------------------->| 1870 | | | | | 1871 | | 200 OK F7 | 1872 | |<--------------------------------------| 1873 | 200 OK | | | | 1874 |<-------------| | | | 1875 | | | | | 1876 | ACK | | | | 1877 |------------->| ACK | 1878 | |-------------------------------------->| 1880 F1 INVITE Alice -> Example.com 1882 INVITE sip:bob@example.com 1883 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 1884 From: Alice ;tag=kkaz- 1885 To: Bob 1886 Supported: histinfo 1887 Call-Id: 12345600@example.com 1888 CSeq: 1 INVITE 1889 Contact: Alice 1890 Content-Length: 1892 [SDP Not Shown] 1894 F2 INVITE Example.com -> Bob 1896 INVITE sip:bob@192.0.2.5 SIP/2.0 1897 Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bK12se 1898 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 1899 From: Alice ;tag=kkaz- 1900 To: Bob 1901 Supported: histinfo 1902 Call-Id: 12345600@example.com 1903 CSeq: 1 INVITE 1904 History-Info: ;index=1 1905 History-Info: ;index=1.1;rc=1 1906 Contact: Alice 1907 Content-Type: application/sdp 1908 Content-Length: 1910 [SDP Not Shown] 1912 F3 302 Moved Temporarily Bob -> Example.com 1914 SIP/2.0 302 Moved Temporarily 1915 Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bK12se 1916 ;received=192.0.2.112 1917 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 1918 From: Alice ;tag=kkaz- 1919 To: Bob ;tag=2hi-1nf 1920 Supported: histinfo 1921 Call-Id: 12345600@example.com 1922 CSeq: 1 INVITE 1923 History-Info: ;index=1 1924 History-Info: ;index=1.1;rc=1 1925 Contact: 1926 Content-Type: application/sdp 1927 Content-Length: 1929 [SDP Not Shown] 1931 F4 INVITE Example.com -> Carol 1933 INVITE sip:carol@192.0.2.4 SIP/2.0 1934 Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bK353s 1935 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 1936 From: Alice ;tag=kkaz- 1937 To: Bob 1938 Supported: histinfo 1939 Call-Id: 12345600@example.com 1940 CSeq: 1 INVITE 1941 History-Info: ;index=1 1942 History-Info: ;\ 1943 index=1.1;rc=1 1944 History-Info: ;index=1.2;mp=1 1945 History-Info: ;index=1.2.1;rc=1.2 1946 Contact: Alice 1947 Content-Type: application/sdp 1948 Content-Length: 1950 [SDP Not Shown] 1952 F5 180 Ringing Carol -> Example.com 1953 SIP/2.0 180 Ringing 1954 Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bK353s 1955 ;received=192.0.2.113 1956 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 1957 From: Alice ;tag=kkaz- 1958 To: Bob ;tag=setss3x 1959 Supported: histinfo 1960 Call-Id: 12345600@example.com 1961 CSeq: 1 INVITE 1962 History-Info: ;index=1 1963 History-Info: ;\ 1964 index=1.1;rc=1 1965 History-Info: ;index=1.2;mp=1 1966 History-Info: ;index=1.2.1;rc=1.2 1967 Contact: 1968 Content-Type: application/sdp 1969 Content-Length: 1971 [SDP Not Shown] 1973 F6 INVITE Example.com -> VM 1975 INVITE sip:vm@192.0.2.6;target=sip:bob%40example.com;cause=408 1976 Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bK12se 1977 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 1978 From: Alice ;tag=kkaz- 1979 To: Bob 1980 Supported: histinfo 1981 Call-Id: 12345600@example.com 1982 CSeq: 1 INVITE 1983 History-Info: ;index=1 1984 History-Info: ;\ 1985 index=1.1;rc=1 1986 History-Info: ;index=1.2;mp=1 1987 History-Info: ;\ 1988 index=1.2.1;rc=1.2 1989 History-Info: ;\ 1991 index=1.3;mp=1.2 1992 History-Info: ;\ 1994 index=1.3.1;rc=1.3 1995 Contact: Alice 1996 Content-Type: application/sdp 1997 Content-Length: 1999 [SDP Not Shown] 2000 F7 200 OK VM -> Example.com 2002 SIP/2.0 200 OK 2003 Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bK12se 2004 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 2005 ;received=192.0.2.114 2006 From: Alice ;tag=kkaz- 2007 To: Bob ;tag=3dweggs 2008 Supported: histinfo 2009 Call-Id: 12345600@example.com 2010 CSeq: 1 INVITE 2011 History-Info: ;index=1 2012 History-Info: ;\ 2013 index=1.1;rc=1 2014 History-Info: ;index=1.2;mp=1 2015 History-Info: ;\ 2016 index=1.2.1;rc=1.2 2017 History-Info: ;\ 2019 index=1.3;mp=1.2 2020 History-Info: ;\ 2022 index=1.3.1;rc=1.3 2023 Contact: 2024 Content-Type: application/sdp 2025 Content-Length: 2027 [SDP Not Shown] 2029 B.2. Consumer Voicemail example call flow 2031 In this example, Alice calls the Bob but Bob has temporarily 2032 forwarded his phone to Carol because she is his wife. Carol does not 2033 answer the call, thus it is forwarded to a VM (voicemail) server 2034 (VMS). In order to determine the appropriate mailbox to use for this 2035 call, the VMS needs the appropriate target for the request. The last 2036 target is determined by finding the hi-entry referenced by the index 2037 of last hi-entry tagged with "rc" for determining the appropriate 2038 mailbox. This hi-entry is used to populate the "target" URI 2039 parameter as defined in [RFC4458]. Note that some VMSs may also (or 2040 instead) use the information available in the History-Info headers 2041 for custom handling of the VM in terms of how and why the called 2042 arrived at the VMS. 2044 Alice example.com Bob Carol VM 2045 | INVITE F1 | | | | 2046 |------------->| | | | 2047 | | INVITE F2 | | | 2048 | |------------->| | | 2049 | | | | | 2050 | 100 Trying | | | | 2051 |<-------------| 302 Moved Temporarily F3 | | 2052 | |<-------------| | | 2053 | | ACK | | | 2054 | |------------->| | | 2055 | | | | | 2056 | | INVITE F5 | | | 2057 | |--------------------------->| | 2058 | | | | | 2059 | | 180 Ringing F6 | | 2060 | |<---------------------------| | 2061 | | | | | 2062 | 180 Ringing | | | | 2063 |<-------------| | | | 2064 | | | | | 2065 | | (timeout) | | 2066 | | | | | 2067 | | INVITE F7 | | | 2068 | |-------------------------------------->| 2069 | | | | | 2070 | | 200 OK F8 | 2071 | |<--------------------------------------| 2072 | 200 OK | | | | 2073 |<-------------| | | | 2074 | | | | | 2075 | ACK | | | | 2076 |------------->| ACK | 2077 | |-------------------------------------->| 2079 F1 INVITE Alice -> Example.com 2081 INVITE sip:bob@example.com 2082 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 2083 From: Alice ;tag=kkaz- 2084 To: Bob 2085 Supported: histinfo 2086 Call-Id: 12345600@example.com 2087 CSeq: 1 INVITE 2088 Contact: Alice 2089 Content-Length: 2091 [SDP Not Shown] 2092 F2 INVITE Example.com -> Bob 2094 INVITE sip:bob@192.0.2.5 SIP/2.0 2095 Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bK12se 2096 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 2097 From: Alice ;tag=kkaz- 2098 To: Bob 2099 Supported: histinfo 2100 Call-Id: 12345600@example.com 2101 CSeq: 1 INVITE 2102 History-Info: ;index=1 2103 History-Info: ;index=1.1;rc=1 2104 Contact: Alice 2105 Content-Type: application/sdp 2106 Content-Length: 2108 [SDP Not Shown] 2110 F3 302 Moved Temporarily Bob -> Example.com 2112 SIP/2.0 302 Moved Temporarily 2113 Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bK12se 2114 ;received=192.0.2.111 2115 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 2116 From: Alice ;tag=kkaz- 2117 To: Bob ;tag=2hi1nfo 2118 Supported: histinfo 2119 Call-Id: 12345600@example.com 2120 CSeq: 1 INVITE 2121 History-Info: ;index=1 2122 History-Info: ;index=1.1;rc=1 2123 Contact: 2124 Content-Type: application/sdp 2125 Content-Length: 2127 [SDP Not Shown] 2129 F4 INVITE Example.com -> Carol 2131 INVITE sip:carol@192.0.2.4 SIP/2.0 2132 Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bKseb1 2133 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 2134 From: Alice ;tag=kkaz- 2135 To: Bob 2136 Supported: histinfo 2137 Call-Id: 12345600@example.com 2138 CSeq: 1 INVITE 2139 History-Info: ;index=1 2140 History-Info: ;\ 2141 index=1.1;rc=1 2142 History-Info: ;index=1.2;mp=1 2143 History-Info: ;index=1.2.1;rc=1.2 2144 Contact: Alice 2145 Content-Type: application/sdp 2146 Content-Length: 2148 [SDP Not Shown] 2150 F5 180 Ringing Carol -> Example.com 2152 SIP/2.0 180 Ringing 2153 Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bKseb1 2154 ;received=192.0.2.112 2155 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 2156 From: Alice ;tag=kkaz- 2157 To: Bob ;tag=setss3x 2158 Supported: histinfo 2159 Call-Id: 12345600@example.com 2160 CSeq: 1 INVITE 2161 History-Info: ;index=1 2162 History-Info: ;\ 2163 index=1.1;rc=1 2164 History-Info: ;index=1.2;mp=1 2165 History-Info: ;index=1.2.1;rc=1.2 2166 Contact: Carol 2167 Content-Type: application/sdp 2168 Content-Length: 2170 [SDP Not Shown] 2172 F6 INVITE Example.com -> VM 2174 INVITE sip:vm@192.0.2.6;target=sip:carol%40example.com 2175 Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bKb3ss 2176 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 2177 From: Alice ;tag=kkaz- 2178 To: Bob 2179 Supported: histinfo 2180 Call-Id: 12345600@example.com 2181 CSeq: 1 INVITE 2182 History-Info: ;index=1 2183 History-Info: ;\ 2184 index=1.1;rc 2185 History-Info: ;\ 2186 index=1.2;mp=1 2188 History-Info: ;index=1.2.1;rc=1.2 2189 History-Info: ;\ 2190 index=1.3;mp=1.2 2191 History-Info: ;\ 2192 index=1.3.1 2193 Contact: Alice 2194 Content-Type: application/sdp 2195 Content-Length: 2197 [SDP Not Shown] 2199 F7 200 OK VM -> Example.com 2201 SIP/2.0 200 OK 2202 Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bKb3ss 2203 ;received=192.0.2.113 2204 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 2205 From: Alice ;tag=kkaz- 2206 To: Bob ;tag=3dweggs 2207 Supported: histinfo 2208 Call-Id: 12345600@example.com 2209 CSeq: 1 INVITE 2210 History-Info: ;index=1 2211 History-Info: ;\ 2212 index=1.1;rc 2213 History-Info: ;\ 2214 index=1.2;mp=1 2215 History-Info: ;index=1.2.1;rc=1.2 2216 History-Info: ;\ 2217 index=1.3;mp=1.2 2218 History-Info: ;\ 2219 index=1.3.1 2220 Contact: 2221 Content-Type: application/sdp 2222 Content-Length: 2224 [SDP Not Shown] 2226 The VMS can look at the last hi-entry and find the target of the 2227 mailbox by looking for the "target" URI parameter in the hi-entry. 2229 B.3. Sequentially Forking (History-Info in Response) 2231 This scenario highlights an example where the History-Info in the 2232 response is useful to an application or user that originated the 2233 request. 2235 Alice sends a call to Bob via sip:example.com. The proxy sip: 2236 example.com sequentially tries Bob on a SIP UA that has bound a 2237 contact with the sip:bob@example.com AOR, and then several alternate 2238 addresses (Office and Home) unsuccessfully before sending a response 2239 to Alice. The hi-entry containing the initial contact is the hi- 2240 entry just prior to the first hi-entry tagged with an "rc" header 2241 field parameter. In this example, the Office and Home are not the 2242 same AOR as sip:bob@example.com, but rather different AORs that have 2243 been configured as alternate addresses for Bob in the proxy. In 2244 other words, Office and Bob are not bound through SIP Registration 2245 with Bob's AOR. This type of arrangement is common for example when 2246 a "routing" rule to a PSTN number is manually configured in a proxy. 2247 These hi-entries are identified by the index contained in the hi- 2248 target-param "mp" header field parameter in the hi-entries. 2250 This scenario illustrates that by providing the History-Info to 2251 Alice, the end-user or an application at Alice could make a decision 2252 on how best to attempt finding Bob without sending multiple requests 2253 to the same destination. Upon receipt of the response containing the 2254 History-Info entries, the Request URIs for the History-Info entries 2255 tagged with "mp" header field parameter are extracted. Those 2256 Request-URIs can be compared to other URIs (if any) that might be 2257 attempted in order to establish the session with Bob. Thus, avoiding 2258 another INVITE to Bob's home phone. Without this mechanism, Alice 2259 might well attempt to reach Bob at his office phone, which would then 2260 retarget the request to Bob's home phone. When that attempt failed, 2261 then Alice might attempt to reach Bob directly at his home phone, 2262 unknowingly for a third time. 2264 Alice example.com Bob Office Home 2265 | | | | | 2266 | INVITE F1 | | | | 2267 |----------->| INVITE F2 | | | 2268 | |----------------->| | | 2269 | 100 Trying F3 | | | 2270 |<-----------| 302 Move Temporarily F4 | | 2271 | |<-----------------| | | 2272 | | ACK F5 | | | 2273 | |----------------->| | | 2274 | | INVITE F6 | | 2275 | |-------------------------->| | 2276 | | 180 Ringing F7 | | 2277 | |<--------------------------| | 2278 | 180 Ringing F8 | | 2279 |<-----------| retransmit INVITE | | 2280 | |-------------------------->| | 2281 | | ( timeout ) | | 2282 | | INVITE F9 | 2283 | |----------------------------------->| 2284 | | 100 Trying F10 | 2285 | |<-----------------------------------| 2286 | | 486 Busy Here F11 | 2287 | |<-----------------------------------| 2288 | 486 Busy Here F12 | 2289 |<-----------| ACK F13 | 2290 | |----------------------------------->| 2291 | ACK F14 | | 2292 |----------->| | 2294 Message Details 2296 F1 INVITE alice -> example.com 2298 INVITE sip:bob@example.com SIP/2.0 2299 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 2300 From: Alice ;tag=sr3dds 2301 To: Bob 2302 Supported: histinfo 2303 Call-Id: 12345600@example.com 2304 CSeq: 1 INVITE 2305 History-Info: ;index=1 2306 Contact: Alice 2307 Content-Type: application/sdp 2308 Content-Length: 2309 2310 F2 INVITE example.com -> Bob 2312 INVITE sip:bob@192.0.2.4 SIP/2.0 2313 Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bKx3st 2314 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 2315 From: Alice ;tag=sr3dds 2316 To: Bob 2317 Supported: histinfo 2318 Call-Id: 12345600@example.com 2319 CSeq: 1 INVITE 2320 Record-Route: 2321 History-Info: ;index=1 2322 History-Info: ;index=1.1;rc=1 2323 Contact: Alice 2324 Content-Type: application/sdp 2325 Content-Length: 2326 2328 F3 100 Trying example.com -> alice 2330 SIP/2.0 100 Trying 2331 Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bKx3st 2332 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 2333 From: Alice ;tag=sr3dds 2334 To: Bob 2335 Call-Id: 12345600@example.com 2336 CSeq: 1 INVITE 2337 Content-Length: 0 2339 F4 302 Moved Temporarily Bob -> example.com 2341 SIP/2.0 302 Moved Temporarily 2342 Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bKrs22 2343 ;received=192.0.2.111 2344 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 2345 From: Alice ;tag=sr3dds 2346 To: Bob ;tag=hi51nfo 2347 Call-Id: 12345600@example.com 2348 CSeq: 1 INVITE 2349 Record-Route: 2350 History-Info: ;index=1 2351 History-Info: ;index=1.1;rc=1 2352 Contact: ;mp=1 2353 Content-Length: 0 2355 F5 ACK example.com -> Bob 2357 ACK sip:bob@example.com SIP/2.0 2358 Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bKrs22 2359 Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bKx3st 2360 From: Alice ;tag=sr3dds 2361 To: Bob ;tag=hi51nfo 2362 Call-Id: 12345600@example.com 2363 CSeq: 1 ACK 2364 Content-Length: 0 2366 F6 INVITE example.com -> office 2368 INVITE sip:office@192.0.2.5 SIP/2.0 2369 Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bKzeld 2370 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bKbst2 2371 From: Alice ;tag=sr3dds 2372 To: Bob 2373 Supported: histinfo 2374 Call-Id: 12345600@example.com 2375 Record-Route: 2376 History-Info: ;index=1 2377 History-Info: ;\ 2378 index=1.1;rc=1 2379 History-Info: ;index=1.2;mp=1 2380 History-Info: ;index=1.2.1;rc=1.2 2381 CSeq: 1 INVITE 2382 Contact: Alice 2383 Content-Type: application/sdp 2384 Content-Length: 2385 2386 F7 180 Ringing office -> example.com 2388 SIP/2.0 180 Ringing 2389 Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bKzeld 2390 ;received=192.0.2.113 2391 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bKbst2 2392 From: Alice ;tag=sr3dds 2393 To: Bob ;tag=53rdds 2394 Supported: histinfo 2395 Call-ID: 12345600@example.com 2396 Record-Route: 2397 History-Info: ;index=1 2398 History-Info: ;\ 2399 index=1.1;rc=1 2400 History-Info: ;index=1.2;mp=1 2401 History-Info: ;index=1.2.1;rc=1.2 2402 CSeq: 1 INVITE 2403 Contact: Office 2404 Content-Length: 0 2406 F8 180 Ringing example.com -> alice 2408 SIP/2.0 180 Ringing 2409 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bKbst2 2410 From: Alice ;tag=sr3dds 2411 To: Bob ;tag=53rdds 2412 Supported: histinfo 2413 Call-Id: 12345600@example.com 2414 History-Info: ;index=1 2415 History-Info: ;\ 2416 index=1.1;rc=1 2417 History-Info: ;index=1.2;mp=1 2418 History-Info: ;index=1.2.1;rc=1.2 2419 CSeq: 1 INVITE 2420 Contact: Office 2421 Content-Length: 0 2422 F9 INVITE example.com -> home 2424 INVITE sip:home@192.0.2.6 SIP/2.0 2425 Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bKx3st 2426 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bKbst2 2427 From: Alice ;tag=sr3dds 2428 To: Bob 2429 Supported: histinfo 2430 Call-Id: 12345600@example.com 2431 Record-Route: 2432 History-Info: ;index=1 2433 History-Info: ;\ 2434 index=1.1;rc=1 2435 History-Info: ;index=1.2;mp=1 2436 History-Info: ;\ 2437 index=1.2.1>;index=1.2.1;rc=1.2 2438 History-Info: ;index=1.3;mp=1 2439 History-Info: ;index=1.3.1;rc=1.3 2440 CSeq: 1 INVITE 2441 Contact: Alice 2442 Content-Type: application/sdp 2443 Content-Length: 2444 2446 F10 100 Trying home -> example.com 2448 SIP/2.0 100 Trying 2449 Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bKx3st 2450 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bKbst2 2451 From: Alice ;tag=sr3dds 2452 To: Bob 2453 Call-Id: 12345600@example.com 2454 CSeq: 1 INVITE 2455 Content-Length: 0 2456 F11 486 Busy Here home -> example.com 2458 SIP/2.0 486 Busy Here 2459 Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bKx3st 2460 ;received=192.0.2.114 2461 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bKbst2 2462 From: Alice ;tag=sr3dds 2463 To: Bob ;tag=53rdds 2464 Call-Id: 12345600@example.com 2465 Record-Route: 2466 History-Info: ;index=1 2467 History-Info: ;\ 2468 index=1.1;rc=1 2469 History-Info: ;index=1.2;mp=1 2470 History-Info: ;\ 2471 index=1.2.1>;index=1.2.1;rc=1.2 2472 History-Info: ;index=1.3;mp=1 2473 History-Info: ;index=1.3.1;rc=1.3 2474 CSeq: 1 INVITE 2475 Content-Length: 0 2477 F12 486 Busy Here example.com -> alice 2479 SIP/2.0 486 Busy Here 2480 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bKbst2 2481 From: Alice ;tag=sr3dds 2482 To: Bob ;tag=53rdds 2483 Call-Id: 12345600@example.com 2484 History-Info: ;index=1 2485 History-Info: ;\ 2486 index=1.1;rc=1 2487 History-Info: ;index=1.2;mp=1 2488 History-Info: ;\ 2489 index=1.2.1>;index=1.2.1;rc=1.2 2490 History-Info: ;index=1.3;mp=1 2491 History-Info: ;index=1.3.1;rc=1.3 2492 CSeq: 1 INVITE 2493 Content-Length: 0 2494 F13 ACK example.com -> home 2496 ACK sip:home@192.0.2.6 SIP/2.0 2497 Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bKx3st 2498 From: Alice ;tag=sr3dds>; 2499 To: Bob ;tag=53rdds 2500 Call-Id: 12345600@example.com 2501 CSeq: 1 ACK 2502 Content-Length: 0 2504 F14 ACK alice -> example.com 2506 ACK sip:bob@example.com SIP/2.0 2507 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bKbst2 2508 From: Alice ;tag=sr3dds 2509 To: Bob ;tag=53rdds 2510 Call-Id: 12345600@example.com 2511 Route: 2512 CSeq: 1 ACK 2513 Content-Length: 0 2515 B.4. History-Info with Privacy Header Field 2517 This example provides a basic call scenario without forking. Alice 2518 has indicated that she wants Privacy associated with the History-Info 2519 header field entries. In addition, sip:biloxi.example.com adds 2520 Privacy header fields indicating that the History-Info header field 2521 information is anonymized outside the biloxi.example.com domain. 2522 Note, that if the atlanta.example.com proxy had added privacy header 2523 fields to all its hi-entries, then all the hi-entries in the response 2524 would be anonymous. 2526 Alice atlanta.example.com biloxi.example.com Bob 2527 | | | | 2528 | INVITE F1 | | | 2529 |--------------->| | | 2530 | | | | 2531 | | INVITE F2 | | 2532 | |--------------->| | 2533 | | | | 2534 | | | INVITE F3 | 2535 | | |--------------->| 2536 | | | | 2537 | | | 200 F4 | 2538 | | |<---------------| 2539 | | | | 2540 | | 200 F5 | | 2541 | |<---------------| | 2542 | | | | 2543 | 200 F6 | | | 2544 |<---------------| | | 2545 | | | | 2546 | ACK | | | 2547 |--------------->| ACK | | 2548 | |--------------->| ACK | 2549 | | |--------------->| 2551 Figure 2: Example with Privacy Header Fields 2553 Message Details 2555 F1 INVITE alice -> atlanta.example.com 2557 INVITE sip:bob@biloxi.example.com;p=x SIP/2.0 2558 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 2559 From: Alice ;tag=22 2560 To: Bob 2561 Supported: histinfo 2562 Privacy: History 2563 Call-Id: 12345600@atlanta.example.com 2564 CSeq: 1 INVITE 2565 History-Info: ;index=1 2566 Contact: Alice 2567 Content-Type: application/sdp 2568 Content-Length: 2569 2570 F2 INVITE atlanta.example.com -> biloxi.example.com 2572 INVITE sip:bob@biloxi.example.com;p=x SIP/2.0 2573 Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=z9hG4bKbst2 2574 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 2575 From: Alice ;tag=22 2576 To: Bob 2577 Supported: histinfo 2578 Call-Id: 12345600@atlanta.example.com 2579 CSeq: 1 INVITE 2580 History-Info: ;index=1 2581 History-Info: ;index=1.1;rc=1 2582 Contact: Alice 2583 Content-Type: application/sdp 2584 Content-Length: 2585 2587 F3 INVITE biloxi.example.com -> Bob 2589 INVITE sip:bob@192.0.1.11 SIP/2.0 2590 Via: SIP/2.0/TCP proxy.biloxi.example.com:5060;branch=z9hG4bKtg3s 2591 Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=z9hG4bKbst2 2592 ;received=192.0.2.111 2593 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 2594 From: Alice ;tag=22 2595 To: Bob 2596 Supported: histinfo 2597 Call-Id: 12345600@atlanta.example.com 2598 CSeq: 1 INVITE 2599 History-Info: ;index=1 2600 History-Info: ;index=1.1;rc=1 2601 History-Info: ;index=1.1.1;rc=1.1 2602 Contact: Alice 2603 Content-Type: application/sdp 2604 Content-Length: 2605 2606 F4 200 OK Bob -> biloxi.example.com 2608 SIP/2.0 200 OK 2609 Via: SIP/2.0/TCP proxy.biloxi.example.com:5060;branch=z9hG4bKtg3s 2610 ;received=192.0.2.112 2611 Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=z9hG4bKbst2 2612 ;received=192.0.2.111 2613 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 2614 From: Alice ;tag=22 2615 To: Bob ;tag=33 2616 Supported: histinfo 2617 Call-Id: 12345600@atlanta.example.com 2618 CSeq: 1 INVITE 2619 History-Info: ;index=1 2620 History-Info: ;index=1.1;rc=1 2621 History-Info: ;index=1.1.1;rc=1.1 2622 Contact: Bob 2623 Content-Type: application/sdp 2624 Content-Length: 2625 2627 F5 200 OK biloxi.example.com -> atlanta.example.com 2629 SIP/2.0 200 OK 2630 Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=z9hG4bKbst2 2631 ;received=192.0.2.111 2632 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 2633 From: Alice ;tag=22 2634 To: Bob ;tag=33 2635 Supported: histinfo 2636 Call-Id: 12345600@atlanta.example.com 2637 CSeq: 1 INVITE 2638 History-Info: ;index=1 2639 History-Info: ;index=1.1;rc=1 2640 History-Info: ;index=1.1.1;rc=1.1 2641 Contact: Bob 2642 Content-Type: application/sdp 2643 Content-Length: 2644 2646 F6 200 OK atlanta.example.com -> Alice 2648 SIP/2.0 200 OK 2649 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 2650 From: Alice ;tag=22 2651 To: Bob ;tag=33 2652 Supported: histinfo 2653 Call-Id: 12345600@atlanta.example.com 2654 CSeq: 1 INVITE 2655 History-Info: ;index=1 2656 History-Info: ;index=1.1;rc=1 2657 History-Info: 2659 Content-Type: application/sdp 2660 Content-Length: 2661 2663 B.5. Privacy for a Specific History-Info Entry 2665 This example provides a basic call scenario similar to Appendix B.4, 2666 however, due to local policy at sip:biloxi.example.com, only the 2667 final hi-entry in the History-Info, which is Bob's local URI, 2668 contains a privacy header field with a priv-value of "history", thus 2669 providing Alice with some information about the history of the 2670 request, but anonymizing Bob's local URI. 2672 Alice atlanta.example.com biloxi.example.com Bob 2673 | | | | 2674 | INVITE F1 | | | 2675 |--------------->| | | 2676 | | | | 2677 | | INVITE F2 | | 2678 | |--------------->| | 2679 | | | | 2680 | | | INVITE F3 | 2681 | | |--------------->| 2682 | | | | 2683 | | | 200 F4 | 2684 | | |<---------------| 2685 | | | | 2686 | | 200 F5 | | 2687 | |<---------------| | 2688 | | | | 2689 | 200 F6 | | | 2690 |<---------------| | | 2691 | | | | 2692 | ACK | | | 2693 |--------------->| ACK | | 2694 | |--------------->| ACK | 2695 | | |--------------->| 2697 Figure 3: Example with Privacy Header Field for Specific URI 2699 Message Details 2701 F1 INVITE alice -> atlanta.example.com 2703 INVITE sip:bob@biloxi.example.com;p=x SIP/2.0 2704 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 2705 From: Alice ;tag=22 2706 To: Bob 2707 Supported: histinfo 2708 Call-Id: 12345600@atlanta.example.com 2709 CSeq: 1 INVITE 2710 History-Info: ;index=1 2711 Contact: Alice 2712 Content-Type: application/sdp 2713 Content-Length: 2714 2715 F2 INVITE atlanta.example.com -> biloxi.example.com 2717 INVITE sip:bob@biloxi.example.com;p=x SIP/2.0 2718 Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=z9hG4bKbst2 2719 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 2720 From: Alice ;tag=22 2721 To: Bob 2722 Supported: histinfo 2723 Call-Id: 12345600@atlanta.example.com 2724 CSeq: 1 INVITE 2725 History-Info: ;index=1 2726 History-Info: ;index=1.1;rc=1 2727 Contact: Alice 2728 Content-Type: application/sdp 2729 Content-Length: 2730 2732 F3 INVITE biloxi.example.com -> Bob 2734 INVITE sip:bob@192.0.1.11 SIP/2.0 2735 Via: SIP/2.0/TCP proxy.biloxi.example.com:5060;branch=z9hG4bKeset 2736 Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=z9hG4bKbst2 2737 ;received=192.0.2.112 2738 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 2739 From: Alice ;tag=22 2740 To: Bob 2741 Supported: histinfo 2742 Call-Id: 12345600@atlanta.example.com 2743 CSeq: 1 INVITE 2744 History-Info: ;index=1 2745 History-Info: ;index=1.1;rc=1 2746 History-Info: ;index=1.1.1;rc=1.1 2747 Contact: Alice 2748 Content-Type: application/sdp 2749 Content-Length: 2750 2751 F4 200 OK Bob -> biloxi.example.com 2753 SIP/2.0 200 OK 2754 Via: SIP/2.0/TCP proxy.biloxi.example.com:5060;branch=z9hG4bKeset 2755 ;received=192.0.2.111 2756 Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=z9hG4bKbst2 2757 ;received=192.0.2.112 2758 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 2759 From: Alice ;tag=22 2760 To: Bob ;tag=33 2761 Supported: histinfo 2762 Call-Id: 12345600@atlanta.example.com 2763 CSeq: 1 INVITE 2764 History-Info: ;index=1 2765 History-Info: ;index=1.1;rc=1 2766 History-Info: ;index=1.1.1;rc=1.1 2767 Contact: Bob 2768 Content-Type: application/sdp 2769 Content-Length: 2770 2772 F5 200 OK biloxi.example.com -> atlanta.example.com 2774 SIP/2.0 200 OK 2775 Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=z9hG4bKbst2 2776 ;received=192.0.2.112 2777 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 2778 From: Alice ;tag=22 2779 To: Bob ;tag=33 2780 Supported: histinfo 2781 Call-Id: 12345600@atlanta.example.com 2782 CSeq: 1 INVITE 2783 History-Info: ;index=1 2784 History-Info: ;index=1.1;rc=1 2785 History-Info: ;index=1.1.1;rc=1.1 2786 Contact: Bob 2787 Content-Type: application/sdp 2788 Content-Length: 2789 2790 F6 200 OK atlanta.example.com -> Alice 2792 SIP/2.0 200 OK 2793 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 2794 From: Alice ;tag=22 2795 To: Bob ;tag=33 2796 Supported: histinfo 2797 Call-Id: 12345600@atlanta.example.com 2798 CSeq: 1 INVITE 2799 History-Info: ;index=1 2800 History-Info: ;index=1.1;rc=1 2801 History-Info: ;index=1.1.1;rc=1.1 2802 Contact: Bob 2803 Content-Type: application/sdp 2804 Content-Length: 2805 2807 Authors' Addresses 2809 Mary Barnes 2810 Polycom 2811 TX 2812 US 2814 Email: mary.ietf.barnes@gmail.com 2816 Francois Audet 2817 Skype 2819 Email: francois.audet@skype.net 2821 Shida Schubert 2822 NTT 2824 Email: shida@ntt-at.com 2825 Hans Erik van Elburg 2826 Detecon International Gmbh 2827 Oberkasseler str. 2 2828 Bonn, 2829 Germany 2831 Email: ietf.hanserik@gmail.com 2833 Christer Holmberg 2834 Ericsson 2835 Hirsalantie 11, Jorvas 2836 Finland 2838 Email: christer.holmberg@ericsson.com