idnits 2.17.1 draft-ietf-sip-history-info-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 2251. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2231. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 2243), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 37. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 5 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 422 has weird spacing: '...r field whe...' == Line 2120 has weird spacing: '...changed occur...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: This document defines a new header for SIP. The document strongly RECOMMENDs the use of the Transport Layer Security (TLS) protocol [RFC2246] as a mandatory mechanism to ensure the overall confidentiality of the History-Info headers (SEC-req-4). This results in History-Info having at least the same level of security as other headers in SIP which are inserted by intermediaries. If TLS is not available for the connection over which the request is being forwarded, then the request MUST not include the History-Info header or the request MUST be redirected to the client, including the History-Info header, so that the request can be retargeted by the client. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: 3.3 Ensuring the Privacy of History-Info Since the History-Info header can inadvertently reveal information about the requestor as described in [RFC3323], the Privacy header SHOULD be used to determine whether an intermediary can include the History-Info header in a Request that it receives and forwards (PRIV-req-2) or that it retargets (PRIV-req-1). Thus, the History-Info header SHOULD not be included in Requests where the requestor has indicated a priv-value of Session or Header level privacy. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: For scenarios whereby calls might overflow from the Silver to the Gold, clearly the alternate group identification, internal routing or actual agent that handles the call SHOULD not be sent to UA1, thus for this scenario, one would expect that the Proxy would not support the sending of the History-Info in the response, even if requested by the calling UA. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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 3323' is mentioned on line 392, but not defined == Missing Reference: 'RFCXXXX' is mentioned on line 1156, but not defined == Missing Reference: 'RFC 3665' is mentioned on line 1912, but not defined == Unused Reference: 'RFC2234' is defined on line 1173, but no explicit reference was found in the text == Unused Reference: 'SIPSVCEX' is defined on line 1181, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346) == Outdated reference: A later version (-15) exists of draft-ietf-sipping-service-examples-07 Summary: 10 errors (**), 0 flaws (~~), 13 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT M. Barnes 2 Document: draft-ietf-sip-history-info-06.txt Editor 3 Category: Standards Track Nortel Networks 5 Expires: July 17th, 2005 Jan 17th, 2005 7 An Extension to the Session Initiation Protocol for Request History 8 Information 10 Status of this Memo 12 By submitting this Internet-Draft, I certify that any applicable 13 patent or other IPR claims of which I am aware have been disclosed, 14 and any of which I become aware will be disclosed, in accordance with 15 RFC 3668. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on July 17th, 2005. 35 Copyright Notice 37 Copyright (C) The Internet Society (2005). All Rights Reserved. 39 Abstract 41 This document defines a standard mechanism for capturing the history 42 information associated with a SIP request. This capability enables 43 many enhanced services by providing the information as to how and why 44 a call arrives at a specific application or user. This document 45 defines a new optional SIP header, History-Info, for capturing the 46 history information in requests. 48 Table of Contents 50 1.Background: Why define a Generic "Request History" capability?.3 51 2. "Request History" Requirements.................................4 52 2.1 Security Requirements......................................5 53 2.2 Privacy Requirements.......................................6 54 3. Request History Information Description........................7 55 3.1 Optionality of History-Info................................8 56 3.2 Securing History-Info......................................8 57 3.3 Ensuring the Privacy of History-Info.......................8 58 4 Request History Information Protocol Details....................9 59 4.1 Protocol Structure of History-Info.........................9 60 4.2 Protocol Examples.........................................11 61 4.3 Protocol usage............................................11 62 4.4 Security for History-Info.................................18 63 4.5 Example Applications using History-Info...................18 64 5. Application Considerations....................................23 65 6. Security Considerations.......................................24 66 7. IANA Considerations...........................................24 67 Normative References.............................................25 68 Informational References.........................................25 69 Appendix. Example Scenarios......................................27 70 Appendix A. Sequentially forking (History-Info in Response)......27 71 Appendix B. Voicemail...........................................32 72 Appendix C. Automatic Call Distribution Example.................38 73 Appendix D. Session via Redirect and Proxy Servers...............39 75 Overview 77 Many services that SIP is anticipated to support require the ability 78 to determine why and how the call arrived at a specific application. 79 Examples of such services include (but are not limited to) sessions 80 initiated to call centers via "click to talk" SIP Uniform Resource 81 Locators (URLs) on a web page, "call history/logging" style services 82 within intelligent "call management" software for SIP User Agents 83 (UAs) and calls to voicemail servers. While SIP implicitly provides 84 the redirect/retarget capabilities that enable calls to be routed to 85 chosen applications, there is currently no standard mechanism within 86 SIP for communicating the history of such a request. This "request 87 history" information allows the receiving application to determine 88 hints about how and why the call arrived at the application/user. 90 This document defines a new SIP header, History-Info, to provide a 91 standard mechanism for capturing the request history information to 92 enable a wide variety of services for networks and end users. The 93 History-Info header provides a building block for development of new 94 services. 96 Section 1 provides additional background motivation for the Request 97 History capability. Section 2 identifies the requirements for a 98 solution, with Section 3 providing an overall description of the 99 solution. 101 Section 4 provides the details of the additions to the SIP protocol. 102 Example uses of the new header are included in Section 4.5, with 103 additional scenarios included in the Appendix. 105 Section 5 summarizes the application considerations identified in the 106 previous sections. Section 6 summarizes the security solution. 108 Conventions used in this document 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in RFC 2119 [RFC2119]. 114 1.Background: Why define a Generic "Request History" capability? 116 SIP implicitly provides redirect/retarget capabilities that enable 117 calls to be routed to specific applications as defined in [RFC3261]. 118 The term 'retarget' will be used henceforth in this document to refer 119 to the process of a Proxy Server/User Agent Client (UAC) changing a 120 Uniform Resource Identifier(URI) in a request and thus changing the 121 target of the request. This term is chosen to avoid associating this 122 request history only with the specific SIP Redirect Server capability 123 that provides for a response to be sent back to a UAC requesting that 124 the UAC should retarget the original request to an alternate URI. 125 The rules for determining request targets as described in section 126 16.5 of [RFC3261] are consistent with the use of the retarget term in 127 this document. 129 The motivation for the request history is that in the process of 130 retargeting old routing information can be forever lost. This lost 131 information may be important history that allows elements to which 132 the call is retargeted to process the call in a locally defined, 133 application specific manner. The proposal in this document is to 134 provide a mechanism for transporting the request history. It is not 135 proposing any application specific behavior for a Proxy or UA upon 136 receipt of the information. Indeed, such behavior should be a local 137 decision for the recipient application. 139 Current network applications provide the ability for elements 140 involved with the call to exchange additional information relating to 141 how and why the call was routed to a particular destination. The 142 following are examples of such applications: 144 1. Web "referral" applications, whereby an application residing 145 within a web server determines that a visitor to a website has 146 arrived at the site via an "associate" site which will receive 147 some "referral" commission for generating this traffic, 149 2. Email forwarding whereby the forwarded-to user obtains a "history" 150 of who sent the email to whom and at what time 152 3. Traditional telephony services such as Voicemail, call-center 153 "automatic call distribution", and "follow-me" style services. 155 Several of the aforementioned applications currently define 156 application specific mechanisms through which it is possible to 157 obtain the necessary history information. 159 In addition, request history information could be used to enhance 160 basic SIP functionality by providing the following: 162 o Some diagnostic information for debugging SIP requests. 164 o A stronger security solution for SIP. A side effect is that each 165 proxy which captures the "request history" information in a secure 166 manner provides an additional means (without requiring signed 167 keys) for the original requestor to be assured that the request 168 was properly retargeted. 170 2. "Request History" Requirements 172 The following list constitutes a set of requirements for a "Request 173 History" capability. 175 1) CAPABILITY-req: The "Request History" capability provides a 176 capability to inform proxies and UAs involved in processing a request 177 about the history/progress of that request. While this is inherently 178 provided when the retarget is in response to a SIP redirect, it is 179 deemed useful for non-redirect retargeting scenarios, as well. 181 2) OPTIONALITY-req: The "Request History" information is optional. 183 2.1) In many cases, it is anticipated that whether the history is 184 added to the Request would be a local policy decision enforced by the 185 specific application, thus no specific protocol element is needed. 187 2.2) Due to the capability being "optional" from the SIP protocol 188 perspective, the impact to an application of not having the "Request 189 History" must be described. Applicability guidelines to be addressed 190 by applications using this capability must be provided as part of the 191 solution to these requirements. 193 3) GENERATION-req: "Request History" information is generated when 194 the request is retargeted. 196 3.1) In some scenarios, it might be possible for more than one 197 instance of retargeting to occur within the same Proxy. A proxy 198 should also generate Request History information for the 'internal 199 retargeting'. 201 3.2) An entity (UA or proxy) retargeting in response to a redirect or 202 REFER should include any Request History information from the 203 redirect/REFER in the new request. 205 4) ISSUER-req: "Request History" information can be generated by a UA 206 or proxy. It can be passed in both requests and responses. 208 5) CONTENT-req: The "Request History" information for each 209 occurrence of retargeting, shall include the following: 211 5.1) The new URI or address to which the request is in the process 212 of being retargeted, 214 5.2) The URI or address from which the request was retargeted, 216 5.3) The reason for the Request-URI or address modification, 218 5.4) Chronological ordering of the Request History information. 220 6) REQUEST-VALIDITY-req: Request-History is applicable to requests 221 not sent within an established dialog. (e.g. INVITE, REGISTER, 222 MESSAGE, and OPTIONS). 224 7) BACKWARDS-req: Request-History information may be passed from the 225 generating entity backwards towards the UAC. This is needed to enable 226 services that inform the calling party about the dialog establishment 227 attempts. 229 8) FORWARDS-req: Request-History information may also be included by 230 the generating entity in the request, if it is forwarded onwards. 232 2.1 Security Requirements 234 The Request History information is being inserted by a network 235 element retargeting a Request, resulting in a slightly different 236 problem than the basic SIP header problem, thus requiring specific 237 consideration. It is recognized that these security requirements can 238 be generalized to a basic requirement of being able to secure 239 information that is inserted by proxies. 241 The potential security problems include the following: 242 1) A rogue application could insert a bogus Request History entry 243 either by adding an additional entry as a result of retargeting or 244 entering invalid information. 246 2) A rogue application could re-arrange the Request History 247 information to change the nature of the end application or to mislead 248 the receiver of the information. 250 Thus, a security solution for "Request History" must meet the 251 following requirements: 253 1) SEC-req-1: The entity receiving the Request History must be able 254 to determine whether any of the previously added Request History 255 content has been altered. 257 2) SEC-req-2: The ordering of the Request History information must be 258 preserved at each instance of retargeting. 260 3) SEC-req-3: The entity receiving the information conveyed by the 261 Request History must be able to authenticate the source of the 262 information. 264 4) SEC-req-4: To ensure the confidentiality of the Request History 265 information, only entities which process the request should have 266 visibility to the information. 268 It should be noted that these security requirements apply to any 269 entity making use of the Request History information, either by 270 retargeting and capturing the information, or as an application 271 making use of the information received in either a Request or 272 Response. 274 2.2 Privacy Requirements 276 Since the Request URI that is captured could inadvertently reveal 277 information about the originator, there are general privacy 278 requirements that MUST be met: 280 1) PRIV-req-1: The entity retargeting the Request must ensure that it 281 maintains the network-provided privacy (as described in [RFC3323]) 282 associated with the Request as it is retargeted. 284 2) PRIV-req-2: The entity receiving the Request History must maintain 285 the privacy associated with the information. 287 In addition, local policy at a proxy may identify privacy 288 requirements associated with the Request URI being captured in the 289 Request History information. 291 3) PRIV-req-3: Request History information subject to privacy 292 requirements shall not be included in outgoing messages unless it is 293 protected as described in [RFC3323]. 295 3. Request History Information Description 297 The fundamental functionality provided by the request history 298 information is the ability to inform proxies and UAs involved in 299 processing a request about the history or progress of that request 300 (CAPABILITY-req). The solution is to capture the Request-URIs as a 301 request is forwarded in a new header for SIP messages: History-Info 302 (CONTENT-req). This allows for the capturing of the history of a 303 request that would be lost with the normal SIP processing involved in 304 the subsequent forwarding of the request. This solution proposes no 305 changes in the fundamental determination of request targets or in the 306 request forwarding as defined in sections 16.5 and 16.6 of the SIP 307 protocol specification [RFC3261]. 309 The History-Info header can appear in any request not associated with 310 an established dialog (e.g. INVITE, REGISTER, MESSAGE, REFER and 311 OPTIONS, PUBLISH and SUBSCRIBE, etc.) (REQUEST-VALIDITY-req) and any 312 valid response to these requests. (ISSUER-req) 314 The History-Info header is added to a Request when a new request is 315 created by a UAC or forwarded by a Proxy, or when the target of a 316 request is changed. The term 'retarget' is introduced to refer to 317 this changing of the target of a request and the subsequent 318 forwarding of that request. It should be noted that retargeting only 319 occurs when the Request-URI indicates a domain for which the 320 processing entity is responsible. In terms of the SIP protocol, the 321 processing associated with retargeting is described in sections 16.5, 322 and 16.6 of [RFC3261]. As described in section 16.5 of [RFC3261], it 323 is possible for the target of a request to be changed by the same 324 proxy multiple times (referred to as 'internal retargeting' in 325 section 2), as the proxy MAY add targets to the target set after 326 beginning Request Forwarding. Section 16.6 of [RFC3261] describes 327 Request Forwarding. It is during this process of Request Forwarding, 328 that the History Information is captured as an optional, additional 329 header field. Thus, the addition of the History-Info header does not 330 impact fundamental SIP Request Forwarding. An entity (UA or proxy) 331 changing the target of a request in response to a redirect or REFER 332 SHOULD also propagate any History-Info header from the initial 333 Request in the new request (GENERATION-req, FORWARDS-req). 335 3.1 Optionality of History-Info 337 The History-Info header is optional in that neither UAs nor Proxies 338 are required to support it. A new Supported header, "histinfo", is 339 included in the Request to indicate whether the History-Info header 340 is returned in Responses (BACKWARDS-req). In addition to the 341 "histinfo" Supported header, local policy determines whether or not 342 the header is added to any request, or for a specific Request-URI, 343 being retargeted. It is possible that this could restrict the 344 applicability of services which make use of the Request History 345 Information to be limited to retargeting within domain(s) controlled 346 by the same local policy, or between domain(s) which negotiate 347 policies with other domains to ensure support of the given policy, or 348 services for which complete History Information isn't required to 349 provide the service. (OPTIONALITY-req) All applications making use 350 of the History-info header MUST clearly define the impact of the 351 information not being available and specify the processing of such a 352 request. 354 3.2 Securing History-Info 356 This document defines a new header for SIP. The document strongly 357 RECOMMENDs the use of the Transport Layer Security (TLS) protocol 358 [RFC2246] as a mandatory mechanism to ensure the overall 359 confidentiality of the History-Info headers (SEC-req-4). This results 360 in History-Info having at least the same level of security as other 361 headers in SIP which are inserted by intermediaries. If TLS is not 362 available for the connection over which the request is being 363 forwarded, then the request MUST not include the History-Info header 364 or the request MUST be redirected to the client, including the 365 History-Info header, so that the request can be retargeted by the 366 client. 368 With the level of security provided by TLS (SEC-req-3), the 369 information in the History-Info header can thus be evaluated to 370 determine if information has been removed by evaluating the indices 371 for gaps (SEC-req-1, SEC-req-2). It would be up to the application 372 to define whether it can make use of the information in the case of 373 missing entries. 375 3.3 Ensuring the Privacy of History-Info 376 Since the History-Info header can inadvertently reveal information 377 about the requestor as described in [RFC3323], the Privacy header 378 SHOULD be used to determine whether an intermediary can include the 379 History-Info header in a Request that it receives and forwards (PRIV- 380 req-2) or that it retargets (PRIV-req-1). Thus, the History-Info 381 header SHOULD not be included in Requests where the requestor has 382 indicated a priv-value of Session or Header level privacy. 384 In addition, the History-Info header can reveal general routing 385 information, which may be viewed by a specific intermediary or 386 network, to be subject to privacy restrictions. Thus, local policy 387 MAY also be used to determine whether to include the History-Info 388 header at all, whether to capture a specific Request-URI in the 389 header, or whether it be included only in the Request as it is 390 retargeted within a specific domain (PRIV-req-3). In the latter 391 case, this is accomplished by adding a new priv-value, history, to 392 the Privacy header [RFC 3323] indicating whether any or a specific 393 History-Info header(s) SHOULD be forwarded. 395 It is recognized that satisfying the privacy requirements can impact 396 the functionality of this solution by overriding the request to 397 generate the information. As with the optionality and security 398 requirements, applications making use of History-Info SHOULD address 399 any impact this may have or MUST explain why it does not impact the 400 application. 402 4 Request History Information Protocol Details 404 This section contains the details and usage of the proposed new SIP 405 protocol elements. It also discusses the security aspects of the 406 solution. 408 4.1 Protocol Structure of History-Info 410 History-Info is a header field as defined by [RFC3261]. It is an 411 optional header field and MAY appear in any request or response not 412 associated with a dialog or which starts a dialog. For example, 413 History-Info MAY appear in INVITE, REGISTER, MESSAGE, REFER, OPTIONS, 414 SUBSCRIBE and PUBLISH and any valid responses, plus NOTIFY requests 415 which initiate a dialog. 417 This document adds the following entry to Table 2 of [RFC3261]. The 418 additions to this table are also provided for extension methods at 419 the time of publication of this document. This is provided as a 420 courtesy to the reader and is not normative in any way. 422 Header field where proxy ACK BYE CAN INV OPT REG MSG 423 ------------ ----- ----- --- --- --- --- --- --- --- 424 History-Info amdr - - - o o o o 425 SUB NOT REF INF UPD PRA PUB 426 --- --- --- --- --- --- --- 427 History-Info amdr o o o - - - o 429 The History-Info header carries the following information, with the 430 mandatory parameters required when the header is included in a 431 request or response: 433 o Targeted-to-URI (hi-targeted-to-uri): A mandatory parameter for 434 capturing the Request URI for the specific Request as it is 435 forwarded. 437 o Index (hi-index): A mandatory parameter for History-Info 438 reflecting the chronological order of the information, indexed 439 to also reflect the forking and nesting of requests. The format 440 for this parameter is a string of digits, separated by dots to 441 indicate the number of forward hops and retargets. This results 442 in a tree representation of the history of the request, with the 443 lowest level index reflecting a branch of the tree. By adding 444 the new entries in order (i.e. following existing entries per 445 the details in section 4.3.3.1), including the index and 446 securing the header, the ordering of the History-info headers in 447 the request is assured (SEC-req-2). In addition, applications 448 may extract a variety of metrics (total number of retargets, 449 total number of retargets from a specific branch, etc.) based 450 upon the index values. 452 o Reason: An optional parameter for History-info, reflected in the 453 History-Info header by including the Reason Header [RFC3326] 454 escaped in the hi-targeted-to-uri. A reason is not included for 455 a hi-targeted-to-uri when it is first added in a History-info 456 header, but rather is added when the retargeting actually 457 occurs. Note, that this does appear to complicate the security 458 problem, however, retargeting only occurs when the hi-targeted- 459 to-uri indicates a domain for which the processing entity is 460 responsible, thus it would be the same processing entity that 461 initially added the hi-targeted-to-URI to the header that would 462 be updating it with the Reason. 464 o Privacy: An optional parameter for History-info, reflected in 465 the History-Info header field values by including the Privacy 466 Header [RFC3323] with a priv-value of "history" escaped in the 467 hi-targeted-to-uri or by adding the Privacy header with a priv- 468 value of "history" to the Request. The use of the Privacy 469 Header with a priv-value of "history" indicates whether a 470 specific or all History-Info headers should not be forwarded. 472 o Extension (hi-extension): An optional parameter to allow for 473 future optional extensions. As per the [RFC3261], any 474 implementation not understanding an extension should ignore it. 476 The following summarizes the syntax of the History-Info header, based 477 upon the standard SIP syntax [RFC3261]: 479 History-Info = "History-Info" HCOLON 481 hi-entry *(COMMA hi-entry) 483 hi-entry = hi-targeted-to-uri *( SEMI hi-param ) 485 hi-targeted-to-uri= name-addr 487 hi-param = hi-index / hi-extension 489 hi-index = "index" EQUAL 1*DIGIT *(DOT 1*DIGIT) 491 hi-extension = generic-param 493 4.2 Protocol Examples 495 The following provides some examples of the History-Info header. Note 496 that the backslash and CRLF between the fields in the examples below 497 are for readability purposes only. 499 History-Info:;index=1;foo=bar 502 History-Info: ; index=1.1, 504 ;index=1.2, 506 ;index=1.3 508 4.3 Protocol usage 510 This section describes the processing specific to UAs and Proxies for 511 the History-Info header, the "histinfo" option tag and the priv-value 512 of "history". As discussed in section 1, the fundamental objective is 513 to capture the target Request-URIs as a request is forwarded. This 514 allows for the capturing of the history of a request that would be 515 lost due to subsequent (re)targeting and forwarding. To accomplish 516 this for the entire history of a request, either the UAC must capture 517 the Request-URI in a History-Info header in the initial request or a 518 proxy must add a History-Info header with both an hi-entry for the 519 Request-URI in the initial request and an hi-entry for the target 520 Request-URI as the request is forwarded. The basic processing is for 521 each entity forwarding a request to add an hi-entry for the target 522 Request-URI, updating the index and adding the Reason as appropriate 523 for any retargeted Request-URI. 525 4.3.1 User Agent Client (UAC) Behavior 527 The UAC SHOULD include the "histinfo" option tag in the Supported 528 header in any request not associated with an established dialog for 529 which the UAC would like the History-Info header in the Response. In 530 addition, the UAC SHOULD initiate the capturing of the History 531 Information by adding a History-Info header, using the Request-URI of 532 the request as the hi-targeted-to-uri and initializing the index to 533 the RECOMMENDED value of 1 in the hi-entry. 535 In the case where the request is routed to a redirect server and the 536 UAC receives a 3xx response with a Contact header, the UAC MAY 537 maintain the previous hi-entry(s) in the request. In this case, the 538 reason header SHOULD be associated with the hi-targeted-to-uri in the 539 previous (last) hi-entry, as described in section 4.3.3.1.2. A new 540 hi-entry MAY then be added for the URI from the Contact header (which 541 becomes the new Request-URI). In this case, the index is created by 542 reading and incrementing the value of the index from the previous hi- 543 entry, thus following the same rules as those prescribed for a proxy 544 in retargeting, described in section 4.3.3.1.3. An example of this 545 scenario can be found in Appendix D. 547 A UAC that does not want the History-Info header added due to privacy 548 considerations SHOULD include a Privacy header with a priv-value(s) 549 of "session", "header" or "history" in the request. 551 With the exception of the processing of a 3xx response described 552 above, the processing of the History-Info header received in the 553 Response is application specific and outside the scope of this 554 document. However, the validity of the information SHOULD be ensured 555 prior to any application usage. For example, the entries MAY be 556 evaluated to determine gaps in indices, which could indicate that an 557 entry has been maliciously removed or removed for privacy reasons. 558 Either way, an application MAY want to be aware of potentially 559 missing information. 561 4.3.2 User Agent Server (UAS) Behavior 563 The processing of the History-Info header by a UAS in a Request 564 depends upon local policy and specific applications at the UAS which 565 might make use of the information. Prior to any application usage of 566 the information, the validity SHOULD be ascertained. For example, 567 the entries MAY be evaluated to determine gaps in indices, which 568 could indicate that an entry has been maliciously removed or removed 569 for privacy reasons. Either way, an application MAY want to be aware 570 of potentially missing information. 572 If the "histinfo" option tag is received in a request, the UAS SHOULD 573 include any History-Info received in the request in the subsequent 574 response. 576 4.3.3 Proxy Behavior 578 The inclusion of the History-Info header in a Request does not alter 579 the fundamental processing of proxies for determining request targets 580 as defined in section 16.5 of [RFC3261]. Whether a proxy adds the 581 History-Info header or a new hi-entry as it forwards a Request 582 depends upon the following considerations: 583 1. Whether the Request contains the "histinfo" option tag in the 584 Supported header. 585 2. Whether the proxy supports the History-Info header. 586 3. Whether the Request contains a Privacy header with a priv- 587 value of "session", "header" or "history". 588 4. Whether any History-Info header added for a proxy/domain 589 should go outside that domain. An example being the use of 590 the History-Info header within the specific domain in which 591 it is retargeted, however, policies (for privacy, user and 592 network security, etc.) would prohibit the exposure of that 593 information outside that domain. To accommodate such a 594 scenario, a proxy MAY insert the Privacy header with a priv- 595 value of "history" when the request is being forwarded within 596 the same domain. An example of such an application is 597 provided in Appendix C. 598 5. Whether an hi-entry is added for a specific Request URI due 599 to local privacy policy considerations. A proxy MAY add the 600 Privacy header with a priv-value of "history" associated with 601 the specific hi-targeted-to-uri. 603 An example policy would be a proxy that only adds the History-Info 604 header if the "histinfo" option tag is in the Supported header. 605 Other proxies may have a policy that they always add the header, but 606 never forward it outside a particular domain, accomplishing this by 607 adding a Privacy header with a priv-value of "history" to each hi- 608 entry to allow the information to be collected for internal 609 retargeting only. 611 Each application making use of the History-Info header SHOULD address 612 the impacts of the local policies on the specific application (e.g. 614 what specification of local policy is optimally required for a 615 specific application and any potential limitations imposed by local 616 policy decisions). 618 Consistent with basic SIP processing of optional headers, proxies 619 SHOULD maintain the History-Info header(s), received in messages 620 being forwarded, independent of whether local policy supports 621 History-Info. 623 The specific processing by proxies for adding the History-Info 624 headers in Requests and Responses, to accommodate the considerations 625 outlined above, is described in detail in the following sections. 627 4.3.3.1 Adding the History-Info header to Requests 629 Upon evaluation of the considerations under which the History-Info 630 header is to be included in requests (e.g. no Privacy header 631 overriding inclusion, local policy supports, etc.), detailed in 632 section 4.3.3, a proxy SHOULD add an hi-entry as it forwards a 633 Request. Section 16.6 of [RFC3261] defines the steps to be followed 634 as the proxy forwards a Request. Step 5 prescribes the addition of 635 optional headers. Although, this would seem the appropriate step for 636 adding the History-info header, the interaction with Step 6 637 "Postprocess routing information" and the impact of a strict route in 638 the Route header could result in the Request-URI being changed, thus 639 adding the History-info header between steps 8 (adding Via header) 640 and 9 (adding Content-Length) is RECOMMENDED. Note, that in the case 641 of loose routing, the Request-URI does not change during the 642 forwarding of a Request, thus the capturing of History-Info for such 643 a request would result in duplicate Request-URIs with different 644 indices. The hi-entry MUST be added following any hi-entry received 645 in the request being forwarded. Additionally, if a request is 646 received that doesn't include a History-Info header, the proxy MAY 647 add a History-Info header with an hi-entry preceding the one being 648 added for the current request being forwarded. The index for this 649 hi-entry is RECOMMENDED to start at 1. The following subsections 650 define the details of creating the information associated with each 651 hi-entry. 653 4.3.3.1.1 Privacy in the History-Info header 655 If there is a Privacy header in the request with a priv-value of 656 "session", "header" or "history", an hi-entry MAY be added, if the 657 request is being forwarded to a Request URI associated with a domain 658 for which the processing entity is responsible (and provided local 659 policy supports the History-Info header, etc.). If a request is 660 being forwarded to a Request URI associated with a domain for which 661 the proxy is not responsible and there is a Privacy header in the 662 request with a priv-value of "session", "header" or "history", the 663 proxy SHOULD remove any hi-entry(s) prior to forwarding, depending 664 upon local policy and whether the proxy might know a priori that it 665 can rely on a downstream privacy service to apply the requested 666 privacy. 668 For the scenario where there is no Privacy header in the request and 669 the request is being forwarded to a Request URI associated with the 670 domain(s) for which this entity is responsible, there are several 671 additional considerations: 672 o If there is no local policy associated with privacy, then an hi- 673 entry MAY be added to the Request. 675 o If the proxy's local policies, per consideration 4 in section 676 4.3.3, indicate that the History-Info header should not be 677 forwarded beyond the domain for which this intermediary is 678 responsible, then a Privacy header with a priv-value of 679 "history" SHOULD be associated with each hi-entry added by that 680 proxy in this scenario. 682 o If the proxy's policy per consideration 5 in section 4.3.3, 683 indicates that History-Info for a specific Request URI should 684 not be forwarded beyond the domain for which this intermediary 685 is responsible, then a Privacy header with a priv-value of 686 "history" SHOULD be associated with the specific hi-entry, for 687 that specific hi-targeted-to-uri, added by that proxy in this 688 scenario. 690 If a request is being forwarded to a Request URI associated with a 691 domain for which the proxy is not responsible and local policy 692 requires privacy associated with any, or with specific hi-entries it 693 has added, any hi-entry with a priv-value of "history" SHOULD be 694 removed prior to forwarding. 696 4.3.3.1.2 Reason in the History-Info header 698 For retargets that are the result of an explicit SIP response, a 699 Reason MUST be associated with the hi-targeted-to-uri. If the SIP 700 response does not include a Reason header, the SIP Response Code that 701 triggered the retargeting MUST be included as the Reason associated 702 with the hi-targeted-to-uri that has been retargeted. If the 703 response contains a non-SIP Reason header (e.g. Q.850), it MUST be 704 captured as an additional Reason associated with the hi-targeted-to- 705 uri that has been retargeted, along with the SIP Response Code. If 706 the Reason header is a SIP reason, then it MUST be used as the Reason 707 associated with the hi-targeted-to-uri rather than the SIP response 708 code. 710 For retargets as a result of timeouts or internal events, a Reason 711 MAY be associated with the hi-targeted-to-uri that has been 712 retargeted. 714 The addition of the Reason should occur prior to the forwarding of 715 the request (which may add a new hi-entry with a new hi-targeted-to- 716 uri) as it is associated with the hi-targeted-to-uri that has been 717 retargeted, since it reflects the reason why the Request to that 718 specific URI was not successful. 720 4.3.3.1.3 Indexing in the History-Info header 722 In order to maintain ordering and accurately reflect the nesting and 723 retargeting of the request, an index MUST be included along with the 724 Targeted-to-URI being captured. Per the ABNF in section 4.1, the 725 index consists of a dot delimited series of digits (e.g. 1.1.2). Each 726 dot reflects a hop or level of nesting, thus the number of hops is 727 determined by the total number of dots. Within each level, the 728 integer reflects the number of peer entities to which the request has 729 been routed. Thus, the indexing results in a logical tree 730 representation for the history of the Request. It is recommended that 731 for each level of indexing, the index start at 1. It is recommended 732 that an increment of 1 is used for advancing to a new branch. 734 The basic rules for adding the index are summarized as follows: 736 1. Basic Forwarding: In the case of a Request that is being 737 forwarded, the index is determined by adding another level of 738 indexing since the depth/length of the branch is increasing. To 739 accomplish this, the proxy reads the value from the History-Info 740 header in the received request, if available, and adds another 741 level of indexing by appending the DOT delimiter followed by an 742 initial index for the new level RECOMMENDED to be 1. For example, 743 if the index in the last History-Info header field in the received 744 request is 1.1, this proxy would initialize its index to 1.1.1 and 745 forward the request. 747 2. Retargeting within a Proxy - 1st instance: For the first 748 instance of retargeting within a Proxy, the calculation of the 749 index follows that prescribed for basic forwarding. 751 3. Retargeting within a Proxy - subsequent instance: For each 752 subsequent retargeting of a request by the same proxy, another 753 branch is added. With the index for each new branch calculated by 754 incrementing the last/lowest digit at the current level, thus the 755 index in the next request forwarded by this same proxy, following 756 the example above, would be 1.1.2. 758 4. Retargeting based upon a Response: In the case of retargeting 759 due to a specific response (e.g. 302), the index would be 760 calculated per rule 3. That is, the lowest/last digit of the index 761 is incremented (i.e. a new branch is created), with the increment 762 RECOMMENDED to be 1. For example, if the index in the History-Info 763 header of the received request was 1.2, then the index in the 764 History-Info header field for the new hi-targeted-to-URI would be 765 1.3. 767 5. Retargeting the request in parallel (forking): If the request 768 forwarding is done in parallel, the index MUST be captured for each 769 forked request per the rules above, with each new Request having a 770 unique index. The only difference in the messaging for this 771 scenario and the messaging produced per basic proxy retargeting in 772 rules 2 and 3 is these forwarded requests do not have History-Info 773 entries associated with their peers. The proxy builds the 774 subsequent response (or request) using the aggregated information 775 associated with each of those requests and including the header 776 entries in the order indicated by the indexing. Responses are 777 processed as described in section 16.7 of [RFC3261] with the 778 aggregated History-Info entries processed similar to step 7 779 "Aggregate Authentication Header Field Values". Section 4.5 780 provides an example of a parallel request scenario, highlighting 781 this indexing mechanism. 783 4.3.3.2 Processing History-Info in Responses 785 A proxy that receives a Request with the "histinfo" option tag in the 786 Supported header, and depending upon a local policy supporting the 787 capture of History-Info, SHOULD return captured History-Info in 788 subsequent, provisional and final responses to the Request, subject 789 to the following considerations for privacy: 791 o If the response is being forwarded to a Request URI associated 792 with a domain for which the proxy is not responsible and there 793 was a Privacy header, in the request received by the proxy, with 794 a priv-value of "session", "header" or "history", the proxy MUST 795 remove the History-Info header (i.e. all hi-entries) prior to 796 forwarding. 798 o If a request is being forwarded to a Request URI associated with 799 a domain for which the proxy is not responsible and local policy 800 requires privacy associated with any or all hi-entry(s) it has 801 added, any hi-entry with a priv-value of "history" MUST be 802 removed prior to forwarding. 804 o If a proxy receives a response, from another intermediary 805 associated with a domain for which it is responsible, including 806 hi-entry(s) with privacy headers and that response is to be 807 forwarded to a domain for which it is not responsible, then 808 those hi-entry(s) MUST be removed. 810 The processing of History-Info in responses follows the methodology 811 described in section 16.7 of [RFC3261], with the processing of 812 History-Info headers adding an additional step, just before step 9 813 "Forwarding the Response". 815 4.3.4 Redirect Server Behavior 817 A redirect server SHOULD NOT add any new History-Info, as that would 818 be done by the entity receiving the 3xx response. However, a redirect 819 server MAY include History-Info in responses by adding any History- 820 Info headers received in a request to a subsequent response. 822 4.4 Security for History-Info 824 As discussed in Section 3, the security requirements are met by 825 recommending the use of TLS (a basic SIP requirement per [RFC3261]) 826 for hop by hop security. If TLS is not available on the connection 827 over which a request, containing a History-Info header, is being 828 forwarded, then either of the following two options MUST be 829 implemented: 830 o The History-Info header MUST be removed prior to forwarding the 831 request, or 832 o The request MUST be redirected, including the History-Info header 833 in the response, to allow the UAC to securely issue the request, 834 including the History-Info header. 836 4.5 Example Applications using History-Info 838 This scenario highlights an example where the History-Info in the 839 response is primarily of use in not retrying routes that have already 840 been tried by another proxy. Note, that this is just an example and 841 that there may be valid reasons why a Proxy would want to retry the 842 routes and thus, this would likely be a local proxy or even user 843 specific policy. 845 UA 1 sends a call to "Bob" to proxy 1. Proxy 1 forwards the request 846 to Proxy 2. Proxy 2 sends the requests in parallel and tries several 847 places (UA2, UA3 and UA4) before sending a response to Proxy 1 that 848 all the places are busy. Proxy 1, without the History-Info, would 849 try several some of the same places (e.g. UA3) based upon registered 850 contacts for "Bob", before completing at UA5. However, with the 851 History-Info, Proxy 1 determines that UA3 has already received the 852 invite, thus the INVITE goes directly to UA5. 854 Section 4.5.1 provides this same scenario using one of the privacy 855 mechanisms, with Proxy2 adding the Privacy header indicating that the 856 History-Info header is not to be propagated outside P2's domain. This 857 scenario highlights the potential functionality lost with the use of 858 "history" privacy in the Privacy header for the entire request and 859 the need for careful consideration on the use of privacy for History- 860 Info. 862 Section 4.5.2 also provides the same scenario using one of the 863 privacy mechanisms, however, due to local policy at Proxy2, only one 864 of the Request-URIs (UA4) in the History-Info contains a priv-value 865 of "history", thus allowing some optimized functionality in the 866 routing of the request, but still maintaining privacy for specific 867 URIs. 869 Additional detailed scenarios are available in the appendix. 871 UA1 Proxy1 Proxy2 UA2 UA3 UA4 UA5 873 | | | | | | | 874 |--INVITE -->| | | | | | 875 | |-INVITE->| | | | | 876 Supported: histinfo 877 History-Info: ;index=1, 878 ; index=1.1 879 | | | | | | | 880 | | |-INVITE>| | | | 881 History-Info: ;index=1, 882 ;index=1.1, 883 ;index=1.1.1 884 | | | | | | | 885 | | |-----INVITE ---->| | | 886 History-Info:;index=1, 887 ; index=1.1, 888 ;index=1.1.2 889 | | | | | | | 890 | | |-------INVITE------------>| | 891 History-Info:;index=1, 892 ;index=1.1, 893 ;index=1.1.3 895 /* All Responses from the INVITEs indicate non-success/non- 896 availability*/ 897 | | | | | | | 898 | |<-480 ---| | | | | 899 History-Info: ;index=1, 900 ; index=1.1, 901 ;index=1.1.1, 903 ; index=1.1.2, 905 ; index=1.1.3 907 | | | | | | | 908 /* Upon receipt of the response, P1 determines another route for the 909 INVITE, but finds that it matches a route already attempted 910 (e.g. UA3, thus the INVITE is only forwarded to UA5, where 911 the session is successfully established */ 912 | | | | | | | 913 | |----------------INVITE --------------------->| 914 History-Info: ;index=1, 915 ; index=1.1, 916 ;index=1.1.1, 918 ; index=1.1.2, 920 ; index=1.1.3 922 ;index=1.2 923 | | | | | | | 924 | |<-----200 OK---------------------------------| 925 |<--200 OK---| | | | | | 926 | | | | | | | 927 |--ACK --------------------------------------------------->| 929 4.5.1 Example with Privacy header for entire request at Proxy2 931 UA1 Proxy1 Proxy2 UA2 UA3 UA4 UA5 933 | | | | | | | 934 |--INVITE -->| | | | | | 935 | |-INVITE->| | | | | 936 Supported: histinfo 937 History-Info: ;index=1, 938 ;index=1.1 939 | | | | | | | 940 | | |-INVITE>| | | | 941 Privacy: history 942 History-Info:;index=1, 943 ;index=1.1, 944 ;index=1.1.1 945 | | | | | | | 946 | | |-----INVITE ---->| | | 947 Privacy: history 948 History-Info:;index=1, 949 ; index=1.1, 950 ;index=1.1.2 951 | | | | | | | 952 | | |-------INVITE------------>| | 953 Privacy: history 954 History-Info:;index=1, 955 ;index=1.1, 956 ;index=1.1.3 958 /* All Responses from the INVITEs indicate non-success/non- 959 availability and only the initial, received History-Info entries 960 are NOT returned to P1 due to the Privacy header value.*/ 961 | | | | | | | 962 | |<-480 ---| | | | | 963 History-Info: ;index=1, 964 ; index=1.1 965 | | | | | | | 966 /* Upon receipt of the response, P1 determines another route for the 967 INVITE, including UA3 which was attempted by P2, but due to 968 Privacy P1 is not aware of this, so UA3 is re-attempted prior to 969 forwarding the INVITE to UA5, where the session is successfully 970 established */ 971 | | | | | | | 972 | |--------------INVITE ----->| | | 973 History-Info: ;index=1, 974 ; index=1.1, 975 ; index=1.2 976 | | | | | | | 977 | |<-- 486 -------------------| | | 978 History-Info: ;index=1, 979 ; index=1.1, 980 ; index=1.2 981 | | | | | | | 982 | |----------------INVITE --------------------->| 983 History-Info: ;index=1, 984 ; index=1.1, 985 ;index=1.2, 987 ;index=1.3 988 | | | | | | | 989 | |<-----200 OK---------------------------------| 990 |<--200 OK---| | | | | | 991 | | | | | | | 992 |--ACK --------------------------------------------------->| 994 4.5.2 Example with Privacy header for specific URI (UA4) at Proxy2 996 UA1 Proxy1 Proxy2 UA2 UA3 UA4 UA5 997 | | | | | | | 998 |--INVITE -->| | | | | | 999 | |-INVITE->| | | | | 1000 Supported: histinfo 1001 History-Info: ;index=1, 1002 ; index=1.1 1003 | | | | | | | 1004 | | |-INVITE>| | | | 1005 History-Info:;index=1, 1006 ;index=1.1, 1007 ;index=1.1.1 1008 | | | | | | | 1009 | | |-----INVITE ---->| | | 1010 History-Info:;index=1, 1011 ;index=1.1, 1012 ;index=1.1.2 1013 | | | | | | | 1014 | | |-------INVITE------------>| | 1015 History-Info: ;index=1, 1016 ;index=1.1, 1017 ; index=1.1.3 1020 /* All Responses from the INVITEs indicate non-success/non- 1021 availability. The History-Info associated with UA4 is not returned 1022 in the response due to the privacy header associated with that URI */ 1023 | | | | | | | 1024 | |<-480 ---| | | | | 1025 History-Info: ;index=1, 1026 ; index=1.1, 1027 ;index=1.1.1, 1029 ; index=1.1.2, 1031 | | | | | | | 1032 /* Upon receipt of the response, P1 determines another route for the 1033 INVITE, but finds that it matches a route already attempted 1034 (e.g. UA3), thus the INVITE is only forwarded to UA5, where 1035 the session is successfully established */ 1036 | | | | | | | 1037 | |----------------INVITE --------------------->| 1038 History-Info: ;index=1, 1039 ; index=1.1, 1040 ;index=1.1.1, 1042 ; index=1.1.2, 1044 ;index=1.2 1045 | | | | | | | 1046 | |<-----200 OK---------------------------------| 1047 |<--200 OK---| | | | | | 1048 | | | | | | | 1049 |--ACK --------------------------------------------------->| 1051 5. Application Considerations 1053 As seen by the example scenarios in the appendix, History-Info 1054 provides a very flexible building block that can be used by 1055 intermediaries and UAs for a variety of services. As such, any 1056 services making use of History-Info must be designed with the 1057 following considerations: 1058 1) History-Info is optional, thus a service MUST define default 1059 behavior for requests and responses not containing History-Info 1060 headers. 1061 2) History-Info may be impacted by privacy considerations. 1062 Applications requiring History-Info need to be aware that if 1063 Header, Session or History level privacy is requested by a UA (or 1064 imposed by an intermediary) that History-Info may not be 1065 available in a request or response. This would be addressed by 1066 an application in the same manner as the previous consideration 1067 by ensuring there is reasonable default behavior should the 1068 information not be available. 1069 3) History-Info may be impacted by local policy. Each application 1070 making use of the History-Info header SHOULD address the impacts 1071 of the local policies on the specific application (e.g. what 1072 specification of local policy is optimally required for a 1073 specific application and any potential limitations imposed by 1074 local policy decisions). Note, that this is related to the 1075 optionality and privacy considerations identified in 1 and 2 1076 above, but goes beyond that. For example, due to the optionality 1077 and privacy considerations, an entity may receive only partial 1078 History-Info entries; will this suffice? Note, that this would be 1079 a limitation for debugging purposes, but might be perfectly 1080 satisfactory for some models whereby only the information from a 1081 specific intermediary is required. 1082 4) The security associated with the History-Info header requires the 1083 use of TLS. In the case of TLS not being available for a 1084 connection over which a request is being forwarded, the History- 1085 Info header may be removed from a request. The impact of lack of 1086 having the information depends upon the nature of the specific 1087 application (e.g. is the information something that appears on a 1088 display or is it processed by automata which could have negative 1089 impacts on the subsequent processing of a request?). It is 1090 suggested that the impact of an intermediary not supporting the 1091 security recommendations should be evaluated by the application 1092 to ensure that the impacts have been sufficiently addressed by 1093 the application. 1095 6. Security Considerations 1097 The threat model and related security and privacy requirements for 1098 the History-Info header are described in section 2.1 and 2.2 of this 1099 document. Sections 3.2, 3.3 and 4.4 provide normative 1100 recommendations related to security and privacy fulfilling these 1101 requirements. The use of TLS is mandated between the entities (i.e. 1102 UAC to Proxy, Proxy to Proxy, and Proxy to UAS) which use the 1103 History-Info header. The appropriate handling of a request in the 1104 case that TLS is not available for a specific connection is described 1105 in section 5. 1107 With TLS, History-Info headers are no less, nor no more, secure than 1108 other SIP headers, which generally have even more impact on the 1109 subsequent processing of SIP sessions than the History-Info header. 1111 7. IANA Considerations 1113 (Note to RFC Editor: Please fill in all occurrences of XXXX in this 1114 section with the RFC number of this specification). 1116 7.1 Registration of new SIP History-Info header 1118 This document defines a new SIP header field name: History-Info and a 1119 new option tag: histinfo. 1121 The following changes should be made to 1122 http:///www.iana.org/assignments/sip-parameters 1124 The following row should be added to the header field section: 1126 Header Name Compact Form Reference 1127 ----------- ------------ --------- 1128 History-Info none [RFCXXXX] 1130 The following should be added to the Options Tags section: 1132 Name Description Reference 1133 ---- ----------- --------- 1134 histinfo When used with the Supported header, [RFCXXXX] 1135 this option tag indicates support 1136 for the History Information to be 1137 captured for requests and returned in 1138 subsequent responses. This tag is not 1139 used in a Proxy-Require or Require 1140 header field since support of 1141 History-Info is optional. 1143 7.2 Registration of "history" for SIP Privacy header 1145 This document defines a new priv-value for the SIP Privacy header: 1146 history 1148 The following changes should be made to 1149 http://www.iana.org/assignments/sip-priv-values 1151 The following should be added to the registration for the SIP 1152 Privacy header: 1154 Name Description Registrant Reference 1155 ---- ----------- ---------- --------- 1156 history Privacy requested for Mary Barnes [RFCXXXX] 1157 History-Info header(s) mary.barnes@nortelnetworks.com 1159 Normative References 1161 [RFC3261] J. Rosenberg et al, "SIP: Session initiation protocol," RFC 1162 3261, June, 2002. 1164 [RFC3326] H. Schulzrinne, D. Oran, G. Camarillo, "The Reason Header 1165 Field for the Session Initiation Protocol", RFC 3326, December, 2002. 1167 [RFC3323] J. Peterson, "A Privacy Mechanism for the Session 1168 Initiation Protocol (SIP)", RFC 3323, November, 2002. 1170 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1171 Requirement Levels", RFC 2119, March 1997. 1173 [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1174 Specifications: ABNF", RFC 2234, November 1997. 1176 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 1177 RFC 2246, January 1999. 1179 Informational References 1181 [SIPSVCEX] A. Johnson, "SIP Service Examples", draft-ietf-sipping- 1182 service-examples-07.txt, July, 2004. 1184 [RFC3665] A. Johnson et al, "SIP Basic Call Flow Examples", RFC 3665, 1185 BCP 75, December, 2003. 1187 Acknowledgements 1189 The editor would like to acknowledge the constructive feedback 1190 provided by Robert Sparks, Paul Kyzivat, Scott Orton, John Elwell, 1191 Nir Chen, Francois Audet, Palash Jain, Brian Stucker, Norma Ng, 1192 Anthony Brown, Jayshree Bharatia, Jonathan Rosenberg, Eric Burger, 1193 Martin Dolly, Roland Jesske, Takuya Sawada, Sebastien Prouvost and 1194 Sebastien Garcin. 1196 The editor would like to acknowledge the significant input from 1197 Rohan Mahy on some of the normative aspects of the ABNF, particularly 1198 around the need for and format of the index and around the security 1199 aspects. 1201 Contributors' Addresses 1203 Cullen, Mark and Jon contributed to the development of the initial 1204 requirements. 1206 Cullen and Mark provided substantial input in the form of email 1207 discussion in the development of the initial version of the 1208 individual solution document. 1210 Cullen Jennings 1211 Cisco Systems 1212 170 West Tasman Dr 1213 MS: SJC-21/3 1215 Tel: +1 408 527 9132 1216 Email: fluffy@cisco.com 1218 Jon Peterson 1219 NeuStar, Inc. 1220 1800 Sutter Street, Suite 570 1221 Concord, CA 94520 1222 USA 1224 Phone: +1 925-363-8720 1225 EMail: Jon.Peterson@NeuStar.biz 1227 Mark Watson 1228 Nortel Networks (UK) 1229 Maidenhead Office Park (Bray House) 1230 Westacott Way 1231 Maidenhead, 1232 Berkshire 1233 England 1235 Tel: +44 (0)1628-434456 1236 Email: mwatson@nortelnetworks.com 1238 Author's Address 1240 Mary Barnes 1241 Nortel Networks 1242 2380 Performance Drive 1243 Richardson, TX USA 1245 Phone: 1-972-684-5432 1246 Email: mary.barnes@nortelnetworks.com 1248 Appendix. Example Scenarios 1250 The scenarios in Appendix A-D provide sample use cases for the 1251 History-Info header for informational purposes only. They are not 1252 intended to be normative and the formatting is for visual purposes, 1253 thus the headers in the URI are not shown properly formatted for 1254 escaping. Refer to section 4.2 examples with the proper formatting. 1256 Appendix A. Sequentially forking (History-Info in Response) 1258 This scenario highlights an example where the History-Info in the 1259 response is useful to an application or user that originated the 1260 request. 1262 "Alice" at UA 1sends a call to "Bob" via proxy 1. Proxy 1 1263 sequentially tries several places (UA2, UA3 and UA4) unsuccessfully 1264 before sending a response to "Alice". 1266 This scenario is provided to show that by providing the History-Info 1267 to UA1, the end user or an application at UA1 could make a decision 1268 on how best to attempt finding "Bob". Without this mechanism UA1 1269 might well attempt UA3 (and thus UA4) and then re-attempt UA4 on a 1270 third manual attempt at reaching "Bob". With this mechanism, either 1271 the end user or application could know that "Bob" is busy on his home 1272 phone and is physically not in the office. If there were an 1273 alternative address for "Bob" known to this end user or application, 1274 that hasn't been attempted, then either the application or the end 1275 user could attempt that. The intent here is to highlight an example 1276 of the flexibility of this mechanism that enables applications well 1277 beyond SIP as it is certainly well beyond the scope of this document 1278 to prescribe detailed applications. 1280 UA1 Proxy1 UA2 UA3 UA4 1281 | | | | | 1282 |-INVITE F1->| | | | 1283 | | | | | 1284 | |--INVITE F2------>| | | 1285 |<--100 F3---| | | | 1286 | |<-302 F4----------| | | 1287 | | | | | 1288 | |-------INVITE F5 --------->| | 1289 | | | | | 1290 | |<-------180 F6 ------------| | 1291 |<---180 F7--| | | | 1292 | . . |---retransmit INVITE ----->| | 1293 | | | | | 1294 | | ( timeout ) | | | 1295 | | | | | 1296 | |------INVITE F8 ------------------->| 1297 |<--100 F9 --| | | | 1298 | | | | | 1299 | |<-486 F10 --------------------------| 1300 | | | | | 1301 | |-- ACK F11------------------------->| 1302 |<--486 F12--| | | | 1303 | | | | | 1304 |--ACK F13-->| | | | 1305 | | | | | 1307 Message Details 1309 F1 INVITE UA1 ->Proxy1 1311 INVITE sip:UserA@example.com SIP/2.0 1312 Via: SIP/2.0/UDP example.net:5060 1313 From: Alice 1314 To: Bob 1315 Call-Id: 12345600@example.net 1316 CSeq: 1 INVITE 1317 Contact: Alice 1318 Content-Type: application/sdp 1319 Content-Length: 1321 v=0 1322 o=UserA 2890844526 2890844526 IN IP4 client.example.net 1323 s=Session SDP 1324 c=IN IP4 192.0.2.3 1325 t=0 0 1326 m=audio 49170 RTP/AVP 0 1327 a=rtpmap:0 PCMU/8000 1329 /*Client for UA1 prepares to receive data on port 49170 1330 from the network. */ 1331 F2 INVITE Proxy1 ->UA2 1333 INVITE sip:UserA@ims.example.com SIP/2.0 1334 Via: SIP/2.0/UDP ims.example.com:5060;branch=1 1335 Via: SIP/2.0/UDP example.net:5060 1336 Record-Route: 1337 From: Alice 1338 To: Bob 1339 Call-Id: 12345600@example.net 1340 CSeq: 1 INVITE 1341 History-Info: ; index=1 1342 Contact: Alice 1343 Content-Type: application/sdp 1344 Content-Length: 1346 v=0 1347 o=UserA 2890844526 2890844526 IN IP4 client.example.net 1348 s=Session SDP 1349 c=IN IP4 192.0.2.3 1350 t=0 0 1351 m=audio 49170 RTP/AVP 0 1352 a=rtpmap:0 PCMU/8000 1354 F3 100 Trying Proxy1 ->UA1 1356 SIP/2.0 100 Trying 1357 Via: SIP/2.0/UDP example.net:5060 1358 From: Alice 1359 To: Bob 1360 Call-Id: 12345600@example.net 1361 CSeq: 1 INVITE 1362 Content-Length: 0 1364 F4 302 Moved Temporarily UA2 ->Proxy1 1366 SIP/2.0 302 Moved Temporarily 1367 Via: SIP/2.0/UDP ims.example.com:5060;branch=1 1368 Via: SIP/2.0/UDP example.net:5060 1369 From: Alice 1370 To: Bob ;tag=3 1371 Call-Id: 12345600@example.net 1372 CSeq: 1 INVITE 1373 Contact: 1374 Content-Length: 0 1376 F5 INVITE Proxy1 -> UA3 1377 INVITE sip:UserB@example.com SIP/2.0 1378 Via: SIP/2.0/UDP ims.example.com:5060;branch=2 1379 Via: SIP/2.0/UDP example.net:5060 1380 From: Alice 1381 To: Bob 1382 Call-Id: 12345600@example.net 1383 History-Info: ; index=1, 1385 ;index=2 1386 CSeq: 1 INVITE 1387 Contact: Alice 1388 Content-Type: application/sdp 1389 Content-Length: 1391 v=0 1392 o=User1 2890844526 2890844526 IN IP4 client.example.net 1393 s=Session SDP 1394 c=IN IP4 192.0.2.3 1395 t=0 0 1396 m=audio 49170 RTP/AVP 0 1397 a=rtpmap:0 PCMU/8000 1399 F6 180 Ringing UA3 ->Proxy1 1401 SIP/2.0 180 Ringing 1402 Via: SIP/2.0/UDP example.net:5060 1403 From: Alice 1404 To: Bob ;tag=5 1405 Call-ID: 12345600@example.net 1406 CSeq: 1 INVITE 1407 Content-Length: 0 1409 F7 180 Ringing Proxy1 -> UA1 1411 SIP/2.0 180 Ringing 1412 SIP/2.0/UDP example.net:5060 1413 From: Alice 1414 To: Bob 1415 Call-Id: 12345600@example.net 1416 CSeq: 1 INVITE 1417 Content-Length: 0 1419 /* User B is not available. INVITE is sent multiple 1420 times until it times out. */ 1422 /* The proxy forwards the INVITE to UA4 after adding the 1423 additional History Information entry. */ 1424 F8 INVITE Proxy1 -> UA4 1426 INVITE sip:UserC@example.com SIP/2.0 1427 Via: SIP/2.0/UDP ims.example.com:5060;branch=3 1428 Via: SIP/2.0/UDP example.net:5060 1429 From: Alice 1430 To: Bob 1431 Call-Id: 12345600@example.net 1432 History-Info:;index=1, 1434 ;index=2, 1436 ;index=3 1437 CSeq: 1 INVITE 1438 Contact: Alice 1439 Content-Type: application/sdp 1440 Content-Length: 1442 v=0 1443 o=User1 2890844526 2890844526 IN IP4 client.example.net 1444 s=Session SDP 1445 c=IN IP4 192.0.2.3 1446 t=0 0 1447 m=audio 49170 RTP/AVP 0 1448 a=rtpmap:0 PCMU/8000 1450 F9 100 Trying Proxy1 ->UA1 1452 SIP/2.0 100 Trying 1453 Via: SIP/2.0/UDP example.net:5060 1454 From: Alice 1455 To: Bob 1456 Call-Id: 12345600@example.net 1457 CSeq: 1 INVITE 1458 Content-Length: 0 1460 F10 486 Busy Here UA4 -> Proxy1 1462 SIP/2.0 486 Busy Here 1463 Via: SIP/2.0/UDP ims.example.com:5060;branch=3 1464 Via: SIP/2.0/UDP example.net:5060 1465 From: Alice 1466 To: Bob 1467 Call-Id: 12345600@example.net 1468 CSeq: 1 INVITE 1469 Content-Length: 0 1470 F11 ACK Proxy1 -> UA4 1472 ACK sip:UserC@example.com SIP/2.0 1473 Via: SIP/2.0/UDP example.net:5060 1474 From: Alice 1475 To: Bob 1476 Call-Id: 12345600@example.net 1477 CSeq: 1 ACK 1478 Content-Length: 0 1480 /* The proxy forwards the 486 to Alice after adding the 1481 associated History Information entries from the series of 1482 INVITES */ 1484 F12 486 Busy Here Proxy1 -> UA1 1486 SIP/2.0 486 Busy Here 1487 Via: SIP/2.0/UDP example.net:5060 1488 From: Alice 1489 To: Bob 1490 Call-Id: 12345600@example.net 1491 History-Info:;index=1, 1493 ;index=2, 1495 ;index=3 1496 CSeq: 1 INVITE 1497 Content-Length: 0 1499 F13 ACK Alice -> Proxy 1 1501 ACK sip:UserA@example.com SIP/2.0 1502 Via: SIP/2.0/UDP example.net:5060 1503 From: Alice 1504 To: Bob 1505 Call-Id: 12345600@example.net 1506 CSeq: 1 ACK 1507 Content-Length: 0 1509 Appendix B. Voicemail 1511 This scenario highlights an example where the History-Info in the 1512 request is primarily of use by an edge service (e.g. Voicemail 1513 Server). It should be noted that this isn't intended to be a complete 1514 specification for this specific edge service as it is quite likely 1515 that additional information is needed by the edge service. History- 1516 Info is just one building block that this service makes use of. 1518 UA 1 called UA A which had been forwarded to UA B which forwarded to 1519 a UA VM (voicemail server). Based upon the retargeted URIs and 1520 Reasons (and other information) in the INVITE, the VM server makes a 1521 policy decision about what mailbox to use, which greeting to play 1522 etc. 1524 UA1 Proxy UA-A UA-B UA-VM 1526 | | | | | 1527 |--INVITE F1-->| | | | 1528 | | | | | 1529 | |--INVITE F2-->| | | 1530 |<--100 F3-----| | | | 1531 | |<-302 F4------| | | 1532 | | | | | 1533 | |--------INVITE F5---------->| | 1534 | | | | | 1535 | |<--------180 F6-------------| | 1536 |<---180 F7----| | | | 1537 | . . . | | | | 1538 | |------retransmit INVITE---->| | 1539 | . . . | | | | 1540 | | (timeout) | | 1541 | | | | | 1542 | |-------INVITE F8---------------------->| 1543 | | | | | 1544 | |<-200 F9-------------------------------| 1545 | | | | | 1546 |<-200 F10-----| | | | 1547 | | | | | 1548 |--ACK F11-------------------------------------------->| 1550 Message Details 1552 INVITE F1 UA1->Proxy 1554 INVITE sip:UserA@example.com SIP/2.0 1555 Via: SIP/2.0/UDP example.net:5060 1556 From: BigGuy 1557 To: LittleGuy 1558 Call-Id: 12345600@example.net 1559 CSeq: 1 INVITE 1560 Contact: BigGuy 1561 Content-Type: application/sdp 1562 Content-Length: 1563 v=0 1564 o=UserA 2890844526 2890844526 IN IP4 client.example.net 1565 s=Session SDP 1566 c=IN IP4 192.0.2.3 1567 t=0 0 1568 m=audio 49170 RTP/AVP 0 1569 a=rtpmap:0 PCMU/8000 1571 /*Client for UA1 prepares to receive data on port 49170 1572 from the network. */ 1574 INVITE F2 Proxy->UA-A 1576 INVITE sip:UserA@ims.example.com SIP/2.0 1577 Via: SIP/2.0/UDPims.example.com:5060;branch=1 1578 Via: SIP/2.0/UDP example.net:5060 1579 Record-Route: 1580 From: BigGuy 1581 To: LittleGuy 1582 Call-Id: 12345600@example.net 1583 CSeq: 1 INVITE 1584 History-Info: ; index=1 1585 Contact: BigGuy 1586 Content-Type: application/sdp 1587 Content-Length: 1589 v=0 1590 o=UserA 2890844526 2890844526 IN IP4 client.example.net 1591 s=Session SDP 1592 c=IN IP4 192.0.2.3 1593 t=0 0 1594 m=audio 49170 RTP/AVP 0 1595 a=rtpmap:0 PCMU/8000 1597 100 Trying F3 Proxy->UA1 1599 SIP/2.0 100 Trying 1600 Via: SIP/2.0/UDP example.net:5060 1601 From: BigGuy 1602 To: LittleGuy 1603 Call-Id: 12345600@example.net 1604 CSeq: 1 INVITE 1605 Content-Length: 0 1607 302 Moved Temporarily F4 UserA->Proxy 1608 SIP/2.0 302 Moved Temporarily 1609 Via: SIP/2.0/UDP ims.example.com:5060;branch=1 1610 Via: SIP/2.0/UDP example.net:5060 1611 From: BigGuy 1612 To: LittleGuy;tag=3 1613 Call-Id: 12345600@example.net 1614 CSeq: 1 INVITE 1615 Contact: 1616 Content-Length: 0 1618 INVITE F5 Proxy-> UA-B 1620 INVITE sip:UserB@example.com SIP/2.0 1621 Via: SIP/2.0/UDP ims.example.com:5060;branch=2 1622 Via: SIP/2.0/UDP example.net:5060 1623 From: BigGuy 1624 To: LittleGuy 1625 Call-Id: 12345600@example.net 1626 History-Info: ; index=1, 1628 ;index=2 1629 CSeq: 1 INVITE 1630 Contact: BigGuy 1631 Content-Type: application/sdp 1632 Content-Length: 1634 v=0 1635 o=User1 2890844526 2890844526 IN IP4 client.example.net 1636 s=Session SDP 1637 c=IN IP4 192.0.2.3 1638 t=0 0 1639 m=audio 49170 RTP/AVP 0 1640 a=rtpmap:0 PCMU/8000 1642 180 Ringing F6 UA-B ->Proxy 1644 SIP/2.0 180 Ringing 1645 Via: SIP/2.0/UDP example.net:5060 1646 From: BigGuy 1647 To: LittleGuy ;tag=5 1648 Call-ID: 12345600@example.net 1649 CSeq: 1 INVITE 1650 Content-Length: 0 1652 180 Ringing F7 Proxy-> UA1 1654 SIP/2.0 180 Ringing 1655 SIP/2.0/UDP example.net:5060 1656 From: BigGuy 1657 To: LittleGuy 1658 Call-Id: 12345600@example.net 1659 CSeq: 1 INVITE 1660 Content-Length: 0 1662 /* User B is not available. INVITE is sent multiple 1663 times until it times out. */ 1665 /* The proxy forwards the INVITE to UA-VM after adding the 1666 additional History Information entry. */ 1668 INVITE F8 Proxy-> UA-VM 1670 INVITE sip:VM@example.com SIP/2.0 1671 Via: SIP/2.0/UDP ims.example.com:5060;branch=3 1672 Via: SIP/2.0/UDP example.net:5060 1673 From: BigGuy 1674 To: LittleGuy 1675 Call-Id: 12345600@example.net 1676 History-Info:;index=1, 1678 ;index=2, 1680 ;index=3 1681 CSeq: 1 INVITE 1682 Contact: BigGuy 1683 Content-Type: application/sdp 1684 Content-Length: 1686 v=0 1687 o=User1 2890844526 2890844526 IN IP4 client.example.net 1688 s=Session SDP 1689 c=IN IP4 192.0.2.3 1690 t=0 0 1691 m=audio 49170 RTP/AVP 0 1692 a=rtpmap:0 PCMU/8000 1694 200 OK F9 1696 SIP/2.0 200 OK UA-VM->Proxy 1698 Via: SIP/2.0/UDP ims.example.com:5060;branch=3 1699 Via: SIP/2.0/UDP example.net:5060 1700 From: BigGuy 1701 To: LittleGuy ;tag=3 1702 Call-Id: 12345600@example.net 1703 CSeq: 1 INVITE 1704 Contact: TheVoiceMail 1705 Content-Type: application/sdp 1706 Content-Length: 1708 v=0 1709 o=UserA 2890844527 2890844527 IN IP4 vm.example.com 1710 s=Session SDP 1711 c=IN IP4 192.0.2.4 1712 t=0 0 1713 m=audio 3456 RTP/AVP 0 1714 a=rtpmap:0 PCMU/8000 1716 200 OK F10 Proxy->UA1 1718 SIP/2.0 200 OK 1719 Via: SIP/2.0/UDP ims.example.com:5060;branch=3 1720 Via: SIP/2.0/UDP example.net:5060 1721 From: BigGuy 1722 To: LittleGuy ;tag=3 1723 Call-Id: 12345600@example.net 1724 CSeq: 1 INVITE 1725 Contact: TheVoiceMail 1726 Content-Type: application/sdp 1727 Content-Length: 1729 v=0 1730 o=UserA 2890844527 2890844527 IN IP4 vm.example.com 1731 s=Session SDP 1732 c=IN IP4 192.0.2.4 1733 t=0 0 1734 m=audio 3456 RTP/AVP 0 1735 a=rtpmap:0 PCMU/8000 1737 ACK F11 UA1-> UA-VM 1739 ACK sip:VM@example.com SIP/2.0 1740 Via: SIP/2.0/UDP example.net:5060 1741 From: BigGuy 1742 To: LittleGuy;tag=3 1743 Call-Id: 12345600@example.net 1744 CSeq: 1 ACK 1745 Content-Length: 0 1747 /* RTP streams are established between UA1 and 1748 UA-VM. UA-VM starts announcement for UA1 */ 1750 Appendix C. Automatic Call Distribution Example 1752 This scenario highlights an example of an Automatic Call Distribution 1753 service, where the agents are divided into groups based upon the type 1754 of customers they handle. In this example, the Gold customers are 1755 given higher priority than Silver customers, so a Gold call would get 1756 serviced even if all the agents servicing the Gold group (ACDGRP1) 1757 were busy, by retargeting the request to the Silver Group. Upon 1758 receipt of the call at the agent assigned to handle the incoming 1759 call, based upon the History-Info header in the message, the 1760 application at the agent can provide an indication that this is a 1761 Gold call, from how many groups it might have overflowed before 1762 reaching the agent, etc. and thus can be handled appropriately by the 1763 agent. 1765 For scenarios whereby calls might overflow from the Silver to the 1766 Gold, clearly the alternate group identification, internal routing or 1767 actual agent that handles the call SHOULD not be sent to UA1, thus 1768 for this scenario, one would expect that the Proxy would not support 1769 the sending of the History-Info in the response, even if requested by 1770 the calling UA. 1772 As with the other examples, this is not prescriptive of how one would 1773 do this type of service but an example of a subset of processing that 1774 might be associated with such a service. In addition, this example 1775 is not addressing any aspects of Agent availability, which might also 1776 be done via a SIP interface. 1778 UA1 Proxy ACDGRP1 Svr ACDGRP2 Svr UA2-ACDGRP2 1780 | | | | | 1781 |--INVITE F1-->| | | | 1782 Supported:histinfo 1783 | | | | | 1784 | |--INVITE F2-->| | | 1785 Supported:histinfo 1786 History-Info: ; index=1 1787 History-Info: ; index=1.1 1788 | | | | | 1789 | |<-302 F3------| | | 1790 Contact: 1791 | | | | | 1792 | |--------INVITE F4---------->| | 1793 History-Info: ; index=1 1794 History-Info: ; index=1.1 1795 History-Info: ; index=1.2 1796 | | | | | 1797 | | | | | 1798 | | | |INVITE F5>| 1799 History-Info: ; index=1 1800 History-Info: ; index=1.1 1801 History-Info: ; index=1.2 1802 | | | | | 1803 | | | |<-200 F6--| 1804 | | | | | 1805 | |<-200 F7--------------------| | 1806 History-Info: ; index=1 1807 History-Info: ; index=1.1 1808 History-Info: ; index=1.2 1809 |<-200 F8------| | | | 1810 < No History-Info included in the response due to Local Policy> 1811 | | | | | 1812 |--ACK F9--------------------------------------------->| 1814 Appendix D. Session via Redirect and Proxy Servers 1816 In this scenario, Alice places a call to Bob using first a Redirect 1817 server then a Proxy Server. The INVITE message is first sent to the 1818 Redirect Server. The Server returns a 302 Moved Temporarily response 1819 (F2) containing a Contact header with Bob's current SIP address. 1820 Alice then generates a new INVITE with Bob's current SIP address 1821 included in another History-Info entry. The INVITE is then sent to 1822 Bob via the Proxy Server, with Bob receiving the complete History 1823 information; the call then proceeds normally. The complete call flow 1824 for this scenario, without the use of History-Info is described in 1825 section 3.6 of the SIP Basic Call Flow Examples [RFC3665]. 1827 Alice Redirect Server Proxy 3 Bob 1828 | | | | 1829 | INVITE F1 | | | 1830 |--------------->| | | 1831 | 302 F2 | | | 1832 |<---------------| | | 1833 | ACK F3 | | | 1834 |--------------->| | | 1835 | INVITE F4 | | 1836 |-------------------------------->| INVITE F5 | 1837 | 100 F6 |--------------->| 1839 Message Details 1841 F1 INVITE Alice -> Redirect Server 1843 INVITE sip:bob@biloxi.example.com SIP/2.0 1844 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKbf9f44 1845 Max-Forwards: 70 1846 From: Alice ;tag=9fxced76sl 1847 To: Bob 1848 Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com 1849 CSeq: 1 INVITE 1850 History-Info: ; index=1 1851 Contact: 1852 Content-Length: 0 1854 F2 302 Moved Temporarily Redirect Proxy -> Alice 1856 SIP/2.0 302 Moved Temporarily 1857 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKbf9f44 1858 ;received=192.0.2.1 1859 From: Alice ;tag=9fxced76sl 1860 To: Bob ;tag=53fHlqlQ2 1861 Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com 1862 CSeq: 1 INVITE 1863 History-Info: ; index=1 1864 Contact: 1865 Content-Length: 0 1867 F3 ACK Alice -> Redirect Server 1869 ACK sip:bob@biloxi.example.com SIP/2.0 1870 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKbf9f44 1871 Max-Forwards: 70 1872 From: Alice ;tag=9fxced76sl 1873 To: Bob ;tag=53fHlqlQ2 1874 Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com 1875 CSeq: 1 ACK 1876 Content-Length: 0 1878 F4 INVITE Alice -> Proxy 3 1880 INVITE sip:bob@chicago.example.com SIP/2.0 1881 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 1882 Max-Forwards: 70 1883 From: Alice ;tag=9fxced76sl 1884 To: Bob 1885 Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com 1886 CSeq: 2 INVITE 1887 History-Info: \ 1888 text="Moved Temporarily">; index=1, 1889 ; index=2 1890 Contact: 1891 Content-Length: 0 1893 F5 INVITE Proxy 3 -> Bob 1895 INVITE sip:bob@client.chicago.example.com SIP/2.0 1896 Via: SIP/2.0/TCP ss3.chicago.example.com:5060;branch=z9hG4bK721e.1 1897 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 1898 ;received=192.0.2.1 1899 Max-Forwards: 69 1900 Record-Route: 1901 From: Alice ;tag=9fxced76sl 1902 To: Bob 1903 Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com 1904 CSeq: 2 INVITE 1905 History-Info: \ 1906 text="Moved Temporarily">; index=1, 1907 ; index=2, 1908 ; index=2.1 1909 Contact: 1910 Content-Length: 0 1912 Detailed Call Flow continues per section 6.3 in [RFC 3665]. 1914 Appendix E. Changelog 1916 NOTE TO THE RFC-Editor: Please remove this section prior to 1917 publication as an RFC. 1919 Changes from the 05 to 06 version: 1921 o General changes to tidy document: 1922 o Change the term "this draft" to "this document". 1923 o Spell out first use of acronyms (ex: UA, UAC, UAS, URI, 1924 URL, TLS) 1925 o Change Histinfo to "histinfo" 1927 o Abstract: delete last 2 sentences in Abstract 1929 o Overview: 1930 o Insert paragraph break just before "This draft defined a new 1931 SIP header..." 1933 o 2nd to last paragraph of Overview, delete all but first 1934 sentence." (the other stuff on where examples would be 1935 further documented isn't really relevant to what this draft 1936 does and had been there for purposes of WG discussion 1937 during development of document). 1939 o Background: Put "retarget" in single quotes when the term is 1940 introduced in the second sentence (consistent with reference in 1941 section 3. 1943 o Section 3, 2nd para, add SUBSCRIBE and PUBLISH as appropriate 1944 methods (consistent with section 4.1) 1946 o Section 3.2: Changed "RECOMMENDs the use of TLS" to "strongly 1947 RECOMMENDS the use of TLS". 1949 o Section 4.1, Privacy bullet item, clarified the first reference 1950 of "History-Info header" as "History-Info header field values". 1952 o Section 4.2: 1953 oFor clarity in the examples, removed the text phrases escaped 1954 into the URI. 1955 oChange capitalized "Cause" to LC "cause". 1957 o Section 6 (Security): deleted the last two paragraphs (on AIB, 1958 Body additions, Security of Inserted Info since those are not 1959 relevant to the security solution required for History-Info), 1960 and restated what security mechanisms are mandatory to 1961 implement, including references to the sections of the document 1962 dealing with those mechanisms. 1964 o References: Updated references: Added TLS and removed body-add, 1965 AIB, and sec-inserted. 1967 Changes from the 04 to 05 version: 1969 o Section 3, 3rd paragraph: Clarified that the Proxy does not 1970 create the requests, but rather forwards. (SP - individual email 1971 Nov. 18) 1973 o Section 4.3.1: 1974 - 2nd paragraph: Added text for handling the reason, referring 1975 to section 4.3.3.1.2 for details(JRE-individual email Nov. 1976 15) 1977 - last paragraph: Clarified that with the exception of 3xx 1978 responses, handling of responses is application specific. 1980 o Section 4.3.3.1.1, lst paragraph, last statment: changed "...the 1981 proxy MUST remove any hi-entry(s) prior to forwarding." 1982 to: 1983 "...the proxy SHOULD remove any hi-entry(s) prior to forwarding, 1984 depending upon local policy and whether the proxy might know 1985 apriori that it can rely on a downstream privacy service to 1986 apply the requested privacy." (WG mailing list - conclusion 1987 posted on Nov. 17) 1989 o Section 4.3.3.1.2, last paragraph : a "is" has been added 1990 between "it" and "associated" in the phrase "as it associated 1991 with the hi-targeted-to-uri ..." (SP - individual email Nov. 1992 18) 1994 o Section 4.5 examples: 1995 o Fixed indexing (2 should have been 1.1, which affects the 1996 whole series). (WG mailing list response to TS posted on 1997 Nov. 3rd) 1998 o Fixed the 480 "timeouts" which should be 408s (note this 1999 error was introduced with changes made in this section in 2000 the 03 version. (NC-individual email Oct 31) 2001 o Fixed missing " on the "Busy Here" on the INVITE to UA5 in 2002 4.5.1. (NC-individual email Oct 31) 2004 Changes from the 03 to the 04 version: 2005 o Editorial nits: 2006 o Removed second reference to "call center" in Overview 2007 section. (EB) 2008 o Changed square brackets on references to requirements to 2009 parenthesis so they wouldn't appear to be external 2010 references. (EB) 2011 o Moved the updates to table 2 in section 4.1, so that it 2012 appears right after the paragraph discussing in which 2013 messages the header can appear. (RM) 2014 o Section 3.2: 2015 o Moved discussion of new security solution proposals per 2016 updated identity draft and rohan's body addition to section 2017 6 as they're not relevant to the solution in this document 2018 (per (JRE-1)). 2019 o Per IETF-60 discussion and Rohan's input, added a statement 2020 that if TLS isn't available on the connection over which 2021 the History-info is being forwarded, either a redirection 2022 (per identity document) is required or the History-info is 2023 not forwarded. 2024 o Section 3.3: 2025 o 2nd paragraph: adding clarification text "In the latter 2026 case,.." to the last sentence. (JRE-2) 2027 o Last paragraph: Clarified in the last sentence that if there 2028 is no impact on the application due to privacy 2029 considerations, why that is so MUST also be explained by 2030 that application. (EB) 2031 o Section 4.1: 2032 o Added SUBSCRIBE and PUBLISH to the list of messages in which 2033 History-Info header may appear. (JRE-3/10) 2034 o Changed the wording in the text descriptions of the fields 2035 to be non-normative (i.e. not caps for the reserved words 2036 in RFC 2119). (KD) 2037 o In the text description for the Index, clarified that the 2038 entries are added in a specific order, with the indexing to 2039 ensure the proper ordering. (JRE-4) 2040 o In the text descriptions for the Reason and Privacy 2041 parameters, changed the references of "Request URI" to "hi- 2042 targeted-to-uri" to explicitly refer to the field in the 2043 header entry. (JRE-5) 2044 o In the ABNF syntax, changed the "hist-info" field name to 2045 "hi-entry". This is then used throughout the remainder of 2046 the document to refer to a "History-Info header entry". 2047 (Note, this impacted the text primarily in section 4.3 - 2048 specifically )(JRE-8/9) 2049 o Section 4.2: Added appropriate hex characters for the escaped 2050 headers in the example (e.g. for ", = and ;). (LIST 10/15) 2051 o Section 4.3.1: changed "notified" to "aware" in terms of 2052 application interface to be less specific about interface to 2053 application (consistent with 4.3.2) 2054 o Section 4.3.2: same change as in 4.3.1. Capitalized "should" in 2055 last sentence. (EB) 2056 o Section 4.3.3: Clarified item 4 to be specific that the privacy 2057 header may be used when the request is being forwarded within 2058 the same domain (accomodating the scenario which allows 2059 information to only be forwarded within the domain in which it 2060 was retargeted). (JRE-11) 2061 o Section 4.3.3.1: rewording to include explicit references to hi- 2062 entry [JRE-8/9] and changed the "header should be added 2063 following..." to "the hi-entry MUST be added following..." (JRE- 2064 4) 2065 o Section 4.3.3.1.1: Reworded privacy section for clarity. 2066 Basically, need to tag each of the entires with 2067 "privacy=history" for retargeting within the domain and strip 2068 out the entries when leaving the domain IF the request has a 2069 privacy header of Session, Header or History or local policy 2070 requires. (JRE-13) 2071 o Section 4.3.3.1.2: Added the use of a Reason header in a 2072 response, as the Reason field associated with a retargeted URI. 2073 (LIST-10/5) 2074 o Section 4.3.3.1.3: 2075 o Clarified that the number of hops is reflected by the total 2076 number of dots (and not the value of the digits) (JRE-14.1) 2078 o Deleted last sentence of 1st paragraph as that was a 2079 holdover from a previous version. (JRE-14.2) 2080 o Item 5: clarified that the referenced scenario is forking 2081 and that the response consists of the aggregated (rather 2082 than the word "amalgamated") information. (JRE-15) 2083 o Section 4.3.3.2: 2084 o Clarified that response processing for History-Info follows 2085 the general processing described in section 16.7 of 2086 RFC3261. (related to JRE-15) 2087 o More detail added on the processing of responses with 2088 Privacy header. (LIST-8/18) 2089 o Section 4.4: Added text addressing the security when TLS is not 2090 available, per Rohan's comment above. 2091 o Section 5: 2092 o Changed the "should" to a "MUST" in the 1st application 2093 consideration in terms of the requirement to define default 2094 behavior should the information not be available, due to 2095 History-Info being an optional header. (EB) 2096 o Updated the 5th consideration for security to reflect the 2097 lack of information due to potential TLS inavailability for 2098 a connection, thus the potential for no History-Info header 2099 (per Rohan's comment). 2100 oSection 6: 2101 o Updated security considerations per TLS issue (Rohan) and to 2102 reference the new security solution proposals. 2103 o Added discussion of new security solution proposals per 2104 updated identity document and rohan's body addition. 2105 oAppendix: 2106 o Added overview clarifying that flows are informational and 2107 not normative. 2108 o Changed domains to appropriate example.com and example.net 2109 ones. 2110 o A.1 Added message details 2111 o A.2 Removed as this is redundant since this example is what 2112 is now in section 4.2. 2114 Changes from the 02 to the 03 version: 2115 o Editorial changes: Updating to the new template to reflect new 2116 IPR guidelines, ensuring that the normative text is complete 2117 and accurate in section 4.1, removing "Editor's Notes", etc. 2118 o Section 4.5: Fixed error in cause (408 -> 480). 2119 o Examples: changed the domain to "example.com", IP addresses to 2120 the 192.0.2.0/24 range, changed occurrences of "Reason:" to 2121 "Reason=", added use of Privacy header to examples. 2122 o Added text to reflect WG consensus on Issue-1: Privacy 2123 indication for History-Info entries. Proposed an extension to 2124 the priv-values defined in RFC 3323 in abstract and section 2125 3.3, impacting the protocol structure in section 4.1 and 2126 processing in 4.3.3 (and 4.3.3.1 and 4.3.3.2). In addition, 2127 the new priv-value needs to be registered with IANA, per 2128 section 7. 2129 o Removed Open Issues section. For Issue-2, there was not WG 2130 consensus to define an algorithm for bounding the number of 2131 History-Info entries, but rather that is left as an 2132 implementation decision. 2133 o Updated Security discussions to reflect WG consensus that TLS 2134 is mandatory and sufficient for general History-Info 2135 implementation. The e2m and m2m security solutions can be 2136 applied to History-Info when they become available to provide a 2137 more robust SIP solution. 2138 o Section 4.1: Added additional text to ensure that all the 2139 information in the History-Info header is appropriately and 2140 normatively described (in text). 2141 o Added text in section 4.3.1 and an example to the appendices to 2142 address the UAC having added multiple History-Info headers for 2143 the case where the 3xx response goes back to the UAC and it's 2144 the UAC that retargets the INVITE request. 2145 o Clarified the addition of the Reason header in section 2146 4.3.3.1.2. 2147 o Further delineated the basic rules in section 4.3.3.1.3 for 2148 calculating the index for various scenarios, as this was still 2149 causing some confusion. 2151 Changes from the 01 to the 02 version: 2153 o Merged the SIPPING WG requirements draft into this document. 2154 Note that this increments the section references in the 2155 remainder of the document by 2 (and by 3 for Security and IANA 2156 considerations due to new section added). Also, removed 2157 redirect server from ISSUER-req since the solution identified 2158 this as not being required (or desirable). 2159 o Added an explicit privacy requirement (PRIV-req-3) for the 2160 proxy's role in recognizing and maintaining privacy associated 2161 with a Request-URI being captured in History-Info due to local 2162 policy. (Note, that the text was already there, it just wasn't 2163 highlighted as an explicit requirement). 2164 o Clarified the use of CRLF and spacing in the example headers in 2165 section 4.2. 2166 o Removed the compact form for the header since unknown headers 2167 with multiple entries would not be recognized (i.e. this may 2168 cause parsing problems). 2169 o Added a summary of Application Considerations to address 2170 concerns about the optional usage of History-Info. 2171 o Converted the references from numbers to labels to avoid the 2172 continual problem of renumbering. 2173 o Minor editorial changes (per NITS highlighted by Rohan and Eric 2174 and some minor rewording for clarity). 2176 Changes from the 00 to the 01 version: 2178 o Attempted to be more explicit about the fundamental processing 2179 associated with the header. Removed definitions of new terms, 2180 only referencing the terms from the requirements in the context 2181 of the fundamental SIP processing implied by the terms. 2182 o Attempted to clarify the Index and the related processing. 2183 o Added more detail addressing the privacy requirements. 2184 o Added a bit more detail on security. The security solution 2185 remains in a separate document and this document will need 2186 updating once that is completed. 2187 o Updated the examples (in section 2.5 and appendix) and clarified 2188 the definition and the maintenance of the Index in sections 2.1 2189 and 2.3.3.1. 2190 o Clarified the Reason description in section 2.1. There had been 2191 an error in the description of the processing that was a remnant 2192 of the change to include only a single URI for each History-Info 2193 header. 2194 o Miscellaneous editorial changes (i.e. HistInfo -> Histinfo, 2195 etc.) 2197 Changes from individual draft-barnes-sipping-history-info-02 to the 2198 00 WG version: 2199 o Updated references and added reference to Security solution 2200 draft. 2201 o Removed appendix D which included background on analysis of 2202 solution options. 2203 o Cleaned up the document format per rfc2223bis. 2204 o Strengthened the inclusion of the INDEX as a MUST (per 2205 discussion at IETF-56). 2206 o Added text around the capturing of the Reason (SHOULD be 2207 captured for SIP responses and MAY be captured for other things 2208 such as timeouts). 2209 o Clarified the response processing 2.3.3.2 to include 2210 provisional responses and the sending of a 183 to convey 2211 History-Info. 2212 Added section 2.3.4 to address Redirect Server behavior. 2214 Intellectual Property Statement 2216 The IETF takes no position regarding the validity or scope of any 2217 intellectual property or other rights that might be claimed to 2218 pertain to the implementation or use of the technology described 2219 in this document or the extent to which any license under such 2220 rights might or might not be available; neither does it represent 2221 that it has made any effort to identify any such rights. 2223 Information on the IETF's procedures with respect to rights in 2224 IETF Documents can be found in BCP 78 and 79. 2226 Copies of IPR disclosures made to the IETF Secretariat and any 2227 assurances of licenses to be made available, or the result of an 2228 attempt made to obtain a general license or permission for the use 2229 of such proprietary rights by implementers or users of this 2230 specification can be obtained from the IETF on-line IPR repository 2231 at http://www.ietf.org/ipr. 2233 The IETF invites any interested party to bring to its attention 2234 any copyrights, patents or patent applications, or other 2235 proprietary rights which may cover technology that may be required 2236 to implement this standard. Please address the information to the 2237 IETF at ietf-ipr.org. 2239 Full Copyright Statement 2241 Copyright (C) The Internet Society (2005). This document is subject 2242 to the rights, licenses and restrictions contained in BCP 78, and 2243 except as set forth therein, the authors retain all their rights. 2245 This document and the information contained herein are provided on an 2246 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2247 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2248 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2249 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2250 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2251 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2253 Acknowledgment 2255 Funding for the RFC Editor function is currently provided by the 2256 Internet Society.