idnits 2.17.1 draft-ietf-sipcore-rfc4244bis-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 423 has weird spacing: '... Alice atla...' == Line 1692 has weird spacing: '... Alice exam...' == Line 1947 has weird spacing: '... Alice atla...' == Line 2000 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 (April 27, 2011) is 4748 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 1052, but not defined ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 4244 (Obsoleted by RFC 7044) Summary: 2 errors (**), 0 flaws (~~), 7 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 29, 2011 S. Schubert 7 NTT 8 J. van Elburg 9 Detecon International Gmbh 10 C. Holmberg 11 Ericsson 12 April 27, 2011 14 An Extension to the Session Initiation Protocol (SIP) for Request 15 History Information 16 draft-ietf-sipcore-rfc4244bis-05.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. This document obsoletes RFC 4244. 32 Status of this Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on October 29, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 5 79 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 5 80 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 6 81 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 82 5. History-Info Header Field Protocol Structure . . . . . . . . . 8 83 5.1. History-Info Header Field Example Scenario . . . . . . . . 10 84 6. User Agent Handling of the History-Info Header Field . . . . . 13 85 6.1. User Agent Client (UAC) Behavior . . . . . . . . . . . . . 13 86 6.2. User Agent Server (UAS) Behavior . . . . . . . . . . . . . 13 87 7. Proxy/Intermediary Handling of History-Info Header Fields . . 13 88 8. Redirect Server Handling of History-Info Header Fields . . . . 14 89 9. Handling of History-Info Header Fields in Requests and 90 Responses . . . . . . . . . . . . . . . . . . . . . . . . . . 14 91 9.1. Receiving a Request . . . . . . . . . . . . . . . . . . . 14 92 9.2. Sending a Request with History-Info . . . . . . . . . . . 15 93 9.3. Receiving a Response with History-Info or Request 94 Timeouts . . . . . . . . . . . . . . . . . . . . . . . . . 15 95 9.4. Sending History-Info in Responses . . . . . . . . . . . . 16 96 10. Processing the History-Info Header Field . . . . . . . . . . . 16 97 10.1. Privacy in the History-Info Header Field . . . . . . . . . 17 98 10.1.1. Indicating Privacy . . . . . . . . . . . . . . . . . 17 99 10.1.2. Applying Privacy . . . . . . . . . . . . . . . . . . 18 100 10.2. Reason in the History-info Header Field . . . . . . . . . 19 101 10.3. Indexing in the History-Info Header Field . . . . . . . . 19 102 10.4. Indicating the Mechanism by which the Target was 103 Determined . . . . . . . . . . . . . . . . . . . . . . . . 21 104 11. Application Considerations . . . . . . . . . . . . . . . . . . 21 105 12. Security Considerations . . . . . . . . . . . . . . . . . . . 23 106 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 107 13.1. Registration of New SIP History-Info Header Field . . . . 24 108 13.2. Registration of "history" for SIP Privacy Header Field . . 25 109 13.3. Registration of Header Field Parameters . . . . . . . . . 25 110 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26 111 15. Changes from RFC 4244 . . . . . . . . . . . . . . . . . . . . 26 112 15.1. Backwards compatibility . . . . . . . . . . . . . . . . . 28 113 16. Changes since last Version . . . . . . . . . . . . . . . . . . 28 114 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 115 17.1. Normative References . . . . . . . . . . . . . . . . . . . 34 116 17.2. Informative References . . . . . . . . . . . . . . . . . . 35 117 Appendix A. Request History Requirements . . . . . . . . . . . . 35 118 A.1. Security Requirements . . . . . . . . . . . . . . . . . . 36 119 A.2. Privacy Requirements . . . . . . . . . . . . . . . . . . . 37 120 Appendix B. Example call flows . . . . . . . . . . . . . . . . . 38 121 B.1. Sequentially Forking (History-Info in Response) . . . . . 38 122 B.2. History-Info with Privacy Header Field . . . . . . . . . . 45 123 B.3. Privacy for a Specific History-Info Entry . . . . . . . . 47 125 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 48 127 1. Introduction 129 Many services that SIP is anticipated to support require the ability 130 to determine why and how a SIP request arrived at a specific 131 application. Examples of such services include (but are not limited 132 to) sessions initiated to call centers via "click to talk" SIP 133 Uniform Resource Locators (URLs) on a web page, "call history/ 134 logging" style services within intelligent "call management" software 135 for SIP User Agents (UAs), and calls to voicemail servers. Although 136 SIP implicitly provides the retarget capabilities that enable SIP 137 requests to be routed to chosen applications, there is a need for a 138 standard mechanism within SIP for communicating the retargeting 139 history of the requests. This "request history" information allows 140 the receiving application to determine hints about how and why the 141 SIP request arrived at the application/user. 143 This document defines a SIP header field, History-Info, to provide a 144 standard mechanism for capturing the request history information to 145 enable a wide variety of services for networks and end-users. SIP 146 header field parameters are defined for the History-Info and Contact 147 header fields to tag the method by which the target of a request is 148 determined. In addition, this document defines a value for the 149 Privacy header field specific to the History-Info header. 151 The History-info header field provides a building block for 152 development of SIP based applications and services. The requirements 153 for the solution described in this document are included in 154 Appendix A. Example scenarios using the History-info header field 155 are included in Appendix B. 157 2. Conventions and Terminology 159 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 160 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 161 document are to be interpreted as described in [RFC2119]. 163 The term "retarget" is used in this document to refer to the process 164 of a SIP entity changing a Uniform Resource Identifier (URI) in a 165 request based on the rules for determining request targets as 166 described in Section 16.5 of [RFC3261] and of the subsequent 167 forwarding of that request as described in step 2 in section 16.6 of 168 [RFC3261]. This includes changing the Request-URI due to a location 169 service lookup and redirect processing. This also includes internal 170 (to a proxy/SIP intermediary) changes of the URI prior to forwarding 171 of the request. 173 The terms "location service", "forward", "redirect" and "AOR" are 174 used consistent with the terminology in [RFC3261]. 176 The references to "domain for which the SIP entity/Proxy/Intermediary 177 is responsible" are consistent with and intended to convey the same 178 context as the usage of that terminology in [RFC3261]. The 179 applicability of History-Info to architectures or models outside the 180 context of [RFC3261] is outside the scope of this specification. 182 3. Background 184 SIP implicitly provides retargeting capabilities that enable SIP 185 requests to be routed to specific applications as defined in 186 [RFC3261]. The motivation for capturing the request history is that 187 in the process of retargeting a request, old routing information can 188 be forever lost. This lost information may be important history that 189 allows elements to which the request is retargeted to process the 190 request in a locally defined, application-specific manner. This 191 document defines a mechanism for transporting the request history. 192 Application-specific behavior is outside the scope of this 193 specification. 195 Current network applications provide the ability for elements 196 involved with the request to obtain additional information relating 197 to how and why the request was routed to a particular destination. 198 The following are examples of such applications: 200 1. Web "referral" applications, whereby an application residing 201 within a web server determines that a visitor to a website has 202 arrived at the site via an "associate" site that will receive 203 some "referral" commission for generating this traffic 205 2. Email forwarding whereby the forwarded-to user obtains a 206 "history" of who sent the email to whom and at what time 208 3. Traditional telephony services such as voicemail, call-center 209 "automatic call distribution", and "follow-me" style services 211 Several of the aforementioned applications currently define 212 application-specific mechanisms through which it is possible to 213 obtain the necessary history information. 215 In addition, request history information could be used to enhance 216 basic SIP functionality by providing the following: 218 o Some diagnostic information for debugging SIP requests. 220 o Capturing aliases and Globally Routable User Agent URIs (GRUUs) 221 [RFC5627], which can be overwritten by a home proxy upon receipt 222 of the initial request. 224 o Facilitating the use of limited use addresses (minted on demand) 225 and sub-addressing. 227 o Preserving service specific URIs that can be overwritten by a 228 downstream proxy, such as those defined in [RFC3087], and control 229 of network announcements and IVR with SIP URI [RFC4240]. 231 4. Overview 233 The fundamental functionality provided by the request history 234 information is the ability to inform proxies and UAs involved in 235 processing a request about the history or progress of that request. 236 The solution is to capture the Request-URIs as a request is 237 retargeted, in a SIP header field: History-Info. This allows for the 238 capturing of the history of a request that would be lost with the 239 normal SIP processing involved in the subsequent retargeting of the 240 request. 242 The History-info header field is added to a Request when a new 243 request is created by a UAC or forwarded by a Proxy, or when the 244 target of a request is changed. It is possible for the target of a 245 request to be changed by the same proxy/SIP Intermediary multiple 246 times (referred to as 'internal retargeting'). A SIP entity changing 247 the target of a request in response to a redirect also propagates any 248 History-info header field from the initial request in the new 249 request. The ABNF and detailed description of the History-Info 250 header field parameters, along with examples is provided in 251 Section 5. Section 6, Section 7 and Section 8 provide the detailed 252 handling of the History-Info header field by SIP User Agents, Proxies 253 and Redirect Servers respectively. 255 This specification also defines two new SIP header field parameters, 256 "rc" and "mp", for the History-Info and Contact header fields, to tag 257 the method by which the target of a request is determined. Further 258 detail on the use of these header field parameters is provided in 259 Section 10.4. 261 In addition, this specification defines a priv-value for the Privacy 262 header, "history", that applies to all the History-info header field 263 entries in a Request or to a specific History-info header field hi- 264 entry as described above. Further detail is provided in 265 Section 10.1. 267 5. History-Info Header Field Protocol Structure 269 The History-info header field can appear in any request not 270 associated with an early or established dialog (e.g., INVITE, 271 REGISTER, MESSAGE, REFER and OPTIONS, PUBLISH and SUBSCRIBE, etc.) 272 and any non-100 provisional or final responses to these requests 273 (ISSUER-req, see Appendix A). 275 The following provides details for the information that is captured 276 in the History-Info header field entry (hi-entry) for each target 277 used for forwarding a request: 279 o hi-targeted-to-uri: A mandatory parameter for capturing the 280 Request-URI for the specific request as it is forwarded. 282 o hi-index: A mandatory parameter for History-Info reflecting the 283 chronological order of the information, indexed to also reflect 284 the forking and nesting of requests. The format for this 285 parameter is a string of digits, separated by dots to indicate the 286 number of forward hops and retargets. This results in a tree 287 representation of the history of the request, with the lowest- 288 level index reflecting a branch of the tree. By adding the new 289 entries in order (i.e., following existing entries per the details 290 in Section 10.3), including the index and sending the messages 291 using a secure transport, the ordering of the History-info header 292 fields in the request is assured. In addition, applications may 293 extract a variety of metrics (total number of retargets, total 294 number of retargets from a specific branch, etc.) based upon the 295 index values. 297 o hi-target-param: An optional parameter reflecting the mechanism by 298 which the Request URI captured in the hi-targeted-to-uri in the 299 hi-entry was determined. This parameter contains either an "rc" 300 or "mp" header field parameter, which is interpreted as follows: 302 "rc": The hi-targeted-to-URI is a contact bound to an AOR in an 303 abstract location service, that AOR being the Request-URI that 304 was retargeted. The AOR-to-contact binding has been placed 305 into the location service by a SIP Registrar that received a 306 SIP REGISTER request. The "rc" header field parameter contains 307 the value of the hi-index in the hi-entry with an 308 hi-targeted-to- uri that reflects the Request-URI that was 309 retargeted 311 "mp": The hi-targeted-to-URI represents a user other than the 312 user associated with the Request-URI in the incoming request 313 that was retargeted. This occurs when a request is statically 314 or dynamically retargeted to another user. The "mp" header 315 field parameter contains the value of the hi-index in the hi- 316 entry with an hi-targeted-to-uri that reflects the Request-URI 317 that was retargeted, thus identifying the "mapped from" target. 319 o Extension (hi-extension): A parameter to allow for future optional 320 extensions. As per [RFC3261], any implementation not 321 understanding an extension MUST ignore it. 323 The ABNF syntax for the History-info header field and header field 324 parameters is as follows: 326 History-Info = "History-Info" HCOLON hi-entry *(COMMA hi-entry) 328 hi-entry = hi-targeted-to-uri *(SEMI hi-param) 330 hi-targeted-to-uri = name-addr 332 hi-param = hi-index / hi-target-param / hi-extension 334 index-val = 1*DIGIT *("." 1*DIGIT) 336 hi-index = "index" EQUAL index-val 338 hi-target-param = rc-param / mp-param 340 rc-param = "rc" EQUAL index-val 342 mp-param = "mp" EQUAL index-val 344 hi-extension = generic-param 346 The ABNF definitions for "generic-param" and "name-addr" are from 347 [RFC3261]. 349 This document also extends the "contact-params" for the Contact 350 header field as defined in [RFC3261] with the "rc" and "mp" header 351 field parameters defined above. 353 In addition to the parameters defined by the ABNF, an hi-entry may 354 also include a Reason header field and/or a Privacy header field, 355 which are both included in the "headers" component of the hi- 356 targeted-to-uri as described below: 358 o Reason: An optional parameter for History-Info, reflected in the 359 History-info header field by including the Reason header field 360 [RFC3326] included in the hi-targeted-to-uri. A reason is 361 included in the hi-targeted-to-uri of an hi-entry to reflect 362 information received in a response to the request sent to that 363 URI. 365 o Privacy: An optional parameter for History-Info, reflected in the 366 History-Info header field values by including the Privacy Header 367 [RFC3323] included in the hi- targeted-to-uri or by adding the 368 Privacy header field to the request. The latter case indicates 369 that the History-Info entries for the domain MUST be anonymized 370 prior to forwarding, whereas the use of the Privacy header field 371 included in the hi-targeted-to-uri means that a specific hi-entry 372 MUST be anonymized. 374 Note that since both the Reason and Privacy parameters are included 375 in the hi-targeted-to-uri, these fields will not be available in the 376 case that the hi-targeted-to-uri is a Tel-URI [RFC3966]. In such 377 cases, the Tel-URI SHOULD be transformed into a SIP URI per section 378 19.1.6 of [RFC3261]. 380 The following provides examples of the format for the History-info 381 header field. Note that the backslash and CRLF between the fields in 382 the examples below are for readability purposes only. 384 History-Info: ;index=1;foo=bar 386 History-Info: ;index=1.1,\ 388 ;index=1.2;mp=1.1,\ 390 ;index=1.3;rc=1.2 392 5.1. History-Info Header Field Example Scenario 394 The following is an illustrative example of usage of History-Info. 396 In this example, Alice (sip:alice@atlanta.example.com) calls Bob 397 (sip:bob@biloxi.example.com). Alice's proxy in her home domain (sip: 398 atlanta.example.com) forwards the request to Bob's proxy (sip: 399 biloxi.example.com). When the request arrives at sip: 400 biloxi.example.com, it does a location service lookup for 401 bob@biloxi.example.com and changes the target of the request to Bob's 402 Contact URIs provided as part of normal SIP registration. In this 403 example, Bob is simultaneously contacted on a PC client and on a 404 phone, and Bob answers on the PC client. 406 One important thing illustrated by this call flow is that without 407 History-Info, Bob would "lose" the target information, including any 408 parameters in the request URI. Bob can recover that information by 409 locating the last hi-entry with an "rc" header field parameter. This 410 "rc" header field parameter contains the index of the hi-entry 411 containing the lost target information - i.e., the 412 sip:bob@biloxi.example.com hi-entry with index=1.1. Note that an hi- 413 entry is not included for the fork to sip:bob@192.0.2.7 since there 414 was no response at the time the 200 OK is sent to Alice. 416 The formatting in this scenario is for visual purposes; thus, 417 backslash and CRLF are used between the fields for readability. 418 Refer to Section 5.1 for the proper formatting. Additional detailed 419 scenarios are available in Appendix B. 421 Note: This example uses loose routing procedures. 423 Alice atlanta.example.com biloxi.example.com Bob@pc Bob@phone 424 | | | | | 425 | INVITE sip:bob@biloxi.example.com;p=x | | 426 |--------------->| | | | 427 | Supported: histinfo | | | 428 | | | | | 429 | | INVITE sip:bob@biloxi.example.com;p=x | 430 | |--------------->| | | 431 | History-Info: ;index=1 432 | History-Info: ;index=1.1 | 433 | | | | | 434 | | | INVITE sip:bob@192.0.2.3| 435 | | |--------------->| | 436 | History-Info: ;index=1 437 | History-Info: ;index=1.1 438 | History-Info: ;index=1.1.1;rc=1.1 439 | | | | | 440 | | | INVITE sip:bob@192.0.2.7| 441 | | |-------------------------->| 442 | History-Info: ;index=1 443 | History-Info: ;index=1.1 444 | History-Info: ;index=1.1.2;rc=1.1 445 | | | 200 | | 446 | | |<---------------| | 447 | History-Info: ;index=1 448 | History-Info: ;index=1.1 449 | History-Info: ;index=1.1.1;rc=1.1 450 | | | | | 451 | | 200 | | | 452 | |<---------------| | | 453 | History-Info: ;index=1 454 | History-Info: ;index=1.1 455 | History-Info: ;index=1.1.1;rc=1.1 456 | | | | | 457 | | | Proxy Cancels INVITE | 458 | | |<=========================>| 459 | | | | | 460 | 200 | | | | 461 |<---------------| | | | 462 | History-Info: ;index=1 463 | History-Info: ;index=1.1 464 | History-Info: | ACK | | | 468 | |--------------->| ACK | | 469 | | |--------------->| | 470 Figure 1: Basic Call 472 6. User Agent Handling of the History-Info Header Field 474 A B2BUA MAY follow the behavior of a SIP intermediary as an 475 alternative to following the behavior of a UAS per Section 6.2 and a 476 UAC per Section 6.1. In behaving as an intermediary, a B2BUA carries 477 forward hi-entries received in requests at the UAS to requests being 478 forwarded by the UAC, as well as carrying forward hi-entries in 479 responses received at the UAC to the responses forwarded by the UAS, 480 subject to privacy considerations per Section 10.1. 482 6.1. User Agent Client (UAC) Behavior 484 The UAC MUST include the "histinfo" option tag in the Supported 485 header field in any new or out-of-dialog request for which the UAC 486 would like the History-info header field in the response. When 487 issuing a request, the UAC MUST follow the procedures in Section 9.2. 488 Note that in the case of an initial request, except where the UAC is 489 part of a B2BUA, there is no cache of hi-entries with which to 490 populate the History-info header field and the hi-index is set to 1 491 per Section 10.3. When receiving a response the UAC MUST follow the 492 procedures in Section 9.3. 494 6.2. User Agent Server (UAS) Behavior 496 When receiving a request, a UAS MUST follow the procedures defined in 497 Section 9.2. When sending a response other than a 3xx response, a 498 UAS MUST follows the procedures as defined in Section 9.4. When 499 sending a 3xx response, the UAS MUST follow the procedures defined 500 for a redirect server per Section 8. An application at the UAS can 501 make use of the cached hi-entries as described in Section 11. 503 7. Proxy/Intermediary Handling of History-Info Header Fields 505 This section describes the procedures for proxies and other SIP 506 intermediaries for the handling of the History-Info header fields for 507 each of the following scenarios: 509 Receiving a Request: An intermediary MUST follow the procedures in 510 Section 9.1 for the handling of hi-entries in incoming SIP 511 requests. 513 Sending a Request: For each outgoing request relating to a target 514 in the target set, the intermediary MUST follow the procedures of 515 Section 9.2. 517 Receiving a Response or Timeout: An intermediary MUST follow the 518 procedures of Section 9.3 when a SIP response is received or a 519 request times out. 521 Sending a Response: An intermediary MUST follow the procedures of 522 Section 9.4 for the handling of the hi-entries when sending a SIP 523 response. 525 In some cases, an intermediary may retarget a request more than once 526 before forwarding - i.e., a request is retargeted to a SIP entity 527 that is "internal" to the intermediary before the same intermediary 528 retargets the request to an external target . A typical example 529 would be a proxy that retargets a request first to a different user 530 (i.e., it maps to a different AOR) and then forwards to a registered 531 contact bound to the same AOR. In this case, the intermediary MUST 532 add an hi-entry for (each of) the internal target(s) per the 533 procedures in Section 9.2. The intermediary MAY include a Reason 534 header field in the hi-entry with the hi-targeted-to-uri that has 535 been retargeted as shown in the INVITE (F6) in the example in 536 Appendix B.1. Figure 1 provides an example of internal retargeting. 538 8. Redirect Server Handling of History-Info Header Fields 540 A redirect server MUST follow the procedures in Section 9.1 when it 541 receives a SIP Request. A redirect server MUST follow the procedures 542 in Section 9.4 when it sends a SIP Response. When generating the 543 Contact header field in a 3xx response, the redirect server MUST add 544 the appropriate target header field parameter to each Contact header 545 field as described in Section 10.4, if applicable. 547 9. Handling of History-Info Header Fields in Requests and Responses 549 This section describes the procedures for SIP entities for the 550 handling of the History-Info header field in SIP requests and 551 responses. 553 9.1. Receiving a Request 555 When receiving a request, a SIP entity MUST create a cache containing 556 the hi-entries associated with the request. The hi-entries MUST be 557 added to the cache in the order in which they were received in the 558 request. 560 If the Request-URI of the incoming request does not match the hi- 561 targeted-to-uri in the last hi-entry (i.e., the previous SIP entity 562 that sent the request did not include a History-Info header field), 563 the SIP entity MUST add an hi-entry to end of the cache, on behalf of 564 the previous SIP entity, as follows: 566 o The SIP entity MUST set the hi-targeted-to-uri to the value of the 567 Request-URI in the incoming request. 569 o If privacy is required, the SIP entity MUST follow the procedures 570 of Section 10.1. 572 o The SIP entity MUST set the hi-index parameter as described in 573 Section 10.3. 575 o The SIP entity MUST NOT include an "rc" or "mp" header field 576 parameter. 578 9.2. Sending a Request with History-Info 580 When sending a request, a SIP entity MUST include all cached hi- 581 entries in the request. In addition, the SIP entity MUST add a new 582 hi-entry to the outgoing request, but the SIP entity MUST NOT add the 583 new hi-entry to the cache at this time. The new hi-entry is 584 populated as follows: 586 hi-targeted-to-uri: The hi-targeted-to-uri MUST be set to the 587 value of the Request-URI of the current (outgoing) request. 589 privacy: If privacy is required, the procedures of Section 10.1 590 MUST be followed. 592 hi-index: The SIP entity MUST include an hi-index for the hi-entry 593 as described in Section 10.3. 595 rc/mp: The SIP entity MUST include an "rc" or "mp" header field 596 parameter in the hi-entry, if applicable, per the procedures in 597 Section 10.4. 599 9.3. Receiving a Response with History-Info or Request Timeouts 601 When a SIP entity receives a non-100 response or a request times out, 602 the SIP entity performs the following steps: 604 Step 1: Add hi-entry to cache 606 The SIP entity MUST add the hi-entry that was added to the request 607 that received the response or timed out to the cache, if it was 608 not already cached. The hi-entry MUST be added to the cache in 609 ascending order as indicated by the values in the hi-index 610 parameters of the hi-entries (e.g., 1.2.1 comes after 1.2 but 611 before 1.2.2 or 1.3). 613 Step 2: Add Reason header field 615 The SIP entity adds one or more Reason header fields to the hi- 616 targeted-to-uri in the (newly) cached hi-entry per the procedures 617 of Section 10.2, except in the case of a 2xx response. 619 Step 3: Add additional hi-entries 621 The SIP entity MUST also add to the cache any hi-entries received 622 in the response that are not already in the cache. This situation 623 can occur when the entity that generated the response retargeted 624 the request before generating the response. As per Step 1, the 625 hi-entries MUST be added to the cache in ascending order as 626 indicated by the values in the hi-index parameters of the hi- 627 entries 629 It is important to note that the cache does not contain hi-entries 630 for requests that have not yet received a non-100 response, so there 631 can be gaps in indices (e.g., 1.2 and 1.4 could but present but not 632 1.3). 634 9.4. Sending History-Info in Responses 636 When sending a response other than a 100, a SIP entity MUST include 637 all the cached hi-entries in the response, subject to the privacy 638 consideration in Section 10.1.2 with the following exception: If the 639 received request contained no hi-entries and there is no "histinfo" 640 option tag in the Supported header field, the SIP entity MUST NOT 641 include hi-entries in the response. 643 10. Processing the History-Info Header Field 645 The following sections describe the procedures for processing the 646 History-Info header field. These procedures are applicable to SIP 647 entities such as Proxies/Intermediaries, Redirect Servers or User 648 Agents. 650 10.1. Privacy in the History-Info Header Field 652 The privacy requirements for this document are described in 653 Appendix A.2. Section 10.1.1 describes the insertion of the Privacy 654 header field defined in [RFC3323] to indicate the privacy to be 655 applied to the History-Info header field entries. Section 10.1.2 656 describes how to apply privacy to a request or response that is being 657 forwarded, based on the presence of the Privacy header field. 659 10.1.1. Indicating Privacy 661 As with other SIP headers described in [RFC3323], the hi-targeted-to- 662 uris in the History-info header field can inadvertently reveal 663 information about the initiator of the request. Thus, the UAC needs 664 a mechanism to indicate that the hi-targeted-to-uris in the hi- 665 entries need to be privacy protected. The Privacy header field is 666 used by the UAC to indicate that privacy is to be applied to all the 667 hi-entries in the request as follows: 669 o If the UAC is including a Privacy header field with a priv-value 670 of "header" in the request, then the UAC SHOULD NOT include a 671 priv-value of "history" in the the Privacy header field in the 672 Request. 674 o If the UAC is including any priv-values other than "header" in the 675 Privacy header field, then the UAC MUST also include a priv-value 676 of "history" in the Privacy header field in the Request. 678 o If the UAC is not including any priv-values in the Privacy header 679 field in the request, then the UAC MUST add a Privacy header 680 field, with a priv-value of "history", to the request. The UAC 681 MUST NOT include a priv-value of "critical" in the Privacy header 682 field in the Request in this case. 684 In addition, the History-info header field can reveal general routing 685 and diverting information within an intermediary, which the 686 intermediary wants to privacy protect. In this case, the 687 intermediary MUST set a Privacy header field to a priv-value of 688 "history" and include the Privacy header field in the hi-targeted-to- 689 uri, for each new hi-entry added by the intermediary, as the request 690 is retargeted within the domain for which the SIP entity is 691 responsible. Note, that the hi-entries that are added to a request 692 from the cache are excluded in this case since the appropriate 693 privacy was set for those hi-entries when they were originally added 694 to a request. The intermediary MUST NOT include any other priv- 695 values in this Privacy header field. Note that the priv-value in the 696 Privacy header for the incoming request does not necessarily 697 influence whether the intermediary includes a Privacy header field in 698 the hi-entries. For example, even if the Privacy header for the 699 incoming request contained a priv-value of "none", the Proxy can 700 still set a priv-value of "history" in the Privacy header field 701 included in the hi-targeted-to-uri. 703 Finally, the terminator of the request may not want to reveal the 704 final reached target to the originator. In this case, the terminator 705 MUST include a Privacy header field with a priv-value of "history" in 706 the hi-targeted-to-uri in the last hi-entry, in the response. As 707 noted above, the terminator of the request MUST NOT use any other 708 priv-values in the Privacy header field included in the hi-entry. 710 10.1.2. Applying Privacy 712 When a request is retargeted to a URI associated with a domain for 713 which the SIP intermediary is not responsible or a response is 714 forwarded to a domain for which the SIP intermediary is not 715 responsible, a Privacy Service at the boundary of the domain applies 716 the appropriate privacy based on the value of the Privacy header 717 field in the message header or in the "headers" component of the hi- 718 targeted-to-uri in the individual hi-entries. 720 If there is a Privacy header field in the message header of a request 721 or response, with a priv-value of "header" or "history", then all the 722 hi-targeted-to-uris in the hi-entries, associated with the domain for 723 which a SIP intermediary is responsible, are anonymized by the 724 Privacy Service. The Privacy Service MUST change any hi-targeted-to- 725 uris in the hi-entries that have not been anonymized to anonymous 726 URIs containing a domain of anonymous.invalid (e.g., 727 anonymous@anonymous.invalid). If there is a Privacy header field in 728 the "headers" component of the hi-targeted-to-uri in the hi-entry, 729 then the Privacy header field value MUST be removed from the hi- 730 entry. Once all the appropriate hi-entries have been anonymized, the 731 Privacy Service MUST remove the priv-value of "history" from the 732 Privacy header field in the message header of the request or 733 response. If there are no remaining priv-values in the Privacy 734 header field, the Privacy Service MUST remove the Privacy header 735 field from the request or response per [RFC3323]. 737 If there is not a Privacy header field in the message header of the 738 request or response that is being forwarded, but there is a Privacy 739 header field with a priv-value of "history" in the "headers" 740 component in any of the hi-targeted-uris in the hi-entries associated 741 with the domain for which a SIP intermediary is responsible, then the 742 Privacy Service MUST anonymize those hi-targeted-to-uris. The 743 Privacy Service MUST populate each of the hi-targeted-to-uris with an 744 anonymous URI with a domain of anonymous.invalid (e.g., 745 anonymous@anonymous.invalid). Any other priv-values in the Privacy 746 header field in the "headers" component of the hi-targeted-to-uris in 747 the hi-entries MUST be ignored. In any case, the Privacy Service 748 MUST remove the Privacy header field from the "headers" compenent of 749 the hi-targeted-to-uris in the hi-entries prior to forwarding. 751 10.2. Reason in the History-info Header Field 753 A Reason header field is added to the "headers" component in an hi- 754 targeted-to-uri when the hi-entry is added to the cache based upon 755 the receipt of a non-100 or non-2xx SIP response, as described in 756 Section 9.3. If the Reason header field is being added due to 757 receipt of an explicit SIP response and the response contains any 758 Reason header fields (see [RFC3326]), then the SIP entity MUST 759 include the Reason header fields in the "headers" component of the 760 hi-targeted-to-uri in the last hi-entry added to the cache, unless 761 the hi-targeted-to-uri is a Tel-URI. If the SIP response does not 762 contain a Reason header field, the SIP entity MUST include a Reason 763 header field, containing the SIP Response Code, in the "headers" 764 component of the hi-targeted-to-uri in the last hi-entry added to the 765 cache, unless the hi-targeted-to-uri is a Tel-URI. 767 If a request has timed out (instead of being explicitly rejected), 768 the SIP entity MUST include a Reason header field, containing a SIP 769 error response code of 408 "Request Timeout". 771 A SIP entity MAY also include a Reason header field in the "headers" 772 component of an hi-targeted-to-uri containing the URI of a request 773 that was retargeted as a result of internal retargeting. 775 If new protocol values for Reason headers are specified in the future 776 per [RFC3326], the use of these Reason headers for the History-Info 777 header field MUST follow the same rules as described above. 779 10.3. Indexing in the History-Info Header Field 781 In order to maintain ordering and accurately reflect the retargeting 782 of the request, the SIP entity MUST add an hi-index to each hi-entry. 783 Per the syntax in Section 5, the hi-index consists of a series of 784 digits separated by dots (e.g., 1.1.2). Each dot reflects a SIP 785 forwarding hop. The digit following each dot reflects the order in 786 which a request was retargeted at the hop. The highest digit at each 787 hop reflects the number of entities to which the request has been 788 retargeted at the specific hop (i.e., the number of branches). Thus, 789 the indexing results in a logical tree representation for the history 790 of the request. 792 The first index in a series of History-Info entries MUST be set to 1. 793 In the case that a SIP entity (intermediary or UAS) adds an hi-entry 794 on behalf of the previous hop, the hi-index MUST be set to 1. For 795 each forward hop (i.e., each new level of indexing), the hi-index 796 MUST start at 1. An increment of 1 MUST be used for advancing to a 797 new branch. 799 The basic rules for adding the hi-index are summarized as follows: 801 1. Forwarding a request without changing the target: In the case of 802 a request that is being forwarded without changing the target, 803 the hi-index reflects the increasing length of the branch. In 804 this case, the SIP entity MUST read the value from the History- 805 info header field in the received request and MUST add another 806 level of indexing by appending the dot delimiter followed by an 807 initial value of 1 for the new level. For example, if the hi- 808 index in the last History-info header field in the received 809 request is 1.1, a proxy would add an hi-entry with an hi-index of 810 1.1.1 and forward the request. 812 2. Retargeting within a processing entity - 1st instance: For the 813 first instance of retargeting within a processing entity, the SIP 814 entity MUST calculate the hi-index as prescribed for basic 815 forwarding. 817 3. Retargeting within a processing entity - subsequent instance: For 818 each subsequent retargeting of a request by the same SIP entity, 819 the SIP entity MUST calculate and add the hi-index for each new 820 branch by incrementing the rightmost value from the hi-index in 821 the last hi-entry. Per the example above, the hi-index in the 822 next request forwarded by this same SIP entity would be 1.1.2. 824 4. Retargeting based upon a Response: In the case of retargeting due 825 to a specific response (e.g., 302), the SIP entity MUST calculate 826 the hi-index calculated per rule 3. That is, the rightmost value 827 of the hi-index MUST be incremented (i.e., a new branch is 828 created). For example, if the hi-index in the History-Info 829 header of the sent request is 1.2 and the response to the request 830 is a 302, then the hi-index in the History-Info header field for 831 the new hi-targeted- to-URI would be 1.3. 833 5. Forking requests: If the request forwarding is done in multiple 834 forks (sequentially or in parallel), the SIP entity MUST set the 835 hi-index for each hi-entry for each forked request per the rules 836 above, with each new request having a unique index. Each index 837 MUST be sequentially assigned. For example, if the index in the 838 last History-Info header field in the received request is 1.1, 839 this processing entity would initialize its index to 1.1.1 for 840 the first fork, 1.1.2 for the second, and so forth (see Figure 1 841 for an example). Note, that in the case of parallel forking, 842 only the hi-entry corresponding to the fork is included in the 843 request. 845 10.4. Indicating the Mechanism by which the Target was Determined 847 This specification defines two header field parameters, "rc" and 848 "mp", indicating two mechanisms by which a new target for a request 849 is determined. Both parameters contain an index whose value is the 850 hi-index of the hi-entry with an hi-targeted-to-uri that represents 851 the Request-URI that was retargeted. 853 The SIP entity MUST determine the specific parameter field to be 854 included in the hi-target-param, in the History-info header field, as 855 the targets are added to the target set per the procedures in section 856 16.5 of [RFC3261] or per section 8.1.3.4 [RFC3261] in the case of 857 retargeting to a contact URI received in a 3xx response. In the 858 latter case, the specific header parameter field in the Contact 859 header becomes the header field parameter that is used in the hi- 860 target-param in the hi-entry when the request is retargeted. If the 861 Contact header field does not contain an "rc" or "mp" header field 862 parameter, then the SIP entity MUST NOT include an "rc" or "mp" 863 header field parameter in the hi-target-param in the hi-entry when 864 the request is retargeted to a contact URI received in a 3xx 865 response. 867 The SIP entity (intermediary or redirect server) determines the 868 specific header field parameter ("rc" or "mp") to be used based on 869 the criteria defined in Section 5 (hi-target-param) for each of the 870 header field parameters. 872 Note that there are two scenarios by which the "mp" header field 873 parameter can be derived. 875 o The mapping was done by the receiving entity on its own authority, 876 in which case the mp-value is the parent index of the hi-entry's 877 index. 879 o The mapping was done due to receiving a 3xx response, in which 880 case the mp-value is an earlier sibling or descendant of an 881 earlier sibling of the hi-entry's index, that of the downstream 882 request which received the 3xx response. 884 11. Application Considerations 886 History-Info provides a very flexible building block that can be used 887 by intermediaries and UAs for a variety of services. Prior to any 888 application usage of the History-Info header field parameters, the 889 SIP entity that processes the hi-entries MUST evaluate the hi- 890 entries. The SIP entity MUST determine if there are gaps in the 891 indices. Gaps are possible if the request is forwarded through 892 intermediaries that do not support the History-info header field and 893 are reflected by the existence of multiple hi-entries with an index 894 of "1". Gaps are also possible in the case of parallel forking if 895 there is an outstanding request at the time the SIP entity sends a 896 response as described in Section 9.4. Thus, if gaps are detected, 897 the SIP entity MUST NOT treat this as an error, but SHOULD indicate 898 to any applications that there are gaps. The interpretation of the 899 information in the History-info header field depends upon the 900 specific application; an application might need to provide special 901 handling in some cases where there are gaps. 903 The following describes some categories of information that 904 applications can use: 906 1. Complete history information - e.g., for debug or other 907 operational and management aspects, optimization of determining 908 targets to avoid retargeting to the same URI, etc. This 909 information is relevant to proxies, UACs and UASs. 911 2. Hi-entry with the index that matches the value of the "rc" header 912 field parameter in the last hi-entry with an "rc" header field 913 parameter in the Request received by a UAS - i.e., the last AOR 914 that was retargeted to a contact based on an AOR-to-contact 915 binding in an abstract location service. 917 3. Hi-entry with the index that matches the value of the "mp" header 918 field parameter in the last hi-entry with an "mp" header field 919 parameter in the hi-target-param in the Request received by a UAS 920 - i.e., the last Request URI that was mapped to reach the 921 destination. 923 4. Hi-entry with the index that matches the value of the "rc" header 924 field parameter in the first hi-entry with an "rc" header field 925 parameter in the Request received by a UAS. Note, this would be 926 the original AoR if all the entities involved support the 927 History-info header field and there is absence of an "mp" header 928 field parameter prior to the "rc" header field parameter in the 929 hi-target-param in the History-info header field. However, there 930 is no guarantee that all entities will support History-Info, thus 931 the hi-entry that matches the value of the "rc" parameter of the 932 first hi-entry with an "rc" parameter in the hi-target-param 933 within the domain associated with the target URI at the 934 destination is more likely to be useful. 936 5. Hi-entry with the index that matches the value of "mp" header 937 field parameter in the first hi-entry with an "mp" header field 938 parameter in the Request received by a UAS. Note, this would be 939 the original mapped URI if all entities supported the History- 940 info header field. However, there is no guarantee that all 941 entities will support History-Info, thus the hi-entry that 942 matches the value of the "mp" header field parameter of the first 943 hi-entry with an "mp" header field parameter within the domain 944 associated with the target URI at the destination is more likely 945 to be useful. 947 In many cases, applications are most interested in the information 948 within a particular domain(s), thus only a subset of the information 949 is required. 951 Some applications may use multiple types of information. For 952 example, an Automatic Call Distribution (ACD)/Call center application 953 that utilizes the hi-entry whose index matches the value of the "mp" 954 header field parameter of the first hi-entry with an "mp" header 955 field parameter, may also display other agents, reflected by other 956 hi-entries prior to entries with an "rc" header field parameter, to 957 whom the call was targeted prior to its arrival at the current agent. 958 This could allow the agent the ability to decide how they might 959 forward or reroute the call if necessary (avoiding agents that were 960 not previously available for whatever reason, etc.). 962 Since support for History-info header field is optional, a service 963 MUST define default behavior for requests and responses not 964 containing History-Info header fields. For example, an entity may 965 receive an incomplete set of hi-entries or hi-entries which are not 966 tagged appropriately with an hi-target-param. This may not impact 967 some applications (e.g., debug), however, it could require some 968 applications to make some default assumptions in this case. For 969 example, in an ACD scenario, the application could select the oldest 970 hi-entry with the domain associated with the ACD system and display 971 that as the original called party. Depending upon how and where the 972 request may have been retargeted, the complete list of agents to whom 973 the call was targeted may not be available. 975 12. Security Considerations 977 The security requirements for this document are specified in 978 Appendix A.1. 980 This document defines a header for SIP. The use of the Transport 981 Layer Security (TLS) protocol [RFC5246] as a mechanism to ensure the 982 overall confidentiality of the History-Info headers (SEC-req-4) is 983 strongly RECOMMENDED. This results in History-Info having at least 984 the same level of security as other headers in SIP that are inserted 985 by intermediaries. With TLS, History-Info headers are no less, nor 986 no more, secure than other SIP headers, which generally have even 987 more impact on the subsequent processing of SIP sessions than the 988 History-info header field. 990 Note that while using the SIPS scheme (as per [RFC5630]) protects 991 History-Info from tampering by arbitrary parties outside the SIP 992 message path, all the intermediaries on the path are trusted 993 implicitly. A malicious intermediary could arbitrarily delete, 994 rewrite, or modify History-Info. This specification does not attempt 995 to prevent or detect attacks by malicious intermediaries. 997 In terms of ensuring the privacy of hi-entries, the same security 998 considerations as those described in [RFC3323] apply. Namely if the 999 entity requesting privacy wants to ensure privacy is applied to the 1000 hi-entries, a Privacy Service that supports both [RFC3323] and this 1001 specification is REQUIRED in the entity's domain, so that the privacy 1002 can be applied, as described in Section 10.1.2, when a request or 1003 response leaves the domain. 1005 13. IANA Considerations 1007 This document requires several IANA registrations detailed in the 1008 following sections. 1010 This document obsoletes [RFC4244] but uses the same SIP header field 1011 name and option tag. The IANA registry needs to update the 1012 references to [RFC4244] with [RFCXXXX]. 1014 13.1. Registration of New SIP History-Info Header Field 1016 This document defines a SIP header field name: History-Info and an 1017 option tag: histinfo. The following changes have been made to 1018 http:///www.iana.org/assignments/sip-parameters The following row has 1019 been added to the header field section:. 1021 The following row has been added to the header field section: 1023 Header Name Compact Form Reference 1024 ----------- ------------ --------- 1025 History-Info none [RFCXXXX] 1027 The following has been added to the Options Tags section: 1029 Name Description Reference 1030 ---- ----------- --------- 1031 histinfo When used with the Supported header, [RFCXXXX] 1032 this option tag indicates the UAC 1033 supports the History Information to be 1034 captured for requests and returned in 1035 subsequent responses. This tag is not 1036 used in a Proxy-Require or Require 1037 header field since support of 1038 History-Info is optional. 1040 Note to RFC Editor: Please replace RFCXXXX with the RFC number of 1041 this specification. 1043 13.2. Registration of "history" for SIP Privacy Header Field 1045 This document defines a priv-value for the SIP Privacy header field: 1046 history The following changes have been made to 1047 http://www.iana.org/assignments/sip-priv-values The following has 1048 been added to the registration for the SIP Privacy header field: 1050 Name Description Registrant Reference 1051 ---- ----------- ---------- --------- 1052 history Privacy requested for Mary Barnes [RFCXXXX] 1053 History-info header mary.barnes@polycom.com 1054 fields(s) 1056 Note to RFC Editor: Please replace RFC XXXX with the RFC number of 1057 this specification. 1059 13.3. Registration of Header Field Parameters 1061 This specification defines the following new SIP header field 1062 parameters in the SIP Header Field parameter sub-registry in the SIP 1063 Parameter Registry, http:/www.iana.org/assignments/sip-parameters. 1065 Header Field Parameter Name Predefined Reference 1066 Values 1067 _____________________________________________________________________ 1068 History-Info mp No [RFC xxxx] 1069 History-Info rc No [RFC xxxx] 1070 Contact mp No [RFC xxxx] 1071 Contact rc No [RFC xxxx] 1072 Note to RFC Editor: Please replace RFC XXXX with the RFC number of 1073 this specification. 1075 14. Acknowledgements 1077 Jonathan Rosenberg et al produced the document that provided 1078 additional use cases precipitating the requirement for the new header 1079 parameters to capture the method by which a Request URI is 1080 determined. The authors would like to acknowledge the constructive 1081 feedback provided by Ian Elz, Paul Kyzivat, John Elwell, Hadriel 1082 Kaplan and Dale Worley. John Elwell provided excellent suggestions 1083 in terms of document structure. 1085 Mark Watson, Cullen Jennings and Jon Peterson provided significant 1086 input into the initial work that resulted in the development of of 1087 [RFC4244]. The editor would like to acknowledge the constructive 1088 feedback provided by Robert Sparks, Paul Kyzivat, Scott Orton, John 1089 Elwell, Nir Chen, Palash Jain, Brian Stucker, Norma Ng, Anthony 1090 Brown, Jayshree Bharatia, Jonathan Rosenberg, Eric Burger, Martin 1091 Dolly, Roland Jesske, Takuya Sawada, Sebastien Prouvost, and 1092 Sebastien Garcin in the development of [RFC4244]. 1094 The editor would like to acknowledge the significant input from Rohan 1095 Mahy on some of the normative aspects of the ABNF for [RFC4244], 1096 particularly around the need for and format of the index and around 1097 the security aspects. 1099 15. Changes from RFC 4244 1101 This RFC replaces [RFC4244]. 1103 Deployment experience with [RFC4244] over the years has shown a 1104 number of issues, warranting an update: 1106 o In order to make [RFC4244] work in "real life", one needs to make 1107 "assumptions" on how History-Info is used. For example, many 1108 implementations filter out many entries, and only leave specific 1109 entries corresponding, for example, to first and last redirection. 1110 Since vendors uses different rules, it causes significant 1111 interoperability isssues. 1113 o [RFC4244] is overly permissive and evasive about recording 1114 entries, causing interoperability issues. 1116 o The examples in the call flows had errors, and confusing because 1117 they often assume "loose routing". 1119 o [RFC4244] has lots of repetitive and unclear text due to the 1120 combination of requirements with solution. 1122 o [RFC4244] gratuitously mandates the use of TLS on every hop. No 1123 existing implementation enforces this rule, and instead, the use 1124 of TLS or not is a general SIP issue, not an [RFC4244] issue per 1125 se. 1127 o [RFC4244] does not include clear procedures on how to deliver 1128 current target URI information to the UAS when the Request-URI is 1129 replaced with a contact. 1131 o [RFC4244] does not allow for marking History-Info entries for easy 1132 processing by User Agents. 1134 The following summarizes the functional changes between this 1135 specification and [RFC4244]: 1137 1. Added header field parameters to capture the specific method by 1138 which a target is determined to facilitate processing by users of 1139 the History-info header field entries. A specific header field 1140 parameter is captured for each of the target URIs as the target 1141 set is determined (per section 16.5 of [RFC3261]). The header 1142 field parameter is used in both the History-Info and the Contact 1143 header fields. 1145 2. Rather than recommending that entries be removed in the case of 1146 certain values of the Privacy header field, the entries are 1147 anonymized. 1149 3. Updated the security section to be equivalent to the security 1150 recommendations for other SIP headers inserted by intermediaries. 1152 The first 2 changes are intended to facilitate application usage of 1153 the History-info header field and eliminate the need to make 1154 assumptions based upon the order of the entries and ensure that the 1155 most complete set of information is available to the applications. 1157 In addition, editorial changes were done to both condense and clarify 1158 the text, moving the requirements to an appendix and removing the 1159 inline references to the requirements. The examples were simplified 1160 and updated to reflect the protocol changes. Several of the call 1161 flows in the appendix were removed and put into a separate document 1162 that includes additional use cases that require the new header 1163 parameters. 1165 15.1. Backwards compatibility 1167 This specification is backwards compatible since [RFC4244] allows for 1168 the addition of new optional parameters. This specification adds an 1169 optional SIP header field parameter to the History-Info and Contact 1170 headers. Entities that have not implemented this specification MUST 1171 ignore these parameters, however, per [RFC4244] an entity MUST NOT 1172 remove this parameter from an hi-entry. 1174 16. Changes since last Version 1176 NOTE TO THE RFC-Editor: Please remove this section prior to 1177 publication as an RFC. 1179 Changes from 04 to 05: 1181 1. Lots of editorial corrections/clarifications per John Elwell's 1182 comment. 1184 2. Updated Reason header section 10.2 to be consistent (i.e., 1185 removed references to retargeting) with section 9.3 (Receiving a 1186 response) where the hi-entries and reason header are added to the 1187 cache. 1189 3. Updated section 9.3 (receiving responses) to also include 1190 timeouts and updated to reflect that we don't add the Reason 1191 header in the case of 2xx responses. 1193 4. Added text in Security considerations with regards to needing a 1194 Privacy Service per RFC 3323 to ensure that the privacy is 1195 applied. 1197 Changes from 03 to 04: 1199 1. Reorganization of sections per John Elwell's comments - i.e., a 1200 common section for building HI referenced by the UA, Intermediary 1201 and Redirect server sections. 1203 2. Removing the use of "escape" when describing the handling of the 1204 Privacy and Reason header fields. 1206 3. Clarification of TEL URIs in terms of not having a Privacy or 1207 Reason header field in the hi-targeted-to-uri. 1209 Changes from 02 to 03: 1211 1. Lots of editorial: 1213 A. Reorganized sections similar to the RFC 4244 order - i.e., 1214 introduce header field parameters and syntax first, then 1215 describe how the functional entities use the header. This 1216 removes redundant (and often inconsistent) text describing 1217 the parameters. 1219 B. Expanded use of "header" to "header field" 1221 C. More precision in terms of "escaping" of the Privacy and 1222 Reason headers in the hi-targeted-to-uri (versus 1223 "adding"/"setting"/etc. them to the hi-entry). 1225 D. Consistent use of parameter names (i.e., hi-entry versus 1226 entry, hi-target versus target, etc.) 1228 E. Moved item 6 in the Index section to the section on Response 1229 handling 1231 F. Removed last remaining vestiges of inline references to 1232 requirements. 1234 2. Clarifications of functionality/applicability including: 1236 A. which messages may contain History-Info 1238 B. removing security text with regards to being able to figure 1239 out if there are missing entries when using TLS (issue #44) 1241 C. More complete information on the new header field parameters 1242 as they relate to the hi-target parameter. 1244 D. Changed wording from passive to active for normative 1245 statements in many cases and removed superfluous normative 1246 language. 1248 3. Rewrite of the Privacy section to address issues and splitting 1249 into the setting of the Privacy header fields and the processing/ 1250 application of the privacy header field priv-values. 1252 4. Rewrite of the Reason header field section - simplifying the text 1253 and adding back the RFC 4244 text with regards to the use of the 1254 Reason header field in cases of internal retargeting. 1256 Changes from 01 to 02: 1258 1. Editorial nits/clarifications. [Issues: 1,6,17,18,21- 1259 23,25,26,30-33,35-37,39,40] 1261 2. Removing extraneous 4244 text - e.g., errors in flows, 1262 "stronger" security, "session" privacy. [Issues: 3,5,7,11 ] 1264 3. Updated definition of "retarget" to be all encompassing - i.e., 1265 also includes internal changes of target URI. Clarified text 1266 for "internal retarging" in proxy section. [Issues: 2,8,9] 1268 4. Clarified that the processing for Proxies is equally applicable 1269 to other SIP intermediaries. [Issue: 9]. 1271 5. Changed more SHOULDs to MUSTs. [Issue: 10] 1273 6. Fixes to Application considerations section. [Issues: 12-15] 1275 7. Changed language in the procedure for Indexing to normative 1276 language. 1278 8. Clarifications for UAC processing: 1280 * MUST add hi-entry. [Issue: 28] 1282 * Clarify applicability to B2BUA. [Issue: 29] 1284 * Fixed text for indexing for UAC in case of 3xx. 1286 9. Changed "hit" URI parameter to header parameters: [Issues:4,40] 1288 * Added index to all target header parameters. [Issues: 41] 1290 * Updated all the relevant sections documenting setting and use 1291 of new header parameters. [Issue: 40] 1293 10. Updated/clarified privacy handling. [Issue: 16] 1295 11. Updated Redirect Server section to allow adding History-info 1296 header fields. [Issue: 24 ] 1298 12. Added text around restrictions for Tel-URIs - i.e., no privacy 1299 or reason. [Issues: 4, 12] 1301 13. Updated text for forking - what goes in response. [Issues: 1302 19,20] 1304 Changes from 00 to 01: 1306 1. Moved examples (except first) in appendix to a new 1307 (informational) document. 1309 2. Updated UAS and UAC sections to clarify and expand on the 1310 handling of the History-info header field. 1312 3. Updated the Application considerations section: 1314 4. 1316 * Included more detail with regards to how applications can make 1317 use of the information, in particular based on the new tags. 1319 * Removed privacy consideration (2nd bullet) since privacy is 1320 now accomplished by anonymizing rather than removal of 1321 entries. 1323 Changes from (individual) barnes-sipcore-4244bis-03 to (WG) ietf- 1324 sipcore-4244bis-00: 1326 1. Added a new SIP/SIPS URI parameter to tag the URIs as they are 1327 added to the target list and those returned in the contact header 1328 in a 3xx response. 1330 2. Updated description of "target" parameter to use the new URI 1331 parameter value in setting the value for the parameter. 1333 3. Clarified privacy. 1335 4. Changed handling at redirect server to include the use of the new 1336 URI parameter and to remove the functionality of adding the 1337 History-Info entries (basically reverting to core 4244 1338 processing). 1340 5. Additional text to clarify that a service such as voicemail can 1341 be done in multiple ways. 1343 6. Editorial changes including removal of some vestiges of tagging 1344 all entries (including the "aor" tag). 1346 Changes from barnes-sipcore-4244bis-02 to 03: 1348 1. Fixed problem with indices in example in voicemail example. 1350 2. Removed oc and rt from the Hi-target parameter. 1352 3. Removed aor tag 1353 4. Added index parameter to "mp" 1355 5. Added use-cases and call-flows from target-uri into appendix. 1357 Changes from barnes-sipcore-4244bis-01 to 02: 1359 1. Added hi-aor parameter that gets marked on the "incoming" hi- 1360 entry. 1362 2. Hi-target parameter defined to be either rc, oc, mp, rt, and now 1363 gets included when adding an hi-entry. 1365 3. Added section on backwards compatibility, as well as added the 1366 recognition and handling of requests that do not support this 1367 specification in the appropriate sections. 1369 4. Updated redirect server/3xx handling to support the new 1370 parameters - i.e., the redirecting entity must add the new hi- 1371 entry since the proxy does not have access to the information as 1372 to how the Contact was determined. 1374 5. Added section on normative differences between this document and 1375 RFC 4244. 1377 6. Restructuring of document to be more in line with current IETF 1378 practices. 1380 7. Moved Requirements section into an Appendix. 1382 8. Fixed ABNF to remove unintended ordering requirement on hi-index 1383 that was introduced in attempting to illustrate it was a 1384 mandatory parameter. 1386 Changes from barnes-sipcore-4244bis-00 to 01 : 1388 1. Clarified "retarget" definition. 1390 2. Removed privacy discussion from optionality section - just refer 1391 to privacy section. 1393 3. Removed extraneous text from target-parameter (leftover from sip- 1394 4244bis). Changed the terminology from the "reason" to the 1395 "mechanism" to avoid ambiguity with parameter. 1397 4. Various changes to clarify some of the text around privacy. 1399 5. Reverted proxy response handling text to previous form - just 1400 changing the privacy aspects to anonymize, rather than remove. 1402 6. Other editorial changes to condense and simplify. 1404 7. Moved Privacy examples to Appendix. 1406 8. Added forking to Basic call example. 1408 Changes from barnes-sipcore-4244bis-00 to 01 : 1410 1. Clarified "retarget" definition. 1412 2. Removed privacy discussion from optionality section - just refer 1413 to privacy section. 1415 3. Removed extraneous text from target-parameter (leftover from sip- 1416 4244bis). Changed the terminology from the "reason" to the 1417 "mechanism" to avoid ambiguity with parameter. 1419 4. Various changes to clarify some of the text around privacy. 1421 5. Reverted proxy response handling text to previous form - just 1422 changing the privacy aspects to anonymize, rather than remove. 1424 6. Other editorial changes to condense and simplify. 1426 7. Moved Privacy examples to Appendix. 1428 8. Added forking to Basic call example. 1430 Changes from barnes-sip-4244bis-00 to barnes-sipcore-4244bis-00: 1432 1. Added tags for each type of retargeting including proxy hops, 1433 etc. - i.e., a tag is defined for each specific mechanism by 1434 which the new Request-URI is determined. Note, this is 1435 extremely helpful in terms of backwards compatibility. 1437 2. Fixed all the examples. Made sure loose routing was used in all 1438 of them. 1440 3. Removed example where a proxy using strict routing is using 1441 History-Info for avoiding trying same route twice. 1443 4. Remove redundant Redirect Server example. 1445 5. Index is now mandated to start at "1" instead of recommended. 1447 6. Updated 3xx behavior as the entity sending the 3XX response MUST 1448 add the hi-target attribute to the previous hi-entry to ensure 1449 that it is appropriately tagged (i.e., it's the only one that 1450 knows how the contact in the 3xx was determined.) 1452 7. Removed lots of ambiguity by making many "MAYs" into "SHOULDs" 1453 and some "SHOULDs" into "MUSTs". 1455 8. Privacy is now recommended to be done by anonymizing entries as 1456 per RFC 3323 instead of by removing or omitting hi-entry(s). 1458 9. Requirement for TLS is now same level as per RFC 3261. 1460 10. Clarified behavior for "Privacy" (i.e., that Privacy is for Hi- 1461 entries, not headers). 1463 11. Removed "OPTIONALITY" as specific requirements, since it's 1464 rather superflous. 1466 12. Other editorial changes to remove redundant text/sections. 1468 Changes from RFC4244 to barnes-sip-4244bis-00: 1470 1. Clarified that HI captures both retargeting as well as cases of 1471 just forwarding a request. 1473 2. Added descriptions of the usage of the terms "retarget", 1474 "forward" and "redirect" to the terminology section. 1476 3. Added additional examples for the functionality provided by HI 1477 for core SIP. 1479 4. Added hi-target parameter values to HI header to ABNF and 1480 protocol description, as well as defining proxy, UAC and UAS 1481 behavior for the parameter. 1483 5. Simplified example call flow in section 4.5. Moved previous call 1484 flow to appendix. 1486 6. Fixed ABNF per RFC4244 errata "dot" -> "." and added new 1487 parameter. 1489 17. References 1491 17.1. Normative References 1493 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1494 A., Peterson, J., Sparks, R., Handley, M., and E. 1495 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1496 June 2002. 1498 [RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason 1499 Header Field for the Session Initiation Protocol (SIP)", 1500 RFC 3326, December 2002. 1502 [RFC3323] Peterson, J., "A Privacy Mechanism for the Session 1503 Initiation Protocol (SIP)", RFC 3323, November 2002. 1505 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1506 Requirement Levels", BCP 14, RFC 2119, March 1997. 1508 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1509 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1511 [RFC4244] Barnes, M., "An Extension to the Session Initiation 1512 Protocol (SIP) for Request History Information", RFC 4244, 1513 November 2005. 1515 17.2. Informative References 1517 [RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User 1518 Agent URIs (GRUUs) in the Session Initiation Protocol 1519 (SIP)", RFC 5627, October 2009. 1521 [RFC5630] Audet, F., "The Use of the SIPS URI Scheme in the Session 1522 Initiation Protocol (SIP)", RFC 5630, October 2009. 1524 [RFC3087] Campbell, B. and R. Sparks, "Control of Service Context 1525 using SIP Request-URI", RFC 3087, April 2001. 1527 [RFC4240] Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network 1528 Media Services with SIP", RFC 4240, December 2005. 1530 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", 1531 RFC 3966, December 2004. 1533 Appendix A. Request History Requirements 1535 The following list constitutes a set of requirements for a "Request 1536 History" capability. 1538 1. CAPABILITY-req: The "Request History" capability provides a 1539 capability to inform proxies and UAs involved in processing a 1540 request about the history/progress of that request. Although 1541 this is inherently provided when the retarget is in response to a 1542 SIP redirect, it is deemed useful for non-redirect retargeting 1543 scenarios, as well. 1545 2. GENERATION-req: "Request History" information is generated when 1546 the request is retargeted. 1548 A. In some scenarios, it might be possible for more than one 1549 instance of retargeting to occur within the same Proxy. A 1550 proxy MUST also generate Request History information for the 1551 'internal retargeting'. 1553 B. An entity (UA or proxy) retargeting in response to a redirect 1554 or REFER MUST include any Request History information from 1555 the redirect/REFER in the new request. 1557 3. ISSUER-req: "Request History" information can be generated by a 1558 UA or proxy. It can be passed in both requests and responses. 1560 4. CONTENT-req: The "Request History" information for each 1561 occurrence of retargeting shall include the following: 1563 A. The new URI or address to which the request is in the process 1564 of being retargeted, 1566 B. The URI or address from which the request was retargeted, and 1567 wether the retarget URI was an AOR 1569 C. The mechanism by which the new URI or address was determined, 1571 D. The reason for the Request-URI or address modification, 1573 E. Chronological ordering of the Request History information. 1575 5. REQUEST-VALIDITY-req: Request History is applicable to requests 1576 not sent within an early or established dialog (e.g., INVITE, 1577 REGISTER, MESSAGE, and OPTIONS). 1579 6. BACKWARDS-req: Request History information may be passed from the 1580 generating entity backwards towards the UAC. This is needed to 1581 enable services that inform the calling party about the dialog 1582 establishment attempts. 1584 7. FORWARDS-req: Request History information may also be included by 1585 the generating entity in the request, if it is forwarded onwards. 1587 A.1. Security Requirements 1589 The Request History information is being inserted by a network 1590 element retargeting a Request, resulting in a slightly different 1591 problem than the basic SIP header problem, thus requiring specific 1592 consideration. It is recognized that these security requirements can 1593 be generalized to a basic requirement of being able to secure 1594 information that is inserted by proxies. 1596 The potential security problems include the following: 1598 1. A rogue application could insert a bogus Request History-Info 1599 entry either by adding an additional hi-entry as a result of 1600 retargeting or entering invalid information. 1602 2. A rogue application could re-arrange the Request History 1603 information to change the nature of the end application or to 1604 mislead the receiver of the information. 1606 3. A rogue application could delete some or all of the Request 1607 History information. 1609 Thus, a security solution for "Request History" must meet the 1610 following requirements: 1612 1. SEC-req-1: The entity receiving the Request History must be able 1613 to determine whether any of the previously added Request History 1614 content has been altered. 1616 2. SEC-req-2: The ordering of the Request History information must 1617 be preserved at each instance of retargeting. 1619 3. SEC-req-3: The entity receiving the information conveyed by the 1620 Request History must be able to authenticate the entity providing 1621 the request. 1623 4. SEC-req-4: To ensure the confidentiality of the Request History 1624 information, only entities that process the request SHOULD have 1625 visibility to the information. 1627 It should be noted that these security requirements apply to any 1628 entity making use of the Request History information. 1630 A.2. Privacy Requirements 1632 Since the Request-URI that is captured could inadvertently reveal 1633 information about the originator, there are general privacy 1634 requirements that MUST be met: 1636 1. PRIV-req-1: The entity retargeting the Request must ensure that 1637 it maintains the network-provided privacy (as described in 1638 [RFC3323]) associated with the Request as it is retargeted. 1640 2. PRIV-req-2: The entity receiving the Request History must 1641 maintain the privacy associated with the information. In 1642 addition, local policy at a proxy may identify privacy 1643 requirements associated with the Request-URI being captured in 1644 the Request History information. 1646 3. PRIV-req-3: Request History information subject to privacy shall 1647 not be included in ougoing messages unless it is protected as 1648 described in [RFC3323]. 1650 Appendix B. Example call flows 1652 The scenarios in this section provide sample use cases for the 1653 History-info header field for informational purposes only. They are 1654 not intended to be normative. A basic forking use case is included, 1655 along with two use cases illustrating the use of the privacy. 1657 B.1. Sequentially Forking (History-Info in Response) 1659 This scenario highlights an example where the History-Info in the 1660 response is useful to an application or user that originated the 1661 request. 1663 Alice sends a call to Bob via sip:example.com. The proxy sip: 1664 example.com sequentially tries Bob on a SIP UA that has bound a 1665 contact with the sip:bob@example.com AOR, and then several alternate 1666 addresses (Office and Home) unsuccessfully before sending a response 1667 to Alice. The hi-entry containing the initial contact is the hi- 1668 entry just prior to the first hi-entry tagged with an "rc" header 1669 field parameter. In this example, the Office and Home are not the 1670 same AOR as sip:bob@example.com, but rather different AORs that have 1671 been configured as alternate addresses for Bob in the proxy. In 1672 other words, Office and Bob are not bound through SIP Registration 1673 with Bob's AOR. This type of arrangement is common for example when 1674 a "routing" rule to a PSTN number is manually configured in a Proxy. 1675 These hi-entries are identified by the index contained in the hi- 1676 target-param "mp" header field parameter in the hi-entries. 1678 This scenario illustrates that by providing the History-Info to 1679 Alice, the end-user or an application at Alice could make a decision 1680 on how best to attempt finding Bob without sending multiple requests 1681 to the same destination. Upon receipt of the response containing the 1682 History-Info entries, the Request URIs for the History-Info entries 1683 tagged with "mp" header field parameter are extracted. Those 1684 Request-URIs can be compared to other URIs (if any) that might be 1685 attempted in order to establish the session with Bob. Thus, avoiding 1686 another INVITE to Bob's home phone. Without this mechanism, Alice 1687 might well attempt to reach Bob at his office phone, which would then 1688 retarget the request to Bob's home phone. When that attempt failed, 1689 then Alice might attempt to reach Bob directly at his home phone, 1690 unknowingly for a third time. 1692 Alice example.com Bob Office Home 1693 | | | | | 1694 | INVITE F1 | | | | 1695 |----------->| INVITE F2 | | | 1696 | |----------------->| | | 1697 | 100 Trying F3 | | | 1698 |<-----------| 302 Move Temporarily F4 | | 1699 | |<-----------------| | | 1700 | | ACK F5 | | | 1701 | |----------------->| | | 1702 | | INVITE F6 | | 1703 | |-------------------------->| | 1704 | | 180 Ringing F7 | | 1705 | |<--------------------------| | 1706 | 180 Ringing F8 | | 1707 |<-----------| retransmit INVITE | | 1708 | |-------------------------->| | 1709 | | ( timeout ) | | 1710 | | INVITE F9 | 1711 | |----------------------------------->| 1712 | | 100 Trying F10 | 1713 | |<-----------------------------------| 1714 | | 486 Busy Here F11 | 1715 | |<-----------------------------------| 1716 | 486 Busy Here F12 | 1717 |<-----------| ACK F13 | 1718 | |----------------------------------->| 1719 | ACK F14 | | 1720 |----------->| | 1721 Message Details 1723 F1 INVITE alice -> example.com 1725 INVITE sip:alice@example.com SIP/2.0 1726 Via: SIP/2.0/TCP 192.0.2.3:5060 1727 From: Alice 1728 To: Bob 1729 Supported: histinfo 1730 Call-Id: 12345600@example.com 1731 CSeq: 1 INVITE 1732 History-Info: ;index=1 1733 Contact: Alice 1734 Content-Type: application/sdp 1735 Content-Length: 1736 1738 F2 INVITE example.com -> Bob 1740 INVITE sip:bob@192.0.2.4 SIP/2.0 1741 Via: SIP/2.0/TCP proxy.example.com:5060 1742 Via: SIP/2.0/TCP 192.0.2.3:5060 1743 From: Alice 1744 To: Bob 1745 Supported: histinfo 1746 Call-Id: 12345600@example.com 1747 CSeq: 1 INVITE 1748 Record-Route: 1749 History-Info: ;index=1 1750 History-Info: ;index=1.1;rc=1 1751 Contact: Alice 1752 Content-Type: application/sdp 1753 Content-Length: 1754 1756 F3 100 Trying example.com -> alice 1758 SIP/2.0 100 Trying 1759 Via: SIP/2.0/TCP 192.0.2.3:5060 1760 From: Alice 1761 To: Bob 1762 Call-Id: 12345600@example.com 1763 CSeq: 1 INVITE 1764 Content-Length: 0 1765 F4 302 Moved Temporarily Bob -> example.com 1767 SIP/2.0 302 Moved Temporarily 1768 Via: SIP/2.0/TCP proxy.example.com:5060 1769 Via: SIP/2.0/TCP 192.0.2.3:5060 1770 From: Alice 1771 To: Bob ;tag=3 1772 Call-Id: 12345600@example.com 1773 CSeq: 1 INVITE 1774 Record-Route: 1775 History-Info: ;index=1 1776 History-Info: ;index=1.1;rc=1 1777 Contact: ;mp=1 1778 Content-Length: 0 1780 F5 ACK 192.0.2.4 -> Bob 1782 ACK sip:home@example.com SIP/2.0 1783 Via: SIP/2.0/TCP proxy.example.com:5060 1784 From: Alice 1785 To: Bob 1786 Call-Id: 12345600@example.com 1787 CSeq: 1 ACK 1788 Content-Length: 0 1790 F6 INVITE example.com -> office 1792 INVITE sip:office@192.0.2.3.com SIP/2.0 1793 Via: SIP/2.0/TCP proxy.example.com:5060;branch=2 1794 Via: SIP/2.0/TCP 192.0.2.3:5060 1795 From: Alice 1796 To: Bob 1797 Supported: histinfo 1798 Call-Id: 12345600@example.com 1799 Record-Route: 1800 History-Info: ;index=1 1801 History-Info: ;\ 1802 index=1.1;rc=1 1803 History-Info: ;index=1.2;mp=1 1804 History-Info: ;index=1.2.1 1805 CSeq: 1 INVITE 1806 Contact: Alice 1807 Content-Type: application/sdp 1808 Content-Length: 1809 1811 F7 180 Ringing office -> example.com 1813 SIP/2.0 180 Ringing 1814 Via: SIP/2.0/TCP proxy.example.com:5060;branch=2 1815 Via: SIP/2.0/TCP 192.0.2.3:5060 1816 From: Alice 1817 To: Bob ;tag=5 1818 Supported: histinfo 1819 Call-ID: 12345600@example.com 1820 Record-Route: 1821 History-Info: ;index=1 1822 History-Info: ;\ 1823 index=1.1;rc=1 1824 History-Info: ;index=1.2;mp=1 1825 History-Info: ;index=1.2.1 1826 CSeq: 1 INVITE 1827 Content-Length: 0 1829 F8 180 Ringing example.com -> alice 1831 SIP/2.0 180 Ringing 1832 Via: SIP/2.0/TCP example.com:5060 1833 From: Alice 1834 To: Bob 1835 Supported: histinfo 1836 Call-Id: 12345600@example.com 1837 History-Info: ;index=1 1838 History-Info: ;\ 1839 index=1.1;rc=1 1840 History-Info: ;index=1.2;mp=1 1841 History-Info: ;index=1.2.1 1842 CSeq: 1 INVITE 1843 Content-Length: 0 1844 F9 INVITE example.com -> home 1846 INVITE sip:home@192.0.2.6 SIP/2.0 1847 Via: SIP/2.0/TCP proxy.example.com:5060;branch=3 1848 Via: SIP/2.0/TCP 192.0.2.3:5060 1849 From: Alice 1850 To: Bob 1851 Supported: histinfo 1852 Call-Id: 12345600@example.com 1853 Record-Route: 1854 History-Info: ;index=1 1855 History-Info: ;\ 1856 index=1.1;rc=1 1857 History-Info: ;index=1.2;mp=1 1858 History-Info: ;\ 1859 index=1.2.1>;index=1.2.1 1860 History-Info: ;index=1.3;mp=1 1861 History-Info: ;index=1.3.1 1862 CSeq: 1 INVITE 1863 Contact: Alice 1864 Content-Type: application/sdp 1865 Content-Length: 1866 1868 F10 100 Trying home -> example.com 1870 SIP/2.0 100 Trying 1871 Via: SIP/2.0/TCP proxy.example.com:5060;branch=3 1872 Via: SIP/2.0/TCP 192.0.2.3:5060 1873 From: Alice 1874 To: Bob 1875 Call-Id: 12345600@example.com 1876 CSeq: 1 INVITE 1877 Content-Length: 0 1878 F11 486 Busy Here home -> example.com 1880 SIP/2.0 486 Busy Here 1881 Via: SIP/2.0/TCP proxy.example.com:5060;branch=3 1882 Via: SIP/2.0/TCP 192.0.2.3:5060 1883 From: Alice 1884 To: Bob 1885 Call-Id: 12345600@example.com 1886 Record-Route: 1887 History-Info: ;index=1 1888 History-Info: ;\ 1889 index=1.1;rc=1 1890 History-Info: ;index=1.2;mp=1 1891 History-Info: ;\ 1892 index=1.2.1>;index=1.2.1 1893 History-Info: ;index=1.3;mp=1 1894 History-Info: ;index=1.3.1 1895 CSeq: 1 INVITE 1896 Content-Length: 0 1898 F12 486 Busy Here example.com -> alice 1900 SIP/2.0 486 Busy Here 1901 Via: SIP/2.0/TCP 192.0.2.3:5060 1902 From: Alice 1903 To: Bob 1904 Call-Id: 12345600@example.com 1905 History-Info: ;index=1 1906 History-Info: ;\ 1907 index=1.1;rc=1 1908 History-Info: ;index=1.2;mp=1 1909 History-Info: ;\ 1910 index=1.2.1>;index=1.2.1 1911 History-Info: ;index=1.3;mp=1 1912 History-Info: ;index=1.3.1 1913 CSeq: 1 INVITE 1914 Content-Length: 0 1915 F13 ACK example.com -> home 1917 ACK sip:home@example.com SIP/2.0 1918 Via: SIP/2.0/TCP proxy.example.com:5060 1919 From: Alice 1920 To: Bob 1921 Call-Id: 12345600@example.com 1922 CSeq: 1 ACK 1923 Content-Length: 0 1925 F14 ACK alice -> example.com 1927 ACK sip:bob@example.com SIP/2.0 1928 Via: SIP/2.0/TCP 192.0.2.3:5060 1929 From: Alice 1930 To: Bob 1931 Call-Id: 12345600@example.com 1932 Route: 1933 CSeq: 1 ACK 1934 Content-Length: 0 1936 B.2. History-Info with Privacy Header Field 1938 This example provides a basic call scenario without forking. Alice 1939 has indicated that she wants Privacy associated with the History-Info 1940 header field entries. In addition, sip:biloxi.example.com adds 1941 Privacy header fields indicating that the History-info header field 1942 information is anonymized outside the biloxi.example.com domain. 1943 Note, that if the atlanta.example.com proxy had added privacy header 1944 fields to all its hi-entries, then all the hi-entries in the response 1945 would be anonymous. 1947 Alice atlanta.example.com biloxi.example.com Bob 1948 | | | | 1949 | INVITE sip:bob@biloxi.example.com;p=x | 1950 |--------------->| | | 1951 | Supported: histinfo | | 1952 | Privacy: History | | 1953 | History-Info: ;index=1 1954 | | | | 1955 | | INVITE sip:bob@biloxi.example.com;p=x 1956 | |--------------->| | 1957 | History-Info: ;index=1 1958 | History-Info: ;index=1.1 1959 | | | | 1960 | | | INVITE sip:bob@192.0.2.3 1961 | | |--------------->| 1962 | History-Info: ;index=1 1963 | History-Info: ;index=1.1 1964 | History-Info: ;index=1.1.1;rc=1.1 1965 | | | | 1966 | | | 200 | 1967 | | |<---------------| 1968 | History-Info: ;index=1 1969 | History-Info: ;index=1.1 1970 | History-Info: ;index=1.1.1;rc=1.1 1971 | | | | 1972 | | 200 | | 1973 | |<---------------| | 1974 | History-Info: ;index=1 1975 | History-Info: ;index=1.1 1976 | History-Info: ;index=1.1.1;rc=1.1 1977 | | | | 1978 | 200 | | | 1979 |<---------------| | | 1980 | History-Info: ;index=1 1981 | History-Info: ;index=1.1 1982 | History-Info: ;index=1.1.1;rc=1.1 1983 | | | | 1984 | ACK | | | 1985 |--------------->| ACK | | 1986 | |--------------->| ACK | 1987 | | |--------------->| 1989 Figure 2: Example with Privacy Header Fields 1991 B.3. Privacy for a Specific History-Info Entry 1993 This example provides a basic call scenario similar to Appendix B.2, 1994 however, due to local policy at sip:biloxi.example.com, only the 1995 final hi-entry in the History-Info, which is Bob's local URI, 1996 contains a privacy header field with a priv-value of "history", thus 1997 providing Alice with some information about the history of the 1998 request, but anonymizing Bob's local URI. 2000 Alice atlanta.example.com biloxi.example.com Bob 2001 | | | | 2002 | INVITE sip:bob@biloxi.example.com;p=x | 2003 |--------------->| | | 2004 | Supported: histinfo | | 2005 | | | | 2006 | | INVITE sip:bob@biloxi.example.com;p=x 2007 | |--------------->| | 2008 | History-Info: ;index=1 2009 | History-Info: ;index=1.1 2010 | | | | 2011 | | | INVITE sip:bob@192.0.2.3 2012 | | |--------------->| 2013 | History-Info: ;index=1 2014 | History-Info: ;index=1.1 2015 | History-Info: ;index=1.1.1;rc=1.1 2016 | | | | 2017 | | | 200 | 2018 | | |<---------------| 2019 | History-Info: ;index=1 2020 | History-Info: ;index=1.1 2021 | History-Info: ;index=1.1.1;rc=1.1 2022 | | | | 2023 | | 200 | | 2024 | |<---------------| | 2025 | History-Info: ;index=1 2026 | History-Info: ;index=1.1 2027 | History-Info: ;index=1.1.1;rc=1.1 2028 | | | | 2029 | 200 | | | 2030 |<---------------| | | 2031 | History-Info: ;index=1 2032 | History-Info: ;index=1.1 2033 | History-Info: ;index=1.1.1;rc=1.1 2034 | | | | 2035 | ACK | | | 2036 |--------------->| ACK | | 2037 | |--------------->| ACK | 2038 | | |--------------->| 2040 Figure 3: Example with Privacy Header Field for Specific URI 2042 Authors' Addresses 2044 Mary Barnes 2045 Polycom 2046 TX 2047 US 2049 Email: mary.ietf.barnes@gmail.com 2051 Francois Audet 2052 Skype 2054 Email: francois.audet@skype.net 2056 Shida Schubert 2057 NTT 2059 Email: shida@agnada.com 2061 Hans Erik van Elburg 2062 Detecon International Gmbh 2063 Oberkasseler str. 2 2064 Bonn, 2065 Germany 2067 Email: ietf.hanserik@gmail.com 2069 Christer Holmberg 2070 Ericsson 2071 Hirsalantie 11, Jorvas 2072 Finland 2074 Email: christer.holmberg@ericsson.com