idnits 2.17.1 draft-ietf-sipcore-rfc4244bis-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? -- The draft header indicates that this document obsoletes RFC4244, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 420 has weird spacing: '... Alice atla...' == Line 1651 has weird spacing: '... Alice exam...' == Line 1906 has weird spacing: '... Alice atla...' == Line 1959 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 (March 15, 2011) is 4791 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: 'RFCXXXX' is mentioned on line 1027, but not defined == Unused Reference: 'RFC3969' is defined on line 1485, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 4244 (Obsoleted by RFC 7044) Summary: 2 errors (**), 0 flaws (~~), 8 warnings (==), 3 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: September 16, 2011 S. Schubert 7 NTT 8 J. van Elburg 9 Detecon International Gmbh 10 C. Holmberg 11 Ericsson 12 March 15, 2011 14 An Extension to the Session Initiation Protocol (SIP) for Request 15 History Information 16 draft-ietf-sipcore-rfc4244bis-04.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 document 29 defines a value for the Privacy header field specific to the History- 30 Info header field. 32 Status of this Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on September 16, 2011. 49 Copyright Notice 51 Copyright (c) 2011 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 This document may contain material from IETF Documents or IETF 65 Contributions published or made publicly available before November 66 10, 2008. The person(s) controlling the copyright in some of this 67 material may not have granted the IETF Trust the right to allow 68 modifications of such material outside the IETF Standards Process. 69 Without obtaining an adequate license from the person(s) controlling 70 the copyright in such materials, this document may not be modified 71 outside the IETF Standards Process, and derivative works of it may 72 not be created outside the IETF Standards Process, except to format 73 it for publication as an RFC or to translate it into languages other 74 than English. 76 Table of Contents 78 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 79 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 80 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 5 81 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 82 5. History-Info Header Field Protocol Structure . . . . . . . . . 7 83 5.1. History-Info Header Field Example Scenario . . . . . . . . 9 84 6. User Agent Handling of the History-Info Header Field . . . . . 12 85 6.1. User Agent Client (UAC) Behavior . . . . . . . . . . . . . 12 86 6.2. User Agent Server (UAS) Behavior . . . . . . . . . . . . . 12 87 7. Proxy/Intermediary Handling of History-Info Header Fields . . 12 88 8. Redirect Server Handling of History-Info Header Fields . . . . 13 89 9. Handling of History-Info Header Fields in Requests and 90 Responses . . . . . . . . . . . . . . . . . . . . . . . . . . 13 91 9.1. Receiving a Request with History-Info . . . . . . . . . . 13 92 9.2. Sending a Request with History-Info . . . . . . . . . . . 14 93 9.3. Receiving a Response with History-Info . . . . . . . . . . 14 94 9.4. Sending History-Info in Responses . . . . . . . . . . . . 15 95 10. Processing the History-Info Header Field . . . . . . . . . . . 15 96 10.1. Privacy in the History-Info Header Field . . . . . . . . . 15 97 10.1.1. Indicating Privacy . . . . . . . . . . . . . . . . . 16 98 10.1.2. Applying Privacy . . . . . . . . . . . . . . . . . . 17 99 10.2. Reason in the History-info Header Field . . . . . . . . . 17 100 10.3. Indexing in the History-Info Header Field . . . . . . . . 18 101 10.4. Mechanism for Target Determination in the History-Info 102 Header Field . . . . . . . . . . . . . . . . . . . . . . . 19 103 11. Application Considerations . . . . . . . . . . . . . . . . . . 20 104 12. Security Considerations . . . . . . . . . . . . . . . . . . . 22 105 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 106 13.1. Registration of New SIP History-Info Header Field . . . . 23 107 13.2. Registration of "history" for SIP Privacy Header Field . . 23 108 13.3. Registration of Header Field Parameters . . . . . . . . . 24 109 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 110 15. Changes from RFC 4244 . . . . . . . . . . . . . . . . . . . . 25 111 15.1. Backwards compatibility . . . . . . . . . . . . . . . . . 26 112 16. Changes since last Version . . . . . . . . . . . . . . . . . . 26 113 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 114 17.1. Normative References . . . . . . . . . . . . . . . . . . . 32 115 17.2. Informative References . . . . . . . . . . . . . . . . . . 33 116 Appendix A. Request History Requirements . . . . . . . . . . . . 33 117 A.1. Security Requirements . . . . . . . . . . . . . . . . . . 35 118 A.2. Privacy Requirements . . . . . . . . . . . . . . . . . . . 35 119 Appendix B. Example call flows . . . . . . . . . . . . . . . . . 36 120 B.1. Sequentially Forking (History-Info in Response) . . . . . 36 121 B.2. History-Info with Privacy Header Field . . . . . . . . . . 43 122 B.3. Privacy for a Specific History-Info Entry . . . . . . . . 45 123 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 46 125 1. Introduction 127 Many services that SIP is anticipated to support require the ability 128 to determine why and how a SIP requests arrived at a specific 129 application. Examples of such services include (but are not limited 130 to) sessions initiated to call centers via "click to talk" SIP 131 Uniform Resource Locators (URLs) on a web page, "call history/ 132 logging" style services within intelligent "call management" software 133 for SIP User Agents (UAs), and calls to voicemail servers. Although 134 SIP implicitly provides the retarget capabilities that enable SIP 135 requests to be routed to chosen applications, there is a need for a 136 standard mechanism within SIP for communicating the retargeting 137 history of the requests. This "request history" information allows 138 the receiving application to determine hints about how and why the 139 SIP request arrived at the application/user. 141 This document defines a SIP header field, History-Info, to provide a 142 standard mechanism for capturing the request history information to 143 enable a wide variety of services for networks and end-users. SIP 144 header field parameters are defined for the History-Info and Contact 145 header fields to tag the method by which the target of a request is 146 determined. In addition, this document defines a value for the 147 Privacy header field specific to the History-Info header. 149 The History-info header field provides a building block for 150 development of SIP based applications and services. The requirements 151 for the solution described in this document are included in 152 Appendix A. Example scenarios using the History-info header field 153 are included in Appendix B. 155 2. Conventions and Terminology 157 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 158 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 159 document are to be interpreted as described in [RFC2119]. 161 The term "retarget" is used in this document to refer to the process 162 of a SIP entity changing a Uniform Resource Identifier (URI) in a 163 request based on the rules for determining request targets as 164 described in Section 16.5 of [RFC3261] and of the subsequent 165 forwarding of that request as described in step 2 in section 16.6 of 166 [RFC3261]. This includes changing the Request-URI due to a location 167 service lookup and redirect processing. This also includes internal 168 (to a proxy/SIP intermediary) changes of the URI prior to forwarding 169 of the request. 171 The terms "location service", "forward", "redirect" and "AOR" are 172 used consistent with the terminology in [RFC3261]. 174 The references to "domain for which the SIP entity/Proxy/Intermediary 175 is responsible" are consistent with and intended to convey the same 176 context as the usage of that terminology in [RFC3261]. The 177 applicability of History-Info to architectures or models outside the 178 context of [RFC3261] is outside the scope of this specification. 180 3. Background 182 SIP implicitly provides retargeting capabilities that enable SIP 183 requests to be routed to specific applications as defined in 184 [RFC3261]. The motivation for capturing the request history is that 185 in the process of retargeting a request, old routing information can 186 be forever lost. This lost information may be important history that 187 allows elements to which the request is retargeted to process the 188 request in a locally defined, application-specific manner. This 189 document defines a mechanism for transporting the request history. 190 Application-specific behavior is outside the scope of this 191 specification. 193 Current network applications provide the ability for elements 194 involved with the request to obtain additional information relating 195 to how and why the request was routed to a particular destination. 196 The following are examples of such applications: 198 1. Web "referral" applications, whereby an application residing 199 within a web server determines that a visitor to a website has 200 arrived at the site via an "associate" site that will receive 201 some "referral" commission for generating this traffic 203 2. Email forwarding whereby the forwarded-to user obtains a 204 "history" of who sent the email to whom and at what time 206 3. Traditional telephony services such as voicemail, call-center 207 "automatic call distribution", and "follow-me" style services 209 Several of the aforementioned applications currently define 210 application-specific mechanisms through which it is possible to 211 obtain the necessary history information. 213 In addition, request history information could be used to enhance 214 basic SIP functionality by providing the following: 216 o Some diagnostic information for debugging SIP requests. 218 o Capturing aliases and Globally Routable User Agent URIs (GRUUs) 219 [RFC5627], which can be overwritten by a home proxy upon receipt 220 of the initial request. 222 o Facilitating the use of limited use addresses (minted on demand) 223 and sub-addressing. 225 o Preserving service specific URIs that can be overwritten by a 226 downstream proxy, such as those defined in [RFC3087], and control 227 of network announcements and IVR with SIP URI [RFC4240]. 229 4. Overview 231 The fundamental functionality provided by the request history 232 information is the ability to inform proxies and UAs involved in 233 processing a request about the history or progress of that request. 234 The solution is to capture the Request-URIs as a request is 235 retargeted, in a SIP header field: History-Info. This allows for the 236 capturing of the history of a request that would be lost with the 237 normal SIP processing involved in the subsequent retargeting of the 238 request. 240 The History-info header field is added to a Request when a new 241 request is created by a UAC or forwarded by a Proxy, or when the 242 target of a request is changed. It is possible for the target of a 243 request to be changed by the same proxy/SIP Intermediary multiple 244 times (referred to as 'internal retargeting'). A SIP entity changing 245 the target of a request in response to a redirect also propagates any 246 History-info header field from the initial request in the new 247 request. The ABNF and detailed description of the History-Info 248 header field parameters, along with examples is provided in 249 Section 5. Section 6, Section 7 and Section 8 provide the detailed 250 handling of the History-Info header field by SIP User Agents, Proxies 251 and Redirect Servers respectively. 253 This specification also defines two new SIP header field parameters, 254 "rc" and "mp", for the History-Info and Contact header fields, to tag 255 the method by which the target of a request is determined. Further 256 detail on the use of these header field parameters is provided in 257 Section 10.4. 259 In addition, this specification defines a priv-value for the Privacy 260 header, "history", that applies to all the History-info header field 261 entries in a Request or to a specific History-info header field hi- 262 entry as described above. Further detail is provided in 263 Section 10.1. 265 5. History-Info Header Field Protocol Structure 267 The History-info header field can appear in any request not 268 associated with an early or established dialog (e.g., INVITE, 269 REGISTER, MESSAGE, REFER and OPTIONS, PUBLISH and SUBSCRIBE, etc.) 270 and any non-100 provisional or final responses to these requests 271 (ISSUER-req, see Appendix A). 273 The following provides details for the information that is captured 274 in the History-Info header field entries for each target used for 275 forwarding a request: 277 o hi-targeted-to-uri: A mandatory parameter for capturing the 278 Request-URI for the specific request as it is forwarded. 280 o hi-index: A mandatory parameter for History-Info reflecting the 281 chronological order of the information, indexed to also reflect 282 the forking and nesting of requests. The format for this 283 parameter is a string of digits, separated by dots to indicate the 284 number of forward hops and retargets. This results in a tree 285 representation of the history of the request, with the lowest- 286 level index reflecting a branch of the tree. By adding the new 287 entries in order (i.e., following existing entries per the details 288 in Section 10.3), including the index and securing the header, the 289 ordering of the History-info header fields in the request is 290 assured. In addition, applications may extract a variety of 291 metrics (total number of retargets, total number of retargets from 292 a specific branch, etc.) based upon the index values. 294 o hi-target-param: An optional parameter reflecting the mechanism by 295 which the Request URI captured in the hi-targeted-to-uri in the 296 hi-entry was determined. This parameter contains either an "rc" 297 or "mp" header field parameter, which is interpreted as follows: 299 "rc": The hi-targeted-to-URI is a contact for the Request-URI, 300 in the incoming request, that is bound to an AOR in an abstract 301 location service. The AOR-to-contact binding has been placed 302 into the location service by a SIP Registrar that received a 303 SIP REGISTER request. The "rc" header field parameter contains 304 the value of the hi-index in the hi-entry with an 305 hi-targeted-to- uri that reflects the Request-URI that was 306 retargeted 308 "mp": The hi-targeted-to-URI represents a user other than the 309 user associated with the Request-URI in the incoming request 310 that was retargeted. This occurs when a request is to 311 statically or dynamically retargeted to another user. The 312 value of the index in the "mp" header field parameter 313 represents the value of the hi-index in the hi-entry with an 314 hi-targeted-to- uri that reflects the Request-URI that was 315 retargeted, thus identifying the "mapped from" target. 317 o Extension (hi-extension): A parameter to allow for future optional 318 extensions. As per [RFC3261], any implementation not 319 understanding an extension MUST ignore it. 321 The ABNF syntax for the History-info header field and header field 322 parameters is as follows: 324 History-Info = "History-Info" HCOLON hi-entry *(COMMA hi-entry) 326 hi-entry = hi-targeted-to-uri *(SEMI hi-param) 328 hi-targeted-to-uri = name-addr 330 hi-param = hi-index / hi-target / hi-extension 332 index-val = 1*DIGIT *("." 1*DIGIT) 334 hi-index = "index" EQUAL index-val 336 hi-target-param = rc-param / mp-param 338 rc-param = "rc" EQUAL index-val 340 mp-param = "mp" EQUAL index-val 342 hi-extension = generic-param 344 The ABNF definitions for "generic-param" and "name-addr" are from 345 [RFC3261]. 347 This document also extends the "contact-params" for the Contact 348 header field as defined in [RFC3261] with the "rc" and "mp" header 349 field parameters defined above. 351 In addition to the parameters defined by the ABNF, an hi-entry may 352 also include a Reason header field and a Privacy header field, which 353 are both included in the hi-targeted-to-uri as described below: 355 o Reason: An optional parameter for History-Info, reflected in the 356 History-info header field by including the Reason header field 357 [RFC3326] included in the hi-targeted-to-uri. A reason is 358 included for the hi-targeted-to-uri that was retargeted as opposed 359 to the hi-targeted-to-uri to which it was retargeted. 361 o Privacy: An optional parameter for History-Info, reflected in the 362 History-Info header field values by including the Privacy Header 363 [RFC3323] included in the hi- targeted-to-uri or by adding the 364 Privacy header field to the request. The latter case indicates 365 that the History-Info entries for the domain MUST be anonymized 366 prior to forwarding, whereas the use of the Privacy header field 367 included in the hi-targeted-to-uri means that a specific hi-entry 368 MUST be anonymized. 370 Note that since both the Reason and Privacy parameters are included 371 in the hi-targeted-to-uri, these fields will not be available in the 372 case that the hi-targeted-to-uri is a Tel-URI [RFC3966]. In such 373 cases, the Tel-URI SHOULD be transformed into a SIP URI per section 374 19.1.6 of [RFC3261]. 376 The following provides examples of the format for the History-info 377 header field. Note that the backslash and CRLF between the fields in 378 the examples below are for readability purposes only. 380 History-Info: ;index=1;foo=bar 382 History-Info: ;index=1.1,\ 384 ;index=1.2;mp=1.1,\ 386 ;index=1.3;rc=1.2 388 5.1. History-Info Header Field Example Scenario 390 The following is an illustrative example of usage of History-Info. 392 In this example, Alice (sip:alice@atlanta.example.com) calls Bob 393 (sip:bob@biloxi.example.com). Alice's proxy in her home domain (sip: 394 atlanta.example.com) forwards the request to Bob's proxy (sip: 395 biloxi.example.com). When the request arrives at sip: 396 biloxi.example.com, it does a location service lookup for 397 bob@biloxi.example.com and changes the target of the request to Bob's 398 Contact URIs provided as part of normal SIP registration. In this 399 example, Bob is simultaneously contacted on a PC client and on a 400 phone, and Bob answers on the PC client. 402 One important thing illustrated by this call flow is that without 403 History-Info, Bob would "lose" the target information, including any 404 parameters in the request URI. Bob can recover that information by 405 locating the last hi-entry with an "rc" header field parameter. This 406 "rc" parameter contains the index of the hi-entry containing the lost 407 target information - i.e., the sip:bob@biloxi.example.com hi-entry 408 with index=1.1. Note that an hi-entry is not included for the fork 409 to sip:bob@192.0.2.7 since there was no response at the time the 200 410 OK is sent to Alice. 412 The formatting in this scenario is for visual purposes; thus, 413 backslash and CRLF are used between the fields for readability and 414 the headers in the URI are not shown properly formatted for escaping. 415 Refer to Section 5.1 for the proper formatting. Additional detailed 416 scenarios are available in Appendix B. 418 Note: This example uses loose routing procedures. 420 Alice atlanta.example.com biloxi.example.com Bob@pc Bob@phone 421 | | | | | 422 | INVITE sip:bob@biloxi.example.com;p=x | | 423 |--------------->| | | | 424 | Supported: histinfo | | | 425 | | | | | 426 | | INVITE sip:bob@biloxi.example.com;p=x | 427 | |--------------->| | | 428 | History-Info: ;index=1 429 | History-Info: ;index=1.1 | 430 | | | | | 431 | | | INVITE sip:bob@192.0.2.3| 432 | | |--------------->| | 433 | History-Info: ;index=1 434 | History-Info: ;index=1.1 435 | History-Info: ;index=1.1.1;rc=1.1 436 | | | | | 437 | | | INVITE sip:bob@192.0.2.7| 438 | | |-------------------------->| 439 | History-Info: ;index=1 440 | History-Info: ;index=1.1 441 | History-Info: ;index=1.1.2;rc=1.1 442 | | | 200 | | 443 | | |<---------------| | 444 | History-Info: ;index=1 445 | History-Info: ;index=1.1 446 | History-Info: ;index=1.1.1;rc=1.1 447 | | | | | 448 | | 200 | | | 449 | |<---------------| | | 450 | History-Info: ;index=1 451 | History-Info: ;index=1.1 452 | History-Info: ;index=1.1.1;rc=1.1 453 | | | | | 454 | | | Proxy Cancels INVITE | 455 | | |<=========================>| 456 | | | | | 457 | 200 | | | | 458 |<---------------| | | | 459 | History-Info: ;index=1 460 | History-Info: ;index=1.1 461 | History-Info: | ACK | | | 465 | |--------------->| ACK | | 466 | | |--------------->| | 467 Figure 1: Basic Call 469 6. User Agent Handling of the History-Info Header Field 471 A B2BUA MAY follow the behavior of a SIP intermediary as an 472 alternative to following the behavior of a UAS per Section 6.2 and a 473 UAC per Section 6.1. In behaving as an intermediary, a B2BUA carries 474 forward hi-entries received in requests at the UAS to the request 475 being forwarded by the UAC, as well as carrying forward responses 476 received at the UAC to the responses forwarded by the UAS, subject to 477 privacy considerations per Section 10.1. 479 6.1. User Agent Client (UAC) Behavior 481 The UAC MUST include the "histinfo" option tag in the Supported 482 header in any new or out-of-dialog request for which the UAC would 483 like the History-info header field in the response. When issuing a 484 request, the UAC MUST follow the procedures in Section 9.2. Note 485 that in the case of an initial request, there is no cache of hi- 486 entries with which to populate the History-info header field as 487 described in and the hi-index is set to 1 per Section 10.3. When 488 receiving a response the UAC MUST follow the procedures in 489 Section 9.3. 491 6.2. User Agent Server (UAS) Behavior 493 When receiving a request, a UAS MUST follow the procedures defined in 494 Section 9.2. When sending a response other than a 3xx response, a 495 UAS MUST follows the procedures as defined in Section 9.4. When 496 sending a 3xx response, the UAS MUST follow the procedures defined 497 for a redirect server per Section 8. An application at the UAS can 498 make use of the cached hi-entries as described in Section 11. 500 7. Proxy/Intermediary Handling of History-Info Header Fields 502 This section describes the procedures for proxies and other SIP 503 intermediaries for the handling of the History-Info header fields for 504 each of the following scenarios: 506 For each outgoing request relating to a target in the target set, 507 the intermediary MUST add an hi-entry for the specific target, per 508 the procedures in Section 9.2. 510 An intermediary MUST follow the procedures in Section 9.1 for the 511 handling of hi-entries in incoming SIP requests. 513 An intermediary MUST follow the procedures of Section 9.4 for for 514 the handling of the hi-entries when sending a SIP response. 516 An intermediary MUST follow the procedures of Section 9.3 when a 517 SIP response containing hi-entries is received. 519 In some cases, an intermediary may retarget a request more than once 520 before forwarding - i.e., a request is retargeted to a SIP entity 521 that is "internal" to the intermediary before the same intermediary 522 retargets the request to an external target . A typical example 523 would be a proxy that retargets a request first to a different user 524 (i.e., it maps to a different AOR) and then forwards to a registered 525 contact bound to the same AOR. In this case, the intermediary MUST 526 add an hi-entry for (each of) the internal target(s) per the 527 procedures in Section 9.2. The intermediary MAY include a Reason 528 header field in the hi-entry with the hi-targeted-to-uri that has 529 been retargeted as shown in the INVITE (F6) in the example in 530 Appendix B.1. Figure 1 provides an example of internal retargeting. 532 8. Redirect Server Handling of History-Info Header Fields 534 A redirect server MUST follow the procedures in Section 9.1 when it 535 receives a SIP Request. A redirect server MUST follow the procedures 536 in Section 9.4 when it sends a SIP Response. When generating the 537 Contact header field in a 3xx response, the redirect server MUST add 538 the appropriate target header field parameter to each Contact header 539 field as described in Section 10.4, if applicable. 541 9. Handling of History-Info Header Fields in Requests and Responses 543 This section describes the procedures for SIP entities for the 544 handling of SIP requests and responses containing the History-Info 545 header fields. 547 9.1. Receiving a Request with History-Info 549 When receiving a request, a SIP entity MUST create a cache containing 550 the hi-entries associated with the request. The hi-entries MUST be 551 added to the cache in the order in which they were received in the 552 request. 554 If the Request-URI of the incoming request does not match the hi- 555 targeted-to-uri in the last hi-entry (i.e., the previous SIP entity 556 that sent the request did not include a History-Info header field), 557 the SIP entity MUST add an hi-entry to end of the cache, on behalf of 558 the previous SIP entity, as follows: 560 The SIP entity MUST set the hi-targeted-to-uri to the value of the 561 Request-URI in the incoming request. 563 If privacy is required, the SIP entity MUST follow the procedures 564 of Section 10.1. 566 The SIP entity MUST set the hi-index parameter to a value of "1", 567 as described in Section 10.3. 569 The SIP entity MUST NOT include an "rc" or "mp" header field 570 parameter. 572 9.2. Sending a Request with History-Info 574 When sending a request, a SIP entity MUST include all cached hi- 575 entries in the request. In addition, the SIP entity MUST add a new 576 hi-entry to the outgoing request populating the header field as 577 follows: 579 The hi-targeted-to-uri MUST be set to the value of the Request-URI 580 of the current (outgoing) request. 582 If privacy is required, the procedures of Section 10.1 MUST be 583 followed. 585 The SIP entity MUST include an hi-index for the hi-entry as 586 described in Section 10.3. 588 The SIP entity MUST include an "rc" or "mp" header field parameter 589 in the hi-entry, if applicable, per the procedures in 590 Section 10.4. 592 9.3. Receiving a Response with History-Info 594 When a SIP entity receives a response other than a 100, the SIP 595 entity performs the following steps: 597 Step 1: Add hi-entry to cache 599 The SIP entity MUST add the hi-entry that was added to the request 600 that received the non-100 response to the cache, if it was not 601 already cached. The hi-entry MUST be added to the cache in 602 ascending order as indicated by the values in the hi-index 603 parameters of the hi-entries (e.g., 1.2.1 comes after 1.2 but 604 before 1.3). 606 Step 2: Add Reason header field 608 The SIP entity then MUST add a Reason header field to the (newly) 609 cached hi-entry reflecting the SIP response code in the non-100 610 response, per the procedures of Section 10.2. 612 Step 3: Add additional hi-entries 614 The SIP entity MUST also add to the cache any hi-entries received 615 in the response that are not already in the cache. This situation 616 can occur when the entity that generated the non-100 response 617 retargeted the request before generating the response. As per 618 Step 1, the hi-entries MUST be added to the cache in ascending 619 order as indicated by the values in the hi-index parameters of the 620 hi-entries 622 It is important to note that the cache does not contain hi-entries 623 for requests that have not yet received a non-100 response, so there 624 can be gaps in indices (e.g., 1.2 and 1.4 could but present but not 625 1.3). 627 9.4. Sending History-Info in Responses 629 When sending a response other than a 100, a SIP entity MUST include 630 all the cached hi-entries in the response with the following 631 exception: If the received request contained no hi-entries and there 632 is no "histinfo" option tag in the Supported header field, the SIP 633 entity MUST NOT include hi-entries in the response. In the former 634 case, the privacy procedures as described in Section 10.1.2 MUST be 635 followed. 637 10. Processing the History-Info Header Field 639 The following sections describe the procedures for processing the 640 History-Info header field. These procedures are applicable to SIP 641 entities such as Proxies/Intermediaries, Redirect Servers or User 642 Agents. 644 10.1. Privacy in the History-Info Header Field 646 The privacy requirements for this document are described in 647 Appendix A.2. Section 10.1.1 describes the use of the Privacy header 648 field defined in [RFC3323] to indicate the privacy to be applied to 649 the History-Info header field entries. Section 10.1.2 describes the 650 processing of the priv-values in the Privacy header field to privacy 651 protect the History-Info header field entries in the request or 652 response that is being forwarded. 654 10.1.1. Indicating Privacy 656 As with other SIP headers described in [RFC3323], the hi-targeted-to- 657 uris in the History-info header field can inadvertently reveal 658 information about the initiator of the request. Thus, the UAC needs 659 a mechanism to indicate that the hi-targeted-to-uris in the hi- 660 entries need to be privacy protected. The Privacy header field is 661 used by the UAC to indicate the privacy to be applied to all the hi- 662 entries in the request as follows: 664 o If the UAC is including a Privacy header field with a priv-value 665 of "header" in the request, then the UAC SHOULD NOT include a 666 priv-value of "history" in the the Privacy header field in the 667 Request. 669 o If the UAC is including any priv-values other than "header" in the 670 Privacy header field, then the UAC MUST also include a priv-value 671 of "history" in the Privacy header field in the Request. 673 o If the UAC is not including any priv-values in the Privacy header 674 field in the request, then the UAC MUST add a Privacy header 675 field, with a priv-value of "history", to the request. The UAC 676 MUST NOT include a priv-value of "critical" in the Privacy header 677 field in the Request in this case. 679 In addition, the History-info header field can reveal general routing 680 and diverting information within an intermediary, which the 681 intermediary wants to privacy protect. In this case, the 682 intermediary MUST set a Privacy header field to a priv-value of 683 "history" and include the Privacy header field in the hi-targeted-to- 684 uri, for each hi-entry added by intermediary, as the request is 685 retargeted within the domain for which the SIP entity is responsible. 686 The intermediary MUST NOT include any other priv-values in this 687 Privacy header field. Note that the priv-value in the Privacy header 688 for the incoming request does not necessarily influence whether the 689 intermediary includes a Privacy header field in the hi-entries. For 690 example, even if the Privacy header for the incoming request 691 contained a priv-value of "none", the Proxy can still set a priv- 692 value of "history" in the Privacy header field included in the hi- 693 targeted-to-uri. 695 Finally, the terminator of the request may not want to reveal the 696 final reached target to the originator. In this case, the terminator 697 MUST include a Privacy header field with a priv-value of "history" in 698 the hi-targeted-to-uri in the last hi-entry, in the response. As 699 noted above, the terminator of the request MUST NOT use any other 700 priv-values in the Privacy header field included in the hi-entry. 702 10.1.2. Applying Privacy 704 When a request is retargeted to a URI associated with a domain for 705 which the SIP intermediary is not responsible or a response is 706 forwarded, a Privacy Service at the boundary of the domain applies 707 the appropriate privacy based on the value of the Privacy header 708 field in the request and in the individual hi-entries. 710 If there is a Privacy header field in the request with a priv-value 711 of "header" or "history", then the hi-targeted-to-uris in the hi- 712 entries, associated with the domain for which a SIP intermediary is 713 responsible, are anonymized. The Privacy Service MUST change any hi- 714 targeted-to-uris in the hi-entries that have not been anonymized to 715 anonymous URIs containing a domain of anonymous.invalid (e.g., 716 anonymous@anonymous.invalid). If the hi-targeted-to-uri in the hi- 717 entry contains an Privacy header field, then the Privacy header field 718 value MUST be removed from the hi-entry. Once all the appropriate 719 hi-entries have been anonymized, the priv-value of "history" MUST be 720 removed from the Privacy header field. If there are no remaining 721 priv-values in the Privacy header field, the Privacy header field 722 MUST be removed from the request per [RFC3323]. 724 If there is not a Privacy header field in the request or response 725 that is being forwarded, the Privacy Service MUST anonymize any hi- 726 entries, associated with the domain for which a SIP intermediary is 727 responsible, that contain a Privacy header field with a priv-value of 728 "history". The Privacy Service MUST populate the hi-targeted-to-uri 729 with an anonymous URI with a domain of anonymous.invalid (e.g., 730 anonymous@anonymous.invalid). Any other priv-values in the Privacy 731 header field in the hi-entries MUST be ignored. In any case, the 732 Privacy Service MUST remove the Privacy header field from the hi- 733 entries prior to forwarding. 735 10.2. Reason in the History-info Header Field 737 If the retargeting is due to receipt of an explicit SIP response and 738 the response contains any Reason header fields (see [RFC3326]), then 739 the SIP entity MUST include the Reason header fields in the hi- 740 targeted-to-uri containing the URI of the request that was 741 retargeted, unless the hi-targeted-to-uri is a Tel-URI. If the SIP 742 response does not contain a Reason header field, the SIP entity MUST 743 include a Reason header field, containing the SIP Response Code that 744 triggered the retargeting, in the hi-targeted-to-uri containing the 745 URI of the request that was retargeted, except in the case that the 746 hi-targeted-to-uri is a Tel-URI. 748 If a request has timed out (instead of being explicitly rejected), 749 the SIP entity MUST include a Reason header field, containing a SIP 750 error response code of 408 "Request Timeout" in hi-targeted-to-uri 751 containing the URI of the request that was retargeted. The SIP 752 entity MAY also include a Reason header field in the hi-targeted-to- 753 uri containing the URI of the request that was retargeted as a result 754 of internal retargeting. 756 If additional Reason headers are defined in the future per [RFC3326], 757 the use of these Reason headers for the History-Info header field 758 MUST follow the same rules as described above. 760 10.3. Indexing in the History-Info Header Field 762 In order to maintain ordering and accurately reflect the retargeting 763 of the request, the SIP entity MUST add an hi-index to each hi-entry. 764 Per the syntax in Section 5, the hi-index consists of a series of 765 digits separated by dots (e.g., 1.1.2). Each dot reflects a SIP 766 forwarding hop. The digit following each dot reflects the order in 767 which a request was retargeted at the hop. The highest digit at each 768 hop reflects the number of entities to which the request has been 769 retargeted at the specific hop (i.e., the number of branches). Thus, 770 the indexing results in a logical tree representation for the history 771 of the request. 773 The first index in a series of History-Info entries MUST be set to 1. 774 In the case that a SIP entity (intermediary or UAS) adds an hi-entry 775 on behalf of the previous hop, the hi-index MUST be set to 1. For 776 each forward hop (i.e., each new level of indexing), the hi-index 777 MUST start at 1. An increment of 1 MUST be used for advancing to a 778 new branch. 780 The basic rules for adding the hi-index are summarized as follows: 782 1. Basic Forwarding: In the case of a request that is being 783 forwarded, the hi-index reflects the increasing length of the 784 branch. In this case, the SIP entity MUST read the value from 785 the History-info header field in the received request and MUST 786 add another level of indexing by appending the dot delimiter 787 followed by an initial hi-index for the new level of 1. For 788 example, if the hi-index in the last History-info header field in 789 the received request is 1.1, a proxy would add an hi-entry with 790 an hi-index to 1.1.1 and forward the request. 792 2. Retargeting within a processing entity - 1st instance: For the 793 first instance of retargeting within a processing entity, the SIP 794 entity MUST calculate the hi-index as prescribed for basic 795 forwarding. 797 3. Retargeting within a processing entity - subsequent instance: For 798 each subsequent retargeting of a request by the same SIP entity, 799 the SIP entity MUST add another branch. The SIP entity MUST 800 calculate the hi-index for each new branch by incrementing the 801 value from the hi-index in the last hi-entry at the current 802 level. Per the example above, the hi-index in the next request 803 forwarded by this same SIP entity would be 1.1.2. 805 4. Retargeting based upon a Response: In the case of retargeting due 806 to a specific response (e.g., 302), the SIP entity MUST calculate 807 the hi-index calculated per rule 3. That is, the lowest/last 808 digit of the hi-index MUST be incremented (i.e., a new branch is 809 created), with the increment of 1. For example, if the hi-index 810 in the History-Info header of the sent request is 1.2 and the 811 response to the request is a 302, then the hi-index in the 812 History-Info header field for the new hi-targeted- to-URI would 813 be 1.3. 815 5. Forking requests: If the request forwarding is done in multiple 816 forks (sequentially or in parallel), the SIP entity MUST set the 817 hi-index for each hi-entry for each forked request per the rules 818 above, with each new request having a unique index. Each index 819 MUST be sequentially assigned. For example, if the index in the 820 last History-Info header field in the received request is 1.1, 821 this processing entity would initialize its index to 1.1.1 for 822 the first fork, 1.1.2 for the second, and so forth (see Figure 1 823 for an example). Note that for each individual fork, only the 824 hi-entry corresponding to that fork is included (e.g., the hi- 825 entry for fork 1.1.1 is not included in the request sent to fork 826 1.1.2, and vice-versa). 828 10.4. Mechanism for Target Determination in the History-Info Header 829 Field 831 This specification defines two header field parameters, "rc" and 832 "mp", indicating two non-inclusive mechanisms by which a new target 833 for a request is determined. Both parameters contain an index whose 834 value is the hi-index of the hi-entry with an hi-targeted-to-uri that 835 represents the Request-URI that was retargeted. 837 The SIP entity MUST determine the specific parameter field to be 838 included in the History-info header field as the targets are added to 839 the target set per the procedures in section 16.5 of [RFC3261] or per 840 section 8.1.3.4 [RFC3261] in the case of 3xx responses. In the 841 latter case, the specific header parameter field in the Contact 842 header becomes the header field parameter that is used in the hi- 843 entry when the request is retargeted. If the Contact header field 844 does not contain an "rc" or "mp" header field parameter, then the SIP 845 entity MUST NOT include an "rc" or "mp" in the hi-entry when the 846 request is retargeted. 848 The SIP entity (intermediary or redirect server) determines the 849 specific header field parameter to be used based on the following 850 criteria: 852 o "rc": The target was determined based on a contact that is bound 853 to an AOR in an abstract location service for the Request-URI 854 being retargeted. 856 o "mp": The target was determined based on a mapping to a user other 857 than the user associated with the Request-URI being retargeted. 859 Note that there are two scenarios by which the "mp" parameter can be 860 derived. 862 o The mapping was done by the receiving entity on its own authority, 863 in which case the mp-value is the parent index of the hi-entry's 864 index. 866 o The mapping was done due to receiving a 3xx response, in which 867 case the mp-value is an earlier sibling of the hi-entry's index, 868 that of the downstream request which received the 3xx response. 870 11. Application Considerations 872 History-Info provides a very flexible building block that can be used 873 by intermediaries and UAs for a variety of services. Prior to any 874 application usage of the History-Info header field parameters, the 875 SIP entity that processes the hi-entries MUST evaluate the hi- 876 entries. The SIP entity MUST determine if there are gaps in the 877 indices. Gaps are possible if the request is forwarded through 878 intermediaries that do not support the History-info header field and 879 are reflected by the existence of multiple hi-entries with an index 880 of "1". Gaps are also possible in the case of parallel forking if 881 there is an outstanding request at the time the SIP entity sends a 882 response as described in Section 9.4. Thus, if gaps are detected, 883 the SIP entity MUST NOT treat this as an error, but rather indicate 884 to any applications that there are gaps. The most complete 885 information available to the application is the History-Info entries 886 starting with the last hi-entry with an index of "1". The 887 interpretation of the information in the History-info header field 888 depends upon the specific application; an application might need to 889 provide special handling in some cases where there are gaps. 891 The following summarizes the categories of information that 892 applications can use: 894 1. Complete history information - e.g., for debug or other 895 operational and management aspects, optimization of determining 896 targets to avoid retargeting to the same URI, etc. This 897 information is relevant to proxies, UACs and UASs. 899 2. Hi-entry with the index that matches the value of the last hi- 900 entry with a "rc" header parameter in the Request received by a 901 UAS - i.e., the Request URI associated with the destination of 902 the request was determined based on an AOR-to-contact binding in 903 an abstract location service. 905 3. Hi-entry with the index that matches the value of the last hi- 906 entry with a "mp" header parameter in the Request received by a 907 UAS - i.e., the last Request URI that was mapped to reach the 908 destination. 910 4. Hi-entry with the index that matches the value of the first hi- 911 entry with a "rc" header parameter in the Request received by a 912 UAS. Note, this would be the original AoR if all the entities 913 involved support the History-info header field and there is 914 absence of a "mp" header parameter prior to the "rc" header 915 parameter in the History-info header field. However, there is no 916 guarantee that all entities will support History-Info, thus the 917 first hi-entry with an "rc" header parameter within the domain 918 associated with the target URI at the destination is more likely 919 to be useful. 921 5. Hi-entry with the index that matches the value of the first hi- 922 entry with a "mp" header parameter in the Request received by a 923 UAS. Note, this would be the original mapped URI if all entities 924 supported the History-info header field. However, there is no 925 guarantee that all entities will support History-Info, thus the 926 first hi-entry with an "mp" header parameter within the domain 927 associated with the target URI at the destination is more likely 928 to be useful. 930 In many cases, applications are most interested in the information 931 within a particular domain(s), thus only a subset of the information 932 is required. 934 Some applications may use multiple types of information. For 935 example, an Automatic Call Distribution (ACD)/Call center application 936 that utilizes the hi-entry who index matches the index of the first 937 History-Info entry with an hi-target value of "mp", may also display 938 other agents, reflected by other History-Info entries prior to 939 entries with hi-target values of "rc", to whom the call was targeted 940 prior to its arrival at the current agent. This could allow the 941 agent the ability to decide how they might forward or reroute the 942 call if necessary (avoiding agents that were not previously available 943 for whatever reason, etc.). 945 Since support for History-info header field is optional, a service 946 MUST define default behavior for requests and responses not 947 containing History-Info headers. For example, an entity may receive 948 only partial History-Info entries or entries which are not tagged 949 appropriately with an hi-target parameter. This may not impact some 950 applications (e.g., debug), however, it could require some 951 applications to make some default assumptions in this case. For 952 example, in an ACD scenario, the application could select the oldest 953 hi-entry with the domain associated with the ACD system and display 954 that as the original called party. Depending upon how and where the 955 request may have been retargeted, the complete list of agents to whom 956 the call was targeted may not be available. 958 12. Security Considerations 960 The security requirements for this document are specified in 961 Appendix A.1. 963 This document defines a header for SIP. The use of the Transport 964 Layer Security (TLS) protocol [RFC5246] as a mechanism to ensure the 965 overall confidentiality of the History-Info headers (SEC-req-4) is 966 strongly RECOMMENDED. This results in History-Info having at least 967 the same level of security as other headers in SIP that are inserted 968 by intermediaries. With TLS, History-Info headers are no less, nor 969 no more, secure than other SIP headers, which generally have even 970 more impact on the subsequent processing of SIP sessions than the 971 History-info header field. 973 Note that while using the SIPS scheme (as per [RFC5630]) protects 974 History-Info from tampering by arbitrary parties outside the SIP 975 message path, all the intermediaries on the path are trusted 976 implicitly. A malicious intermediary could arbitrarily delete, 977 rewrite, or modify History-Info. This specification does not attempt 978 to prevent or detect attacks by malicious intermediaries. 980 13. IANA Considerations 982 This document requires several IANA registrations detailed in the 983 following sections. 985 This document updates [RFC4244] but uses the same SIP header field 986 name and option tag. The IANA registry needs to update the 987 references to [RFC4244] with [RFCXXXX]. 989 13.1. Registration of New SIP History-Info Header Field 991 This document defines a SIP header field name: History-Info and an 992 option tag: histinfo. The following changes have been made to 993 http:///www.iana.org/assignments/sip-parameters The following row has 994 been added to the header field section:. 996 The following row has been added to the header field section: 998 Header Name Compact Form Reference 999 ----------- ------------ --------- 1000 History-Info none [RFCXXXX] 1002 The following has been added to the Options Tags section: 1004 Name Description Reference 1005 ---- ----------- --------- 1006 histinfo When used with the Supported header, [RFCXXXX] 1007 this option tag indicates the UAC 1008 supports the History Information to be 1009 captured for requests and returned in 1010 subsequent responses. This tag is not 1011 used in a Proxy-Require or Require 1012 header field since support of 1013 History-Info is optional. 1015 Note to RFC Editor: Please replace RFC XXXX with the RFC number of 1016 this specification. 1018 13.2. Registration of "history" for SIP Privacy Header Field 1020 This document defines a priv-value for the SIP Privacy header field: 1021 history The following changes have been made to 1022 http://www.iana.org/assignments/sip-priv-values The following has 1023 been added to the registration for the SIP Privacy header field: 1025 Name Description Registrant Reference 1026 ---- ----------- ---------- --------- 1027 history Privacy requested for Mary Barnes [RFCXXXX] 1028 History-info header mary.barnes@polycom.com 1029 fields(s) 1031 Note to RFC Editor: Please replace RFC XXXX with the RFC number of 1032 this specification. 1034 13.3. Registration of Header Field Parameters 1036 This specification defines the following new SIP header field 1037 parameters in the SIP Header Field parameter sub-registry in the SIP 1038 Parameter Registry, http:/www.iana.org/assignments/sip-parameters. 1040 Header Field Parameter Name Predefined Reference 1041 Values 1042 _____________________________________________________________________ 1043 History-Info mp No [RFC xxxx] 1044 History-Info rc No [RFC xxxx] 1045 Contact mp No [RFC xxxx] 1046 Contact rc No [RFC xxxx] 1048 Note to RFC Editor: Please replace RFC XXXX with the RFC number of 1049 this specification. 1051 14. Acknowledgements 1053 Jonathan Rosenberg et al produced the document that provided 1054 additional use cases precipitating the requirement for the new header 1055 parameters to capture the method by which a Request URI is 1056 determined. The authors would like to acknowledge the constructive 1057 feedback provided by Ian Elz, Paul Kyzivat, John Elwell, Hadriel 1058 Kaplan and Dale Worley. 1060 Mark Watson, Cullen Jennings and Jon Peterson provided significant 1061 input into the initial work that resulted in the development of of 1062 [RFC4244]. The editor would like to acknowledge the constructive 1063 feedback provided by Robert Sparks, Paul Kyzivat, Scott Orton, John 1064 Elwell, Nir Chen, Palash Jain, Brian Stucker, Norma Ng, Anthony 1065 Brown, Jayshree Bharatia, Jonathan Rosenberg, Eric Burger, Martin 1066 Dolly, Roland Jesske, Takuya Sawada, Sebastien Prouvost, and 1067 Sebastien Garcin in the development of [RFC4244]. 1069 The editor would like to acknowledge the significant input from Rohan 1070 Mahy on some of the normative aspects of the ABNF for [RFC4244], 1071 particularly around the need for and format of the index and around 1072 the security aspects. 1074 15. Changes from RFC 4244 1076 This RFC replaces [RFC4244]. 1078 Deployment experience with [RFC4244] over the years has shown a 1079 number of issues, warranting an update: 1081 o In order to make [RFC4244] work in "real life", one needs to make 1082 "assumptions" on how History-Info is used. For example, many 1083 implementations filter out many entries, and only leave specific 1084 entries corresponding, for example, to first and last redirection. 1085 Since vendors uses different rules, it causes significant 1086 interoperability isssues. 1088 o [RFC4244] is overly permissive and evasive about recording 1089 entries, causing interoperability issues. 1091 o The examples in the call flows had errors, and confusing because 1092 they often assume "loose routing". 1094 o [RFC4244] has lots of repetitive and unclear text due to the 1095 combination of requirements with solution. 1097 o [RFC4244] gratuitously mandates the use of TLS on every hop. No 1098 existing implementation enforces this rule, and instead, the use 1099 of TLS or not is a general SIP issue, not an [RFC4244] issue per 1100 se. 1102 o [RFC4244] does not include clear procedures on how to deliver 1103 current target URI information to the UAS when the Request-URI is 1104 replaced with a contact. 1106 o [RFC4244] does not allow for marking History-Info entries for easy 1107 processing by User Agents. 1109 The following summarizes the functional changes between this 1110 specification and [RFC4244]: 1112 1. Added header field parameters to capture the specific method by 1113 which a target is determined to facilitate processing by users of 1114 the History-info header field entries. A specific header field 1115 parameter is captured for each of the target URIs as the target 1116 set is determined (per section 16.5 of [RFC3261]). The header 1117 field parameter is used in both the History-Info and the Contact 1118 header fields. 1120 2. Rather than recommending that entries be removed in the case of 1121 certain values of the Privacy header field, the entries are 1122 anonymized. 1124 3. Updated the security section to be equivalent to the security 1125 recommendations for other SIP headers inserted by intermediaries. 1127 The first 2 changes are intended to facilitate application usage of 1128 the History-info header field and eliminate the need to make 1129 assumptions based upon the order of the entries and ensure that the 1130 most complete set of information is available to the applications. 1132 In addition, editorial changes were done to both condense and clarify 1133 the text, moving the requirements to an appendix and removing the 1134 inline references to the requirements. The examples were simplified 1135 and updated to reflect the protocol changes. Several of the call 1136 flows in the appendix were removed and put into a separate document 1137 that includes additional use cases that require the new header 1138 parameters. 1140 15.1. Backwards compatibility 1142 This specification is backwards compatible since [RFC4244] allows for 1143 the addition of new optional parameters. This specification adds an 1144 optional SIP header field parameter to the History-Info and Contact 1145 headers. Entities that have not implemented this specification MUST 1146 ignore these parameters, however, per [RFC4244] an entity MUST NOT 1147 remove this parameter from an hi-entry. 1149 16. Changes since last Version 1151 NOTE TO THE RFC-Editor: Please remove this section prior to 1152 publication as an RFC. 1154 Changes from 03 to 04: 1156 1. Reorganization of sections per John Elwell's comments - i.e., a 1157 common section for building HI referenced by the UA, Intermediary 1158 and Redirect server sections. 1160 2. Removing the use of "escape" when describing the handling of the 1161 Privacy and Reason header fields. 1163 3. Clarification of TEL URIs in terms of not having a Privacy or 1164 Reason header field in the hi-targeted-to-uri. 1166 Changes from 02 to 03: 1168 1. Lots of editorial: 1170 A. Reorganized sections similar to the RFC 4244 order - i.e., 1171 introduce header field parameters and syntax first, then 1172 describe how the functional entities use the header. This 1173 removes redundant (and often inconsistent) text describing 1174 the parameters. 1176 B. Expanded use of "header" to "header field" 1178 C. More precision in terms of "escaping" of the Privacy and 1179 Reason headers in the hi-targeted-to-uri (versus 1180 "adding"/"setting"/etc. them to the hi-entry). 1182 D. Consistent use of parameter names (i.e., hi-entry versus 1183 entry, hi-target versus target, etc.) 1185 E. Moved item 6 in the Index section to the section on Response 1186 handling 1188 F. Removed last remaining vestiges of inline references to 1189 requirements. 1191 2. Clarifications of functionality/applicability including: 1193 A. which messages may contain History-Info 1195 B. removing security text with regards to being able to figure 1196 out if there are missing entries when using TLS (issue #44) 1198 C. More complete information on the new header field parameters 1199 as they relate to the hi-target parameter. 1201 D. Changed wording from passive to active for normative 1202 statements in many cases and removed superfluous normative 1203 language. 1205 3. Rewrite of the Privacy section to address issues and splitting 1206 into the setting of the Privacy header fields and the processing/ 1207 application of the privacy header field priv-values. 1209 4. Rewrite of the Reason header field section - simplifying the text 1210 and adding back the RFC 4244 text with regards to the use of the 1211 Reason header field in cases of internal retargeting. 1213 Changes from 01 to 02: 1215 1. Editorial nits/clarifications. [Issues: 1,6,17,18,21- 1216 23,25,26,30-33,35-37,39,40] 1218 2. Removing extraneous 4244 text - e.g., errors in flows, 1219 "stronger" security, "session" privacy. [Issues: 3,5,7,11 ] 1221 3. Updated definition of "retarget" to be all encompassing - i.e., 1222 also includes internal changes of target URI. Clarified text 1223 for "internal retarging" in proxy section. [Issues: 2,8,9] 1225 4. Clarified that the processing for Proxies is equally applicable 1226 to other SIP intermediaries. [Issue: 9]. 1228 5. Changed more SHOULDs to MUSTs. [Issue: 10] 1230 6. Fixes to Application considerations section. [Issues: 12-15] 1232 7. Changed language in the procedure for Indexing to normative 1233 language. 1235 8. Clarifications for UAC processing: 1237 * MUST add hi-entry. [Issue: 28] 1239 * Clarify applicability to B2BUA. [Issue: 29] 1241 * Fixed text for indexing for UAC in case of 3xx. 1243 9. Changed "hit" URI parameter to header parameters: [Issues:4,40] 1245 * Added index to all target header parameters. [Issues: 41] 1247 * Updated all the relevant sections documenting setting and use 1248 of new header parameters. [Issue: 40] 1250 10. Updated/clarified privacy handling. [Issue: 16] 1252 11. Updated Redirect Server section to allow adding History-info 1253 header fields. [Issue: 24 ] 1255 12. Added text around restrictions for Tel-URIs - i.e., no privacy 1256 or reason. [Issues: 4, 12] 1258 13. Updated text for forking - what goes in response. [Issues: 1259 19,20] 1261 Changes from 00 to 01: 1263 1. Moved examples (except first) in appendix to a new 1264 (informational) document. 1266 2. Updated UAS and UAC sections to clarify and expand on the 1267 handling of the History-info header field. 1269 3. Updated the Application considerations section: 1271 * Included more detail with regards to how applications can make 1272 use of the information, in particular based on the new tags. 1274 * Removed privacy consideration (2nd bullet) since privacy is 1275 now accomplished by anonymizing rather than removal of 1276 entries. 1278 Changes from (individual) barnes-sipcore-4244bis-03 to (WG) ietf- 1279 sipcore-4244bis-00: 1281 1. Added a new SIP/SIPS URI parameter to tag the URIs as they are 1282 added to the target list and those returned in the contact header 1283 in a 3xx response. 1285 2. Updated description of "target" parameter to use the new URI 1286 parameter value in setting the value for the parameter. 1288 3. Clarified privacy. 1290 4. Changed handling at redirect server to include the use of the new 1291 URI parameter and to remove the functionality of adding the 1292 History-Info entries (basically reverting to core 4244 1293 processing). 1295 5. Additional text to clarify that a service such as voicemail can 1296 be done in multiple ways. 1298 6. Editorial changes including removal of some vestiges of tagging 1299 all entries (including the "aor" tag). 1301 Changes from barnes-sipcore-4244bis-02 to 03: 1303 1. Fixed problem with indices in example in voicemail example. 1305 2. Removed oc and rt from the Hi-target parameter. 1307 3. Removed aor tag 1309 4. Added index parameter to "mp" 1310 5. Added use-cases and call-flows from target-uri into appendix. 1312 Changes from barnes-sipcore-4244bis-01 to 02: 1314 1. Added hi-aor parameter that gets marked on the "incoming" hi- 1315 entry. 1317 2. Hi-target parameter defined to be either rc, oc, mp, rt, and now 1318 gets included when adding an hi-entry. 1320 3. Added section on backwards compatibility, as well as added the 1321 recognition and handling of requests that do not support this 1322 specification in the appropriate sections. 1324 4. Updated redirect server/3xx handling to support the new 1325 parameters - i.e., the redirecting entity must add the new hi- 1326 entry since the proxy does not have access to the information as 1327 to how the Contact was determined. 1329 5. Added section on normative differences between this document and 1330 RFC 4244. 1332 6. Restructuring of document to be more in line with current IETF 1333 practices. 1335 7. Moved Requirements section into an Appendix. 1337 8. Fixed ABNF to remove unintended ordering requirement on hi-index 1338 that was introduced in attempting to illustrate it was a 1339 mandatory parameter. 1341 Changes from barnes-sipcore-4244bis-00 to 01 : 1343 1. Clarified "retarget" definition. 1345 2. Removed privacy discussion from optionality section - just refer 1346 to privacy section. 1348 3. Removed extraneous text from target-parameter (leftover from sip- 1349 4244bis). Changed the terminology from the "reason" to the 1350 "mechanism" to avoid ambiguity with parameter. 1352 4. Various changes to clarify some of the text around privacy. 1354 5. Reverted proxy response handling text to previous form - just 1355 changing the privacy aspects to anonymize, rather than remove. 1357 6. Other editorial changes to condense and simplify. 1359 7. Moved Privacy examples to Appendix. 1361 8. Added forking to Basic call example. 1363 Changes from barnes-sipcore-4244bis-00 to 01 : 1365 1. Clarified "retarget" definition. 1367 2. Removed privacy discussion from optionality section - just refer 1368 to privacy section. 1370 3. Removed extraneous text from target-parameter (leftover from sip- 1371 4244bis). Changed the terminology from the "reason" to the 1372 "mechanism" to avoid ambiguity with parameter. 1374 4. Various changes to clarify some of the text around privacy. 1376 5. Reverted proxy response handling text to previous form - just 1377 changing the privacy aspects to anonymize, rather than remove. 1379 6. Other editorial changes to condense and simplify. 1381 7. Moved Privacy examples to Appendix. 1383 8. Added forking to Basic call example. 1385 Changes from barnes-sip-4244bis-00 to barnes-sipcore-4244bis-00: 1387 1. Added tags for each type of retargeting including proxy hops, 1388 etc. - i.e., a tag is defined for each specific mechanism by 1389 which the new Request-URI is determined. Note, this is 1390 extremely helpful in terms of backwards compatibility. 1392 2. Fixed all the examples. Made sure loose routing was used in all 1393 of them. 1395 3. Removed example where a proxy using strict routing is using 1396 History-Info for avoiding trying same route twice. 1398 4. Remove redundant Redirect Server example. 1400 5. Index is now mandated to start at "1" instead of recommended. 1402 6. Updated 3xx behavior as the entity sending the 3XX response MUST 1403 add the hi-target attribute to the previous hi-entry to ensure 1404 that it is appropriately tagged (i.e., it's the only one that 1405 knows how the contact in the 3xx was determined.) 1407 7. Removed lots of ambiguity by making many "MAYs" into "SHOULDs" 1408 and some "SHOULDs" into "MUSTs". 1410 8. Privacy is now recommended to be done by anonymizing entries as 1411 per RFC 3323 instead of by removing or omitting hi-entry(s). 1413 9. Requirement for TLS is now same level as per RFC 3261. 1415 10. Clarified behavior for "Privacy" (i.e., that Privacy is for Hi- 1416 entries, not headers). 1418 11. Removed "OPTIONALITY" as specific requirements, since it's 1419 rather superflous. 1421 12. Other editorial changes to remove redundant text/sections. 1423 Changes from RFC4244 to barnes-sip-4244bis-00: 1425 1. Clarified that HI captures both retargeting as well as cases of 1426 just forwarding a request. 1428 2. Added descriptions of the usage of the terms "retarget", 1429 "forward" and "redirect" to the terminology section. 1431 3. Added additional examples for the functionality provided by HI 1432 for core SIP. 1434 4. Added hi-target parameter values to HI header to ABNF and 1435 protocol description, as well as defining proxy, UAC and UAS 1436 behavior for the parameter. 1438 5. Simplified example call flow in section 4.5. Moved previous call 1439 flow to appendix. 1441 6. Fixed ABNF per RFC4244 errata "dot" -> "." and added new 1442 parameter. 1444 17. References 1446 17.1. Normative References 1448 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1449 A., Peterson, J., Sparks, R., Handley, M., and E. 1450 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1451 June 2002. 1453 [RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason 1454 Header Field for the Session Initiation Protocol (SIP)", 1455 RFC 3326, December 2002. 1457 [RFC3323] Peterson, J., "A Privacy Mechanism for the Session 1458 Initiation Protocol (SIP)", RFC 3323, November 2002. 1460 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1461 Requirement Levels", BCP 14, RFC 2119, March 1997. 1463 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1464 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1466 [RFC4244] Barnes, M., "An Extension to the Session Initiation 1467 Protocol (SIP) for Request History Information", RFC 4244, 1468 November 2005. 1470 17.2. Informative References 1472 [RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User 1473 Agent URIs (GRUUs) in the Session Initiation Protocol 1474 (SIP)", RFC 5627, October 2009. 1476 [RFC5630] Audet, F., "The Use of the SIPS URI Scheme in the Session 1477 Initiation Protocol (SIP)", RFC 5630, October 2009. 1479 [RFC3087] Campbell, B. and R. Sparks, "Control of Service Context 1480 using SIP Request-URI", RFC 3087, April 2001. 1482 [RFC4240] Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network 1483 Media Services with SIP", RFC 4240, December 2005. 1485 [RFC3969] Camarillo, G., "The Internet Assigned Number Authority 1486 (IANA) Uniform Resource Identifier (URI) Parameter 1487 Registry for the Session Initiation Protocol (SIP)", 1488 BCP 99, RFC 3969, December 2004. 1490 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", 1491 RFC 3966, December 2004. 1493 Appendix A. Request History Requirements 1495 The following list constitutes a set of requirements for a "Request 1496 History" capability. 1498 1. CAPABILITY-req: The "Request History" capability provides a 1499 capability to inform proxies and UAs involved in processing a 1500 request about the history/progress of that request. Although 1501 this is inherently provided when the retarget is in response to a 1502 SIP redirect, it is deemed useful for non-redirect retargeting 1503 scenarios, as well. 1505 2. GENERATION-req: "Request History" information is generated when 1506 the request is retargeted. 1508 A. In some scenarios, it might be possible for more than one 1509 instance of retargeting to occur within the same Proxy. A 1510 proxy MUST also generate Request History information for the 1511 'internal retargeting'. 1513 B. An entity (UA or proxy) retargeting in response to a redirect 1514 or REFER MUST include any Request History information from 1515 the redirect/REFER in the new request. 1517 3. ISSUER-req: "Request History" information can be generated by a 1518 UA or proxy. It can be passed in both requests and responses. 1520 4. CONTENT-req: The "Request History" information for each 1521 occurrence of retargeting shall include the following: 1523 A. The new URI or address to which the request is in the process 1524 of being retargeted, 1526 B. The URI or address from which the request was retargeted, and 1527 wether the retarget URI was an AOR 1529 C. The mechanism by which the new URI or address was determined, 1531 D. The reason for the Request-URI or address modification, 1533 E. Chronological ordering of the Request History information. 1535 5. REQUEST-VALIDITY-req: Request History is applicable to requests 1536 not sent within an early or established dialog (e.g., INVITE, 1537 REGISTER, MESSAGE, and OPTIONS). 1539 6. BACKWARDS-req: Request History information may be passed from the 1540 generating entity backwards towards the UAC. This is needed to 1541 enable services that inform the calling party about the dialog 1542 establishment attempts. 1544 7. FORWARDS-req: Request History information may also be included by 1545 the generating entity in the request, if it is forwarded onwards. 1547 A.1. Security Requirements 1549 The Request History information is being inserted by a network 1550 element retargeting a Request, resulting in a slightly different 1551 problem than the basic SIP header problem, thus requiring specific 1552 consideration. It is recognized that these security requirements can 1553 be generalized to a basic requirement of being able to secure 1554 information that is inserted by proxies. 1556 The potential security problems include the following: 1558 1. A rogue application could insert a bogus Request History-Info 1559 entry either by adding an additional hi-entry as a result of 1560 retargeting or entering invalid information. 1562 2. A rogue application could re-arrange the Request History 1563 information to change the nature of the end application or to 1564 mislead the receiver of the information. 1566 3. A rogue application could delete some or all of the Request 1567 History information. 1569 Thus, a security solution for "Request History" must meet the 1570 following requirements: 1572 1. SEC-req-1: The entity receiving the Request History must be able 1573 to determine whether any of the previously added Request History 1574 content has been altered. 1576 2. SEC-req-2: The ordering of the Request History information must 1577 be preserved at each instance of retargeting. 1579 3. SEC-req-3: The entity receiving the information conveyed by the 1580 Request History must be able to authenticate the entity providing 1581 the request. 1583 4. SEC-req-4: To ensure the confidentiality of the Request History 1584 information, only entities that process the request SHOULD have 1585 visibility to the information. 1587 It should be noted that these security requirements apply to any 1588 entity making use of the Request History information. 1590 A.2. Privacy Requirements 1592 Since the Request-URI that is captured could inadvertently reveal 1593 information about the originator, there are general privacy 1594 requirements that MUST be met: 1596 1. PRIV-req-1: The entity retargeting the Request must ensure that 1597 it maintains the network-provided privacy (as described in 1598 [RFC3323]) associated with the Request as it is retargeted. 1600 2. PRIV-req-2: The entity receiving the Request History must 1601 maintain the privacy associated with the information. In 1602 addition, local policy at a proxy may identify privacy 1603 requirements associated with the Request-URI being captured in 1604 the Request History information. 1606 3. PRIV-req-3: Request History information subject to privacy shall 1607 not be included in ougoing messages unless it is protected as 1608 described in [RFC3323]. 1610 Appendix B. Example call flows 1612 The scenarios in this section provide sample use cases for the 1613 History-info header field for informational purposes only. They are 1614 not intended to be normative. A basic forking use case is included, 1615 along with two use cases illustrating the use of the privacy. 1617 B.1. Sequentially Forking (History-Info in Response) 1619 This scenario highlights an example where the History-Info in the 1620 response is useful to an application or user that originated the 1621 request. 1623 Alice sends a call to Bob via sip:example.com. The proxy sip: 1624 example.com sequentially tries Bob on a SIP UA that has bound a 1625 contact with the sip:bob@example.com AOR, and then several alternate 1626 addresses (Office and Home) unsuccessfully before sending a response 1627 to Alice. The hi-entry containing the initial contact is the hi- 1628 entry just prior to the first hi-entry tagged with an hi-target value 1629 of "rc". In this example, the Office and Home are not the same AOR 1630 as sip:bob@example.com, but rather different AORs that have been 1631 configured as alternate addresses for Bob in the proxy. In other 1632 words, Office and Bob are not bound through SIP Registration with 1633 Bob's AOR. This type of arrangement is common for example when a 1634 "routing" rule to a PSTN number is manually configured in a Proxy. 1635 These hi-entries are identified by the index contained in the hi- 1636 target "mp" parameter in the hi-entries. 1638 This scenario illustrates that by providing the History-Info to 1639 Alice, the end-user or an application at Alice could make a decision 1640 on how best to attempt finding Bob without sending multiple requests 1641 to the same destination. Upon receipt of the response containing the 1642 History-Info entries, the Request URIs for the History-Info entries 1643 tagged with "mp" are extracted. Those Request-URIs can be compared 1644 to other URIs (if any) that might be attempted in order to establish 1645 the session with Bob. Thus, avoiding another INVITE to Bob's home 1646 phone. Without this mechanism, Alice might well attempt to reach Bob 1647 at his office phone, which would then retarget the request to Bob's 1648 home phone. When that attempt failed, then Alice might attempt to 1649 reach Bob directly at his home phone, unknowingly for a third time. 1651 Alice example.com Bob Office Home 1652 | | | | | 1653 | INVITE F1 | | | | 1654 |----------->| INVITE F2 | | | 1655 | |----------------->| | | 1656 | 100 Trying F3 | | | 1657 |<-----------| 302 Move Temporarily F4 | | 1658 | |<-----------------| | | 1659 | | ACK F5 | | | 1660 | |----------------->| | | 1661 | | INVITE F6 | | 1662 | |-------------------------->| | 1663 | | 180 Ringing F7 | | 1664 | |<--------------------------| | 1665 | 180 Ringing F8 | | 1666 |<-----------| retransmit INVITE | | 1667 | |-------------------------->| | 1668 | | ( timeout ) | | 1669 | | INVITE F9 | 1670 | |----------------------------------->| 1671 | | 100 Trying F10 | 1672 | |<-----------------------------------| 1673 | | 486 Busy Here F11 | 1674 | |<-----------------------------------| 1675 | 486 Busy Here F12 | 1676 |<-----------| ACK F13 | 1677 | |----------------------------------->| 1678 | ACK F14 | | 1679 |----------->| | 1680 Message Details 1682 F1 INVITE alice -> example.com 1684 INVITE sip:alice@example.com SIP/2.0 1685 Via: SIP/2.0/TCP 192.0.2.3:5060 1686 From: Alice 1687 To: Bob 1688 Supported: histinfo 1689 Call-Id: 12345600@example.com 1690 CSeq: 1 INVITE 1691 History-Info: ;index=1 1692 Contact: Alice 1693 Content-Type: application/sdp 1694 Content-Length: 1695 1697 F2 INVITE example.com -> Bob 1699 INVITE sip:bob@192.0.2.4 SIP/2.0 1700 Via: SIP/2.0/TCP proxy.example.com:5060 1701 Via: SIP/2.0/TCP 192.0.2.3:5060 1702 From: Alice 1703 To: Bob 1704 Supported: histinfo 1705 Call-Id: 12345600@example.com 1706 CSeq: 1 INVITE 1707 Record-Route: 1708 History-Info: ;index=1 1709 History-Info: ;index=1.1;rc=1 1710 Contact: Alice 1711 Content-Type: application/sdp 1712 Content-Length: 1713 1715 F3 100 Trying example.com -> alice 1717 SIP/2.0 100 Trying 1718 Via: SIP/2.0/TCP 192.0.2.3:5060 1719 From: Alice 1720 To: Bob 1721 Call-Id: 12345600@example.com 1722 CSeq: 1 INVITE 1723 Content-Length: 0 1724 F4 302 Moved Temporarily Bob -> example.com 1726 SIP/2.0 302 Moved Temporarily 1727 Via: SIP/2.0/TCP proxy.example.com:5060 1728 Via: SIP/2.0/TCP 192.0.2.3:5060 1729 From: Alice 1730 To: Bob ;tag=3 1731 Call-Id: 12345600@example.com 1732 CSeq: 1 INVITE 1733 Record-Route: 1734 History-Info: ;index=1 1735 History-Info: ;index=1.1;rc=1 1736 Contact: ;mp=1 1737 Content-Length: 0 1739 F5 ACK 192.0.2.4 -> Bob 1741 ACK sip:home@example.com SIP/2.0 1742 Via: SIP/2.0/TCP proxy.example.com:5060 1743 From: Alice 1744 To: Bob 1745 Call-Id: 12345600@example.com 1746 CSeq: 1 ACK 1747 Content-Length: 0 1749 F6 INVITE example.com -> office 1751 INVITE sip:office@192.0.2.3.com SIP/2.0 1752 Via: SIP/2.0/TCP proxy.example.com:5060;branch=2 1753 Via: SIP/2.0/TCP 192.0.2.3:5060 1754 From: Alice 1755 To: Bob 1756 Supported: histinfo 1757 Call-Id: 12345600@example.com 1758 Record-Route: 1759 History-Info: ;index=1 1760 History-Info: ;\ 1761 index=1.1;rc=1 1762 History-Info: ;index=1.2;mp=1 1763 History-Info: ;index=1.2.1 1764 CSeq: 1 INVITE 1765 Contact: Alice 1766 Content-Type: application/sdp 1767 Content-Length: 1768 1770 F7 180 Ringing office -> example.com 1772 SIP/2.0 180 Ringing 1773 Via: SIP/2.0/TCP proxy.example.com:5060;branch=2 1774 Via: SIP/2.0/TCP 192.0.2.3:5060 1775 From: Alice 1776 To: Bob ;tag=5 1777 Supported: histinfo 1778 Call-ID: 12345600@example.com 1779 Record-Route: 1780 History-Info: ;index=1 1781 History-Info: ;\ 1782 index=1.1;rc=1 1783 History-Info: ;index=1.2;mp=1 1784 History-Info: ;index=1.2.1 1785 CSeq: 1 INVITE 1786 Content-Length: 0 1788 F8 180 Ringing example.com -> alice 1790 SIP/2.0 180 Ringing 1791 Via: SIP/2.0/TCP example.com:5060 1792 From: Alice 1793 To: Bob 1794 Supported: histinfo 1795 Call-Id: 12345600@example.com 1796 History-Info: ;index=1 1797 History-Info: ;\ 1798 index=1.1;rc=1 1799 History-Info: ;index=1.2;mp=1 1800 History-Info: ;index=1.2.1 1801 CSeq: 1 INVITE 1802 Content-Length: 0 1803 F9 INVITE example.com -> home 1805 INVITE sip:home@192.0.2.6 SIP/2.0 1806 Via: SIP/2.0/TCP proxy.example.com:5060;branch=3 1807 Via: SIP/2.0/TCP 192.0.2.3:5060 1808 From: Alice 1809 To: Bob 1810 Supported: histinfo 1811 Call-Id: 12345600@example.com 1812 Record-Route: 1813 History-Info: ;index=1 1814 History-Info: ;\ 1815 index=1.1;rc=1 1816 History-Info: ;index=1.2;mp=1 1817 History-Info: ;\ 1818 index=1.2.1>;index=1.2.1 1819 History-Info: ;index=1.3;mp=1 1820 History-Info: ;index=1.3.1 1821 CSeq: 1 INVITE 1822 Contact: Alice 1823 Content-Type: application/sdp 1824 Content-Length: 1825 1827 F10 100 Trying home -> example.com 1829 SIP/2.0 100 Trying 1830 Via: SIP/2.0/TCP proxy.example.com:5060;branch=3 1831 Via: SIP/2.0/TCP 192.0.2.3:5060 1832 From: Alice 1833 To: Bob 1834 Call-Id: 12345600@example.com 1835 CSeq: 1 INVITE 1836 Content-Length: 0 1837 F11 486 Busy Here home -> example.com 1839 SIP/2.0 486 Busy Here 1840 Via: SIP/2.0/TCP proxy.example.com:5060;branch=3 1841 Via: SIP/2.0/TCP 192.0.2.3:5060 1842 From: Alice 1843 To: Bob 1844 Call-Id: 12345600@example.com 1845 Record-Route: 1846 History-Info: ;index=1 1847 History-Info: ;\ 1848 index=1.1;rc=1 1849 History-Info: ;index=1.2;mp=1 1850 History-Info: ;\ 1851 index=1.2.1>;index=1.2.1 1852 History-Info: ;index=1.3;mp=1 1853 History-Info: ;index=1.3.1 1854 CSeq: 1 INVITE 1855 Content-Length: 0 1857 F12 486 Busy Here example.com -> alice 1859 SIP/2.0 486 Busy Here 1860 Via: SIP/2.0/TCP 192.0.2.3:5060 1861 From: Alice 1862 To: Bob 1863 Call-Id: 12345600@example.com 1864 History-Info: ;index=1 1865 History-Info: ;\ 1866 index=1.1;rc=1 1867 History-Info: ;index=1.2;mp=1 1868 History-Info: ;\ 1869 index=1.2.1>;index=1.2.1 1870 History-Info: ;index=1.3;mp=1 1871 History-Info: ;index=1.3.1 1872 CSeq: 1 INVITE 1873 Content-Length: 0 1874 F13 ACK example.com -> home 1876 ACK sip:home@example.com SIP/2.0 1877 Via: SIP/2.0/TCP proxy.example.com:5060 1878 From: Alice 1879 To: Bob 1880 Call-Id: 12345600@example.com 1881 CSeq: 1 ACK 1882 Content-Length: 0 1884 F14 ACK alice -> example.com 1886 ACK sip:bob@example.com SIP/2.0 1887 Via: SIP/2.0/TCP 192.0.2.3:5060 1888 From: Alice 1889 To: Bob 1890 Call-Id: 12345600@example.com 1891 Route: 1892 CSeq: 1 ACK 1893 Content-Length: 0 1895 B.2. History-Info with Privacy Header Field 1897 This example provides a basic call scenario without forking. Alice 1898 has indicated that she wants Privacy associated with the History-Info 1899 header field entries. In addition, sip:biloxi.example.com adds 1900 Privacy header fields indicating that the History-info header field 1901 information is anonymized outside the biloxi.example.com domain. 1902 Note, that if the atlanta.example.com proxy had added privacy header 1903 fields to all its hi-entries, then all the hi-entries in the response 1904 would be anonymous. 1906 Alice atlanta.example.com biloxi.example.com Bob 1907 | | | | 1908 | INVITE sip:bob@biloxi.example.com;p=x | 1909 |--------------->| | | 1910 | Supported: histinfo | | 1911 | Privacy: History | | 1912 | History-Info: ;index=1 1913 | | | | 1914 | | INVITE sip:bob@biloxi.example.com;p=x 1915 | |--------------->| | 1916 | History-Info: ;index=1 1917 | History-Info: ;index=1.1 1918 | | | | 1919 | | | INVITE sip:bob@192.0.2.3 1920 | | |--------------->| 1921 | History-Info: ;index=1 1922 | History-Info: ;index=1.1 1923 | History-Info: ;index=1.1.1;rc=1.1 1924 | | | | 1925 | | | 200 | 1926 | | |<---------------| 1927 | History-Info: ;index=1 1928 | History-Info: ;index=1.1 1929 | History-Info: ;index=1.1.1;rc=1.1 1930 | | | | 1931 | | 200 | | 1932 | |<---------------| | 1933 | History-Info: ;index=1 1934 | History-Info: ;index=1.1 1935 | History-Info: ;index=1.1.1;rc=1.1 1936 | | | | 1937 | 200 | | | 1938 |<---------------| | | 1939 | History-Info: ;index=1 1940 | History-Info: ;index=1.1 1941 | History-Info: ;index=1.1.1;rc=1.1 1942 | | | | 1943 | ACK | | | 1944 |--------------->| ACK | | 1945 | |--------------->| ACK | 1946 | | |--------------->| 1948 Figure 2: Example with Privacy Header Fields 1950 B.3. Privacy for a Specific History-Info Entry 1952 This example provides a basic call scenario similar to Appendix B.2, 1953 however, due to local policy at sip:biloxi.example.com, only the 1954 final hi-entry in the History-Info, which is Bob's local URI, 1955 contains a privacy header field with a priv-value of "history", thus 1956 providing Alice with some information about the history of the 1957 request, but anonymizing Bob's local URI. 1959 Alice atlanta.example.com biloxi.example.com Bob 1960 | | | | 1961 | INVITE sip:bob@biloxi.example.com;p=x | 1962 |--------------->| | | 1963 | Supported: histinfo | | 1964 | | | | 1965 | | INVITE sip:bob@biloxi.example.com;p=x 1966 | |--------------->| | 1967 | History-Info: ;index=1 1968 | History-Info: ;index=1.1 1969 | | | | 1970 | | | INVITE sip:bob@192.0.2.3 1971 | | |--------------->| 1972 | History-Info: ;index=1 1973 | History-Info: ;index=1.1 1974 | History-Info: ;index=1.1.1;rc=1.1 1975 | | | | 1976 | | | 200 | 1977 | | |<---------------| 1978 | History-Info: ;index=1 1979 | History-Info: ;index=1.1 1980 | History-Info: ;index=1.1.1;rc=1.1 1981 | | | | 1982 | | 200 | | 1983 | |<---------------| | 1984 | History-Info: ;index=1 1985 | History-Info: ;index=1.1 1986 | History-Info: ;index=1.1.1;rc=1.1 1987 | | | | 1988 | 200 | | | 1989 |<---------------| | | 1990 | History-Info: ;index=1 1991 | History-Info: ;index=1.1 1992 | History-Info: ;index=1.1.1;rc=1.1 1993 | | | | 1994 | ACK | | | 1995 |--------------->| ACK | | 1996 | |--------------->| ACK | 1997 | | |--------------->| 1999 Figure 3: Example with Privacy Header Field for Specific URI 2001 Authors' Addresses 2003 Mary Barnes 2004 Polycom 2005 TX 2006 US 2008 Email: mary.ietf.barnes@gmail.com 2010 Francois Audet 2011 Skype 2013 Email: francois.audet@skype.net 2015 Shida Schubert 2016 NTT 2018 Email: shida@agnada.com 2020 Hans Erik van Elburg 2021 Detecon International Gmbh 2022 Oberkasseler str. 2 2023 Bonn, 2024 Germany 2026 Email: ietf.hanserik@gmail.com 2028 Christer Holmberg 2029 Ericsson 2030 Hirsalantie 11, Jorvas 2031 Finland 2033 Email: christer.holmberg@ericsson.com