idnits 2.17.1 draft-ietf-sipcore-rfc4244bis-09.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 443 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 (Sept 2012) is 4487 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC XXXX' is mentioned on line 1152, but not defined == Unused Reference: 'RFC3969' is defined on line 1384, 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 (~~), 5 warnings (==), 1 comment (--). 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: March 5, 2013 S. Schubert 7 NTT 8 J. van Elburg 9 Detecon International Gmbh 10 C. Holmberg 11 Ericsson 12 Sept 2012 14 An Extension to the Session Initiation Protocol (SIP) for Request 15 History Information 16 draft-ietf-sipcore-rfc4244bis-09.txt 18 Abstract 20 This document defines a standard mechanism for capturing the history 21 information associated with a Session Initiation Protocol (SIP) 22 request. This capability enables many enhanced services by providing 23 the information as to how and why a SIP request arrives at a specific 24 application or user. This document defines an optional SIP header 25 field, History-Info, for capturing the history information in 26 requests. The document also defines SIP header field parameters for 27 the History-Info and Contact header fields to tag the method by which 28 the target of a request is determined. In addition, this 29 specification defines a value for the Privacy header field that 30 directs the anonymization of values in the History-Info header field. 31 This document obsoletes RFC 4244. 33 Status of this Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on March 5, 2013. 50 Copyright Notice 52 Copyright (c) 2012 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 This document may contain material from IETF Documents or IETF 66 Contributions published or made publicly available before November 67 10, 2008. The person(s) controlling the copyright in some of this 68 material may not have granted the IETF Trust the right to allow 69 modifications of such material outside the IETF Standards Process. 70 Without obtaining an adequate license from the person(s) controlling 71 the copyright in such materials, this document may not be modified 72 outside the IETF Standards Process, and derivative works of it may 73 not be created outside the IETF Standards Process, except to format 74 it for publication as an RFC or to translate it into languages other 75 than English. 77 Table of Contents 79 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 80 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 81 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 5 82 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 83 5. History-Info Header Field Protocol Structure . . . . . . . . . 7 84 5.1. History-Info Header Field Example Scenario . . . . . . . . 10 85 6. User Agent Handling of the History-Info Header Field . . . . . 13 86 6.1. User Agent Client (UAC) Behavior . . . . . . . . . . . . . 13 87 6.2. User Agent Server (UAS) Behavior . . . . . . . . . . . . . 13 88 7. Proxy/Intermediary Handling of History-Info Header Fields . . 13 89 8. Redirect Server Handling of History-Info Header Fields . . . . 14 90 9. Handling of History-Info Header Fields in Requests and 91 Responses . . . . . . . . . . . . . . . . . . . . . . . . . . 14 92 9.1. Receiving a Request . . . . . . . . . . . . . . . . . . . 15 93 9.2. Sending a Request with History-Info . . . . . . . . . . . 15 94 9.3. Receiving a Response with History-Info or Request 95 Timeouts . . . . . . . . . . . . . . . . . . . . . . . . . 16 96 9.4. Sending History-Info in Responses . . . . . . . . . . . . 16 97 10. Processing the History-Info Header Field . . . . . . . . . . . 17 98 10.1. Privacy in the History-Info Header Field . . . . . . . . . 17 99 10.1.1. Indicating Privacy . . . . . . . . . . . . . . . . . 17 100 10.1.2. Applying Privacy . . . . . . . . . . . . . . . . . . 18 101 10.2. Reason in the History-Info Header Field . . . . . . . . . 19 102 10.3. Indexing in the History-Info Header Field . . . . . . . . 20 103 10.4. Mechanism for Target Determination in the History-Info 104 Header Field . . . . . . . . . . . . . . . . . . . . . . . 21 105 11. Application Considerations . . . . . . . . . . . . . . . . . . 22 106 12. Application Specific Usage . . . . . . . . . . . . . . . . . . 24 107 12.1. PBX Voicemail . . . . . . . . . . . . . . . . . . . . . . 24 108 12.2. Consumer Voicemail . . . . . . . . . . . . . . . . . . . . 25 109 13. Security Considerations . . . . . . . . . . . . . . . . . . . 25 110 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 111 14.1. Registration of New SIP History-Info Header Field . . . . 26 112 14.2. Registration of "history" for SIP Privacy Header Field . . 27 113 14.3. Registration of Header Field Parameters . . . . . . . . . 27 114 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 115 16. Changes from RFC 4244 . . . . . . . . . . . . . . . . . . . . 28 116 16.1. Backwards compatibility . . . . . . . . . . . . . . . . . 30 117 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 118 17.1. Normative References . . . . . . . . . . . . . . . . . . . 31 119 17.2. Informative References . . . . . . . . . . . . . . . . . . 32 120 Appendix A. Request History Requirements . . . . . . . . . . . . 32 121 A.1. Security Requirements . . . . . . . . . . . . . . . . . . 33 122 A.2. Privacy Requirements . . . . . . . . . . . . . . . . . . . 34 123 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 125 1. Introduction 127 Many services that SIP is anticipated to support require the ability 128 to determine why and how a SIP request 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 obtain information 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 specification 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 specification are included in 152 Appendix A. 154 2. Conventions and Terminology 156 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 157 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 158 document are to be interpreted as described in [RFC2119]. 160 The term "retarget" is used in this specification to refer to the 161 process of a SIP entity changing the request-URI [RFC3261, section 162 7.1] in a request based on the rules for determining request targets 163 as described in Section 16.5 of [RFC3261] and of the subsequent 164 forwarding of that request as described in step 2 in section 16.6 of 165 [RFC3261]. This includes changing the Request-URI due to a location 166 service lookup and redirect processing. This also includes internal 167 (to a Proxy/SIP intermediary) changes of the URI prior to forwarding 168 of the request. 170 The terms "location service", "forward", "redirect" and "AOR" are 171 used consistent with the terminology in [RFC3261]. 173 The terms "target user" is used in this specification as the human 174 user associated with particular AoR or AoRs (in case the human user 175 has multiple alias). 177 The references to "domain for which the SIP entity/Proxy/Intermediary 178 is responsible" are consistent with and intended to convey the same 179 context as the usage of that terminology in [RFC3261]. The 180 applicability of History-Info to architectures or models outside the 181 context of [RFC3261] is outside the scope of this specification. 183 3. Background 185 SIP implicitly provides retargeting capabilities that enable SIP 186 requests to be routed to specific applications as defined in 187 [RFC3261]. The motivation for capturing the request history is that 188 in the process of retargeting a request, old routing information can 189 be forever lost. This lost information may be important history that 190 allows elements to which the request is retargeted to process the 191 request in a locally defined, application-specific manner. This 192 document defines a mechanism for transporting the request history. 193 Application-specific behavior is outside the scope of this 194 specification. 196 Current network applications for other protocols provide the ability 197 for elements involved with the request to obtain additional 198 information relating to how and why the request was routed to a 199 particular destination. The following are examples of such 200 applications: 202 1. Web "referral" applications, whereby an application residing 203 within a web server determines that a visitor to a website has 204 arrived at the site via an "associate" site that will receive 205 some "referral" commission for generating this traffic 207 2. Email forwarding whereby the forwarded-to user obtains a detailed 208 "trace of the path" of the message from sender to receiver and at 209 what time 211 3. Traditional telephony services such as voicemail, call-center 212 "automatic call distribution", and "follow-me" style services 214 Several of the aforementioned applications currently define 215 application-specific mechanisms through which it is possible to 216 obtain the necessary history information. 218 In addition, request history information could be used to enhance 219 basic SIP functionality by providing the following: 221 o Some diagnostic information for debugging SIP requests. 223 o Capturing aliases and Globally Routable User Agent URIs (GRUUs) 224 [RFC5627], which can be overwritten by a registrar or a "home 225 proxy" (a proxy serving as the terminal point for routing an 226 address-of-record) upon receipt of the initial request. 228 o Facilitating the use of limited use addresses (minted on demand) 229 and sub-addressing. 231 o Preserving service specific URIs that can be overwritten by a 232 downstream proxy, such as those defined in [RFC3087], and control 233 of network announcements and IVR with SIP URI [RFC4240]. 235 4. Overview 237 The fundamental functionality provided by the request history 238 information is the ability to inform proxies and UAs involved in 239 processing a request about the history or progress of that request. 240 The solution is to capture the Request-URIs as a request is 241 retargeted, in a SIP header field: History-Info. This allows for the 242 capturing of the history of a request that would be lost with the 243 normal SIP processing involved in the subsequent retargeting of the 244 request. 246 The History-Info header field is added to a Request when a new 247 request is created by a UAC or forwarded by a Proxy, or when the 248 target of a request is changed. It is possible for the target of a 249 request to be changed by the same proxy/SIP intermediary multiple 250 times (referred to as 'internal retargeting'). A SIP entity changing 251 the target of a request in response to a redirect also propagates any 252 History-Info header field from the initial request in the new 253 request. The ABNF and detailed description of the History-Info 254 header field parameters along with examples, is provided in 255 Section 5. Section 6, Section 7 and Section 8 provide the detailed 256 handling of the History-Info header field by SIP User Agents, Proxies 257 and Redirect Servers respectively. 259 This specification also defines three new SIP header field 260 parameters, "rc", "mp" and "np", for the History-Info and Contact 261 header fields, to tag the method by which the target of a request is 262 determined. Further detail on the use of these header field 263 parameters is provided in Section 10.4. 265 In addition, this specification defines a priv-value for the Privacy 266 header, "history", that requires anonymization of all the History- 267 Info header field entries in a Request or to a specific History-Info 268 header field hi-entry as described above. Further detail is provided 269 in Section 10.1. 271 5. History-Info Header Field Protocol Structure 273 The History-Info header field defined in this specification defines 274 the usage in out-of-dialog requests or initial requests for a dialog 275 (e.g., INVITE, REGISTER, MESSAGE, REFER and OPTIONS, PUBLISH and 276 SUBSCRIBE, etc.) and any non-100 provisional or final responses to 277 these requests. 279 The following provides details for the information that is captured 280 in the History-Info header field entries for each target used for 281 forwarding a request: 283 o hi-targeted-to-uri: A mandatory parameter for capturing the 284 Request-URI for the specific request as it is forwarded. 286 o hi-index: A mandatory parameter for History-Info reflecting the 287 chronological order of the information, indexed to reflect the 288 forking and retargeting of requests. The format for this 289 parameter is a sequance of nonnegative integers, separated by dots 290 to indicate the number of forward hops and retargets. This 291 results in a tree representation of the history of the request, 292 with the lowest-level index reflecting a leaf. By adding the new 293 entries in order (i.e., following existing entries per the details 294 in Section 10.3), including the index and sending the messages 295 using a secure transport, the ordering of the History-Info header 296 fields in the request is assured. In addition, applications may 297 extract a variety of metrics (total number of retargets, total 298 number of retargets from a specific branch, etc.) based upon the 299 index values. 301 o hi-target-param: An optional parameter reflecting the mechanism by 302 which the Request URI captured in the hi-targeted-to-uri in the 303 History-Info header field value (hi-entry) was determined. This 304 parameter is either an "rc", "mp" or "np" header field parameter, 305 which is interpreted as follows: 307 "rc": The hi-targeted-to-URI represents a change in Request-URI 308 while the target user remains the same. This occurs for 309 example when user has multiple AoRs as an alias. The "rc" 310 header field parameter contains the value of the hi-index in 311 the hi-entry with an hi-targeted-to-uri that reflects the 312 Request-URI that was retargeted 313 "mp": The hi-targeted-to-URI represents a user other than the 314 target user associated with the Request-URI in the incoming 315 request that was retargeted. This occurs when a request is 316 statically or dynamically retargeted to another user 317 represented by an AoR unassociated with the AoR of the original 318 target user. The "mp" header field parameter contains the 319 value of the hi-index in the hi-entry with an hi-targeted-to- 320 uri that reflects the Request-URI that was retargeted, thus 321 identifying the "mapped from" target. 323 "np": The hi-targeted-to-URI represents that there was no 324 change in Request-URI. This would apply for example when a 325 proxy merely forwards a request to a next hop proxy and loose 326 routing is used. The "np" header field parameter contains the 327 value of the hi-index in the hi-entry with an hi-targeted-to- 328 uri that reflects the Request-URI that was copied unchanged 329 into the request represented by this hi-entry. That value will 330 usually be the hi-index of the parent hi-entry of this hi- 331 entry. 333 o Extension (hi-extension): A parameter to allow for future optional 334 extensions. As per [RFC3261], any implementation not 335 understanding an extension MUST ignore it. 337 The ABNF syntax [RFC5234] for the History-Info header field and 338 header field parameters is as follows: 340 History-Info = "History-Info" HCOLON hi-entry *(COMMA hi-entry) 342 hi-entry = hi-targeted-to-uri *(SEMI hi-param) 344 hi-targeted-to-uri = addr-spec / name-addr 346 hi-param = hi-index / hi-target-param / hi-extension 348 hi-index = "index" EQUAL index-val 350 index-val = number *("." number) 352 number = [ %31-39 *DIGIT ] DIGIT 354 hi-target-param = rc-param / mp-param / np-param 356 rc-param = "rc" EQUAL index-val 358 mp-param = "mp" EQUAL index-val 360 np-param = "np" EQUAL index-val 362 hi-extension = generic-param 364 The ABNF definitions for "generic-param" and "name-addr" are from 365 [RFC3261]. 367 This document also extends the "contact-params" for the Contact 368 header field as defined in [RFC3261] with the "rc", "mp" and "np" 369 header field parameters defined above. 371 In addition to the parameters defined by the ABNF, an hi-entry may 372 also include a Reason header field and/or a Privacy header field, 373 which are both included in the "headers" component of the hi- 374 targeted-to-uri as described below: 376 o Reason: An optional parameter for History-Info, reflected in the 377 History-Info header field by including the Reason header field 378 [RFC3326] included in the hi-targeted-to-uri. A reason is 379 included in the hi-targeted-to-uri of an hi-entry to reflect 380 information received in a response to the request sent to that 381 URI. 383 o Privacy: An optional parameter for History-Info, reflected in the 384 History-Info header field values by including the Privacy Header 385 [RFC3323] included in the hi- targeted-to-uri or by adding the 386 Privacy header field to the request. The latter case indicates 387 that the History-Info entries for all History-Info entries whose 388 hi-targeted-to-uri has the same domain as the domain for which the 389 SIP entity processing the message is responsible MUST be 390 anonymized prior to forwarding, whereas the use of the Privacy 391 header field included in the hi-targeted-to-uri means that a 392 specific hi-entry MUST be anonymized. 394 Note that since both the Reason and Privacy parameters are included 395 in the hi-targeted-to-uri, these fields will not be available in the 396 case that the hi-targeted-to-uri is a Tel-URI [RFC3966]. 398 The following provides examples of the format for the History-Info 399 header field. Note that the backslash, CRLF and whitespace between 400 the lines in the examples below are inserted for readability purposes 401 only. Note, however, that History-Info can be broken into multiple 402 lines due to the SWS that is part of HCOLON, COMMA and SEMI, and 403 there can be multiple History-Info header fields due to the rule of 404 section 7.3 [RFC3261]. Additional detailed examples are available in 405 [I-D.barnes-sipcore-rfc4244bis-callflows]. 407 History-Info: ;index=1;foo=bar 409 History-Info: ;index=1.1,\ 411 ;index=1.2;mp=1.1,\ 413 ;index=1.3;rc=1.2 415 5.1. History-Info Header Field Example Scenario 417 The following is an illustrative example of usage of History-Info. 419 In this example, Alice (sip:alice@atlanta.example.com) calls Bob 420 (sip:bob@biloxi.example.com). Alice's proxy in her home domain (sip: 421 atlanta.example.com) forwards the request to Bob's proxy (sip: 422 biloxi.example.com). When the request arrives at sip: 423 biloxi.example.com, it does a location service lookup for 424 bob@biloxi.example.com and changes the target of the request to Bob's 425 Contact URIs provided as part of normal SIP registration. In this 426 example, Bob is simultaneously contacted on a PC client and on a 427 phone, and Bob answers on the PC client. 429 One important thing illustrated by this call flow is that without 430 History-Info, Bob would "lose" the original target information or the 431 initial request-URI, including any parameters in the request URI. 432 Bob can recover that information by locating the last hi-entry with 433 an "rc" header field parameter. This "rc" header field parameter 434 contains the index of the hi-entry containing the lost target 435 information - i.e., the sip:bob@biloxi.example.com hi-entry with 436 index=1.1. Note that in the 200 response to Alice, an hi-entry is 437 not included for the fork to sip:bob@192.0.2.7 (index 1.1.1) since 438 biloxi.example.com had not received a response from that fork at the 439 time it sent the 200 OK that ultimately reached Alice. 441 Note: This example uses loose routing procedures. 443 Alice atlanta.example.com biloxi.example.com Bob@pc Bob@phone 444 | | | | | 445 | INVITE sip:bob@biloxi.example.com;p=x | | 446 |--------------->| | | | 447 | Supported: histinfo | | | 448 | | | | | 449 | | INVITE sip:bob@biloxi.example.com;p=x | 450 | |--------------->| | | 451 | History-Info: ;index=1 | 452 | History-Info: ;np=1;index=1.1 453 | | | | | 454 | | | INVITE sip:bob@192.0.2.3| 455 | | |--------------->| | 456 | History-Info: ;index=1 457 | History-Info: ;np=1;index=1.1 458 | History-Info: ;index=1.1.1;rc=1.1 459 | | | | | 460 | | | INVITE sip:bob@192.0.2.7| 461 | | |-------------------------->| 462 | History-Info: ;index=1 463 | History-Info: ;np=1;index=1.1 464 | History-Info: ;index=1.1.2;rc=1.1 465 | | | 200 | | 466 | | |<---------------| | 467 | History-Info: ;index=1 468 | History-Info: ;np=1;index=1.1 469 | History-Info: ;index=1.1.1;rc=1.1 470 | | | | | 471 | | 200 | | | 472 | |<---------------| | | 473 | History-Info: ;index=1 474 | History-Info: ;np=1;index=1.1 475 | History-Info: ;index=1.1.1;rc=1.1 476 | | | | | 477 | | | Proxy Cancels INVITE | 478 | | |<=========================>| 479 | | | | | 480 | 200 | | | | 481 |<---------------| | | | 482 | History-Info: ;index=1 483 | History-Info: ;np=1;index=1.1 484 | History-Info: ;index=1.1.1;rc=1.1 485 | | | | | 486 | ACK | | | | 487 |--------------->| ACK | | | 488 | |--------------->| ACK | | 489 | | |--------------->| | 490 Figure 1: Basic Call 492 6. User Agent Handling of the History-Info Header Field 494 A B2BUA MAY follow the behavior of a SIP intermediary as an 495 alternative to following the behavior of a UAS per Section 6.2 and a 496 UAC per Section 6.1. In behaving as an intermediary, a B2BUA carries 497 forward hi-entries received in requests at the UAS to requests being 498 forwarded by the UAC, as well as carrying forward hi-entries in 499 responses received at the UAC to the responses forwarded by the UAS, 500 subject to privacy considerations per Section 10.1. 502 6.1. User Agent Client (UAC) Behavior 504 The UAC MUST include the "histinfo" option tag in the Supported 505 header field in any out-of-dialog requests or initial requests for a 506 dialog for which the UAC would like the History-Info header field in 507 the response. When issuing a request, the UAC MUST follow the 508 procedures in Section 9.2. In the case of an initial request, except 509 where the UAC is part of a B2BUA, there is no cache of hi- entries 510 with which to populate the History-Info header field and the hi-index 511 is set to 1 per Section 10.3. When receiving a response the UAC MUST 512 follow the procedures in Section 9.3. 514 If the UAC generates further forks of the initial request (either due 515 to acting on a 3xx response or internally-directed forking to 516 multiple destinations), the successive requests will add hi-entries 517 with hi-indexes of 2, 3, etc. 519 6.2. User Agent Server (UAS) Behavior 521 When receiving a request, a UAS MUST follow the procedures defined in 522 Section 9.2. When sending a response other than a 3xx response, a 523 UAS MUST follows the procedures as defined in Section 9.4. When 524 sending a 3xx response, the UAS MUST follow the procedures defined 525 for a redirect server per Section 8. An application at the UAS can 526 make use of the cached hi-entries as described in Section 11. 528 7. Proxy/Intermediary Handling of History-Info Header Fields 530 This section describes the procedures for proxies and other SIP 531 intermediaries for the handling of the History-Info header fields for 532 each of the following scenarios: 534 Receiving a Request: An intermediary MUST follow the procedures in 535 Section 9.1 for the handling of hi-entries in incoming SIP 536 requests. 538 Sending a Request: For each outgoing request relating to a target in 539 the target set, the intermediary MUST follow the procedures of 540 Section 9.2. 542 Receiving a Response or Timeout: An intermediary MUST follow the 543 procedures of Section 9.3 when a SIP response is received or a 544 request times out. 546 Sending a Response: An intermediary MUST follow the procedures of 547 Section 9.4 for the handling of the hi-entries when sending a SIP 548 response. 550 In some cases, an intermediary may retarget a request more than once 551 before forwarding - i.e., a request is retargeted to a SIP entity 552 that is "internal" to the intermediary before the same intermediary 553 retargets the request to an external target . A typical example 554 would be a proxy that retargets a request first to a different user 555 (i.e., it maps to a different AOR) and then forwards to a registered 556 contact bound to the same AOR. In this case, the intermediary MUST 557 add a hi-entry for (each of) the internal target(s) per the 558 procedures in Section 9.2. The intermediary MAY include a Reason 559 header field in the hi-entry with the hi-targeted-to-uri that has 560 been retargeted. 562 8. Redirect Server Handling of History-Info Header Fields 564 A redirect server MUST follow the procedures in Section 9.1 when it 565 receives a SIP Request. A redirect server MUST follow the procedures 566 in Section 9.4 when it sends a SIP Response. When generating the 567 Contact header field in a 3xx response, the redirect server MUST add 568 the appropriate "mp", "np" or "rc" header field parameter to each 569 Contact header field as described in Section 10.4, if applicable. 571 9. Handling of History-Info Header Fields in Requests and Responses 573 This section describes the procedures for SIP entities for the 574 handling of the History-Info header field in SIP requests and 575 responses. 577 9.1. Receiving a Request 579 When receiving a request, a SIP entity MUST keep a copy of the hi- 580 entries from the incoming request. This document describes this copy 581 in terms of a cache containing the hi-entries associated with the 582 request. The hi-entries MUST be added to the cache in the order in 583 which they were received in the request. 585 If the Request-URI of the incoming request does not match the hi- 586 targeted-to-uri in the last hi-entry (i.e., the previous SIP entity 587 that sent the request did not include a History-Info header field), 588 the SIP entity MUST add a hi-entry to end of the cache, on behalf of 589 the previous SIP entity before proceeding to Section 9.2, as follows: 591 The SIP entity MUST set the hi-targeted-to-uri to the value of the 592 Request-URI in the incoming request. If the Request-URI is a Tel- 593 URI, it SHOULD be transformed into a SIP URI per section 19.1.6 of 594 [RFC3261] before being added as a hi-targted-to-uri. 596 If privacy is required, the SIP entity MUST follow the procedures 597 of Section 10.1. 599 The SIP entity MUST set the hi-index parameter as described in 600 Section 10.3. 602 The SIP entity MUST NOT include an "rc", "mp" or "np" header field 603 parameter. 605 9.2. Sending a Request with History-Info 607 When sending a request, a SIP entity MUST include all the hi-entries 608 from the cache that was created per Section 9.1. In addition, the 609 SIP entity MUST add a new hi-entry to the outgoing request, but the 610 SIP entity MUST NOT add the hi-entry to the cache at this time. The 611 hi-entries in the outgoing request's History-Info header field is the 612 preorder of the tree of hi-entries, that is, by the lexicographic 613 ordering of the hi-indexes. The new hi-entry is populated as 614 follows: 616 hi-targeted-to-uri: The hi-targeted-to-uri MUST be set to the value 617 of the Request-URI of the current (outgoing) request. 619 privacy: If privacy is required, the procedures of Section 10.1 MUST 620 be followed. 622 hi-index: The SIP entity MUST include an hi-index for the hi-entry 623 as described in Section 10.3. 625 rc/mp/np: The SIP entity MUST include an "rc", "mp" or "np" header 626 field parameter in the hi-entry, if applicable, per the procedures 627 in Section 10.4. 629 9.3. Receiving a Response with History-Info or Request Timeouts 631 When a SIP entity receives a non-100 response or a request times out, 632 the SIP entity performs the following steps: 634 Step 1: Add hi-entry to cache 636 The SIP entity MUST add the hi-entry that was added to the request 637 that received the non-100 response or timed out to the cache, if 638 it was not already cached. The hi-entry MUST be added to the 639 cache in ascending order as indicated by the values in the hi- 640 index parameters of the hi-entries (e.g., 1.2.1 comes after 1.2 641 but before 1.2.2 or 1.3). 643 Step 2: Add Reason header field 645 The SIP entity adds one or more Reason header fields to the hi- 646 targeted-to-uri in the (newly) cached hi-entry reflecting the SIP 647 response code in the non-100 response, per the procedures of 648 Section 10.2. 650 Step 3: Add additional hi-entries 652 The SIP entity MUST also add to the cache any hi-entries received 653 in the response that are not already in the cache. This situation 654 can occur when the entity that generated the non-100 response 655 retargeted the request before generating the response. As per 656 Step 1, the hi-entries MUST be added to the cache in ascending 657 order as indicated by the values in the hi-index parameters of the 658 hi-entries 660 It is important to note that the cache (and the request or response) 661 does not contain hi-entries for requests that have not yet received a 662 non-100 response, so there can be gaps in indices (e.g., 1.2 and 1.4 663 could but present but not 1.3). 665 9.4. Sending History-Info in Responses 667 When sending a response other than a 100, a SIP entity MUST include 668 all the cached hi-entries in the response, subject to the privacy 669 consideration in Section 10.1.2, and with the following exception: If 670 the received request contained no hi-entries and there is no 671 "histinfo" option tag in the Supported header field, the SIP entity 672 MUST NOT include History-Info in the response. 674 10. Processing the History-Info Header Field 676 The following sections describe the procedures for processing the 677 History-Info header field. These procedures are applicable to SIP 678 entities such as Proxies/Intermediaries, Redirect Servers or User 679 Agents. 681 10.1. Privacy in the History-Info Header Field 683 The privacy requirements for this document are described in 684 Appendix A.2. Section 10.1.1 describes the insertion of the Privacy 685 header field defined in [RFC3323] to indicate the privacy to be 686 applied to the History-Info header field entries. Section 10.1.2 687 describes how to apply privacy to a request or response that is being 688 forwarded, based on the presence of the Privacy header field. 690 10.1.1. Indicating Privacy 692 As with other SIP headers described in [RFC3323], the hi-targeted-to- 693 uris in the History-Info header field can inadvertently reveal 694 information about the initiator of the request. Thus, the UAC needs 695 a mechanism to indicate that the hi-targeted-to-uris in the hi- 696 entries need to be privacy protected. The Privacy header field is 697 used by the UAC to indicate that privacy is to be applied to all the 698 hi-entries in the request as follows: 700 o If the UAC is including a Privacy header field with a priv-value 701 of "header" in the request, then the UAC SHOULD NOT include a 702 priv-value of "history" in the Privacy header field in the 703 Request. 705 o If the UAC is including any priv-values other than "header" in the 706 Privacy header field, then the UAC MUST also include a priv-value 707 of "history" in the Privacy header field in the Request. 709 o If the UAC is not including any priv-values in the Privacy header 710 field in the request, then the UAC MUST add a Privacy header 711 field, with a priv-value of "history", to the request. The UAC 712 MUST NOT include a priv-value of "critical" in the Privacy header 713 field in the Request in this case. 715 In addition, the History-Info header field can reveal general routing 716 and diverting information within an intermediary, which the 717 intermediary wants to privacy protect. In this case, the 718 intermediary MUST construct a Privacy header field with the single 719 priv-value of "history" and include the Privacy header field in the 720 hi-targeted-to-uri, for each new hi-entry created by the intermediary 721 whose hi-targeted-to-uri it wishes to privacy protect. Note that the 722 priv-value in the Privacy header for the incoming request does not 723 necessarily influence whether the intermediary includes a Privacy 724 header field in the hi-entries. For example, even if the Privacy 725 header for the incoming request contained a priv-value of "none", the 726 Proxy can still set a priv-value of "history" in the Privacy header 727 field included in the hi-targeted-to-uri. 729 Finally, the UAS may not want to reveal the final reached target to 730 the originator. In this case, the UAS MUST include a Privacy header 731 field with a priv-value of "history" in the hi-targeted-to-uri in the 732 last hi-entry, in the response. As noted above, the UAS of the 733 request MUST NOT use any other priv-values in the Privacy header 734 field included in the hi-entry. 736 10.1.2. Applying Privacy 738 When a SIP message is forwarded to a domain for which the SIP 739 intermediary is not responsible, a Privacy Service at the boundary of 740 the domain applies the appropriate privacy based on the value of the 741 Privacy header field in the message header or in the "headers" 742 component of the hi-targeted-to-uri in the individual hi-entries. 744 If there is a Privacy header field in the message header of a request 745 or response, with a priv-value of "header" or "history", then all the 746 hi-targeted-to-uris in the hi-entries, associated with the domain for 747 which the SIP intermediary is responsible, are anonymized by the 748 Privacy Service. The Privacy Service MUST change any hi-targeted-to- 749 uris in these hi-entries that have not been anonymized(evidenced by 750 their domain not being "anonymous.invalid") to anonymous URIs 751 containing a domain of anonymous.invalid (e.g., 752 anonymous@anonymous.invalid). If there is a Privacy header field in 753 the "headers" component of the hi-targeted-to-uri in the hi-entries, 754 then the Privacy header field value MUST be removed from the hi- 755 entry. Once all the appropriate hi-entries have been anonymized, the 756 Privacy Service MUST remove the priv-value of "history" from the 757 Privacy header field in the message header of the request or 758 response. If there are no remaining priv-values in the Privacy 759 header field, the Privacy Service MUST remove the Privacy header 760 field from the request or response per [RFC3323]. 762 If there is not a Privacy header field in the message header of the 763 request or response that is being forwarded, but there is a Privacy 764 header field with a priv-value of "history" in the "headers" 765 component in any of the hi-targeted-uris in the hi-entries associated 766 with the domain for which a SIP intermediary is responsible, then the 767 Privacy Service MUST update those hi-targeted-to-uris as described 768 above. Any other priv-values in the Privacy header field in the 769 "headers" component of the hi-targeted-to-uris in the hi-entries MUST 770 be ignored. In any case, the Privacy Service MUST remove the Privacy 771 header field from the "headers" compenent of the hi-targeted-to-uris 772 in the hi-entries prior to forwarding. 774 10.2. Reason in the History-Info Header Field 776 A Reason header field is added to the "headers" component in an hi- 777 targeted-to-uri when the hi-entry is added to the cache based upon 778 the receipt of a non-100 or non-2xx SIP response, as described in 779 Section 9.3. If the Reason header field is being added due to 780 receipt of an explicit SIP response and the response contains any 781 Reason header fields (see [RFC3326]), then the SIP entity MUST 782 include the Reason header fields in the "headers" component of the 783 hi-targeted-to-uri in the last hi-entry added to the cache, unless 784 the hi-targeted-to-uri is a Tel-URI. If the SIP response does not 785 contain a Reason header field, the SIP entity MUST include a Reason 786 header field, containing the SIP Response Code, in the "headers" 787 component of the hi-targeted-to-uri in the last hi-entry added to the 788 cache, unless the hi-targeted-to-uri is a Tel-URI. 790 If a request has timed out (instead of being explicitly rejected), 791 the SIP entity MUST update the cache as if the request received a SIP 792 error response code of 408 "Request Timeout". 794 A request can receive multiple non-100 non-2xx responses which carry 795 or imply (for responses without Reason headers, and for timeouts) 796 multiple, possibly duplicated, reason-values to be applied to an hi- 797 targeted-to-uri. In these situations, the SIP entity creating 798 History-Info header value would choose the appropriate Reason header 799 field value. 801 A SIP entity MAY also include a Reason header field in the "headers" 802 component of an hi-targeted-to-uri containing the URI of a request 803 that was retargeted as a result of internal retargeting. 805 If additional Reason header field parameters are defined in the 806 future per [RFC3326], the use of these Reason header field parameters 807 for the History-Info header field MUST follow the same rules as 808 described above. 810 10.3. Indexing in the History-Info Header Field 812 In order to maintain ordering and accurately reflect the retargeting 813 of the request, the SIP entity MUST add a hi-index to each hi-entry. 814 Per the syntax in Section 5, the hi-index consists of a series of 815 nonnegative integer separated by dots (e.g., 1.1.2). Each dot 816 reflects a SIP forwarding hop. The nonnegative integer following 817 each dot reflects the order in which a request was retargeted at the 818 hop. The highest nonnegative integer at each hop reflects the number 819 of entities to which the request has been retargeted at the specific 820 hop (i.e., the number of branches) at the time that the request 821 represented by this hi-entry was generated. Thus, the indexing 822 results in a logical tree representation for the history of the 823 request and the hi-entries are given in the preorder of the tree. 825 The first index in a series of History-Info entries MUST be set to 1. 826 In the case that a SIP entity (intermediary or UAS) adds a first hi- 827 entry on behalf of the previous hop, the hi-index MUST be set to 1. 828 For each forward hop (i.e., each new level of indexing), the last 829 integers of the hi-indexes of the new requests MUST be generated 830 starting at 1 and incrementing by 1 for each additional request" 832 The basic rules for adding the hi-index are summarized as follows: 834 1. Forwarding a request without changing the target: In the case of 835 a request that is being forwarded without changing the target, 836 the hi-index reflects the increasing length of the branch. In 837 this case, the SIP entity MUST read the value from the History- 838 Info header field in the received request and MUST add another 839 level of indexing by appending the dot delimiter followed by an 840 initial value of 1 for the new level. For example, if the hi- 841 index in the last History-Info header field in the received 842 request is 1.1, a proxy would add a hi-entry with an hi-index of 843 1.1.1 and forward the request. 845 2. Retargeting within a processing entity - 1st instance: For the 846 first instance of retargeting within a processing entity, the SIP 847 entity MUST calculate the hi-index as prescribed for basic 848 forwarding. 850 3. Retargeting within a processing entity - subsequent instance: For 851 each subsequent retargeting of a request by the same SIP entity, 852 the SIP entity MUST calculate and add the hi-index for each new 853 branch by incrementing the rightmost value from the hi-index in 854 the last hi-entry. Per the example above, the hi-index in the 855 next request forwarded by this same SIP entity would be 1.1.2. 857 4. Retargeting based upon a Response: In the case of retargeting due 858 to a specific response (e.g., 302), the SIP entity MUST calculate 859 the hi-index calculated per rule 3. That is, the rightmost value 860 of the hi-index MUST be incremented (i.e., a new branch is 861 created). For example, if the hi-index in the History-Info 862 header field of the sent request is 1.2 and the response to the 863 request is a 302, then the hi-index in the History-Info header 864 field for the new hi-targeted-to-URI would be 1.3. 866 5. Forking requests: If the request forwarding is done in multiple 867 forks (sequentially or in parallel), the SIP entity MUST set the 868 hi-index for each hi-entry for each forked request per the rules 869 above, with each new request having a unique index. Each index 870 MUST be sequentially assigned. For example, if the index in the 871 last History-Info header field in the received request is 1.1, 872 this processing entity would initialize its index to 1.1.1 for 873 the first fork, 1.1.2 for the second, and so forth (see Figure 1 874 for an example). Note, that in the case of parallel forking, 875 only the hi-entry corresponding to the fork is included in the 876 request because no response can yet have been received for any of 877 the parallel forked requests. 879 6. Missing entity: If the request clearly has a gap in the hi-entry 880 (i.e., the last hi-entry and Request-URI differ), the entity 881 adding an hi-entry MUST add a single index with a value of "0" 882 (i.e., the non-negative integer zero) prior to adding the 883 appropriate index for the action to be taken. For example, if 884 the index of the last hi-entry in the request received was 1.1.2 885 and there was a missing hi-entry and the request was being 886 forwarded to the next hop, the resulting index will be 1.1.2.0.1. 888 10.4. Mechanism for Target Determination in the History-Info Header 889 Field 891 This specification defines three header field parameters, "rc", "mp" 892 and "np". The header field parameters "rc" and "mp" indicate the 893 mechanism by which a new target for a request is determined. The 894 header field "np" reflects that the target has not changed. All 895 parameters contain an index whose value is the hi-index of the hi- 896 entry with an hi-targeted-to-uri that represents the Request-URI that 897 was retargeted. 899 The SIP entity MUST determine the specific parameter field to be 900 included in the hi-target-param, in the History-Info header field, as 901 the targets are added to the target set per the procedures in section 902 16.5 of [RFC3261] or per section 8.1.3.4 [RFC3261] in the case of 903 retargeting to a contact URI received in a 3xx response. In the 904 latter case, the specific header field parameter in the Contact 905 header field becomes the header field parameter that is used in the 906 hi-entry when the request is retargeted. If the Contact header field 907 does not contain an "rc" or "mp" header field parameter, then the SIP 908 entity MUST NOT include an "rc" or "mp" header field parameter in the 909 hi-target-param in the hi-entry when the request is retargeted to a 910 contact URI received in a 3xx response. This is because the redirect 911 server is the only element with any knowledge on how the target was 912 determined. Note, that the "np" header field parameter is not 913 applicable in the case of redirection. 915 The SIP entity (intermediary or redirect server) determines the 916 specific header field parameter ("rc", "mp" or "np") to be used based 917 on the following criteria: 919 o "rc": The Request-URI has changed while retaining the target user 920 associated with the original Request-URI prior to retargeting. 922 o "mp": The target was determined based on a mapping to a user other 923 than the target user associated with the Request-URI being 924 retargeted. 926 o "np": The target hasn't changed and the associated Request-URI 927 remained the same. 929 Note that there are two scenarios by which the "mp" header field 930 parameter can be derived. 932 o The mapping was done by the receiving entity on its own authority, 933 in which case the mp-value is the parent index of the hi-entry's 934 index. 936 o The mapping was done due to receiving a 3xx response, in which 937 case the mp-value is an earlier sibling or descendant of an 938 earlier sibling of the hi-entry's index, that of the downstream 939 request which received the 3xx response. 941 11. Application Considerations 943 History-Info provides a very flexible building block that can be used 944 by intermediaries and UAs for a variety of services. Prior to any 945 application usage of the History-Info header field parameters, the 946 SIP entity that processes the hi-entries MUST evaluate the hi- 947 entries. The SIP entity MUST be prepared to process effectively 948 messages whose hi-entries show evidence of "gaps", that is, 949 situations that reveal that not all of the forks of the request have 950 been recorded in the hi-entries. Gaps are possible if the request is 951 forwarded through intermediaries that do not support the History-Info 952 header field and are reflected by the existence of hi-entries with a 953 nonnegative integer of "0" e.g. "1.1.0.1". Gaps are also possible in 954 the case of parallel forking if there is an outstanding request at 955 the time the SIP entity sends a message. Thus, if gaps are detected, 956 the SIP entity MUST NOT treat this as an error, but SHOULD indicate 957 to any applications that there are gaps. The interpretation of the 958 information in the History-Info header field depends upon the 959 specific application; an application might need to provide special 960 handling in some cases where there are gaps. 962 The following describes some categories of information that 963 applications can use: 965 1. Complete history information - e.g., for debug or other 966 operational and management aspects, optimization of determining 967 targets to avoid retargeting to the same URI, etc. This 968 information is relevant to proxies, UACs and UASs. 970 2. Hi-entry with the index that matches the value of the "rc" header 971 field parameter in the last hi-entry with a "rc" header field 972 parameter in the Request received by a UAS - i.e., the last AOR 973 that was retargeted to a contact based on an AOR-to-contact 974 binding. 976 3. Hi-entry with the index that matches the value of the "mp" header 977 field parameter in the last hi-entry with a "mp" header field 978 parameter in the hi-target-param in the Request received by a UAS 979 - i.e., the last Request URI that was mapped to reach the 980 destination. 982 4. Hi-entry with the index that matches the value of the "rc" header 983 field parameter in the first hi-entry with a "rc" header field 984 parameter in the Request received by a UAS. Note, this would be 985 the original AoR if all the entities involved support the 986 History-Info header field and there is absence of an "mp" header 987 field parameter prior to the "rc" header field parameter in the 988 hi-target-param in the History-Info header field. However, there 989 is no guarantee that all entities will support History-Info, thus 990 the hi-entry that matches the value of the "rc" header field 991 parameter of the first hi-entry with an "rc" header field 992 parameter in the hi-target-param within the domain associated 993 with the target URI at the destination is more likely to be 994 useful. 996 5. Hi-entry with the index that matches the value of "mp" header 997 field parameter in the first hi-entry with an "mp" header field 998 parameter in the Request received by a UAS. Note, this would be 999 the original mapped URI if all entities supported the History- 1000 Info header field. However, there is no guarantee that all 1001 entities will support History-Info, thus the hi-entry that 1002 matches the value of the "mp" header field parameter of the first 1003 hi-entry with an "mp" header field parameter within the domain 1004 associated with the target URI at the destination is more likely 1005 to be useful. 1007 In many cases, applications are most interested in the information 1008 within a particular domain(s), thus only a subset of the information 1009 is required. 1011 Some applications may use multiple types of information. For 1012 example, an Automatic Call Distribution (ACD)/Call center application 1013 that utilizes the hi-entry which index matches the value of the "mp" 1014 header field parameter of the first hi-entry with an "mp" header 1015 field parameter, may also display other agents, reflected by other 1016 hi-entries prior to entries with hi-target value of "rc" header field 1017 parameter, to whom the call was targeted prior to its arrival at the 1018 current agent. This could allow the agent the ability to decide how 1019 they might forward or reroute the call if necessary (avoiding agents 1020 that were not previously available for whatever reason, etc.). 1022 Since support for History-Info header field is optional, a service 1023 MUST define default behavior for requests and responses not 1024 containing History-Info header fields. For example, an entity may 1025 receive an incomplete set of hi-entries or hi-entries which are not 1026 tagged appropriately with an hi-target-param in the case of entries 1027 added by entities that are only compliant to RFC4244. This may not 1028 impact some applications (e.g., debug), however, it could require 1029 some applications to make some default assumptions in this case. For 1030 example, in an ACD scenario, the application could select the oldest 1031 hi-entry with the domain associated with the ACD system and display 1032 that as the original called party. Depending upon how and where the 1033 request may have been retargeted, the complete list of agents to whom 1034 the call was targeted may not be available. 1036 12. Application Specific Usage 1038 Following are possible (non-normative) application-specific usages of 1039 History-Info. 1041 12.1. PBX Voicemail 1043 A voicemail system typically requires the original called party 1044 information to determine the appropriate mailbox so an appropriate 1045 greeting can be provided and the appropriate party notified of the 1046 message. 1048 The original target is determined by finding the first hi-entry 1049 tagged with "rc" and using the hi-entry referenced by the index of 1050 "rc" header field parameter as the target for determining the 1051 appropriate mailbox. This hi-entry is used to populate the "target" 1052 URI parameter as defined in [RFC4458] The VMS can look at the last 1053 hi-entry and find the target of the mailbox by looking at the URI 1054 entry in the "target" URI parameter in the hi-entry. 1056 This example usage does not work properly in the presence of 1057 forwarding that takes place before the call reaches the company in 1058 that case not the first hi-entry with an rc value, but the first hi- 1059 entry with an rc value following an mp entry needs to be picked. 1061 12.2. Consumer Voicemail 1063 The voicemail system in these environment typically requires the last 1064 called party information to determine the appropriate mailbox so an 1065 appropriate greeting can be provided and the appropriate party 1066 notified of the message. 1068 The last target is determined by finding the hi-entry referenced by 1069 the index of last hi-entry tagged with "rc" for determining the 1070 appropriate mailbox. This hi-entry is used to populate the "target" 1071 URI parameter as defined in [RFC4458]. The VMS can look at the last 1072 hi-entry and find the target of the mailbox by looking for the 1073 "target" URI parameter in the hi-entry. 1075 13. Security Considerations 1077 The security requirements for this specification are specified in 1078 Appendix A.1. 1080 This document defines a header field for SIP. The use of the 1081 Transport Layer Security (TLS) protocol [RFC5246] as a mechanism to 1082 ensure the overall confidentiality of the History-Info header fields 1083 (SEC-req-4) is strongly RECOMMENDED. This results in History-Info 1084 having at least the same level of security as other headers in SIP 1085 that are inserted by intermediaries. With TLS, History-Info header 1086 fields are no less, nor no more, secure than other SIP header fields, 1087 which generally have even more impact on the subsequent processing of 1088 SIP sessions than the History-Info header field. 1090 Note that while using the SIPS scheme (as per [RFC5630]) protects 1091 History-Info from tampering by arbitrary parties outside the SIP 1092 message path, all the intermediaries on the path are trusted 1093 implicitly. A malicious intermediary could arbitrarily delete, 1094 rewrite, or modify History-Info. This specification does not attempt 1095 to prevent or detect attacks by malicious intermediaries. 1097 In terms of ensuring the privacy of hi-entries, the same security 1098 considerations as those described in [RFC3323] apply. Namely if the 1099 entity requesting privacy wants to ensure privacy is applied to the 1100 hi-entries, a Privacy Service that supports both [RFC3323] and this 1101 specification is REQUIRED in the entity's domain, so that the privacy 1102 can be applied, as described in Section 10.1.2, when a request or 1103 response leaves the domain. 1105 14. IANA Considerations 1107 This document requires several IANA registrations detailed in the 1108 following sections. 1110 This document obsoletes [RFC4244] but uses the same SIP header field 1111 name and option tag. The IANA registry needs to update the 1112 references to [RFC4244] with [RFC XXXX]. 1114 14.1. Registration of New SIP History-Info Header Field 1116 This document defines a SIP header field name: History-Info and an 1117 option tag: histinfo. The following changes have been made to 1118 http:///www.iana.org/assignments/sip-parameters The following row has 1119 been added to the header field section:. 1121 The following row has been added to the header field section: 1123 Header Name Compact Form Reference 1124 ----------- ------------ --------- 1125 History-Info none [RFC XXXX] 1127 The following has been added to the Options Tags section: 1129 Name Description Reference 1130 ---- ----------- --------- 1131 histinfo When used with the Supported header field, [RFC XXXX] 1132 this option tag indicates the UAC 1133 supports the History Information to be 1134 captured for requests and returned in 1135 subsequent responses. This tag is not 1136 used in a Proxy-Require or Require 1137 header field since support of 1138 History-Info is optional. 1140 Note to RFC Editor: Please replace RFC XXXX with the RFC number of 1141 this specification. 1143 14.2. Registration of "history" for SIP Privacy Header Field 1145 This document defines a priv-value for the SIP Privacy header field: 1146 history The following changes have been made to 1147 http://www.iana.org/assignments/sip-priv-values The following has 1148 been added to the registration for the SIP Privacy header field: 1150 Name Description Registrant Reference 1151 ---- ----------- ---------- --------- 1152 history Privacy requested for Mary Barnes [RFC XXXX] 1153 History-Info header mary.barnes@polycom.com 1154 fields(s) 1156 Note to RFC Editor: Please replace RFC XXXX with the RFC number of 1157 this specification. 1159 14.3. Registration of Header Field Parameters 1161 This specification defines the following new SIP header field 1162 parameters in the SIP Header Field parameter sub-registry in the SIP 1163 Parameter Registry, http:/www.iana.org/assignments/sip-parameters. 1165 Header Field Parameter Name Predefined Reference 1166 Values 1167 _____________________________________________________________________ 1168 History-Info mp No [RFC xxxx] 1169 History-Info rc No [RFC xxxx] 1170 History-Info np No [RFC xxxx] 1171 Contact mp No [RFC xxxx] 1172 Contact rc No [RFC xxxx] 1173 Contact np No [RFC xxxx] 1175 Note to RFC Editor: Please replace RFC XXXX with the RFC number of 1176 this specification. 1178 15. Acknowledgements 1180 Jonathan Rosenberg et al produced the document that provided 1181 additional use cases precipitating the requirement for the new header 1182 parameters to capture the method by which a Request URI is 1183 determined. The authors would like to acknowledge the constructive 1184 feedback provided by Ian Elz, Paul Kyzivat, John Elwell, Hadriel 1185 Kaplan and Dale Worley. John Elwell provided excellent suggestions 1186 in terms of document structure. 1188 Mark Watson, Cullen Jennings and Jon Peterson provided significant 1189 input into the initial work that resulted in the development of of 1190 [RFC4244]. The editor would like to acknowledge the constructive 1191 feedback provided by Robert Sparks, Paul Kyzivat, Scott Orton, John 1192 Elwell, Nir Chen, Palash Jain, Brian Stucker, Norma Ng, Anthony 1193 Brown, Jayshree Bharatia, Jonathan Rosenberg, Eric Burger, Martin 1194 Dolly, Roland Jesske, Takuya Sawada, Sebastien Prouvost, and 1195 Sebastien Garcin in the development of [RFC4244]. 1197 The editor would like to acknowledge the significant input from Rohan 1198 Mahy on some of the normative aspects of the ABNF for [RFC4244], 1199 particularly around the need for and format of the index and around 1200 the security aspects. 1202 16. Changes from RFC 4244 1204 This RFC replaces [RFC4244]. 1206 Deployment experience with [RFC4244] over the years has shown a 1207 number of issues, warranting an update: 1209 o In order to make [RFC4244] work in "real life", one needs to make 1210 "assumptions" on how History-Info is used. For example, many 1211 implementations filter out many entries, and only leave specific 1212 entries corresponding, for example, to first and last redirection. 1213 Since vendors uses different rules, it causes significant 1214 interoperability issues. 1216 o [RFC4244] is overly permissive and evasive about recording 1217 entries, causing interoperability issues. 1219 o The examples in the call flows had errors, and confusing because 1220 they often assume "loose routing". 1222 o [RFC4244] has lots of repetitive and unclear text due to the 1223 combination of requirements with solution. 1225 o [RFC4244] gratuitously mandates the use of TLS on every hop. No 1226 existing implementation enforces this rule, and instead, the use 1227 of TLS or not is a general SIP issue, not an [RFC4244] issue per 1228 se. 1230 o [RFC4244] does not include clear procedures on how to deliver 1231 current target URI information to the UAS when the Request-URI is 1232 replaced with a contact. 1234 o [RFC4244] does not allow for marking History-Info entries for easy 1235 processing by User Agents. 1237 The following summarizes the functional changes between this 1238 specification and [RFC4244]: 1240 1. Added header field parameters to capture the specific method by 1241 which a target is determined to facilitate processing by users of 1242 the History-Info header field entries. A specific header field 1243 parameter is captured for each of the target URIs as the target 1244 set is determined (per section 16.5 of [RFC3261]). The header 1245 field parameter is used in both the History-Info and the Contact 1246 header fields. 1248 2. Added a way to indicate a gap in History-Info by adding a non- 1249 negative integer of "0". 1251 3. Rather than recommending that entries be removed in the case of 1252 certain values of the Privacy header field, the entries are 1253 anonymized. 1255 4. Updated the security section to be equivalent to the security 1256 recommendations for other SIP header fields inserted by 1257 intermediaries. 1259 5. Removed Appendix B since a separate call flow document is being 1260 published as a companion to this document. 1262 The first 2 changes are intended to facilitate application usage of 1263 the History-Info header field and eliminate the need to make 1264 assumptions based upon the order of the entries and ensure that the 1265 most complete set of information is available to the applications. 1267 In addition, editorial changes were done to both condense and clarify 1268 the text, moving the requirements to an appendix and removing the 1269 inline references to the requirements. The examples were simplified 1270 and updated to reflect the protocol changes. Several of the call 1271 flows in the appendix were removed and put into a separate document 1272 that includes additional use cases that require the new header field 1273 parameters. 1275 16.1. Backwards compatibility 1277 This specification is backwards compatible since [RFC4244] allows for 1278 the addition of new optional parameters. This specification adds an 1279 optional SIP header field parameter to the History-Info and Contact 1280 header fields. Entities that have not implemented this specification 1281 will ignore these parameters, however, per [RFC4244] an entity will 1282 not remove these parameters from an hi-entry. While entities 1283 compliant to this document and [RFC4244] must be able to recognize 1284 gaps in the hi-entries, this document requires that an index of "0" 1285 be used in this case. Whereas [RFC4244] recommended (but did not 1286 require) the use of "1". However, since the ABNF in [RFC4244] 1287 defines the index as a DIGIT, "0" would be a valid value, thus an 1288 [RFC4244] implementation should not have an issue if it receives hi- 1289 entries added by intermediaries compliant to this document. 1291 As for the behavior of the UACs, UASs and intermediaries, the 1292 following additional normative changes have been made: 1294 UAC behavior 1296 1. Inclusion of option tag by UAC has changed from SHOULD to MUST. 1298 2. Inclusion of hi-target-entry along with hi-index has changed from 1299 MAY/RECOMMEND to MUST/MUST. 1301 3. Behavior surrounding the addition of hi-target-entry based on 3xx 1302 response has changed from MAY/SHOULD to MUST. 1304 None of the behavior changes would cause any backward or forward 1305 compatibility issues. 1307 UAS behavior 1309 1. Inclusion of hi-entry in response has changed from SHOULD to 1310 MUST. 1312 As the entity receiving response with hi-entry expected it with 1313 SHOULD, this change will not cause any backward compatibility issues. 1315 Proxy/Redirect Server behavior 1317 1. Inclusion of H-I as forwarding the request has changed from 1318 SHOULD to MUST. 1320 2. Association of Reason with time-out/internal reason has changed 1321 from MAY to MUST. 1323 3. Inclusion of hi-index has changed from RECOMMENDED to MUST. 1325 4. Inclusion of hi-entries in response has changed from SHOULD to 1326 MUST. 1328 None of above behavior changes impact backwards compatibility since 1329 they only strengthen normative behavior to improve interoperability. 1331 In cases where an entity that is compliant to this document, receives 1332 a request that contains hi-entries compliant only to RFC4244 (i.e, 1333 the hi-entries do not contain any of the new header field 1334 parameters), the entity should not make any changes to the hi-entries 1335 - i.e., the entries should be cached and forwarded as any other 1336 entries are. As with RFC4244 compliant entities, applications must 1337 be able to function in cases of missing information. The same 1338 applies to this document as specified in Section 11. 1340 17. References 1342 17.1. Normative References 1344 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1345 A., Peterson, J., Sparks, R., Handley, M., and E. 1346 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1347 June 2002. 1349 [RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason 1350 Header Field for the Session Initiation Protocol (SIP)", 1351 RFC 3326, December 2002. 1353 [RFC3323] Peterson, J., "A Privacy Mechanism for the Session 1354 Initiation Protocol (SIP)", RFC 3323, November 2002. 1356 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1357 Requirement Levels", BCP 14, RFC 2119, March 1997. 1359 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1360 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1362 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1363 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1365 [RFC4244] Barnes, M., "An Extension to the Session Initiation 1366 Protocol (SIP) for Request History Information", RFC 4244, 1367 November 2005. 1369 17.2. Informative References 1371 [RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User 1372 Agent URIs (GRUUs) in the Session Initiation Protocol 1373 (SIP)", RFC 5627, October 2009. 1375 [RFC5630] Audet, F., "The Use of the SIPS URI Scheme in the Session 1376 Initiation Protocol (SIP)", RFC 5630, October 2009. 1378 [RFC3087] Campbell, B. and R. Sparks, "Control of Service Context 1379 using SIP Request-URI", RFC 3087, April 2001. 1381 [RFC4240] Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network 1382 Media Services with SIP", RFC 4240, December 2005. 1384 [RFC3969] Camarillo, G., "The Internet Assigned Number Authority 1385 (IANA) Uniform Resource Identifier (URI) Parameter 1386 Registry for the Session Initiation Protocol (SIP)", 1387 BCP 99, RFC 3969, December 2004. 1389 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", 1390 RFC 3966, December 2004. 1392 [RFC4458] Jennings, C., Audet, F., and J. Elwell, "Session 1393 Initiation Protocol (SIP) URIs for Applications such as 1394 Voicemail and Interactive Voice Response (IVR)", RFC 4458, 1395 April 2006. 1397 [I-D.barnes-sipcore-rfc4244bis-callflows] 1398 Barnes, M., Audet, F., Schubert, S., Elburg, H., and C. 1399 Holmberg, "Session Initiation Protocol (SIP) History-Info 1400 Header Call Flow Examples", 1401 draft-barnes-sipcore-rfc4244bis-callflows-03 (work in 1402 progress), March 2012. 1404 Appendix A. Request History Requirements 1406 The following list constitutes a set of requirements for a "Request 1407 History" capability. 1409 1. CAPABILITY-req: The "Request History" capability provides a 1410 capability to inform proxies and UAs involved in processing a 1411 request about the history/progress of that request. Although 1412 this is inherently provided when the retarget is in response to a 1413 SIP redirect, it is deemed useful for non-redirect retargeting 1414 scenarios, as well. 1416 2. GENERATION-req: "Request History" information is generated when 1417 the request is retargeted. 1419 A. In some scenarios, it might be possible for more than one 1420 instance of retargeting to occur within the same proxy. A 1421 proxy MUST also generate Request History information for the 1422 'internal retargeting'. 1424 B. An entity (UA or proxy) retargeting in response to a redirect 1425 or REFER MUST include any Request History information from 1426 the redirect/REFER in the new request. 1428 3. ISSUER-req: "Request History" information can be generated by a 1429 UA or proxy. It can be passed in both requests and responses. 1431 4. CONTENT-req: The "Request History" information for each 1432 occurrence of retargeting shall include the following: 1434 A. The new URI or address to which the request is in the process 1435 of being retargeted, 1437 B. The URI or address from which the request was retargeted, and 1438 whether the retarget URI was an AOR 1440 C. The mechanism by which the new URI or address was determined, 1442 D. The reason for the Request-URI or address modification, 1444 E. Chronological ordering of the Request History information. 1446 5. REQUEST-VALIDITY-req: Request History is applicable to requests 1447 not sent within an early or established dialog (e.g., INVITE, 1448 REGISTER, MESSAGE, and OPTIONS). 1450 6. BACKWARDS-req: Request History information may be passed from the 1451 generating entity backwards towards the UAC. This is needed to 1452 enable services that inform the calling party about the dialog 1453 establishment attempts. 1455 7. FORWARDS-req: Request History information may also be included by 1456 the generating entity in the request, if it is forwarded onwards. 1458 A.1. Security Requirements 1460 The Request History information is being inserted by a network 1461 element retargeting a Request, resulting in a slightly different 1462 problem than the basic SIP header problem, thus requiring specific 1463 consideration. It is recognized that these security requirements can 1464 be generalized to a basic requirement of being able to secure 1465 information that is inserted by proxies. 1467 The potential security problems include the following: 1469 1. A rogue application could insert a bogus Request History-Info 1470 entry either by adding an additional hi-entry as a result of 1471 retargeting or entering invalid information. 1473 2. A rogue application could re-arrange the Request History 1474 information to change the nature of the end application or to 1475 mislead the receiver of the information. 1477 3. A rogue application could delete some or all of the Request 1478 History information. 1480 Thus, a security solution for "Request History" must meet the 1481 following requirements: 1483 1. SEC-req-1: The entity receiving the Request History must be able 1484 to determine whether any of the previously added Request History 1485 content has been altered. 1487 2. SEC-req-2: The ordering of the Request History information must 1488 be preserved at each instance of retargeting. 1490 3. SEC-req-3: The entity receiving the information conveyed by the 1491 Request History must be able to authenticate the entity providing 1492 the request. 1494 4. SEC-req-4: To ensure the confidentiality of the Request History 1495 information, only entities that process the request SHOULD have 1496 visibility to the information. 1498 It should be noted that these security requirements apply to any 1499 entity making use of the Request History information. 1501 A.2. Privacy Requirements 1503 Since the Request-URI that is captured could inadvertently reveal 1504 information about the originator, there are general privacy 1505 requirements that MUST be met: 1507 1. PRIV-req-1: The entity retargeting the Request must ensure that 1508 it maintains the network-provided privacy (as described in 1509 [RFC3323]) associated with the Request as it is retargeted. 1511 2. PRIV-req-2: The entity receiving the Request History must 1512 maintain the privacy associated with the information. In 1513 addition, local policy at a proxy may identify privacy 1514 requirements associated with the Request-URI being captured in 1515 the Request History information. 1517 3. PRIV-req-3: Request History information subject to privacy shall 1518 not be included in out going messages unless it is protected as 1519 described in [RFC3323]. 1521 Authors' Addresses 1523 Mary Barnes 1524 Polycom 1525 TX 1526 US 1528 Email: mary.ietf.barnes@gmail.com 1530 Francois Audet 1531 Skype 1533 Email: francois.audet@skype.net 1535 Shida Schubert 1536 NTT 1538 Email: shida@ntt-at.com 1540 Hans Erik van Elburg 1541 Detecon International Gmbh 1542 Sternengasse 14-16 1543 Cologne, 1544 Germany 1546 Email: ietf.hanserik@gmail.com 1547 Christer Holmberg 1548 Ericsson 1549 Hirsalantie 11, Jorvas 1550 Finland 1552 Email: christer.holmberg@ericsson.com