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