idnits 2.17.1 draft-ietf-sipcore-rfc4244bis-10.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 448 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 4515 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 1165, but not defined ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 4244 (Obsoleted by RFC 7044) == Outdated reference: A later version (-08) exists of draft-ietf-sipcore-rfc4244bis-callflows-01 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-10.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 . . . . . . . . . . . . . . . . . . . . . . . 28 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. Example scenarios using the History-Info header field 153 are available in [I-D.ietf-sipcore-rfc4244bis-callflows]. 155 2. Conventions and Terminology 157 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 158 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 159 document are to be interpreted as described in [RFC2119]. 161 The term "retarget" is used in this specification to refer to the 162 process of a SIP entity changing the request-URI [RFC3261, section 163 7.1] in a request based on the rules for determining request targets 164 as described in Section 16.5 of [RFC3261] and of the subsequent 165 forwarding of that request as described in step 2 in section 16.6 of 166 [RFC3261]. This includes changing the Request-URI due to a location 167 service lookup and redirect processing. This also includes internal 168 (to a Proxy/SIP intermediary) changes of the URI prior to forwarding 169 of the request. 171 The terms "location service", "forward", "redirect" and "AOR" are 172 used consistently with the terminology in [RFC3261]. 174 The terms "target user" is used in this specification as the human 175 user associated with particular AoR or AoRs (in case the human user 176 has multiple alias). 178 The references to "domain for which the SIP entity/Proxy/Intermediary 179 is responsible" are consistent with and intended to convey the same 180 context as the usage of that terminology in [RFC3261]. The 181 applicability of History-Info to architectures or models outside the 182 context of [RFC3261] is outside the scope of this specification. 184 3. Background 186 SIP implicitly provides retargeting capabilities that enable SIP 187 requests to be routed to specific applications as defined in 188 [RFC3261]. The motivation for capturing the request history is that 189 in the process of retargeting a request, old routing information can 190 be forever lost. This lost information may be important history that 191 allows elements to which the request is retargeted to process the 192 request in a locally defined, application-specific manner. This 193 document defines a mechanism for transporting the request history. 194 Application-specific behavior is outside the scope of this 195 specification. 197 Current network applications for other protocols provide the ability 198 for elements involved with the request to obtain additional 199 information relating to how and why the request was routed to a 200 particular destination. The following are examples of such 201 applications: 203 1. Web "referral" applications, whereby an application residing 204 within a web server determines that a visitor to a website has 205 arrived at the site via an "associate" site that will receive 206 some "referral" commission for generating this traffic 208 2. Email forwarding whereby the forwarded-to user obtains a detailed 209 "trace of the path" of the message from sender to receiver and at 210 what time 212 3. Traditional telephony services such as voicemail, call-center 213 "automatic call distribution", and "follow-me" style services 215 Several of the aforementioned applications currently define 216 application-specific mechanisms through which it is possible to 217 obtain the necessary history information. 219 In addition, request history information could be used to enhance 220 basic SIP functionality by providing the following: 222 o Some diagnostic information for debugging SIP requests. 224 o Capturing aliases and Globally Routable User Agent URIs (GRUUs) 225 [RFC5627], which can be overwritten by a registrar or a "home 226 proxy" (a proxy serving as the terminal point for routing an 227 address-of-record) upon receipt of the initial request. 229 o Facilitating the use of limited use addresses (minted on demand) 230 and sub-addressing. 232 o Preserving service specific URIs that can be overwritten by a 233 downstream proxy, such as those defined in [RFC3087], and control 234 of network announcements and IVR with SIP URI [RFC4240]. 236 4. Overview 238 The fundamental functionality provided by the request history 239 information is the ability to inform proxies and user agents (UAs) 240 involved in processing a request about the history or progress of 241 that request. The solution is to capture the Request-URIs as a 242 request is retargeted, in a SIP header field: History-Info. This 243 allows for the capturing of the history of a request that would be 244 lost with the normal SIP processing involved in the subsequent 245 retargeting of the request. 247 The History-Info header field is added to a Request when a new 248 request is created by a user agent client (UAC) or forwarded by a 249 Proxy, or when the target of a request is changed. It is possible 250 for the target of a request to be changed by the same proxy/SIP 251 intermediary multiple times (referred to as 'internal retargeting'). 252 A SIP entity changing the target of a request in response to a 253 redirect also propagates any History-Info header field from the 254 initial request in the new request. The ABNF and detailed 255 description of the History-Info header field parameters along with 256 examples, is provided in Section 5. Section 6, Section 7 and 257 Section 8 provide the detailed handling of the History-Info header 258 field by SIP User Agents, Proxies and Redirect Servers respectively. 260 This specification also defines three new SIP header field 261 parameters, "rc", "mp" and "np", for the History-Info and Contact 262 header fields, to tag the method by which the target of a request is 263 determined. Further detail on the use of these header field 264 parameters is provided in Section 5. 266 In addition, this specification defines a priv-value for the Privacy 267 header, "history", that requires anonymization of all the History- 268 Info header field entries in a Request or to a specific History-Info 269 header field hi-entry as described above. Further detail is provided 270 in Section 10.1. 272 5. History-Info Header Field Protocol Structure 274 The History-Info header field defined in this specification defines 275 the usage in out-of-dialog requests or initial requests for a dialog 276 (e.g., INVITE, REGISTER, MESSAGE, REFER and OPTIONS, PUBLISH and 277 SUBSCRIBE, etc.) and any non-100 provisional or final responses to 278 these requests. 280 The following provides details for the information that is captured 281 in the History-Info header field entries for each target used for 282 forwarding a request: 284 o hi-targeted-to-uri: A mandatory parameter for capturing the 285 Request-URI for the specific request as it is forwarded. 287 o hi-index: A mandatory parameter for History-Info reflecting the 288 chronological order of the information, indexed to reflect the 289 forking and retargeting of requests. The format for this 290 parameter is a sequance of nonnegative integers, separated by dots 291 to indicate the number of forward hops and retargets. This 292 results in a tree representation of the history of the request, 293 with the lowest-level index reflecting a leaf. By adding the new 294 entries in order (i.e., following existing entries per the details 295 in Section 10.3), including the index and sending the messages 296 using a secure transport, the ordering of the History-Info header 297 fields in the request is assured. In addition, applications may 298 extract a variety of metrics (total number of retargets, total 299 number of retargets from a specific branch, etc.) based upon the 300 index values. 302 o hi-target-param: An optional parameter reflecting the mechanism by 303 which the Request URI captured in the hi-targeted-to-uri in the 304 History-Info header field value (hi-entry) was determined. This 305 parameter is either an "rc", "mp" or "np" header field parameter, 306 which is interpreted as follows: 308 "rc": The hi-targeted-to-URI represents a change in Request-URI 309 while the target user remains the same. This occurs for 310 example when user has multiple AoRs as an alias. The "rc" 311 header field parameter contains the value of the hi-index in 312 the hi-entry with an hi-targeted-to-uri that reflects the 313 Request-URI that was retargeted 315 "mp": The hi-targeted-to-URI represents a user other than the 316 target user associated with the Request-URI in the incoming 317 request that was retargeted. This occurs when a request is 318 statically or dynamically retargeted to another user 319 represented by an AoR unassociated with the AoR of the original 320 target user. The "mp" header field parameter contains the 321 value of the hi-index in the hi-entry with an hi-targeted-to- 322 uri that reflects the Request-URI that was retargeted, thus 323 identifying the "mapped from" target. 325 "np": The hi-targeted-to-URI represents that there was no 326 change in Request-URI. This would apply for example when a 327 proxy merely forwards a request to a next hop proxy and loose 328 routing is used. The "np" header field parameter contains the 329 value of the hi-index in the hi-entry with an hi-targeted-to- 330 uri that reflects the Request-URI that was copied unchanged 331 into the request represented by this hi-entry. That value will 332 usually be the hi-index of the parent hi-entry of this hi- 333 entry. 335 o Extension (hi-extension): A parameter to allow for future optional 336 extensions. As per [RFC3261], any implementation not 337 understanding an extension MUST ignore it. 339 The ABNF syntax [RFC5234] for the History-Info header field and 340 header field parameters is as follows: 342 History-Info = "History-Info" HCOLON hi-entry *(COMMA hi-entry) 344 hi-entry = hi-targeted-to-uri *(SEMI hi-param) 346 hi-targeted-to-uri = addr-spec / name-addr 348 hi-param = hi-index / hi-target-param / hi-extension 350 hi-index = "index" EQUAL index-val 352 index-val = number *("." number) 354 number = [ %31-39 *DIGIT ] DIGIT 356 hi-target-param = rc-param / mp-param / np-param 358 rc-param = "rc" EQUAL index-val 360 mp-param = "mp" EQUAL index-val 362 np-param = "np" EQUAL index-val 364 hi-extension = generic-param 366 The ABNF definitions for "generic-param" and "name-addr" are from 367 [RFC3261]. 369 This document also extends the "contact-params" for the Contact 370 header field as defined in [RFC3261] with the "rc", "mp" and "np" 371 header field parameters defined above. 373 In addition to the parameters defined by the ABNF, an hi-entry may 374 also include a Reason header field and/or a Privacy header field, 375 which are both included in the "headers" component of the hi- 376 targeted-to-uri as described below: 378 o Reason: An optional parameter for History-Info, reflected in the 379 History-Info header field by including the Reason header field 380 [RFC3326] included in the hi-targeted-to-uri. A reason is 381 included in the hi-targeted-to-uri of an hi-entry to reflect 382 information received in a response to the request sent to that 383 URI. 385 o Privacy: An optional parameter for History-Info, reflected in the 386 History-Info header field values by including the Privacy Header 387 [RFC3323] included in the hi- targeted-to-uri or by adding the 388 Privacy header field to the request. The latter case indicates 389 that the History-Info entries for all History-Info entries whose 390 hi-targeted-to-uri has the same domain as the domain for which the 391 SIP entity processing the message is responsible MUST be 392 anonymized prior to forwarding, whereas the use of the Privacy 393 header field included in the hi-targeted-to-uri means that a 394 specific hi-entry MUST be anonymized. 396 Note that since both the Reason and Privacy parameters are included 397 in the hi-targeted-to-uri, these fields will not be available in the 398 case that the hi-targeted-to-uri is a Tel-URI [RFC3966]. 400 The following provides examples of the format for the History-Info 401 header field. Note that the backslash, CRLF and whitespace between 402 the lines in the examples below are inserted for readability purposes 403 only. Note, however, that History-Info can be broken into multiple 404 lines due to the SWS (sep whitespace) that is part of HCOLON, COMMA 405 and SEMI, and there can be multiple History-Info header fields due to 406 the rule of section 7.3 [RFC3261]. Additional detailed examples are 407 available in [I-D.ietf-sipcore-rfc4244bis-callflows]. 409 History-Info: ;index=1;foo=bar 411 History-Info: ;index=1.1,\ 413 ;index=1.2;mp=1.1,\ 415 ;index=1.3;rc=1.2 417 5.1. History-Info Header Field Example Scenario 419 The following is an illustrative example of usage of History-Info. 421 In this example, Alice (sip:alice@atlanta.example.com) calls Bob 422 (sip:bob@biloxi.example.com). Alice's proxy in her home domain (sip: 423 atlanta.example.com) forwards the request to Bob's proxy (sip: 424 biloxi.example.com). When the request arrives at sip: 425 biloxi.example.com, it does a location service lookup for 426 bob@biloxi.example.com and changes the target of the request to Bob's 427 Contact URIs provided as part of normal SIP registration. In this 428 example, Bob is simultaneously contacted on a PC client and on a 429 phone, and Bob answers on the PC client. 431 One important thing illustrated by this call flow is that without 432 History-Info, Bob would "lose" the original target information or the 433 initial request-URI, including any parameters in the request URI. 434 Bob can recover that information by locating the last hi-entry with 435 an "rc" header field parameter. This "rc" header field parameter 436 contains the index of the hi-entry containing the lost target 437 information - i.e., the sip:bob@biloxi.example.com hi-entry with 438 index=1.1. Note that in the 200 response to Alice, an hi-entry is 439 not included for the fork to sip:bob@192.0.2.7 (index 1.1.1) since 440 biloxi.example.com had not received a response from that fork at the 441 time it sent the 200 OK that ultimately reached Alice. 443 Additional detailed examples are available in 444 [I-D.ietf-sipcore-rfc4244bis-callflows]. 446 Note: This example uses loose routing procedures. 448 Alice atlanta.example.com biloxi.example.com Bob@pc Bob@phone 449 | | | | | 450 | INVITE sip:bob@biloxi.example.com;p=x | | 451 |--------------->| | | | 452 | Supported: histinfo | | | 453 | | | | | 454 | | INVITE sip:bob@biloxi.example.com;p=x | 455 | |--------------->| | | 456 | History-Info: ;index=1 | 457 | History-Info: ;np=1;index=1.1 458 | | | | | 459 | | | INVITE sip:bob@192.0.2.3| 460 | | |--------------->| | 461 | History-Info: ;index=1 462 | History-Info: ;np=1;index=1.1 463 | History-Info: ;index=1.1.1;rc=1.1 464 | | | | | 465 | | | INVITE sip:bob@192.0.2.7| 466 | | |-------------------------->| 467 | History-Info: ;index=1 468 | History-Info: ;np=1;index=1.1 469 | History-Info: ;index=1.1.2;rc=1.1 470 | | | 200 | | 471 | | |<---------------| | 472 | History-Info: ;index=1 473 | History-Info: ;np=1;index=1.1 474 | History-Info: ;index=1.1.1;rc=1.1 475 | | | | | 476 | | 200 | | | 477 | |<---------------| | | 478 | History-Info: ;index=1 479 | History-Info: ;np=1;index=1.1 480 | History-Info: ;index=1.1.1;rc=1.1 481 | | | | | 482 | | | Proxy Cancels INVITE | 483 | | |<=========================>| 484 | | | | | 485 | 200 | | | | 486 |<---------------| | | | 487 | History-Info: ;index=1 488 | History-Info: ;np=1;index=1.1 489 | History-Info: ;index=1.1.1;rc=1.1 490 | | | | | 491 | ACK | | | | 492 |--------------->| ACK | | | 493 | |--------------->| ACK | | 494 | | |--------------->| | 495 Figure 1: Basic Call 497 6. User Agent Handling of the History-Info Header Field 499 A back-to-back user agent (B2BUA) MAY follow the behavior of a SIP 500 intermediary as an alternative to following the behavior of a user 501 agent server (UAS) per Section 6.2 and a UAC per Section 6.1. In 502 behaving as an intermediary, a B2BUA carries forward hi-entries 503 received in requests at the UAS to requests being forwarded by the 504 UAC, as well as carrying forward hi-entries in responses received at 505 the UAC to the responses forwarded by the UAS, subject to privacy 506 considerations per Section 10.1. 508 6.1. User Agent Client (UAC) Behavior 510 The UAC MUST include the "histinfo" option tag in the Supported 511 header field in any out-of-dialog requests or initial requests for a 512 dialog for which the UAC would like the History-Info header field in 513 the response. When issuing a request, the UAC MUST follow the 514 procedures in Section 9.2. In the case of an initial request, except 515 where the UAC is part of a B2BUA, there is no cache of hi- entries 516 with which to populate the History-Info header field and the hi-index 517 is set to 1 per Section 10.3. When receiving a response the UAC MUST 518 follow the procedures in Section 9.3. 520 If the UAC generates further forks of the initial request (either due 521 to acting on a 3xx response or internally-directed forking to 522 multiple destinations), the successive requests will add hi-entries 523 with hi-indexes of 2, 3, etc. 525 6.2. User Agent Server (UAS) Behavior 527 When receiving a request, a UAS MUST follow the procedures defined in 528 Section 9.2. When sending a response other than a 3xx response, a 529 UAS MUST follows the procedures as defined in Section 9.4. When 530 sending a 3xx response, the UAS MUST follow the procedures defined 531 for a redirect server per Section 8. An application at the UAS can 532 make use of the cached hi-entries as described in Section 11. 534 7. Proxy/Intermediary Handling of History-Info Header Fields 536 This section describes the procedures for proxies and other SIP 537 intermediaries for the handling of the History-Info header fields for 538 each of the following scenarios: 540 Receiving a Request: An intermediary MUST follow the procedures in 541 Section 9.1 for the handling of hi-entries in incoming SIP 542 requests. 544 Sending a Request: For each outgoing request relating to a target in 545 the target set, the intermediary MUST follow the procedures of 546 Section 9.2. 548 Receiving a Response or Timeout: An intermediary MUST follow the 549 procedures of Section 9.3 when a SIP response is received or a 550 request times out. 552 Sending a Response: An intermediary MUST follow the procedures of 553 Section 9.4 for the handling of the hi-entries when sending a SIP 554 response. 556 In some cases, an intermediary may retarget a request more than once 557 before forwarding - i.e., a request is retargeted to a SIP entity 558 that is "internal" to the intermediary before the same intermediary 559 retargets the request to an external target . A typical example 560 would be a proxy that retargets a request first to a different user 561 (i.e., it maps to a different AOR) and then forwards to a registered 562 contact bound to the same AOR. In this case, the intermediary MUST 563 add a hi-entry for (each of) the internal target(s) per the 564 procedures in Section 9.2. The intermediary MAY include a Reason 565 header field in the hi-entry with the hi-targeted-to-uri that has 566 been retargeted. Note, that this is shown in the INVITE (F6) in the 567 example entitled "Sequentially Forking (History-Info in Response)" in 568 [I-D.ietf-sipcore-rfc4244bis-callflows]. 570 8. Redirect Server Handling of History-Info Header Fields 572 A redirect server MUST follow the procedures in Section 9.1 when it 573 receives a SIP Request. A redirect server MUST follow the procedures 574 in Section 9.4 when it sends a SIP Response. When generating the 575 Contact header field in a 3xx response, the redirect server MUST add 576 the appropriate "mp", "np" or "rc" header field parameter to each 577 Contact header field as described in Section 10.4, if applicable. 579 9. Handling of History-Info Header Fields in Requests and Responses 581 This section describes the procedures for SIP entities for the 582 handling of the History-Info header field in SIP requests and 583 responses. 585 9.1. Receiving a Request 587 When receiving a request, a SIP entity MUST keep a copy of the hi- 588 entries from the incoming request. This document describes this copy 589 in terms of a cache containing the hi-entries associated with the 590 request. The hi-entries MUST be added to the cache in the order in 591 which they were received in the request. 593 If the Request-URI of the incoming request does not match the hi- 594 targeted-to-uri in the last hi-entry (i.e., the previous SIP entity 595 that sent the request did not include a History-Info header field), 596 the SIP entity MUST add a hi-entry to end of the cache, on behalf of 597 the previous SIP entity before proceeding to Section 9.2, as follows: 599 The SIP entity MUST set the hi-targeted-to-uri to the value of the 600 Request-URI in the incoming request. If the Request-URI is a Tel- 601 URI, it SHOULD be transformed into a SIP URI per section 19.1.6 of 602 [RFC3261] before being added as a hi-targted-to-uri. 604 If privacy is required, the SIP entity MUST follow the procedures 605 of Section 10.1. 607 The SIP entity MUST set the hi-index parameter as described in 608 Section 10.3. 610 The SIP entity MUST NOT include an "rc", "mp" or "np" header field 611 parameter. 613 9.2. Sending a Request with History-Info 615 When sending a request, a SIP entity MUST include all the hi-entries 616 from the cache that was created per Section 9.1. In addition, the 617 SIP entity MUST add a new hi-entry to the outgoing request, but the 618 SIP entity MUST NOT add the hi-entry to the cache at this time. The 619 hi-entries in the outgoing request's History-Info header field is the 620 preorder of the tree of hi-entries, that is, by the lexicographic 621 ordering of the hi-indexes. The new hi-entry is populated as 622 follows: 624 hi-targeted-to-uri: The hi-targeted-to-uri MUST be set to the value 625 of the Request-URI of the current (outgoing) request. 627 privacy: If privacy is required, the procedures of Section 10.1 MUST 628 be followed. 630 hi-index: The SIP entity MUST include an hi-index for the hi-entry 631 as described in Section 10.3. 633 rc/mp/np: The SIP entity MUST include an "rc", "mp" or "np" header 634 field parameter in the hi-entry, if applicable, per the procedures 635 in Section 10.4. 637 9.3. Receiving a Response with History-Info or Request Timeouts 639 When a SIP entity receives a non-100 response or a request times out, 640 the SIP entity performs the following steps: 642 Step 1: Add hi-entry to cache 644 The SIP entity MUST add the hi-entry that was added to the request 645 that received the non-100 response or timed out to the cache, if 646 it was not already cached. The hi-entry MUST be added to the 647 cache in ascending order as indicated by the values in the hi- 648 index parameters of the hi-entries (e.g., 1.2.1 comes after 1.2 649 but before 1.2.2 or 1.3). 651 Step 2: Add Reason header field 653 The SIP entity adds one or more Reason header fields to the hi- 654 targeted-to-uri in the (newly) cached hi-entry reflecting the SIP 655 response code in the non-100 response, per the procedures of 656 Section 10.2. 658 Step 3: Add additional hi-entries 660 The SIP entity MUST also add to the cache any hi-entries received 661 in the response that are not already in the cache. This situation 662 can occur when the entity that generated the non-100 response 663 retargeted the request before generating the response. As per 664 Step 1, the hi-entries MUST be added to the cache in ascending 665 order as indicated by the values in the hi-index parameters of the 666 hi-entries 668 It is important to note that the cache (and the request or response) 669 does not contain hi-entries for requests that have not yet received a 670 non-100 response, so there can be gaps in indices (e.g., 1.2 and 1.4 671 could but present but not 1.3). 673 9.4. Sending History-Info in Responses 675 When sending a response other than a 100, a SIP entity MUST include 676 all the cached hi-entries in the response, subject to the privacy 677 consideration in Section 10.1.2, and with the following exception: If 678 the received request contained no hi-entries and there is no 679 "histinfo" option tag in the Supported header field, the SIP entity 680 MUST NOT include History-Info in the response. 682 10. Processing the History-Info Header Field 684 The following sections describe the procedures for processing the 685 History-Info header field. These procedures are applicable to SIP 686 entities such as Proxies/Intermediaries, Redirect Servers or User 687 Agents. 689 10.1. Privacy in the History-Info Header Field 691 The privacy requirements for this document are described in 692 Appendix A.2. Section 10.1.1 describes the insertion of the Privacy 693 header field defined in [RFC3323] to indicate the privacy to be 694 applied to the History-Info header field entries. Section 10.1.2 695 describes how to apply privacy to a request or response that is being 696 forwarded, based on the presence of the Privacy header field. 698 10.1.1. Indicating Privacy 700 As with other SIP headers described in [RFC3323], the hi-targeted-to- 701 uris in the History-Info header field can inadvertently reveal 702 information about the initiator of the request. Thus, the UAC needs 703 a mechanism to indicate that the hi-targeted-to-uris in the hi- 704 entries need to be privacy protected. The Privacy header field is 705 used by the UAC to indicate that privacy is to be applied to all the 706 hi-entries in the request as follows: 708 o If the UAC is including a Privacy header field with a priv-value 709 of "header" in the request, then the UAC SHOULD NOT include a 710 priv-value of "history" in the Privacy header field in the 711 Request. 713 o If the UAC is including any priv-values other than "header" in the 714 Privacy header field, then the UAC MUST also include a priv-value 715 of "history" in the Privacy header field in the Request. 717 o If the UAC is not including any priv-values in the Privacy header 718 field in the request, then the UAC MUST add a Privacy header 719 field, with a priv-value of "history", to the request. The UAC 720 MUST NOT include a priv-value of "critical" in the Privacy header 721 field in the Request in this case. 723 In addition, the History-Info header field can reveal general routing 724 and diverting information within an intermediary, which the 725 intermediary wants to privacy protect. In this case, the 726 intermediary MUST construct a Privacy header field with the single 727 priv-value of "history" and include the Privacy header field in the 728 hi-targeted-to-uri, for each new hi-entry created by the intermediary 729 whose hi-targeted-to-uri it wishes to privacy protect. Note that the 730 priv-value in the Privacy header for the incoming request does not 731 necessarily influence whether the intermediary includes a Privacy 732 header field in the hi-entries. For example, even if the Privacy 733 header for the incoming request contained a priv-value of "none", the 734 Proxy can still set a priv-value of "history" in the Privacy header 735 field included in the hi-targeted-to-uri. 737 Finally, the UAS may not want to reveal the final reached target to 738 the originator. In this case, the UAS MUST include a Privacy header 739 field with a priv-value of "history" in the hi-targeted-to-uri in the 740 last hi-entry, in the response. As noted above, the UAS of the 741 request MUST NOT use any other priv-values in the Privacy header 742 field included in the hi-entry. 744 10.1.2. Applying Privacy 746 When a SIP message is forwarded to a domain for which the SIP 747 intermediary is not responsible, a Privacy Service at the boundary of 748 the domain applies the appropriate privacy based on the value of the 749 Privacy header field in the message header or in the "headers" 750 component of the hi-targeted-to-uri in the individual hi-entries. 752 If there is a Privacy header field in the message header of a request 753 or response, with a priv-value of "header" or "history", then all the 754 hi-targeted-to-uris in the hi-entries, associated with the domain for 755 which the SIP intermediary is responsible, are anonymized by the 756 Privacy Service. The Privacy Service MUST change any hi-targeted-to- 757 uris in these hi-entries that have not been anonymized(evidenced by 758 their domain not being "anonymous.invalid") to anonymous URIs 759 containing a domain of anonymous.invalid (e.g., 760 anonymous@anonymous.invalid). If there is a Privacy header field in 761 the "headers" component of the hi-targeted-to-uri in the hi-entries, 762 then the Privacy header field value MUST be removed from the hi- 763 entry. Once all the appropriate hi-entries have been anonymized, the 764 Privacy Service MUST remove the priv-value of "history" from the 765 Privacy header field in the message header of the request or 766 response. If there are no remaining priv-values in the Privacy 767 header field, the Privacy Service MUST remove the Privacy header 768 field from the request or response per [RFC3323]. 770 If there is not a Privacy header field in the message header of the 771 request or response that is being forwarded, but there is a Privacy 772 header field with a priv-value of "history" in the "headers" 773 component in any of the hi-targeted-uris in the hi-entries associated 774 with the domain for which a SIP intermediary is responsible, then the 775 Privacy Service MUST update those hi-targeted-to-uris as described 776 above. Any other priv-values in the Privacy header field in the 777 "headers" component of the hi-targeted-to-uris in the hi-entries MUST 778 be ignored. In any case, the Privacy Service MUST remove the Privacy 779 header field from the "headers" compenent of the hi-targeted-to-uris 780 in the hi-entries prior to forwarding. 782 10.2. Reason in the History-Info Header Field 784 A Reason header field is added to the "headers" component in an hi- 785 targeted-to-uri when the hi-entry is added to the cache based upon 786 the receipt of a non-100 or non-2xx SIP response, as described in 787 Section 9.3. If the Reason header field is being added due to 788 receipt of an explicit SIP response and the response contains any 789 Reason header fields (see [RFC3326]), then the SIP entity MUST 790 include the Reason header fields in the "headers" component of the 791 hi-targeted-to-uri in the last hi-entry added to the cache, unless 792 the hi-targeted-to-uri is a Tel-URI. If the SIP response does not 793 contain a Reason header field, the SIP entity MUST include a Reason 794 header field, containing the SIP Response Code, in the "headers" 795 component of the hi-targeted-to-uri in the last hi-entry added to the 796 cache, unless the hi-targeted-to-uri is a Tel-URI. 798 If a request has timed out (instead of being explicitly rejected), 799 the SIP entity MUST update the cache as if the request received a SIP 800 error response code of 408 "Request Timeout". 802 A request can receive multiple non-100 non-2xx responses which carry 803 or imply (for responses without Reason headers, and for timeouts) 804 multiple, possibly duplicated, reason-values to be applied to an hi- 805 targeted-to-uri. In these situations, the SIP entity creating 806 History-Info header value would choose the appropriate Reason header 807 field value. 809 A SIP entity MAY also include a Reason header field in the "headers" 810 component of an hi-targeted-to-uri containing the URI of a request 811 that was retargeted as a result of internal retargeting. 813 If additional Reason header field parameters are defined in the 814 future per [RFC3326], the use of these Reason header field parameters 815 for the History-Info header field MUST follow the same rules as 816 described above. 818 10.3. Indexing in the History-Info Header Field 820 In order to maintain ordering and accurately reflect the retargeting 821 of the request, the SIP entity MUST add a hi-index to each hi-entry. 822 Per the syntax in Section 5, the hi-index consists of a series of 823 nonnegative integer separated by dots (e.g., 1.1.2). Each dot 824 reflects a SIP forwarding hop. The nonnegative integer following 825 each dot reflects the order in which a request was retargeted at the 826 hop. The highest nonnegative integer at each hop reflects the number 827 of entities to which the request has been retargeted at the specific 828 hop (i.e., the number of branches) at the time that the request 829 represented by this hi-entry was generated. Thus, the indexing 830 results in a logical tree representation for the history of the 831 request and the hi-entries are given in the preorder of the tree. 833 The first index in a series of History-Info entries MUST be set to 1. 834 In the case that a SIP entity (intermediary or UAS) adds a first hi- 835 entry on behalf of the previous hop, the hi-index MUST be set to 1. 836 For each forward hop (i.e., each new level of indexing), the last 837 integers of the hi-indexes of the new requests MUST be generated 838 starting at 1 and incrementing by 1 for each additional request" 840 The basic rules for adding the hi-index are summarized as follows: 842 1. Forwarding a request without changing the target: In the case of 843 a request that is being forwarded without changing the target, 844 the hi-index reflects the increasing length of the branch. In 845 this case, the SIP entity MUST read the value from the History- 846 Info header field in the received request and MUST add another 847 level of indexing by appending the dot delimiter followed by an 848 initial value of 1 for the new level. For example, if the hi- 849 index in the last History-Info header field in the received 850 request is 1.1, a proxy would add a hi-entry with an hi-index of 851 1.1.1 and forward the request. 853 2. Retargeting within a processing entity - 1st instance: For the 854 first instance of retargeting within a processing entity, the SIP 855 entity MUST calculate the hi-index as prescribed for basic 856 forwarding. 858 3. Retargeting within a processing entity - subsequent instance: For 859 each subsequent retargeting of a request by the same SIP entity, 860 the SIP entity MUST calculate and add the hi-index for each new 861 branch by incrementing the rightmost value from the hi-index in 862 the last hi-entry. Per the example above, the hi-index in the 863 next request forwarded by this same SIP entity would be 1.1.2. 865 4. Retargeting based upon a Response: In the case of retargeting due 866 to a specific response (e.g., 302), the SIP entity MUST calculate 867 the hi-index calculated per rule 3. That is, the rightmost value 868 of the hi-index MUST be incremented (i.e., a new branch is 869 created). For example, if the hi-index in the History-Info 870 header field of the sent request is 1.2 and the response to the 871 request is a 302, then the hi-index in the History-Info header 872 field for the new hi-targeted-to-URI would be 1.3. 874 5. Forking requests: If the request forwarding is done in multiple 875 forks (sequentially or in parallel), the SIP entity MUST set the 876 hi-index for each hi-entry for each forked request per the rules 877 above, with each new request having a unique index. Each index 878 MUST be sequentially assigned. For example, if the index in the 879 last History-Info header field in the received request is 1.1, 880 this processing entity would initialize its index to 1.1.1 for 881 the first fork, 1.1.2 for the second, and so forth (see Figure 1 882 for an example). Note, that in the case of parallel forking, 883 only the hi-entry corresponding to the fork is included in the 884 request because no response can yet have been received for any of 885 the parallel forked requests. 887 6. Missing entity: If the request clearly has a gap in the hi-entry 888 (i.e., the last hi-entry and Request-URI differ), the entity 889 adding an hi-entry MUST add a single index with a value of "0" 890 (i.e., the non-negative integer zero) prior to adding the 891 appropriate index for the action to be taken. For example, if 892 the index of the last hi-entry in the request received was 1.1.2 893 and there was a missing hi-entry and the request was being 894 forwarded to the next hop, the resulting index will be 1.1.2.0.1. 896 10.4. Mechanism for Target Determination in the History-Info Header 897 Field 899 This specification defines three header field parameters, "rc", "mp" 900 and "np". The header field parameters "rc" and "mp" indicate the 901 mechanism by which a new target for a request is determined. The 902 header field "np" reflects that the target has not changed. All 903 parameters contain an index whose value is the hi-index of the hi- 904 entry with an hi-targeted-to-uri that represents the Request-URI that 905 was retargeted. 907 The SIP entity MUST determine the specific parameter field to be 908 included in the hi-target-param, in the History-Info header field, as 909 the targets are added to the target set per the procedures in section 910 16.5 of [RFC3261] or per section 8.1.3.4 [RFC3261] in the case of 911 retargeting to a contact URI received in a 3xx response. In the 912 latter case, the specific header field parameter in the Contact 913 header field becomes the header field parameter that is used in the 914 hi-entry when the request is retargeted. If the Contact header field 915 does not contain an "rc" or "mp" header field parameter, then the SIP 916 entity MUST NOT include an "rc" or "mp" header field parameter in the 917 hi-target-param in the hi-entry when the request is retargeted to a 918 contact URI received in a 3xx response. This is because the redirect 919 server is the only element with any knowledge on how the target was 920 determined. Note, that the "np" header field parameter is not 921 applicable in the case of redirection. 923 The SIP entity (intermediary or redirect server) determines the 924 specific header field parameter ("rc", "mp" or "np") to be used based 925 on the following criteria: 927 o "rc": The Request-URI has changed while retaining the target user 928 associated with the original Request-URI prior to retargeting. 930 o "mp": The target was determined based on a mapping to a user other 931 than the target user associated with the Request-URI being 932 retargeted. 934 o "np": The target hasn't changed and the associated Request-URI 935 remained the same. 937 Note that there are two scenarios by which the "mp" header field 938 parameter can be derived. 940 o The mapping was done by the receiving entity on its own authority, 941 in which case the mp-value is the parent index of the hi-entry's 942 index. 944 o The mapping was done due to receiving a 3xx response, in which 945 case the mp-value is an earlier sibling or descendant of an 946 earlier sibling of the hi-entry's index, that of the downstream 947 request which received the 3xx response. 949 11. Application Considerations 951 History-Info provides a very flexible building block that can be used 952 by intermediaries and UAs for a variety of services. Prior to any 953 application usage of the History-Info header field parameters, the 954 SIP entity that processes the hi-entries MUST evaluate the hi- 955 entries. The SIP entity MUST be prepared to process effectively 956 messages whose hi-entries show evidence of "gaps", that is, 957 situations that reveal that not all of the forks of the request have 958 been recorded in the hi-entries. Gaps are possible if the request is 959 forwarded through intermediaries that do not support the History-Info 960 header field and are reflected by the existence of hi-entries with a 961 nonnegative integer of "0" e.g. "1.1.0.1". Gaps are also possible in 962 the case of parallel forking if there is an outstanding request at 963 the time the SIP entity sends a message. Thus, if gaps are detected, 964 the SIP entity MUST NOT treat this as an error, but SHOULD indicate 965 to any applications that there are gaps. The interpretation of the 966 information in the History-Info header field depends upon the 967 specific application; an application might need to provide special 968 handling in some cases where there are gaps. 970 The following describes some categories of information that 971 applications can use: 973 1. Complete history information - e.g., for debug or other 974 operational and management aspects, optimization of determining 975 targets to avoid retargeting to the same URI, etc. This 976 information is relevant to proxies, UACs and UASs. 978 2. Hi-entry with the index that matches the value of the "rc" header 979 field parameter in the last hi-entry with a "rc" header field 980 parameter in the Request received by a UAS - i.e., the last AOR 981 that was retargeted to a contact based on an AOR-to-contact 982 binding. 984 3. Hi-entry with the index that matches the value of the "mp" header 985 field parameter in the last hi-entry with a "mp" header field 986 parameter in the hi-target-param in the Request received by a UAS 987 - i.e., the last Request URI that was mapped to reach the 988 destination. 990 4. Hi-entry with the index that matches the value of the "rc" header 991 field parameter in the first hi-entry with a "rc" header field 992 parameter in the Request received by a UAS. Note, this would be 993 the original AoR if all the entities involved support the 994 History-Info header field and there is absence of an "mp" header 995 field parameter prior to the "rc" header field parameter in the 996 hi-target-param in the History-Info header field. However, there 997 is no guarantee that all entities will support History-Info, thus 998 the hi-entry that matches the value of the "rc" header field 999 parameter of the first hi-entry with an "rc" header field 1000 parameter in the hi-target-param within the domain associated 1001 with the target URI at the destination is more likely to be 1002 useful. 1004 5. Hi-entry with the index that matches the value of "mp" header 1005 field parameter in the first hi-entry with an "mp" header field 1006 parameter in the Request received by a UAS. Note, this would be 1007 the original mapped URI if all entities supported the History- 1008 Info header field. However, there is no guarantee that all 1009 entities will support History-Info, thus the hi-entry that 1010 matches the value of the "mp" header field parameter of the first 1011 hi-entry with an "mp" header field parameter within the domain 1012 associated with the target URI at the destination is more likely 1013 to be useful. 1015 In many cases, applications are most interested in the information 1016 within a particular domain(s), thus only a subset of the information 1017 is required. 1019 Some applications may use multiple types of information. For 1020 example, an Automatic Call Distribution (ACD)/Call center application 1021 that utilizes the hi-entry which index matches the value of the "mp" 1022 header field parameter of the first hi-entry with an "mp" header 1023 field parameter, may also display other agents, reflected by other 1024 hi-entries prior to entries with hi-target value of "rc" header field 1025 parameter, to whom the call was targeted prior to its arrival at the 1026 current agent. This could allow the agent the ability to decide how 1027 they might forward or reroute the call if necessary (avoiding agents 1028 that were not previously available for whatever reason, etc.). 1030 Since support for History-Info header field is optional, a service 1031 MUST define default behavior for requests and responses not 1032 containing History-Info header fields. For example, an entity may 1033 receive an incomplete set of hi-entries or hi-entries which are not 1034 tagged appropriately with an hi-target-param in the case of entries 1035 added by entities that are only compliant to RFC4244. This may not 1036 impact some applications (e.g., debug), however, it could require 1037 some applications to make some default assumptions in this case. For 1038 example, in an ACD scenario, the application could select the oldest 1039 hi-entry with the domain associated with the ACD system and display 1040 that as the original called party. Depending upon how and where the 1041 request may have been retargeted, the complete list of agents to whom 1042 the call was targeted may not be available. 1044 12. Application Specific Usage 1046 The following are possible (non-normative) application-specific 1047 usages of History-Info. 1049 12.1. PBX Voicemail 1051 A voicemail system typically requires the original called party 1052 information to determine the appropriate mailbox so an appropriate 1053 greeting can be provided and the appropriate party notified of the 1054 message. 1056 The original target is determined by finding the first hi-entry 1057 tagged with "rc" and using the hi-entry referenced by the index of 1058 "rc" header field parameter as the target for determining the 1059 appropriate mailbox. This hi-entry is used to populate the "target" 1060 URI parameter as defined in [RFC4458] The VMS can look at the last 1061 hi-entry and find the target of the mailbox by looking at the URI 1062 entry in the "target" URI parameter in the hi-entry. 1064 This example usage does not work properly in the presence of 1065 forwarding that takes place before the call reaches the company in 1066 that case not the first hi-entry with an rc value, but the first hi- 1067 entry with an rc value following an mp entry needs to be picked. 1068 Further detail for this example can be found in the call flow 1069 entitled "PBX Voicemail Example" in 1070 [I-D.ietf-sipcore-rfc4244bis-callflows]. 1072 12.2. Consumer Voicemail 1074 The voicemail system in these environment typically requires the last 1075 called party information to determine the appropriate mailbox so an 1076 appropriate greeting can be provided and the appropriate party 1077 notified of the message. 1079 The last target is determined by finding the hi-entry referenced by 1080 the index of last hi-entry tagged with "rc" for determining the 1081 appropriate mailbox. This hi-entry is used to populate the "target" 1082 URI parameter as defined in [RFC4458]. The VMS can look at the last 1083 hi-entry and find the target of the mailbox by looking for the 1084 "target" URI parameter in the hi-entry. Further detail for this 1085 example can be found in the call flow entitled "Consumer Voicemail 1086 Example" in [I-D.ietf-sipcore-rfc4244bis-callflows]. 1088 13. Security Considerations 1090 The security requirements for this specification are specified in 1091 Appendix A.1. 1093 This document defines a header field for SIP. The use of the 1094 Transport Layer Security (TLS) protocol [RFC5246] as a mechanism to 1095 ensure the overall confidentiality of the History-Info header fields 1096 (SEC-req-4) is strongly RECOMMENDED. This results in History-Info 1097 having at least the same level of security as other headers in SIP 1098 that are inserted by intermediaries. With TLS, History-Info header 1099 fields are no less, nor no more, secure than other SIP header fields, 1100 which generally have even more impact on the subsequent processing of 1101 SIP sessions than the History-Info header field. 1103 Note that while using the SIPS scheme (as per [RFC5630]) protects 1104 History-Info from tampering by arbitrary parties outside the SIP 1105 message path, all the intermediaries on the path are trusted 1106 implicitly. A malicious intermediary could arbitrarily delete, 1107 rewrite, or modify History-Info. This specification does not attempt 1108 to prevent or detect attacks by malicious intermediaries. 1110 In terms of ensuring the privacy of hi-entries, the same security 1111 considerations as those described in [RFC3323] apply. Namely if the 1112 entity requesting privacy wants to ensure privacy is applied to the 1113 hi-entries, a Privacy Service that supports both [RFC3323] and this 1114 specification is REQUIRED in the entity's domain, so that the privacy 1115 can be applied, as described in Section 10.1.2, when a request or 1116 response leaves the domain. 1118 14. IANA Considerations 1120 This document requires several IANA registrations detailed in the 1121 following sections. 1123 This document obsoletes [RFC4244] but uses the same SIP header field 1124 name, Privacy header field and Option tag. The IANA registry needs 1125 to update the references to [RFC4244] with [RFC XXXX], where XXXX is 1126 the RFC number for this document. 1128 14.1. Registration of New SIP History-Info Header Field 1130 This document defines a SIP header field name: History-Info and an 1131 option tag: histinfo. The following updates have been made to 1132 http:///www.iana.org/assignments/sip-parameters. 1134 The following row has been updated in the header field section: 1136 Header Name Compact Form Reference 1137 ----------- ------------ --------- 1138 History-Info none [RFC XXXX] 1140 The following has been updated in the Options Tags section: 1142 Name Description Reference 1143 ---- ----------- --------- 1144 histinfo When used with the Supported header field, [RFC XXXX] 1145 this option tag indicates the UAC 1146 supports the History Information to be 1147 captured for requests and returned in 1148 subsequent responses. This tag is not 1149 used in a Proxy-Require or Require 1150 header field since support of 1151 History-Info is optional. 1153 Note to RFC Editor: Please replace RFC XXXX with the RFC number of 1154 this specification. 1156 14.2. Registration of "history" for SIP Privacy Header Field 1158 This document defines a priv-value for the SIP Privacy header field: 1159 history. The following updates have been made to 1160 http://www.iana.org/assignments/sip-priv-values. The following has 1161 been updated in the registration for the SIP Privacy header field: 1163 Name Description Registrant Reference 1164 ---- ----------- ---------- --------- 1165 history Privacy requested for Mary Barnes [RFC XXXX] 1166 History-Info header mary.barnes@polycom.com 1167 fields(s) 1169 Note to RFC Editor: Please replace RFC XXXX with the RFC number of 1170 this specification. 1172 14.3. Registration of Header Field Parameters 1174 This specification defines the following new SIP header field 1175 parameters in the SIP Header Field parameter sub-registry in the SIP 1176 Parameter Registry, http:/www.iana.org/assignments/sip-parameters. 1178 Header Field Parameter Name Predefined Reference 1179 Values 1180 _____________________________________________________________________ 1181 History-Info mp No [RFC xxxx] 1182 History-Info rc No [RFC xxxx] 1183 History-Info np No [RFC xxxx] 1184 Contact mp No [RFC xxxx] 1185 Contact rc No [RFC xxxx] 1186 Contact np No [RFC xxxx] 1187 Note to RFC Editor: Please replace RFC XXXX with the RFC number of 1188 this specification. 1190 15. Acknowledgements 1192 Jonathan Rosenberg et al produced the document that provided 1193 additional use cases precipitating the requirement for the new header 1194 parameters to capture the method by which a Request URI is 1195 determined. The authors would like to acknowledge the constructive 1196 feedback provided by Ian Elz, Paul Kyzivat, John Elwell, Hadriel 1197 Kaplan and Dale Worley. John Elwell provided excellent suggestions 1198 in terms of document structure. 1200 Mark Watson, Cullen Jennings and Jon Peterson provided significant 1201 input into the initial work that resulted in the development of of 1202 [RFC4244]. The editor would like to acknowledge the constructive 1203 feedback provided by Robert Sparks, Paul Kyzivat, Scott Orton, John 1204 Elwell, Nir Chen, Palash Jain, Brian Stucker, Norma Ng, Anthony 1205 Brown, Jayshree Bharatia, Jonathan Rosenberg, Eric Burger, Martin 1206 Dolly, Roland Jesske, Takuya Sawada, Sebastien Prouvost, and 1207 Sebastien Garcin in the development of [RFC4244]. 1209 The editor would like to acknowledge the significant input from Rohan 1210 Mahy on some of the normative aspects of the ABNF for [RFC4244], 1211 particularly around the need for and format of the index and around 1212 the security aspects. 1214 16. Changes from RFC 4244 1216 This RFC replaces [RFC4244]. 1218 Deployment experience with [RFC4244] over the years has shown a 1219 number of issues, warranting an update: 1221 o In order to make [RFC4244] work in "real life", one needs to make 1222 "assumptions" on how History-Info is used. For example, many 1223 implementations filter out many entries, and only leave specific 1224 entries corresponding, for example, to first and last redirection. 1225 Since vendors uses different rules, it causes significant 1226 interoperability issues. 1228 o [RFC4244] is overly permissive and evasive about recording 1229 entries, causing interoperability issues. 1231 o The examples in the call flows had errors, and confusing because 1232 they often assume "loose routing". 1234 o [RFC4244] has lots of repetitive and unclear text due to the 1235 combination of requirements with solution. 1237 o [RFC4244] gratuitously mandates the use of TLS on every hop. No 1238 existing implementation enforces this rule, and instead, the use 1239 of TLS or not is a general SIP issue, not an [RFC4244] issue per 1240 se. 1242 o [RFC4244] does not include clear procedures on how to deliver 1243 current target URI information to the UAS when the Request-URI is 1244 replaced with a contact. 1246 o [RFC4244] does not allow for marking History-Info entries for easy 1247 processing by User Agents. 1249 The following summarizes the functional changes between this 1250 specification and [RFC4244]: 1252 1. Added header field parameters to capture the specific method by 1253 which a target is determined to facilitate processing by users of 1254 the History-Info header field entries. A specific header field 1255 parameter is captured for each of the target URIs as the target 1256 set is determined (per section 16.5 of [RFC3261]). The header 1257 field parameter is used in both the History-Info and the Contact 1258 header fields. 1260 2. Added a way to indicate a gap in History-Info by adding a non- 1261 negative integer of "0". 1263 3. Rather than recommending that entries be removed in the case of 1264 certain values of the Privacy header field, the entries are 1265 anonymized. 1267 4. Updated the security section to be equivalent to the security 1268 recommendations for other SIP header fields inserted by 1269 intermediaries. 1271 5. Removed Appendix B since a separate call flow document is being 1272 published as a companion to this document. 1274 The first 2 changes are intended to facilitate application usage of 1275 the History-Info header field and eliminate the need to make 1276 assumptions based upon the order of the entries and ensure that the 1277 most complete set of information is available to the applications. 1279 In addition, editorial changes were done to both condense and clarify 1280 the text, moving the requirements to an appendix and removing the 1281 inline references to the requirements. The examples were simplified 1282 and updated to reflect the protocol changes. Several of the call 1283 flows in the appendix were removed and put into a separate document 1284 that includes additional use cases that require the new header field 1285 parameters. 1287 16.1. Backwards compatibility 1289 This specification is backwards compatible since [RFC4244] allows for 1290 the addition of new optional parameters. This specification adds an 1291 optional SIP header field parameter to the History-Info and Contact 1292 header fields. Entities that have not implemented this specification 1293 will ignore these parameters, however, per [RFC4244] an entity will 1294 not remove these parameters from an hi-entry. While entities 1295 compliant to this document and [RFC4244] must be able to recognize 1296 gaps in the hi-entries, this document requires that an index of "0" 1297 be used in this case. Whereas [RFC4244] recommended (but did not 1298 require) the use of "1". However, since the ABNF in [RFC4244] 1299 defines the index as a DIGIT, "0" would be a valid value, thus an 1300 [RFC4244] implementation should not have an issue if it receives hi- 1301 entries added by intermediaries compliant to this document. 1303 As for the behavior of the UACs, UASs and intermediaries, the 1304 following additional normative changes have been made: 1306 UAC behavior 1308 1. Inclusion of option tag by UAC has changed from SHOULD to MUST. 1310 2. Inclusion of hi-target-entry along with hi-index has changed from 1311 MAY/RECOMMEND to MUST/MUST. 1313 3. Behavior surrounding the addition of hi-target-entry based on 3xx 1314 response has changed from MAY/SHOULD to MUST. 1316 None of the behavior changes would cause any backward or forward 1317 compatibility issues. 1319 UAS behavior 1321 1. Inclusion of hi-entry in response has changed from SHOULD to 1322 MUST. 1324 As the entity receiving response with hi-entry expected it with 1325 SHOULD, this change will not cause any backward compatibility issues. 1327 Proxy/Redirect Server behavior 1328 1. Inclusion of H-I as forwarding the request has changed from 1329 SHOULD to MUST. 1331 2. Association of Reason with time-out/internal reason has changed 1332 from MAY to MUST. 1334 3. Inclusion of hi-index has changed from RECOMMENDED to MUST. 1336 4. Inclusion of hi-entries in response has changed from SHOULD to 1337 MUST. 1339 None of above behavior changes impact backwards compatibility since 1340 they only strengthen normative behavior to improve interoperability. 1342 In cases where an entity that is compliant to this document, receives 1343 a request that contains hi-entries compliant only to RFC4244 (i.e, 1344 the hi-entries do not contain any of the new header field 1345 parameters), the entity MUST NOT add any of the new header field 1346 parameters to the hi-entries. The hi-entries MUST be cached and 1347 forwarded as any other entries are as specified in Section 9.1. As 1348 with RFC4244 compliant entities, applications must be able to 1349 function in cases of missing information, as specified in Section 11. 1351 17. References 1353 17.1. Normative References 1355 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1356 A., Peterson, J., Sparks, R., Handley, M., and E. 1357 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1358 June 2002. 1360 [RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason 1361 Header Field for the Session Initiation Protocol (SIP)", 1362 RFC 3326, December 2002. 1364 [RFC3323] Peterson, J., "A Privacy Mechanism for the Session 1365 Initiation Protocol (SIP)", RFC 3323, November 2002. 1367 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1368 Requirement Levels", BCP 14, RFC 2119, March 1997. 1370 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1371 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1373 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1374 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1376 [RFC4244] Barnes, M., "An Extension to the Session Initiation 1377 Protocol (SIP) for Request History Information", RFC 4244, 1378 November 2005. 1380 17.2. Informative References 1382 [RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User 1383 Agent URIs (GRUUs) in the Session Initiation Protocol 1384 (SIP)", RFC 5627, October 2009. 1386 [RFC5630] Audet, F., "The Use of the SIPS URI Scheme in the Session 1387 Initiation Protocol (SIP)", RFC 5630, October 2009. 1389 [RFC3087] Campbell, B. and R. Sparks, "Control of Service Context 1390 using SIP Request-URI", RFC 3087, April 2001. 1392 [RFC4240] Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network 1393 Media Services with SIP", RFC 4240, December 2005. 1395 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", 1396 RFC 3966, December 2004. 1398 [RFC4458] Jennings, C., Audet, F., and J. Elwell, "Session 1399 Initiation Protocol (SIP) URIs for Applications such as 1400 Voicemail and Interactive Voice Response (IVR)", RFC 4458, 1401 April 2006. 1403 [I-D.ietf-sipcore-rfc4244bis-callflows] 1404 Barnes, M., Audet, F., Schubert, S., Elburg, H., and C. 1405 Holmberg, "Session Initiation Protocol (SIP) History-Info 1406 Header Call Flow Examples", 1407 draft-ietf-sipcore-rfc4244bis-callflows-01 (work in 1408 progress), September 2012. 1410 Appendix A. Request History Requirements 1412 The following list constitutes a set of requirements for a "Request 1413 History" capability. 1415 1. CAPABILITY-req: The "Request History" capability provides a 1416 capability to inform proxies and UAs involved in processing a 1417 request about the history/progress of that request. Although 1418 this is inherently provided when the retarget is in response to a 1419 SIP redirect, it is deemed useful for non-redirect retargeting 1420 scenarios, as well. 1422 2. GENERATION-req: "Request History" information is generated when 1423 the request is retargeted. 1425 A. In some scenarios, it might be possible for more than one 1426 instance of retargeting to occur within the same proxy. A 1427 proxy MUST also generate Request History information for the 1428 'internal retargeting'. 1430 B. An entity (UA or proxy) retargeting in response to a redirect 1431 or REFER MUST include any Request History information from 1432 the redirect/REFER in the new request. 1434 3. ISSUER-req: "Request History" information can be generated by a 1435 UA or proxy. It can be passed in both requests and responses. 1437 4. CONTENT-req: The "Request History" information for each 1438 occurrence of retargeting shall include the following: 1440 A. The new URI or address to which the request is in the process 1441 of being retargeted, 1443 B. The URI or address from which the request was retargeted, and 1444 whether the retarget URI was an AOR 1446 C. The mechanism by which the new URI or address was determined, 1448 D. The reason for the Request-URI or address modification, 1450 E. Chronological ordering of the Request History information. 1452 5. REQUEST-VALIDITY-req: Request History is applicable to requests 1453 not sent within an early or established dialog (e.g., INVITE, 1454 REGISTER, MESSAGE, and OPTIONS). 1456 6. BACKWARDS-req: Request History information may be passed from the 1457 generating entity backwards towards the UAC. This is needed to 1458 enable services that inform the calling party about the dialog 1459 establishment attempts. 1461 7. FORWARDS-req: Request History information may also be included by 1462 the generating entity in the request, if it is forwarded onwards. 1464 A.1. Security Requirements 1466 The Request History information is being inserted by a network 1467 element retargeting a Request, resulting in a slightly different 1468 problem than the basic SIP header problem, thus requiring specific 1469 consideration. It is recognized that these security requirements can 1470 be generalized to a basic requirement of being able to secure 1471 information that is inserted by proxies. 1473 The potential security problems include the following: 1475 1. A rogue application could insert a bogus Request History-Info 1476 entry either by adding an additional hi-entry as a result of 1477 retargeting or entering invalid information. 1479 2. A rogue application could re-arrange the Request History 1480 information to change the nature of the end application or to 1481 mislead the receiver of the information. 1483 3. A rogue application could delete some or all of the Request 1484 History information. 1486 Thus, a security solution for "Request History" must meet the 1487 following requirements: 1489 1. SEC-req-1: The entity receiving the Request History must be able 1490 to determine whether any of the previously added Request History 1491 content has been altered. 1493 2. SEC-req-2: The ordering of the Request History information must 1494 be preserved at each instance of retargeting. 1496 3. SEC-req-3: The entity receiving the information conveyed by the 1497 Request History must be able to authenticate the entity providing 1498 the request. 1500 4. SEC-req-4: To ensure the confidentiality of the Request History 1501 information, only entities that process the request SHOULD have 1502 visibility to the information. 1504 It should be noted that these security requirements apply to any 1505 entity making use of the Request History information. 1507 A.2. Privacy Requirements 1509 Since the Request-URI that is captured could inadvertently reveal 1510 information about the originator, there are general privacy 1511 requirements that MUST be met: 1513 1. PRIV-req-1: The entity retargeting the Request must ensure that 1514 it maintains the network-provided privacy (as described in 1515 [RFC3323]) associated with the Request as it is retargeted. 1517 2. PRIV-req-2: The entity receiving the Request History must 1518 maintain the privacy associated with the information. In 1519 addition, local policy at a proxy may identify privacy 1520 requirements associated with the Request-URI being captured in 1521 the Request History information. 1523 3. PRIV-req-3: Request History information subject to privacy shall 1524 not be included in out going messages unless it is protected as 1525 described in [RFC3323]. 1527 Authors' Addresses 1529 Mary Barnes 1530 Polycom 1531 TX 1532 US 1534 Email: mary.ietf.barnes@gmail.com 1536 Francois Audet 1537 Skype 1539 Email: francois.audet@skype.net 1541 Shida Schubert 1542 NTT 1544 Email: shida@ntt-at.com 1546 Hans Erik van Elburg 1547 Detecon International Gmbh 1548 Sternengasse 14-16 1549 Cologne, 1550 Germany 1552 Email: ietf.hanserik@gmail.com 1553 Christer Holmberg 1554 Ericsson 1555 Hirsalantie 11, Jorvas 1556 Finland 1558 Email: christer.holmberg@ericsson.com