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