idnits 2.17.1 draft-ietf-sipcore-rfc4244bis-12.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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 454 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 (Oct 2013) is 3844 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 1198, 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-06 Summary: 2 errors (**), 0 flaws (~~), 6 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: April 4, 2014 S. Schubert 7 NTT 8 J. van Elburg 9 Detecon International Gmbh 10 C. Holmberg 11 Ericsson 12 Oct 2013 14 An Extension to the Session Initiation Protocol (SIP) for Request 15 History Information 16 draft-ietf-sipcore-rfc4244bis-12.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 April 4, 2014. 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 6.3. Back-2-Back User Agent (B2BUA) Behavior . . . . . . . . . 13 89 7. Proxy/Intermediary Handling of History-Info Header Fields . . 14 90 8. Redirect Server Handling of History-Info Header Fields . . . . 14 91 9. Handling of History-Info Header Fields in Requests and 92 Responses . . . . . . . . . . . . . . . . . . . . . . . . . . 15 93 9.1. Receiving a Request . . . . . . . . . . . . . . . . . . . 15 94 9.2. Sending a Request with History-Info . . . . . . . . . . . 15 95 9.3. Receiving a Response with History-Info or Request 96 Timeouts . . . . . . . . . . . . . . . . . . . . . . . . . 16 97 9.4. Sending History-Info in Responses . . . . . . . . . . . . 17 98 10. Processing the History-Info Header Field . . . . . . . . . . . 17 99 10.1. Privacy in the History-Info Header Field . . . . . . . . . 17 100 10.1.1. Indicating Privacy . . . . . . . . . . . . . . . . . 17 101 10.1.2. Applying Privacy . . . . . . . . . . . . . . . . . . 18 102 10.2. Reason in the History-Info Header Field . . . . . . . . . 19 103 10.3. Indexing in the History-Info Header Field . . . . . . . . 20 104 10.4. Mechanism for Target Determination in the History-Info 105 Header Field . . . . . . . . . . . . . . . . . . . . . . . 21 106 11. Application Considerations . . . . . . . . . . . . . . . . . . 23 107 12. Application Specific Usage . . . . . . . . . . . . . . . . . . 25 108 12.1. PBX Voicemail . . . . . . . . . . . . . . . . . . . . . . 25 109 12.2. Consumer Voicemail . . . . . . . . . . . . . . . . . . . . 25 110 13. Security Considerations . . . . . . . . . . . . . . . . . . . 26 111 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 112 14.1. Registration of New SIP History-Info Header Field . . . . 27 113 14.2. Registration of "history" for SIP Privacy Header Field . . 27 114 14.3. Registration of Header Field Parameters . . . . . . . . . 28 115 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 116 16. Changes from RFC 4244 . . . . . . . . . . . . . . . . . . . . 29 117 16.1. Backwards compatibility . . . . . . . . . . . . . . . . . 30 118 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 119 17.1. Normative References . . . . . . . . . . . . . . . . . . . 32 120 17.2. Informative References . . . . . . . . . . . . . . . . . . 32 121 Appendix A. Request History Requirements . . . . . . . . . . . . 33 122 A.1. Security Requirements . . . . . . . . . . . . . . . . . . 34 123 A.2. Privacy Requirements . . . . . . . . . . . . . . . . . . . 35 124 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 126 1. Introduction 128 Many services that SIP is anticipated to support require the ability 129 to determine why and how a SIP request arrived at a specific 130 application. Examples of such services include (but are not limited 131 to) sessions initiated to call centers via "click to talk" SIP 132 Uniform Resource Locators (URLs) on a web page, "call history/ 133 logging" style services within intelligent "call management" software 134 for SIP User Agents (UAs), and calls to voicemail servers. Although 135 SIP implicitly provides the retarget capabilities that enable SIP 136 requests to be routed to chosen applications, there is a need for a 137 standard mechanism within SIP for communicating the retargeting 138 history of the requests. This "request history" information allows 139 the receiving application to obtain information about how and why the 140 SIP request arrived at the application/user. 142 This document defines a SIP header field, History-Info, to provide a 143 standard mechanism for capturing the request history information to 144 enable a wide variety of services for networks and end-users. SIP 145 header field parameters are defined for the History-Info and Contact 146 header fields to tag the method by which the target of a request is 147 determined. This specification also defines a value, "history", for 148 the Privacy header field. In addition a SIP option tag, "histinfo", 149 is defined. 151 The History-Info header field provides a building block for 152 development of SIP based applications and services. The requirements 153 for the solution described in this specification are included in 154 Appendix A. Example scenarios using the History-Info header field 155 are available in [I-D.ietf-sipcore-rfc4244bis-callflows]. 157 2. Conventions and Terminology 159 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 160 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 161 document are to be interpreted as described in [RFC2119]. 163 The term "retarget" is used in this specification to refer to the 164 process of a SIP entity changing the request-URI [RFC3261, section 165 7.1] in a request based on the rules for determining request targets 166 as described in Section 16.5 of [RFC3261] and of the subsequent 167 forwarding of that request as described in step 2 in section 16.6 of 168 [RFC3261]. This includes changing the Request-URI due to a location 169 service lookup and redirect processing. This also includes internal 170 (to a Proxy/SIP intermediary) changes of the URI prior to forwarding 171 of the request. 173 The terms "location service", "forward", "redirect" and "AOR" are 174 used consistently with the terminology in [RFC3261]. 176 The terms "target user" is used in this specification as the human 177 user associated with particular AoR or AoRs (in case the human user 178 has multiple alias). 180 The references to "domain for which the SIP entity/Proxy/Intermediary 181 is responsible" are consistent with and intended to convey the same 182 context as the usage of that terminology in [RFC3261]. The 183 applicability of History-Info to architectures or models outside the 184 context of [RFC3261] is outside the scope of this specification. 186 3. Background 188 SIP implicitly provides retargeting capabilities that enable SIP 189 requests to be routed to specific applications as defined in 190 [RFC3261]. The motivation for capturing the request history is that 191 in the process of retargeting a request, old routing information can 192 be forever lost. This lost information may be important history that 193 allows elements to which the request is retargeted to process the 194 request in a locally defined, application-specific manner. This 195 document defines a mechanism for transporting the request history. 196 Application-specific behavior is outside the scope of this 197 specification. 199 Current network applications for other protocols provide the ability 200 for elements involved with the request to obtain additional 201 information relating to how and why the request was routed to a 202 particular destination. The following are examples of such 203 applications: 205 1. Web "referral" applications, whereby an application residing 206 within a web server determines that a visitor to a website has 207 arrived at the site via an "associate" site that will receive 208 some "referral" commission for generating this traffic 210 2. Email relaying whereby the recipient obtains a detailed "trace of 211 the path" of the message from originator to receiver, including 212 the time of each relay. 214 3. Traditional telephony services such as voicemail, call-center 215 "automatic call distribution", and "follow-me" style services 217 Several of the aforementioned applications currently define 218 application-specific mechanisms through which it is possible to 219 obtain the necessary history information. 221 In addition, request history information could be used to enhance 222 basic SIP functionality by providing the following: 224 o Some diagnostic information for debugging SIP requests. 226 o Capturing aliases and Globally Routable User Agent URIs (GRUUs) 227 [RFC5627], which can be overwritten by a registrar or a "home 228 proxy" (a proxy serving as the terminal point for routing an 229 address-of-record) upon receipt of the initial request. 231 o Facilitating the use of limited use addresses (minted on demand) 232 and sub-addressing. 234 o Preserving service specific URIs that can be overwritten by a 235 downstream proxy, such as those defined in [RFC3087], and control 236 of network announcements and IVR with SIP URI [RFC4240]. 238 4. Overview 240 The fundamental functionality provided by the request history 241 information is the ability to inform proxies and user agents (UAs) 242 involved in processing a request about the history or progress of 243 that request. The solution is to capture the Request-URIs as a 244 request is retargeted, in a SIP header field: History-Info. This 245 allows for the capturing of the history of a request that would be 246 lost with the normal SIP processing involved in the subsequent 247 retargeting of the request. 249 The History-Info header field is added to a Request when a new 250 request is created by a user agent client (UAC) or forwarded by a 251 Proxy, or when the target of a request is changed. It is possible 252 for the target of a request to be changed by the same proxy/SIP 253 intermediary multiple times (referred to as 'internal retargeting'). 254 A SIP entity changing the target of a request in response to a 255 redirect also propagates any History-Info header field from the 256 initial request in the new request. The ABNF and detailed 257 description of the History-Info header field parameters along with 258 examples, is provided in Section 5. Section 6, Section 7 and 259 Section 8 provide the detailed handling of the History-Info header 260 field by SIP User Agents, Proxies and Redirect Servers respectively. 262 This specification also defines three new SIP header field 263 parameters, "rc", "mp" and "np", for the History-Info and Contact 264 header fields, to tag the method by which the target of a request is 265 determined. Further detail on the use of these header field 266 parameters is provided in Section 5. 268 This specification also defines a priv-value for the Privacy header, 269 "history", that requires anonymization of all the History-Info header 270 field entries in a Request or to a specific History-Info header field 271 hi-entry as described above. Further detail is provided in 272 Section 10.1. 274 In addition a SIP option tag, "histinfo", is defined. The use of 275 this option tag is described in Section 6.1. 277 5. History-Info Header Field Protocol Structure 279 The History-Info header field defined in this specification defines 280 the usage in out-of-dialog requests or initial requests for a dialog 281 (e.g., INVITE, REGISTER, MESSAGE, REFER and OPTIONS, PUBLISH and 282 SUBSCRIBE, etc.) and any non-100 provisional or final responses to 283 these requests. 285 The following provides details for the information that is captured 286 in the History-Info header field entries for each target used for 287 forwarding a request: 289 o hi-targeted-to-uri: A mandatory parameter for capturing the 290 Request-URI for the specific request as it is forwarded. 292 o hi-index: A mandatory parameter for History-Info reflecting the 293 chronological order of the information, indexed to reflect the 294 forking and retargeting of requests. The format for this 295 parameter is a sequence of non-negative integers, separated by 296 dots to indicate the number of forward hops and retargets. This 297 results in a tree representation of the history of the request, 298 with the lowest-level index reflecting a leaf. By adding the new 299 entries in chronological order (i.e., following existing entries 300 per the details in Section 10.3), including the index and sending 301 the messages using a secure transport, the ordering of the 302 History-Info header fields in the request is assured. In 303 addition, applications may extract a variety of metrics (total 304 number of retargets, total number of retargets from a specific 305 branch, etc.) based upon the index values. 307 o hi-target-param: An optional parameter reflecting the mechanism by 308 which the Request URI captured in the hi-targeted-to-uri in the 309 History-Info header field value (hi-entry) was determined. This 310 parameter is either an "rc", "mp" or "np" header field parameter, 311 which is interpreted as follows: 313 "rc": The hi-targeted-to-URI represents a change in Request-URI 314 while the target user remains the same. This occurs for 315 example when user has multiple AoRs as an alias. The "rc" 316 header field parameter contains the value of the hi-index in 317 the hi-entry with an hi-targeted-to-uri that reflects the 318 Request-URI that was retargeted 320 "mp": The hi-targeted-to-URI represents a user other than the 321 target user associated with the Request-URI in the incoming 322 request that was retargeted. This occurs when a request is 323 statically or dynamically retargeted to another user 324 represented by an AoR unassociated with the AoR of the original 325 target user. The "mp" header field parameter contains the 326 value of the hi-index in the hi-entry with an hi-targeted-to- 327 uri that reflects the Request-URI that was retargeted, thus 328 identifying the "mapped from" target. 330 "np": The hi-targeted-to-URI represents that there was no 331 change in Request-URI. This would apply for example when a 332 proxy merely forwards a request to a next hop proxy and loose 333 routing is used. The "np" header field parameter contains the 334 value of the hi-index in the hi-entry with an hi-targeted-to- 335 uri that reflects the Request-URI that was copied unchanged 336 into the request represented by this hi-entry. That value will 337 usually be the hi-index of the parent hi-entry of this hi- 338 entry. 340 o Extension (hi-extension): A parameter to allow for future optional 341 extensions. As per [RFC3261], any implementation not 342 understanding an extension MUST ignore it. 344 The ABNF syntax [RFC5234] for the History-Info header field and 345 header field parameters is as follows: 347 History-Info = "History-Info" HCOLON hi-entry *(COMMA hi-entry) 349 hi-entry = hi-targeted-to-uri *(SEMI hi-param) 351 hi-targeted-to-uri = name-addr 353 hi-param = hi-index / hi-target-param / hi-extension 355 hi-index = "index" EQUAL index-val 357 index-val = number *("." number) 359 number = [ %31-39 *DIGIT ] DIGIT 361 hi-target-param = rc-param / mp-param / np-param 363 rc-param = "rc" EQUAL index-val 365 mp-param = "mp" EQUAL index-val 367 np-param = "np" EQUAL index-val 369 hi-extension = generic-param 371 The ABNF definitions for "generic-param", "name-addr", "HCOLON", 372 "COMMA", "SEMI" and "EQUAL" are from [RFC3261]. 374 This document also extends the "contact-params" for the Contact 375 header field as defined in [RFC3261] with the "rc", "mp" and "np" 376 header field parameters defined above. 378 In addition to the parameters defined by the ABNF, an hi-entry may 379 also include a Reason header field and/or a Privacy header field, 380 which are both included in the "headers" component of the hi- 381 targeted-to-uri as described below: 383 o Reason: An optional parameter for History-Info, reflected in the 384 History-Info header field by including the Reason header field 385 [RFC3326] included in the hi-targeted-to-uri. A reason is 386 included in the hi-targeted-to-uri of an hi-entry to reflect 387 information received in a response to the request sent to that 388 URI. 390 o Privacy: An optional parameter for History-Info, reflected in the 391 History-Info header field values by including the Privacy Header 392 [RFC3323] with a priv-value of "history", as defined in this 393 document, included in the hi- targeted-to-uri or by adding the 394 Privacy header field with a priv-value of "history" to the 395 request. The latter case indicates that the History-Info entries 396 for all History-Info entries whose hi-targeted-to-uri has the same 397 domain as the domain for which the SIP entity processing the 398 message is responsible MUST be anonymized prior to forwarding, 399 whereas the use of the Privacy header field included in the hi- 400 targeted-to-uri means that a specific hi-entry MUST be anonymized. 402 Note that since both the Reason and Privacy parameters are included 403 in the hi-targeted-to-uri, these fields will not be available in the 404 case that the hi-targeted-to-uri is a Tel-URI [RFC3966]. 406 The following provides examples of the format for the History-Info 407 header field. Note that the backslash, CRLF and whitespace between 408 the lines in the examples below are inserted for readability purposes 409 only. Note, however, that History-Info can be broken into multiple 410 lines due to the SWS (sep whitespace) that is part of HCOLON, COMMA 411 and SEMI, and there can be multiple History-Info header fields due to 412 the rule of section 7.3 [RFC3261]. Additional detailed examples are 413 available in [I-D.ietf-sipcore-rfc4244bis-callflows]. 415 History-Info: ;index=1;foo=bar 417 History-Info: ;index=1.1,\ 419 ;index=1.2;mp=1.1,\ 421 ;index=1.3;rc=1.2 423 5.1. History-Info Header Field Example Scenario 425 The following is an illustrative example of usage of History-Info. 427 In this example, Alice (sip:alice@atlanta.example.com) calls Bob 428 (sip:bob@biloxi.example.com). Alice's proxy in her home domain (sip: 429 atlanta.example.com) forwards the request to Bob's proxy (sip: 430 biloxi.example.com). When the request arrives at sip: 431 biloxi.example.com, it does a location service lookup for 432 bob@biloxi.example.com and changes the target of the request to Bob's 433 Contact URIs provided as part of normal SIP registration. In this 434 example, Bob is simultaneously contacted on a PC client and on a 435 phone, and Bob answers on the PC client. 437 One important thing illustrated by this call flow is that without 438 History-Info, Bob would "lose" the original target information or the 439 initial request-URI, including any parameters in the request URI. 440 Bob can recover that information by locating the last hi-entry with 441 an "rc" header field parameter. This "rc" header field parameter 442 contains the index of the hi-entry containing the lost target 443 information - i.e., the sip:bob@biloxi.example.com hi-entry with 444 index=1.1. Note that in the 200 response to Alice, an hi-entry is 445 not included for the fork to sip:bob@192.0.2.7 (index 1.1.1) since 446 biloxi.example.com had not received a response from that fork at the 447 time it sent the 200 OK that ultimately reached Alice. 449 Additional detailed examples are available in 450 [I-D.ietf-sipcore-rfc4244bis-callflows]. 452 Note: This example uses loose routing procedures. 454 Alice atlanta.example.com biloxi.example.com Bob@pc Bob@phone 455 | | | | | 456 | INVITE sip:bob@biloxi.example.com;p=x | | 457 |--------------->| | | | 458 | Supported: histinfo | | | 459 | History-Info: ;index=1 | 460 | | | | | 461 | | INVITE sip:bob@biloxi.example.com;p=x | 462 | |--------------->| | | 463 | History-Info: ;index=1 | 464 | History-Info: ;np=1;index=1.1 465 | | | | | 466 | | | INVITE sip:bob@192.0.2.3| 467 | | |--------------->| | 468 | History-Info: ;index=1 469 | History-Info: ;np=1;index=1.1 470 | History-Info: ;index=1.1.1;rc=1.1 471 | | | | | 472 | | | INVITE sip:bob@192.0.2.7| 473 | | |-------------------------->| 474 | History-Info: ;index=1 475 | History-Info: ;np=1;index=1.1 476 | History-Info: ;index=1.1.2;rc=1.1 477 | | | 200 | | 478 | | |<---------------| | 479 | History-Info: ;index=1 480 | History-Info: ;np=1;index=1.1 481 | History-Info: ;index=1.1.1;rc=1.1 482 | | | | | 483 | | 200 | | | 484 | |<---------------| | | 485 | History-Info: ;index=1 486 | History-Info: ;np=1;index=1.1 487 | History-Info: ;index=1.1.1;rc=1.1 488 | | | | | 489 | | | Proxy Cancels INVITE | 490 | | |<=========================>| 491 | | | | | 492 | 200 | | | | 493 |<---------------| | | | 494 | History-Info: ;index=1 495 | History-Info: ;np=1;index=1.1 496 | History-Info: ;index=1.1.1;rc=1.1 497 | | | | | 498 | ACK | | | | 499 |--------------->| ACK | | | 500 | |--------------->| ACK | | 501 | | |--------------->| | 502 Figure 1: Basic Call 504 6. User Agent Handling of the History-Info Header Field 506 This section describes the processing specific to UAs(UACs, UASs and 507 B2BUAs) for the History-Info header." 509 6.1. User Agent Client (UAC) Behavior 511 The UAC MUST include the "histinfo" option tag in the Supported 512 header field in any out-of-dialog requests or initial requests for a 513 dialog for which the UAC would like the History-Info header field in 514 the response. When issuing a request, the UAC MUST follow the 515 procedures in Section 9.2. In the case of an initial request, except 516 where the UAC is part of a B2BUA, there is no cache of hi- entries 517 with which to populate the History-Info header field and the hi-index 518 is set to 1 per Section 10.3. When receiving a response the UAC MUST 519 follow the procedures in Section 9.3. 521 If the UAC generates further forks of the initial request (either due 522 to acting on a 3xx response or internally-directed forking to 523 multiple destinations), the successive requests will add hi-entries 524 with hi-indexes of 2, 3, etc. 526 6.2. User Agent Server (UAS) Behavior 528 When receiving a request, a UAS MUST follow the procedures defined in 529 Section 9.2. When sending a response other than a 3xx response, a 530 UAS MUST follows the procedures as defined in Section 9.4. When 531 sending a 3xx response, the UAS MUST follow the procedures defined 532 for a redirect server per Section 8. An application at the UAS can 533 make use of the cached hi-entries as described in Section 11. 535 6.3. Back-2-Back User Agent (B2BUA) Behavior 537 A back-to-back user agent (B2BUA) MAY follow the behavior of a SIP 538 intermediary, per Section 7, as an alternative to following the 539 behavior of a user agent server (UAS) per Section 6.2 and a UAC per 540 Section 6.1. In behaving as an intermediary, a B2BUA carries forward 541 hi-entries received in requests at the UAS to requests being 542 forwarded by the UAC, as well as carrying forward hi-entries in 543 responses received at the UAC to the responses forwarded by the UAS, 544 subject to privacy considerations per Section 10.1. 546 7. Proxy/Intermediary Handling of History-Info Header Fields 548 This section describes the procedures for proxies and other SIP 549 intermediaries for the handling of the History-Info header fields for 550 each of the following scenarios: 552 Receiving a Request: An intermediary MUST follow the procedures in 553 Section 9.1 for the handling of hi-entries in incoming SIP 554 requests. 556 Sending a Request: For each outgoing request relating to a target in 557 the target set, the intermediary MUST follow the procedures of 558 Section 9.2. 560 Receiving a Response or Timeout: An intermediary MUST follow the 561 procedures of Section 9.3 when a SIP response is received or a 562 request times out. 564 Sending a Response: An intermediary MUST follow the procedures of 565 Section 9.4 for the handling of the hi-entries when sending a SIP 566 response. 568 In some cases, an intermediary may retarget a request more than once 569 before forwarding - i.e., a request is retargeted to a SIP entity 570 that is "internal" to the intermediary before the same intermediary 571 retargets the request to an external target . A typical example 572 would be a proxy that retargets a request first to a different user 573 (i.e., it maps to a different AOR) and then forwards to a registered 574 contact bound to the same AOR. In this case, the intermediary MUST 575 add a hi-entry for (each of) the internal target(s) per the 576 procedures in Section 9.2. The intermediary MAY include a Reason 577 header field in the hi-entry with the hi-targeted-to-uri that has 578 been retargeted. Note, that this is shown in the INVITE (F6) in the 579 example entitled "Sequentially Forking (History-Info in Response)" in 580 [I-D.ietf-sipcore-rfc4244bis-callflows]. 582 8. Redirect Server Handling of History-Info Header Fields 584 A redirect server MUST follow the procedures in Section 9.1 when it 585 receives a SIP Request. A redirect server MUST follow the procedures 586 in Section 9.4 when it sends a SIP Response. When generating the 587 Contact header field in a 3xx response, the redirect server MUST add 588 the appropriate "mp", "np" or "rc" header field parameter to each 589 Contact header field as described in Section 10.4, if applicable. 591 9. Handling of History-Info Header Fields in Requests and Responses 593 This section describes the procedures for SIP entities for the 594 handling of the History-Info header field in SIP requests and 595 responses. 597 9.1. Receiving a Request 599 When receiving a request, a SIP entity MUST keep a copy of the hi- 600 entries from the incoming request. This document describes this copy 601 in terms of a cache containing the hi-entries associated with the 602 request. The hi-entries MUST be added to the cache in the order in 603 which they were received in the request. 605 If the Request-URI of the incoming request does not match the hi- 606 targeted-to-uri in the last hi-entry (i.e., the previous SIP entity 607 that sent the request did not include a History-Info header field), 608 the SIP entity MUST add a hi-entry to end of the cache, on behalf of 609 the previous SIP entity before proceeding to Section 9.2, as follows: 611 The SIP entity MUST set the hi-targeted-to-uri to the value of the 612 Request-URI in the incoming request. If the Request-URI is a Tel- 613 URI, it SHOULD be transformed into a SIP URI per section 19.1.6 of 614 [RFC3261] before being added as a hi-targted-to-uri. 616 If privacy is required, the SIP entity MUST follow the procedures 617 of Section 10.1. 619 The SIP entity MUST set the hi-index parameter as described in 620 Section 10.3. 622 The SIP entity MUST NOT include an "rc", "mp" or "np" header field 623 parameter. 625 9.2. Sending a Request with History-Info 627 When sending a request, a SIP entity MUST include all the hi-entries 628 from the cache that was created per Section 9.1. In addition, the 629 SIP entity MUST add a new hi-entry to the outgoing request, but the 630 SIP entity MUST NOT add the hi-entry to the cache at this time. The 631 hi-entries in the outgoing request's History-Info header field is the 632 preorder of the tree of hi-entries, that is, by the lexicographic 633 ordering of the hi-indexes. The new hi-entry is populated as 634 follows: 636 hi-targeted-to-uri: The hi-targeted-to-uri MUST be set to the value 637 of the Request-URI of the current (outgoing) request. 639 privacy: If privacy is required, the procedures of Section 10.1 MUST 640 be followed. 642 hi-index: The SIP entity MUST include an hi-index for the hi-entry 643 as described in Section 10.3. 645 rc/mp/np: The SIP entity MUST include an "rc", "mp" or "np" header 646 field parameter in the hi-entry, if applicable, per the procedures 647 in Section 10.4. 649 9.3. Receiving a Response with History-Info or Request Timeouts 651 When a SIP entity receives a non-100 response or a request times out, 652 the SIP entity performs the following steps: 654 Step 1: Add hi-entry to cache 656 The SIP entity MUST add the hi-entry that was added to the request 657 that received the non-100 response or timed out to the cache, if 658 it was not already cached. The hi-entry MUST be added to the 659 cache in ascending order as indicated by the values in the hi- 660 index parameters of the hi-entries (e.g., 1.2.1 comes after 1.2 661 but before 1.2.2 or 1.3). 663 Step 2: Add Reason header field 665 If the response is not a 100 or 2xx response, the SIP entity adds 666 one or more Reason header fields to the hi-targeted-to-uri in the 667 (newly) cached hi-entry reflecting the SIP response code in the 668 non-100 or non-2xx response, per the procedures of Section 10.2. 670 Step 3: Add additional hi-entries 672 The SIP entity MUST also add to the cache any hi-entries received 673 in the response that are not already in the cache. This situation 674 can occur when the entity that generated the non-100 response 675 retargeted the request before generating the response. As per 676 Step 1, the hi-entries MUST be added to the cache in ascending 677 order as indicated by the values in the hi-index parameters of the 678 hi-entries 680 It is important to note that the cache (and the request or response) 681 does not contain hi-entries for requests that have not yet received a 682 non-100 response, so there can be gaps in indices (e.g., 1.2 and 1.4 683 could be present but not 1.3). 685 9.4. Sending History-Info in Responses 687 When sending a response other than a 100, a SIP entity MUST include 688 all the cached hi-entries in the response, subject to the privacy 689 consideration in Section 10.1.2, and with the following exception: If 690 the received request contained no hi-entries and there is no 691 "histinfo" option tag in the Supported header field, the SIP entity 692 MUST NOT include History-Info in the response. 694 10. Processing the History-Info Header Field 696 The following sections describe the procedures for processing the 697 History-Info header field. These procedures are applicable to SIP 698 entities such as Proxies/Intermediaries, Redirect Servers or User 699 Agents. 701 10.1. Privacy in the History-Info Header Field 703 The privacy requirements for this document are described in 704 Appendix A.2. Section 10.1.1 describes the insertion of the Privacy 705 header field defined in [RFC3323] to indicate the privacy to be 706 applied to the History-Info header field entries. Section 10.1.2 707 describes how to apply privacy to a request or response that is being 708 forwarded, based on the presence of the Privacy header field. 710 10.1.1. Indicating Privacy 712 As with other SIP headers described in [RFC3323], the hi-targeted-to- 713 uris in the History-Info header field can inadvertently reveal 714 information about the initiator of the request. Thus, the UAC needs 715 a mechanism to indicate that the hi-targeted-to-uris in the hi- 716 entries need to be privacy protected. The Privacy header field is 717 used by the UAC to indicate that privacy is to be applied to all the 718 hi-entries in the request as follows: 720 o If the UAC is including a Privacy header field with a priv-value 721 of "header" in the request, then the UAC SHOULD NOT include a 722 priv-value of "history" in the Privacy header field in the 723 Request. 725 o If the UAC is including any priv-values other than "header" in the 726 Privacy header field, then the UAC MUST also include a priv-value 727 of "history" in the Privacy header field in the Request. 729 o If the UAC is not including any priv-values in the Privacy header 730 field in the request, then the UAC MUST add a Privacy header 731 field, with a priv-value of "history", to the request. The UAC 732 MUST NOT include a priv-value of "critical" in the Privacy header 733 field in the Request in this case. 735 In addition, the History-Info header field can reveal general routing 736 and diverting information within an intermediary, which the 737 intermediary wants to privacy protect. In this case, the 738 intermediary MUST construct a Privacy header field with the single 739 priv-value of "history" and include the Privacy header field in the 740 hi-targeted-to-uri, for each new hi-entry created by the intermediary 741 whose hi-targeted-to-uri it wishes to privacy protect. Note that the 742 priv-value in the Privacy header for the incoming request does not 743 necessarily influence whether the intermediary includes a Privacy 744 header field in the hi-entries. For example, even if the Privacy 745 header for the incoming request contained a priv-value of "none", the 746 Proxy can still set a priv-value of "history" in the Privacy header 747 field included in the hi-targeted-to-uri. 749 Finally, the UAS may not want to reveal the final reached target to 750 the originator. In this case, the UAS MUST include a Privacy header 751 field with a priv-value of "history" in the hi-targeted-to-uri in the 752 last hi-entry, in the response. As noted above, the UAS of the 753 request MUST NOT use any other priv-values in the Privacy header 754 field included in the hi-entry. 756 10.1.2. Applying Privacy 758 When a SIP message is forwarded to a domain for which the SIP 759 intermediary is not responsible, a Privacy Service at the boundary of 760 the domain applies the appropriate privacy based on the value of the 761 Privacy header field in the message header or in the "headers" 762 component of the hi-targeted-to-uri in the individual hi-entries. 764 If there is a Privacy header field in the message header of a request 765 or response, with a priv-value of "header" or "history", then all the 766 hi-targeted-to-uris in the hi-entries, associated with the domain for 767 which the SIP intermediary is responsible, are anonymized by the 768 Privacy Service. The Privacy Service MUST change any hi-targeted-to- 769 uris in these hi-entries that have not been anonymized (evidenced by 770 their domain not being "anonymous.invalid") to anonymous URIs 771 containing a domain of anonymous.invalid as recommended in section 772 4.1.1.3 of [RFC3323]. As defined in section 4.1.1.2 of [RFC3323] the 773 recommendations of [RFC3261] for anonymyzing the URI Username SHOULD 774 be followed (i.e., "anonymous" in the user portion of the URI). If 775 there is a Privacy header field in the "headers" component of the hi- 776 targeted-to-uri in the hi-entries, then the Privacy header field 777 value MUST be removed from the hi- entry. Once all the appropriate 778 hi-entries have been anonymized, the Privacy Service MUST remove the 779 priv-value of "history" from the Privacy header field in the message 780 header of the request or response. If there are no remaining priv- 781 values in the Privacy header field, the Privacy Service MUST remove 782 the Privacy header field from the request or response per [RFC3323]. 784 If there is not a Privacy header field in the message header of the 785 request or response that is being forwarded, but there is a Privacy 786 header field with a priv-value of "history" in the "headers" 787 component in any of the hi-targeted-uris in the hi-entries associated 788 with the domain for which a SIP intermediary is responsible, then the 789 Privacy Service MUST update those hi-targeted-to-uris as described 790 above. Any other priv-values in the Privacy header field in the 791 "headers" component of the hi-targeted-to-uris in the hi-entries MUST 792 be ignored. In any case, the Privacy Service MUST remove the Privacy 793 header field from the "headers" compenent of the hi-targeted-to-uris 794 in the hi-entries prior to forwarding. 796 10.2. Reason in the History-Info Header Field 798 A Reason header field is added to the "headers" component in an hi- 799 targeted-to-uri when the hi-entry is added to the cache based upon 800 the receipt of a SIP response that is neither a 100 nor a 2xx 801 response, as described in Section 9.3. If the Reason header field is 802 being added due to receipt of an explicit SIP response and the 803 response contains any Reason header fields (see [RFC3326]), then the 804 SIP entity MUST include the Reason header fields in the "headers" 805 component of the hi-targeted-to-uri in the last hi-entry added to the 806 cache, unless the hi-targeted-to-uri is a Tel-URI. If the SIP 807 response does not contain a Reason header field, the SIP entity MUST 808 include a Reason header field, containing the SIP Response Code, in 809 the "headers" component of the hi-targeted-to-uri in the last hi- 810 entry added to the cache, unless the hi-targeted-to-uri is a Tel-URI. 812 If a request has timed out (instead of being explicitly rejected), 813 the SIP entity MUST update the cache as if the request received a SIP 814 error response code of 408 "Request Timeout". 816 A request can receive multiple responses, that are neither 100 nor 817 2xx responses, which carry or imply (for responses without Reason 818 headers, and for timeouts) multiple, possibly duplicated, reason- 819 values to be applied to an hi- targeted-to-uri. In these situations, 820 the SIP entity creating History-Info header value would choose the 821 appropriate Reason header field value. 823 A SIP entity MAY also include a Reason header field in the "headers" 824 component of an hi-targeted-to-uri containing the URI of a request 825 that was retargeted as a result of internal retargeting. 827 If additional Reason header field parameters are defined in the 828 future per [RFC3326], the use of these Reason header field parameters 829 for the History-Info header field MUST follow the same rules as 830 described above. 832 10.3. Indexing in the History-Info Header Field 834 In order to maintain ordering and accurately reflect the retargeting 835 of the request, the SIP entity MUST add a hi-index to each hi-entry. 836 Per the syntax in Section 5, the hi-index consists of a series of 837 nonnegative integer separated by dots (e.g., 1.1.2). Each dot 838 reflects a SIP forwarding hop. The nonnegative integer following 839 each dot reflects the order in which a request was retargeted at the 840 hop. The highest nonnegative integer at each hop reflects the number 841 of entities to which the request has been retargeted at the specific 842 hop (i.e., the number of branches) at the time that the request 843 represented by this hi-entry was generated. Thus, the indexing 844 results in a logical tree representation for the history of the 845 request and the hi-entries are given in the preorder of the tree. 847 The first index in a series of History-Info entries MUST be set to 1. 848 In the case that a SIP entity (intermediary or UAS) adds a first hi- 849 entry on behalf of the previous hop, the hi-index MUST be set to 1. 850 For each forward hop (i.e., each new level of indexing), the last 851 integers of the hi-indexes of the new requests MUST be generated 852 starting at 1 and incrementing by 1 for each additional request. 854 The basic rules for adding the hi-index are summarized as follows: 856 1. Forwarding a request without changing the target: In the case of 857 a request that is being forwarded without changing the target, 858 the hi-index reflects the increasing length of the branch. In 859 this case, the SIP entity MUST read the value from the History- 860 Info header field in the received request and MUST add another 861 level of indexing by appending the dot delimiter followed by an 862 initial value of 1 for the new level. For example, if the hi- 863 index in the last History-Info header field in the received 864 request is 1.1, a proxy would add a hi-entry with an hi-index of 865 1.1.1 and forward the request. 867 2. Retargeting within a processing entity - 1st instance: For the 868 first instance of retargeting within a processing entity, the SIP 869 entity MUST calculate the hi-index as prescribed for basic 870 forwarding. 872 3. Retargeting within a processing entity - subsequent instance: For 873 each subsequent retargeting of a request by the same SIP entity, 874 the SIP entity MUST calculate and add the hi-index for each new 875 branch by incrementing the rightmost value from the hi-index in 876 the last hi-entry. Per the example above, the hi-index in the 877 next request forwarded by this same SIP entity would be 1.1.2. 879 4. Retargeting based upon a Response: In the case of retargeting due 880 to a specific response (e.g., 302), the SIP entity MUST calculate 881 the hi-index calculated per rule 3. That is, the rightmost value 882 of the hi-index MUST be incremented (i.e., a new branch is 883 created). For example, if the hi-index in the History-Info 884 header field of the sent request is 1.2 and the response to the 885 request is a 302, then the hi-index in the History-Info header 886 field for the new hi-targeted-to-URI would be 1.3. 888 5. Forking requests: If the request forwarding is done in multiple 889 forks (sequentially or in parallel), the SIP entity MUST set the 890 hi-index for each hi-entry for each forked request per the rules 891 above, with each new request having a unique index. Each index 892 MUST be sequentially assigned. For example, if the index in the 893 last History-Info header field in the received request is 1.1, 894 this processing entity would initialize its index to 1.1.1 for 895 the first fork, 1.1.2 for the second, and so forth (see Figure 1 896 for an example). Note, that in the case of parallel forking, 897 only the hi-entry corresponding to the fork is included in the 898 request because no response can yet have been received for any of 899 the parallel forked requests. 901 6. Missing entry: If the request clearly has a gap in the hi-entry 902 (i.e., the last hi-entry and Request-URI differ), the entity 903 adding an hi-entry MUST add a single index with a value of "0" 904 (i.e., the non-negative integer zero) prior to adding the 905 appropriate index for the action to be taken. For example, if 906 the index of the last hi-entry in the request received was 1.1.2 907 and there was a missing hi-entry and the request was being 908 forwarded to the next hop, the resulting index will be 1.1.2.0.1. 909 In the case of requests which are forked by a proxy that does not 910 support History-Info, it is possible for hi-entries generated by 911 different entities to have the same index - i.e., each entity 912 supporting History-Info would receive a forked request with the 913 same hi-index to which they would add the value of ".0" prior to 914 adding the appropriate index. Thus, in the previous example, 915 each of the next hop entities would generate an hi-index of 916 1.1.2.0.1. 918 10.4. Mechanism for Target Determination in the History-Info Header 919 Field 921 This specification defines three header field parameters, "rc", "mp" 922 and "np". The header field parameters "rc" and "mp" indicate the 923 mechanism by which a new target for a request is determined. The 924 header field "np" reflects that the target has not changed. All 925 parameters contain an index whose value is the hi-index of the hi- 926 entry with an hi-targeted-to-uri that represents the Request-URI that 927 was retargeted. 929 The SIP entity MUST determine the specific parameter field to be 930 included in the hi-target-param, in the History-Info header field, as 931 the targets are added to the target set per the procedures in section 932 16.5 of [RFC3261] or per section 8.1.3.4 [RFC3261] in the case of 933 retargeting to a contact URI received in a 3xx response. In the 934 latter case, the specific header field parameter in the Contact 935 header field becomes the header field parameter that is used in the 936 hi-entry when the request is retargeted. If the Contact header field 937 does not contain an "rc" or "mp" header field parameter, then the SIP 938 entity MUST NOT include an "rc" or "mp" header field parameter in the 939 hi-target-param in the hi-entry when the request is retargeted to a 940 contact URI received in a 3xx response. This is because the redirect 941 server is the only element with any knowledge on how the target was 942 determined. Note, that the "np" header field parameter is not 943 applicable in the case of redirection. 945 The SIP entity (intermediary or redirect server) determines the 946 specific header field parameter ("rc", "mp" or "np") to be used based 947 on the following criteria: 949 o "rc": The Request-URI has changed while retaining the target user 950 associated with the original Request-URI prior to retargeting. 952 o "mp": The target was determined based on a mapping to a user other 953 than the target user associated with the Request-URI being 954 retargeted. 956 o "np": The target hasn't changed and the associated Request-URI 957 remained the same. 959 Note that there are two scenarios by which the "mp" header field 960 parameter can be derived. 962 o The mapping was done by the receiving entity on its own authority, 963 in which case the mp-value is the parent index of the hi-entry's 964 index. 966 o The mapping was done due to receiving a 3xx response, in which 967 case the mp-value is an earlier sibling or descendant of an 968 earlier sibling of the hi-entry's index, that of the downstream 969 request which received the 3xx response. 971 11. Application Considerations 973 History-Info provides a very flexible building block that can be used 974 by intermediaries and UAs for a variety of services. Prior to any 975 application usage of the History-Info header field parameters, the 976 SIP entity that processes the hi-entries MUST evaluate the hi- 977 entries. The SIP entity MUST be prepared to process effectively 978 messages whose hi-entries show evidence of "gaps", that is, 979 situations that reveal that not all of the forks of the request have 980 been recorded in the hi-entries. Gaps are possible if the request is 981 forwarded through intermediaries that do not support the History-Info 982 header field and are reflected by the existence of hi-entries with a 983 nonnegative integer of "0" e.g. "1.1.0.1". Gaps are also possible in 984 the case of parallel forking if there is an outstanding request at 985 the time the SIP entity sends a message. In addition, gaps may 986 introduce the possibility of duplicate values for the hi-index in the 987 case that a proxy that does not support History-Info forks a request. 988 If gaps are detected, the SIP entity MUST NOT treat this as an error, 989 but SHOULD indicate to any applications that there are gaps. The 990 interpretation of the information in the History-Info header field 991 depends upon the specific application; an application might need to 992 provide special handling in some cases where there are gaps. 994 The following describes some categories of information that 995 applications can use: 997 1. Complete history information - e.g., for debug or other 998 operational and management aspects, optimization of determining 999 targets to avoid retargeting to the same URI, etc. This 1000 information is relevant to proxies, UACs and UASs. 1002 2. Hi-entry with the index that matches the value of the "rc" header 1003 field parameter in the last hi-entry with a "rc" header field 1004 parameter in the Request received by a UAS - i.e., the last AOR 1005 that was retargeted to a contact based on an AOR-to-contact 1006 binding. 1008 3. Hi-entry with the index that matches the value of the "mp" header 1009 field parameter in the last hi-entry with a "mp" header field 1010 parameter in the hi-target-param in the Request received by a UAS 1011 - i.e., the last Request URI that was mapped to reach the 1012 destination. 1014 4. Hi-entry with the index that matches the value of the "rc" header 1015 field parameter in the first hi-entry with a "rc" header field 1016 parameter in the Request received by a UAS. Note, this would be 1017 the original AoR if all the entities involved support the 1018 History-Info header field and there is absence of an "mp" header 1019 field parameter prior to the "rc" header field parameter in the 1020 hi-target-param in the History-Info header field. However, there 1021 is no guarantee that all entities will support History-Info, thus 1022 the hi-entry that matches the value of the "rc" header field 1023 parameter of the first hi-entry with an "rc" header field 1024 parameter in the hi-target-param within the domain associated 1025 with the target URI at the destination is more likely to be 1026 useful. 1028 5. Hi-entry with the index that matches the value of "mp" header 1029 field parameter in the first hi-entry with an "mp" header field 1030 parameter in the Request received by a UAS. Note, this would be 1031 the original mapped URI if all entities supported the History- 1032 Info header field. However, there is no guarantee that all 1033 entities will support History-Info, thus the hi-entry that 1034 matches the value of the "mp" header field parameter of the first 1035 hi-entry with an "mp" header field parameter within the domain 1036 associated with the target URI at the destination is more likely 1037 to be useful. 1039 In many cases, applications are most interested in the information 1040 within a particular domain(s), thus only a subset of the information 1041 is required. 1043 Some applications may use multiple types of information. For 1044 example, an Automatic Call Distribution (ACD)/Call center application 1045 that utilizes the hi-entry which index matches the value of the "mp" 1046 header field parameter of the first hi-entry with an "mp" header 1047 field parameter, may also display other agents, reflected by other 1048 hi-entries prior to entries with hi-target value of "rc" header field 1049 parameter, to whom the call was targeted prior to its arrival at the 1050 current agent. This could allow the agent the ability to decide how 1051 they might forward or reroute the call if necessary (avoiding agents 1052 that were not previously available for whatever reason, etc.). 1054 Since support for History-Info header field is optional, a service 1055 MUST define default behavior for requests and responses not 1056 containing History-Info header fields. For example, an entity may 1057 receive an incomplete set of hi-entries or hi-entries which are not 1058 tagged appropriately with an hi-target-param in the case of entries 1059 added by entities that are only compliant to RFC4244. This may not 1060 impact some applications (e.g., debug), however, it could require 1061 some applications to make some default assumptions in this case. For 1062 example, in an ACD scenario, the application could select the oldest 1063 hi-entry with the domain associated with the ACD system and display 1064 that as the original called party. Depending upon how and where the 1065 request may have been retargeted, the complete list of agents to whom 1066 the call was targeted may not be available. 1068 12. Application Specific Usage 1070 The following are possible (non-normative) application-specific 1071 usages of History-Info. 1073 12.1. PBX Voicemail 1075 A voicemail system typically requires the original called party 1076 information to determine the appropriate mailbox so an appropriate 1077 greeting can be provided and the appropriate party notified of the 1078 message. 1080 The original target is determined by finding the first hi-entry 1081 tagged with "rc" and using the hi-entry referenced by the index of 1082 "rc" header field parameter as the target for determining the 1083 appropriate mailbox. This hi-entry is used to populate the "target" 1084 URI parameter as defined in [RFC4458] The VMS can look at the last 1085 hi-entry and find the target of the mailbox by looking at the URI 1086 entry in the "target" URI parameter in the hi-entry. 1088 This example usage does not work properly in the presence of 1089 forwarding that takes place before the call reaches the company in 1090 that case not the first hi-entry with an rc value, but the first hi- 1091 entry with an rc value following an mp entry needs to be picked. 1092 Further detail for this example can be found in the call flow 1093 entitled "PBX Voicemail Example" in 1094 [I-D.ietf-sipcore-rfc4244bis-callflows]. 1096 Note that in the case where there is no entry tagged with "rc", a VMS 1097 can follow the procedures, as defined in [RFC4458], for the 1098 "Interaction with Request History Information". 1100 12.2. Consumer Voicemail 1102 The voicemail system in these environment typically requires the last 1103 called party information to determine the appropriate mailbox so an 1104 appropriate greeting can be provided and the appropriate party 1105 notified of the message. 1107 The last target is determined by finding the hi-entry referenced by 1108 the index of last hi-entry tagged with "rc" for determining the 1109 appropriate mailbox. This hi-entry is used to populate the "target" 1110 URI parameter as defined in [RFC4458]. The VMS can look at the last 1111 hi-entry and find the target of the mailbox by looking for the 1112 "target" URI parameter in the hi-entry. Further detail for this 1113 example can be found in the call flow entitled "Consumer Voicemail 1114 Example" in [I-D.ietf-sipcore-rfc4244bis-callflows]. 1116 In the case where there is no entry tagged with "rc", a VMS can 1117 follow the procedures, as defined in [RFC4458], for the "Interaction 1118 with Request History Information". 1120 13. Security Considerations 1122 The security requirements for this specification are specified in 1123 Appendix A.1. 1125 This document defines a header field for SIP. The use of the 1126 Transport Layer Security (TLS) protocol [RFC5246] as a mechanism to 1127 ensure the overall confidentiality of the History-Info header fields 1128 (SEC-req-4) is strongly RECOMMENDED. If TLS is NOT used, the 1129 intermediary MUST ensure that the messages are only sent within an 1130 environment that is secured by other means or that the messages don't 1131 leave the intermediary's domain. This results in History-Info having 1132 at least the same level of security as other headers in SIP that are 1133 inserted by intermediaries. With TLS, History-Info header fields are 1134 no less, nor no more, secure than other SIP header fields, which 1135 generally have even more impact on the subsequent processing of SIP 1136 sessions than the History-Info header field. 1138 Note that while using the SIPS scheme (as per [RFC5630]) protects 1139 History-Info from tampering by arbitrary parties outside the SIP 1140 message path, all the intermediaries on the path are trusted 1141 implicitly. A malicious intermediary could arbitrarily delete, 1142 rewrite, or modify History-Info. This specification does not attempt 1143 to prevent or detect attacks by malicious intermediaries. 1145 In terms of ensuring the privacy of hi-entries, the same security 1146 considerations as those described in [RFC3323] apply. The privacy 1147 service that's defined in [RFC3323] MUST also support the new privacy 1148 header field priv-value of "history" and anonymize hi-entries in the 1149 case of a priv-value of "header" as described in Section 10.1.2. 1151 14. IANA Considerations 1153 This document requires several IANA registrations detailed in the 1154 following sections. 1156 This document obsoletes [RFC4244] but uses the same SIP header field 1157 name, Privacy header field and Option tag. The IANA registry needs 1158 to update the references to [RFC4244] with [RFC XXXX], where XXXX is 1159 the RFC number for this document. 1161 14.1. Registration of New SIP History-Info Header Field 1163 This document defines a SIP header field name: History-Info and an 1164 option tag: histinfo. The following updates have been made to 1165 http:///www.iana.org/assignments/sip-parameters. 1167 The following row has been updated in the header field section: 1169 Header Name Compact Form Reference 1170 ----------- ------------ --------- 1171 History-Info none [RFC XXXX] 1173 The following has been updated in the Options Tags section: 1175 Name Description Reference 1176 ---- ----------- --------- 1177 histinfo When used with the Supported header field, [RFC XXXX] 1178 this option tag indicates the UAC 1179 supports the History Information to be 1180 captured for requests and returned in 1181 subsequent responses. This tag is not 1182 used in a Proxy-Require or Require 1183 header field since support of 1184 History-Info is optional. 1186 Note to RFC Editor: Please replace RFC XXXX with the RFC number of 1187 this specification. 1189 14.2. Registration of "history" for SIP Privacy Header Field 1191 This document defines a priv-value for the SIP Privacy header field: 1192 history. The following updates have been made to 1193 http://www.iana.org/assignments/sip-priv-values. The following has 1194 been updated in the registration for the SIP Privacy header field: 1196 Name Description Registrant Reference 1197 ---- ----------- ---------- --------- 1198 history Privacy requested for Mary Barnes [RFC XXXX] 1199 History-Info header mary.ietf.barnes@gmail.com 1200 fields(s) 1202 Note to RFC Editor: Please replace RFC XXXX with the RFC number of 1203 this specification. 1205 14.3. Registration of Header Field Parameters 1207 This specification defines the following new SIP header field 1208 parameters in the SIP Header Field parameter sub-registry in the SIP 1209 Parameter Registry, http:/www.iana.org/assignments/sip-parameters. 1211 Header Field Parameter Name Predefined Reference 1212 Values 1213 ____________________________________________________________________ 1214 History-Info mp No [RFC xxxx] 1215 History-Info rc No [RFC xxxx] 1216 History-Info np No [RFC xxxx] 1217 Contact mp No [RFC xxxx] 1218 Contact rc No [RFC xxxx] 1219 Contact np No [RFC xxxx] 1221 Note to RFC Editor: Please replace RFC XXXX with the RFC number of 1222 this specification. 1224 15. Acknowledgements 1226 Jonathan Rosenberg et al produced the document that provided 1227 additional use cases precipitating the requirement for the new header 1228 parameters to capture the method by which a Request URI is 1229 determined. The authors would like to acknowledge the constructive 1230 feedback provided by Ian Elz, Paul Kyzivat, John Elwell, Hadriel 1231 Kaplan, Marianne Mohali, Brett Tate, and Dale Worley. John Elwell 1232 also provided excellent suggestions in terms of document structure. 1233 Dan Romascanu performed the Gen-ART review. 1235 Mark Watson, Cullen Jennings and Jon Peterson provided significant 1236 input into the initial work that resulted in the development of of 1237 [RFC4244]. The editor would like to acknowledge the constructive 1238 feedback provided by Robert Sparks, Paul Kyzivat, Scott Orton, John 1239 Elwell, Nir Chen, Palash Jain, Brian Stucker, Norma Ng, Anthony 1240 Brown, Jayshree Bharatia, Jonathan Rosenberg, Eric Burger, Martin 1241 Dolly, Roland Jesske, Takuya Sawada, Sebastien Prouvost, and 1242 Sebastien Garcin in the development of [RFC4244]. 1244 The editor would like to acknowledge the significant input from Rohan 1245 Mahy on some of the normative aspects of the ABNF for [RFC4244], 1246 particularly around the need for and format of the index and around 1247 the security aspects. 1249 16. Changes from RFC 4244 1251 This RFC replaces [RFC4244]. 1253 Deployment experience with [RFC4244] over the years has shown a 1254 number of issues, warranting an update: 1256 o In order to make [RFC4244] work in "real life", one needs to make 1257 "assumptions" on how History-Info is used. For example, many 1258 implementations filter out many entries, and only leave specific 1259 entries corresponding, for example, to first and last redirection. 1260 Since vendors uses different rules, it causes significant 1261 interoperability issues. 1263 o [RFC4244] is overly permissive and evasive about recording 1264 entries, causing interoperability issues. 1266 o The examples in the call flows had errors, and confusing because 1267 they often assume "loose routing". 1269 o [RFC4244] has lots of repetitive and unclear text due to the 1270 combination of requirements with solution. 1272 o [RFC4244] gratuitously mandates the use of TLS on every hop. No 1273 existing implementation enforces this rule, and instead, the use 1274 of TLS or not is a general SIP issue, not an [RFC4244] issue per 1275 se. 1277 o [RFC4244] does not include clear procedures on how to deliver 1278 current target URI information to the UAS when the Request-URI is 1279 replaced with a contact. 1281 o [RFC4244] does not allow for marking History-Info entries for easy 1282 processing by User Agents. 1284 The following summarizes the functional changes between this 1285 specification and [RFC4244]: 1287 1. Added header field parameters to capture the specific method by 1288 which a target is determined to facilitate processing by users of 1289 the History-Info header field entries. A specific header field 1290 parameter is captured for each of the target URIs as the target 1291 set is determined (per section 16.5 of [RFC3261]). The header 1292 field parameter is used in both the History-Info and the Contact 1293 header fields. 1295 2. Added a way to indicate a gap in History-Info by adding a non- 1296 negative integer of "0". 1298 3. Rather than recommending that entries be removed in the case of 1299 certain values of the Privacy header field, the entries are 1300 anonymized. 1302 4. Updated the security section to be equivalent to the security 1303 recommendations for other SIP header fields inserted by 1304 intermediaries. 1306 5. Removed Appendix B since a separate call flow document is being 1307 published as a companion to this document. 1309 The first 2 changes are intended to facilitate application usage of 1310 the History-Info header field and eliminate the need to make 1311 assumptions based upon the order of the entries and ensure that the 1312 most complete set of information is available to the applications. 1314 In addition, editorial changes were done to both condense and clarify 1315 the text, moving the requirements to an appendix and removing the 1316 inline references to the requirements. The examples were simplified 1317 and updated to reflect the protocol changes. Several of the call 1318 flows in the appendix were removed and put into a separate document 1319 that includes additional use cases that require the new header field 1320 parameters. 1322 16.1. Backwards compatibility 1324 This specification is backwards compatible since [RFC4244] allows for 1325 the addition of new optional parameters. This specification adds an 1326 optional SIP header field parameter to the History-Info and Contact 1327 header fields. Entities that have not implemented this specification 1328 will ignore these parameters, however, per [RFC4244] an entity will 1329 not remove these parameters from an hi-entry. While entities 1330 compliant to this document and [RFC4244] must be able to recognize 1331 gaps in the hi-entries, this document requires that an index of "0" 1332 be used in this case. Whereas [RFC4244] recommended (but did not 1333 require) the use of "1". However, since the ABNF in [RFC4244] 1334 defines the index as a DIGIT, "0" would be a valid value, thus an 1335 [RFC4244] implementation should not have an issue if it receives hi- 1336 entries added by intermediaries compliant to this document. 1338 As for the behavior of the UACs, UASs and intermediaries, the 1339 following additional normative changes have been made: 1341 UAC behavior 1343 1. Inclusion of option tag by UAC has changed from SHOULD to MUST. 1345 2. Inclusion of hi-target-entry along with hi-index has changed from 1346 MAY/RECOMMEND to MUST/MUST. 1348 3. Behavior surrounding the addition of hi-target-entry based on 3xx 1349 response has changed from MAY/SHOULD to MUST. 1351 None of the behavior changes would cause any backward or forward 1352 compatibility issues. 1354 UAS behavior 1356 1. Inclusion of hi-entry in response has changed from SHOULD to 1357 MUST. 1359 As the entity receiving response with hi-entry expected it with 1360 SHOULD, this change will not cause any backward compatibility issues. 1362 Proxy/Redirect Server behavior 1364 1. Inclusion of H-I as forwarding the request has changed from 1365 SHOULD to MUST. 1367 2. Association of Reason with time-out/internal reason has changed 1368 from MAY to MUST. 1370 3. Inclusion of hi-index has changed from RECOMMENDED to MUST. 1372 4. Inclusion of hi-entries in response has changed from SHOULD to 1373 MUST. 1375 None of above behavior changes impact backwards compatibility since 1376 they only strengthen normative behavior to improve interoperability. 1378 In cases where an entity that is compliant to this document, receives 1379 a request that contains hi-entries compliant only to RFC4244 (i.e, 1380 the hi-entries do not contain any of the new header field 1381 parameters), the entity MUST NOT add any of the new header field 1382 parameters to the hi-entries. The hi-entries MUST be cached and 1383 forwarded as any other entries are as specified in Section 9.1. As 1384 with RFC4244 compliant entities, applications must be able to 1385 function in cases of missing information, as specified in Section 11. 1387 17. References 1388 17.1. Normative References 1390 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1391 A., Peterson, J., Sparks, R., Handley, M., and E. 1392 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1393 June 2002. 1395 [RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason 1396 Header Field for the Session Initiation Protocol (SIP)", 1397 RFC 3326, December 2002. 1399 [RFC3323] Peterson, J., "A Privacy Mechanism for the Session 1400 Initiation Protocol (SIP)", RFC 3323, November 2002. 1402 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1403 Requirement Levels", BCP 14, RFC 2119, March 1997. 1405 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1406 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1408 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1409 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1411 [RFC4244] Barnes, M., "An Extension to the Session Initiation 1412 Protocol (SIP) for Request History Information", RFC 4244, 1413 November 2005. 1415 17.2. Informative References 1417 [RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User 1418 Agent URIs (GRUUs) in the Session Initiation Protocol 1419 (SIP)", RFC 5627, October 2009. 1421 [RFC5630] Audet, F., "The Use of the SIPS URI Scheme in the Session 1422 Initiation Protocol (SIP)", RFC 5630, October 2009. 1424 [RFC3087] Campbell, B. and R. Sparks, "Control of Service Context 1425 using SIP Request-URI", RFC 3087, April 2001. 1427 [RFC4240] Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network 1428 Media Services with SIP", RFC 4240, December 2005. 1430 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", 1431 RFC 3966, December 2004. 1433 [RFC4458] Jennings, C., Audet, F., and J. Elwell, "Session 1434 Initiation Protocol (SIP) URIs for Applications such as 1435 Voicemail and Interactive Voice Response (IVR)", RFC 4458, 1436 April 2006. 1438 [I-D.ietf-sipcore-rfc4244bis-callflows] 1439 Barnes, M., Audet, F., Schubert, S., Elburg, H., and C. 1440 Holmberg, "Session Initiation Protocol (SIP) History-Info 1441 Header Call Flow Examples", 1442 draft-ietf-sipcore-rfc4244bis-callflows-06 (work in 1443 progress), July 2013. 1445 Appendix A. Request History Requirements 1447 The following list constitutes a set of requirements for a "Request 1448 History" capability. 1450 1. CAPABILITY-req: The "Request History" capability provides a 1451 capability to inform proxies and UAs involved in processing a 1452 request about the history/progress of that request. Although 1453 this is inherently provided when the retarget is in response to a 1454 SIP redirect, it is deemed useful for non-redirect retargeting 1455 scenarios, as well. 1457 2. GENERATION-req: "Request History" information is generated when 1458 the request is retargeted. 1460 A. In some scenarios, it might be possible for more than one 1461 instance of retargeting to occur within the same proxy. A 1462 proxy MUST also generate Request History information for the 1463 'internal retargeting'. 1465 B. An entity (UA or proxy) retargeting in response to a redirect 1466 or REFER MUST include any Request History information from 1467 the redirect/REFER in the new request. 1469 3. ISSUER-req: "Request History" information can be generated by a 1470 UA or proxy. It can be passed in both requests and responses. 1472 4. CONTENT-req: The "Request History" information for each 1473 occurrence of retargeting shall include the following: 1475 A. The new URI or address to which the request is in the process 1476 of being retargeted, 1478 B. The URI or address from which the request was retargeted, and 1479 whether the retarget URI was an AOR 1481 C. The mechanism by which the new URI or address was determined, 1482 D. The reason for the Request-URI or address modification, 1484 E. Chronological ordering of the Request History information. 1486 5. REQUEST-VALIDITY-req: Request History is applicable to requests 1487 not sent within an early or established dialog (e.g., INVITE, 1488 REGISTER, MESSAGE, and OPTIONS). 1490 6. BACKWARDS-req: Request History information may be passed from the 1491 generating entity backwards towards the UAC. This is needed to 1492 enable services that inform the calling party about the dialog 1493 establishment attempts. 1495 7. FORWARDS-req: Request History information may also be included by 1496 the generating entity in the request, if it is forwarded onwards. 1498 A.1. Security Requirements 1500 The Request History information is being inserted by a network 1501 element retargeting a Request, resulting in a slightly different 1502 problem than the basic SIP header problem, thus requiring specific 1503 consideration. It is recognized that these security requirements can 1504 be generalized to a basic requirement of being able to secure 1505 information that is inserted by proxies. 1507 The potential security problems include the following: 1509 1. A rogue application could insert a bogus Request History-Info 1510 entry either by adding an additional hi-entry as a result of 1511 retargeting or entering invalid information. 1513 2. A rogue application could re-arrange the Request History 1514 information to change the nature of the end application or to 1515 mislead the receiver of the information. 1517 3. A rogue application could delete some or all of the Request 1518 History information. 1520 Thus, a security solution for "Request History" must meet the 1521 following requirements: 1523 1. SEC-req-1: The entity receiving the Request History must be able 1524 to determine whether any of the previously added Request History 1525 content has been altered. 1527 2. SEC-req-2: The ordering of the Request History information must 1528 be preserved at each instance of retargeting. 1530 3. SEC-req-3: The entity receiving the information conveyed by the 1531 Request History must be able to authenticate the entity providing 1532 the request. 1534 4. SEC-req-4: To ensure the confidentiality of the Request History 1535 information, only entities that process the request SHOULD have 1536 visibility to the information. 1538 It should be noted that these security requirements apply to any 1539 entity making use of the Request History information. 1541 A.2. Privacy Requirements 1543 Since the Request-URI that is captured could inadvertently reveal 1544 information about the originator, there are general privacy 1545 requirements that MUST be met: 1547 1. PRIV-req-1: The entity retargeting the Request must ensure that 1548 it maintains the network-provided privacy (as described in 1549 [RFC3323]) associated with the Request as it is retargeted. 1551 2. PRIV-req-2: The entity receiving the Request History must 1552 maintain the privacy associated with the information. In 1553 addition, local policy at a proxy may identify privacy 1554 requirements associated with the Request-URI being captured in 1555 the Request History information. 1557 3. PRIV-req-3: Request History information subject to privacy shall 1558 not be included in out going messages unless it is protected as 1559 described in [RFC3323]. 1561 Authors' Addresses 1563 Mary Barnes 1564 Polycom 1565 TX 1566 US 1568 Email: mary.ietf.barnes@gmail.com 1570 Francois Audet 1571 Skype 1573 Email: francois.audet@skype.net 1574 Shida Schubert 1575 NTT 1577 Email: shida@ntt-at.com 1579 Hans Erik van Elburg 1580 Detecon International Gmbh 1581 Sternengasse 14-16 1582 Cologne, 1583 Germany 1585 Email: ietf.hanserik@gmail.com 1587 Christer Holmberg 1588 Ericsson 1589 Hirsalantie 11, Jorvas 1590 Finland 1592 Email: christer.holmberg@ericsson.com