idnits 2.17.1 draft-ietf-sip-history-info-03.txt: -(1217): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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 1872. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1855. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1878), 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: ---------------------------------------------------------------------------- == There are 4 instances of lines with non-ascii characters in the document. 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 516 has weird spacing: '...r field whe...' == Line 1140 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 '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: 'REQNAME-req' is mentioned on line 129, but not defined == Missing Reference: 'CAPABILITY-req' is mentioned on line 317, but not defined == Missing Reference: 'CONTENT-req' is mentioned on line 319, but not defined == Missing Reference: 'REQUEST-VALIDITY-req' is mentioned on line 328, but not defined == Missing Reference: 'ISSUER-req' is mentioned on line 329, but not defined == Missing Reference: 'GENERATION-req' is mentioned on line 349, but not defined == Missing Reference: 'FORWARDS-req' is mentioned on line 349, but not defined == Missing Reference: 'BACKWARDS-req' is mentioned on line 356, but not defined == Missing Reference: 'OPTIONALITY-req' is mentioned on line 365, but not defined == Missing Reference: 'SEC-req-4' is mentioned on line 373, but not defined == Missing Reference: 'SEC-req-3' is mentioned on line 376, but not defined == Missing Reference: 'SEC-req-1' is mentioned on line 378, but not defined == Missing Reference: 'SEC-req-2' is mentioned on line 465, but not defined == Missing Reference: 'PRIV-req-1' is mentioned on line 413, but not defined == Missing Reference: 'PRIV-req-3' is mentioned on line 423, but not defined -- Looks like a reference, but probably isn't: '4' on line 656 == Missing Reference: 'RFCXXXX' is mentioned on line 1129, but not defined == Missing Reference: 'RFC 3665' is mentioned on line 1837, but not defined == Unused Reference: 'RFC2234' is defined on line 1248, 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? -- Possible downref: Normative reference to a draft: ref. 'SIPIISEC' == Outdated reference: A later version (-15) exists of draft-ietf-sipping-service-examples-05 == Outdated reference: A later version (-06) exists of draft-ietf-sip-identity-01 Summary: 9 errors (**), 0 flaws (~~), 27 warnings (==), 10 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-03.txt Editor 3 Category: Standards Track Nortel Networks 5 Expires: January 8, 2005 July 8, 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 January 8th, 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.......................................7 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...................10 64 4.1 Protocol Structure of History-Info........................10 65 4.2 Protocol Examples.........................................12 66 4.3 Protocol usage............................................12 67 4.4 Security for History-Info.................................17 68 4.5 Example Applications using History-Info...................18 69 5. Application Considerations....................................22 70 6. Security Considerations.......................................23 71 7. IANA Considerations...........................................23 72 Normative References.............................................26 73 Informational References.........................................27 74 Appendix A Forking Scenarios....................................28 75 A.1 Sequentially forking (History-Info in Response)...........28 76 A.2 Sequential Forking (with Success).........................30 77 Appendix B Voicemail............................................31 78 Appendix C Automatic Call Distribution Example..................36 79 Appendix D Session via Redirect and Proxy Servers................37 80 Full Copyright Statement.........................................40 82 Overview 84 Many services that SIP is anticipated to support require the ability 85 to determine why and how the call arrived at a specific application. 86 Examples of such services include (but are not limited to) sessions 87 initiated to call centers via "click to talk" SIP URLs on a web page, 88 "call history/logging" style services within intelligent "call 89 management" software for SIP UAs and calls to voicemail servers and 90 call centers. While SIP implicitly provides the redirect/retarget 91 capabilities that enable calls to be routed to chosen applications, 92 there is currently no standard mechanism within SIP for communicating 93 the history of such a request. This "request history" information 94 allows the receiving application to determine hints about how and why 95 the call arrived at the application/user. This draft defines a new 96 SIP header, History-Info, to provide a standard mechanism for 97 capturing the request history information to enable a wide variety of 98 services for networks and end users. The History-Info header 99 provides a building block for development of new services. 101 Section 1 provides additional background motivation for the Request 102 History capability. Section 2 identifies the requirements for a 103 solution, with Section 3 providing an overall description of the 104 solution. 106 Section 4 provides the details of the additions to the SIP protocol. 107 Example uses of the new header are included in Section 4.5, with 108 additional scenarios included in the Appendix. It is anticipated that 109 these would be moved and progressed in a general Service examples 110 draft such as [SIPSVCEX] or individual informational drafts 111 describing these specific services, since the History-Info header is 112 just one of the building blocks for implementing these services. 113 Individual drafts would be particularly useful for documenting 114 services for which there are multiple solutions, as it is not the 115 intent, nor is it within the scope, of this draft to prescribe a 116 complete solution for any of these applications. 118 Section 5 summarizes the application considerations identified in the 119 previous sections. Section 6 summarizes the security solution. 121 Conventions used in this document 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 125 document are to be interpreted as described in RFC 2119 [RFC2119]. 127 In order to provide a cross reference of the solution description to 128 the requirements without reiterating the entirety of the requirements 129 inline, the requirements are referenced as [REQNAME-req] following 130 the text or paragraph which explicitly satisfies the requirement. 132 1.Background: Why define a Generic "Request History" capability? 134 SIP implicitly provides redirect/retarget capabilities that enable 135 calls to be routed to specific applications as defined in [RFC3261]. 136 The term retarget will be used henceforth in this draft to refer to 137 the process of a Proxy Server/UAC changing a URI in a request and 138 thus changing the target of the request. This term is chosen to 139 avoid associating this request history only with the specific SIP 140 Redirect Server capability that provides for a response to be sent 141 back to a UAC requesting that the UAC should retarget the original 142 request to an alternate URI. The rules for determining request 143 targets as described in section 16.5 of [RFC3261] are consistent with 144 the use of the retarget term in this draft. 146 The motivation for the request history is that in the process of 147 retargeting old routing information can be forever lost. This lost 148 information may be important history that allows elements to which 149 the call is retargeted to process the call in a locally defined, 150 application specific manner. The proposal in this draft is to provide 151 a mechanism for transporting the request history. It is not 152 proposing any application specific behavior for a Proxy or UA upon 153 receipt of the information. Indeed, such behavior should be a local 154 decision for the recipient application. 156 Current network applications provide the ability for elements 157 involved with the call to exchange additional information relating to 158 how and why the call was routed to a particular destination. The 159 following are examples of such applications: 161 1. Web "referral" applications, whereby an application residing 162 within a web server determines that a visitor to a website has 163 arrived at the site via an "associate" site which will receive 164 some "referral" commission for generating this traffic, 166 2. Email forwarding whereby the forwarded-to user obtains a "history" 167 of who sent the email to whom and at what time 169 3. Traditional telephony services such as Voicemail, call-center 170 "automatic call distribution", and "follow-me" style services. 172 Several of the aforementioned applications currently define 173 application specific mechanisms through which it is possible to 174 obtain the necessary history information. 176 In addition, request history information could be used to enhance 177 basic SIP functionality by providing the following: 179 4. Some diagnostic information for debugging SIP requests. 181 5. A stronger security solution for SIP. A side effect is that each 182 proxy which captures the "request history" information in a secure 183 manner provides an additional means (without requiring signed keys) 184 for the original requestor to be assured that the request was 185 properly retargeted. 187 2. "Request History" Requirements 189 The following list constitutes a set of requirements for a "Request 190 History" capability. 192 1) CAPABILITY-req: The "Request History" capability provides a 193 capability to inform proxies and UAs involved in processing a request 194 about the history/progress of that request. While this is inherently 195 provided when the retarget is in response to a SIP redirect, it is 196 deemed useful for non-redirect retargeting scenarios, as well. 198 2) OPTIONALITY-req: The "Request History" information is optional. 200 2.1) In many cases, it is anticipated that whether the history is 201 added to the Request would be a local policy decision enforced by the 202 specific application, thus no specific protocol element is needed. 204 2.2) Due to the capability being "optional" from the SIP protocol 205 perspective, the impact to an application of not having the "Request 206 History" must be described. Applicability guidelines to be addressed 207 by applications using this capability must be provided as part of the 208 solution to these requirements. 210 3) GENERATION-req: "Request History" information is generated when 211 the request is retargeted. 213 3.1) In some scenarios, it might be possible for more than one 214 instance of retargeting to occur within the same Proxy. A proxy 215 should also generate Request History information for the 'internal 216 retargeting'. 218 3.2) An entity (UA or proxy) retargeting in response to a redirect or 219 REFER should include any Request History information from the 220 redirect/REFER in the new request. 222 4) ISSUER-req: "Request History" information can be generated by a UA 223 or proxy. It can be passed in both requests and responses. 225 5) CONTENT-req: The "Request History" information for each 226 occurrence of retargeting, shall include the following: 228 5.1) The new URI or address to which the request is in the process 229 of being retargeted, 231 5.2) The URI or address from which the request was retargeted, 233 5.3) The reason for the Request-URI or address modification, 235 5.4) Chronological ordering of the Request History information. 237 6) REQUEST-VALIDITY-req: Request-History is applicable to requests 238 not sent within an established dialog. (i.e. INVITE, REGISTER, 239 MESSAGE, and OPTIONS). 241 7) BACKWARDS-req: Request-History information may be passed from the 242 generating entity backwards towards the UAC. This is needed to enable 243 services that inform the calling party about the dialog establishment 244 attempts. 246 8) FORWARDS-req: Request-History information may also be included by 247 the generating entity in the request, if it is forwarded onwards. 249 2.1 Security Requirements 251 The Request History information is being inserted by a network 252 element retargeting a Request, resulting in a slightly different 253 problem than the basic SIP header problem, thus requiring specific 254 consideration. It is recognized that these security requirements can 255 be generalized to a basic requirement of being able to secure 256 information that is inserted by proxies. 258 The potential security problems include the following: 259 1) A rogue application could insert a bogus Request History entry 260 either by adding an additional entry as a result of retargeting or 261 entering invalid information. 263 2) A rogue application could re-arrange the Request History 264 information to change the nature of the end application or to mislead 265 the receiver of the information. 267 Thus, a security solution for "Request History" must meet the 268 following requirements: 270 1) SEC-req-1: The entity receiving the Request History must be able 271 to determine whether any of the previously added Request History 272 content has been altered. 274 2) SEC-req-2: The ordering of the Request History information must be 275 preserved at each instance of retargeting. 277 3) SEC-req-3: The entity receiving the information conveyed by the 278 Request History must be able to authenticate the source of the 279 information. 281 4) SEC-req-4: To ensure the confidentiality of the Request History 282 information, only entities which process the request should have 283 visibility to the information. 285 It should be noted that these security requirements apply to any 286 entity making use of the Request History information, either by 287 retargeting and capturing the information, or as an application 288 making use of the information received in either a Request or 289 Response. 291 2.2 Privacy Requirements 293 Since the Request URI that is captured could inadvertently reveal 294 information about the originator, there are general privacy 295 requirements that MUST be met: 297 1) PRIV-req-1: The entity retargeting the Request must ensure that it 298 maintains the network-provided privacy (as described in [RFC3323]) 299 associated with the Request as it is retargeted. 301 2) PRIV-req-2: The entity receiving the Request History must maintain 302 the privacy associated with the information. 304 In addition, local policy at a proxy may identify privacy 305 requirements associated with the Request URI being captured in the 306 Request History information. 308 3) PRIV-req-3: Request History information subject to privacy 309 requirements shall not be included in outgoing messages unless it is 310 protected as described in [RFC3323]. 312 3. Request History Information Description 314 The fundamental functionality provided by the request history 315 information is the ability to inform proxies and UAs involved in 316 processing a request about the history or progress of that request 317 [CAPABILITY-req]. The solution is to capture the Request-URIs as a 318 request is forwarded in a new header for SIP messages: History-Info 319 [CONTENT-req]. This allows for the capturing of the history of a 320 request that would be lost with the normal SIP processing involved in 321 the subsequent forwarding of the request. This solution proposes no 322 changes in the fundamental determination of request targets or in the 323 request forwarding as defined in sections 16.5 and 16.6 of the SIP 324 protocol specification [RFC3261]. 326 The History-Info header can appear in any request not associated with 327 an established dialog, which includes INVITE, REGISTER, MESSAGE, 328 REFER and OPTIONS [REQUEST-VALIDITY-req] and any valid response to 329 these requests.[ISSUER-req] 330 The History-Info header is added to a Request when a new request is 331 created by a UAC or Proxy, or when the target of a request is 332 changed. The term 'retarget' is introduced to refer to this changing 333 of the target of a request and the subsequent forwarding of that 334 request. It should be noted that retargeting only occurs when the 335 Request-URI indicates a domain for which the processing entity is 336 responsible. In terms of the SIP protocol, the processing associated 337 with retargeting is described in sections 16.5, and 16.6 of 338 [RFC3261]. As described in section 16.5 of [RFC3261], it is possible 339 for the target of a request to be changed by the same proxy multiple 340 times (referred to as 'internal retargeting' in section 2), as the 341 proxy MAY add targets to the target set after beginning Request 342 Forwarding. Section 16.6 of [RFC3261] describes Request Forwarding. 343 It is during this process of Request Forwarding, that the History 344 Information is captured as an optional, additional header field. 345 Thus, the addition of the History-Info header does not impact 346 fundamental SIP Request Forwarding. An entity (UA or proxy) changing 347 the target of a request in response to a redirect or REFER SHOULD 348 also propagate any History-Info header from the initial Request in 349 the new request [GENERATION-req, FORWARDS-req]. 351 3.1 Optionality of History-Info 353 The History-Info header is optional in that neither UAs nor Proxies 354 are required to support it. A new Supported header, Histinfo, is 355 included in the Request to indicate whether the History-Info header 356 is returned in Responses [BACKWARDS-req]. In addition to the Histinfo 357 Supported header, local policy determines whether or not the header 358 is added to any request, or for a specific Request-URI, being 359 retargeted. It is possible that this could restrict the applicability 360 of services which make use of the Request History Information to be 361 limited to retargeting within domain(s) controlled by the same local 362 policy, or between domain(s) which negotiate policies with other 363 domains to ensure support of the given policy, or services for which 364 "complete" History Information isn't required to provide the service. 365 [OPTIONALITY-req] All applications making use of the History-info 366 header MUST clearly define the impact of the information not being 367 available and specify the processing of such a request. 369 3.2 Securing History-Info 371 This draft defines a new header for SIP. The draft RECOMMENDs the use 372 of TLS as a mandatory mechanism to ensure the overall confidentiality 373 of the History-Info headers [SEC-req-4]. This results in History-Info 374 having at least the same level of security as other headers in SIP 375 which are inserted by intermediaries. With the level of security 376 provided by TLS [SEC-req-3], the information in the History-Info 377 header can thus be evaluated to determine if information has been 378 removed by evaluating the indices for gaps [SEC-req-1, SEC-req-2]. 380 It would be up to the application to define whether it can make use 381 of the information in the case of missing entries. 383 A more robust security solution would need to consider the aspects of 384 the problem that are different than the hop by hop security problem 385 solved by TLS, as each hop is not required to add the History-Info 386 header. History-Info also introduces a slightly different problem 387 than the basic SIP header or Identity [SIPATHID] problems, which is 388 focused on securing the information in the initial request end to 389 end. The History-Info header is being inserted by an entity as it 390 targets and forwards a Request, thus the requirements for the 391 security solution are similar to the Via and Record-Route headers. 392 For the History-Info header, the general requirement is to secure a 393 header that is inserted by an intermediary and then subsequently 394 referenced, by other intermediaries to build the next header entry, 395 or by an end application using the information to provide a service. 397 Thus, the general requirement for a more robust security solution for 398 SIP takes the form of a middle to middle and middle to end security 399 solution, which is addressed in a separate document [SIPIISEC]. The 400 use of the middle-to-end security solution discussed in [SIPIISEC] 401 allows the integrity of the History-Info to be ascertained as it 402 traverses the intermediaries. Thus, including the History-Info 403 header in SIP Requests and securing in this manner would add an 404 additional level of security end to end, assuring the initiator of a 405 Request that it has indeed reached the intended recipient. 407 3.3 Ensuring the Privacy of History-Info 409 Since the History-Info header can inadvertently reveal information 410 about the requestor as described in [RFC3323], the Privacy header 411 SHOULD be used to determine whether an intermediary can include the 412 History-Info header in a Request that it receives and forwards [PRIV- 413 req-2] or that it retargets [PRIV-req-1]. Thus, the History-Info 414 header SHOULD not be included in Requests where the requestor has 415 indicated a priv-value of Session or Header level privacy. 417 In addition, the History-Info header can reveal general routing 418 information, which may be viewed by a specific intermediary or 419 network, to be subject to privacy restrictions. Thus, local policy 420 MAY also be used to determine whether to include the History-Info 421 header at all, whether to capture a specific Request-URI in the 422 header, or whether it be included only in the Request as it is 423 retargeted within a specific domain. [PRIV-req-3] This is 424 accomplished by adding a new priv-value to the Privacy header [RFC 425 3323] indicating whether any or a specific History-Info header(s) 426 SHOULD be forwarded. 428 It is recognized that satisfying the privacy requirements can impact 429 the functionality of this solution by overriding the request to 430 generate the information. As with the optionality and security 431 requirements, applications making use of History-Info SHOULD address 432 any impact this may have. 434 4 Request History Information Protocol Details 436 This section contains the details and usage of the proposed new SIP 437 protocol elements. It also discusses the security aspects of the 438 solution. 440 4.1 Protocol Structure of History-Info 442 History-Info is a header field as defined by [RFC3261]. It is an 443 optional header field and MAY appear in any request or response not 444 associated with a dialog or which starts a dialog. For example, 445 History-Info MAY appear in INVITE, REGISTER, MESSAGE, REFER and 446 OPTIONS and any valid responses, plus NOTIFY requests which initiate 447 a dialog. 449 The History-Info header carries the following information, with the 450 mandatory parameters REQUIRED when the header is included a request 451 or response: 453 o Targeted-to-URI (hi-targeted-to-uri): A mandatory parameter for 454 capturing the Request URI for the specific Request as it is 455 forwarded. 457 o Index (hi-index): A mandatory parameter for History-Info 458 reflecting the chronological order of the information, indexed 459 to also reflect the forking and nesting of requests. The format 460 for this parameter is a string of digits, separated by dots to 461 indicate the number of forward hops and retargets. This results 462 in a tree representation of the history of the request, with the 463 lowest level index reflecting a branch of the tree. By including 464 the index and securing the header, the ordering of the History- 465 info headers in the request is assured.[SEC-req-2] In addition, 466 applications MAY extract a variety of metrics (total number of 467 retargets, total number of retargets from a specific branch, 468 etc.) based upon the index values. 470 o Reason: An optional parameter for History-info, reflected in the 471 History-Info header by including the Reason Header [RFC3326] 472 escaped in the Request URI being retargeted. A reason is not 473 included for a Request URI when it is first added in a History- 474 info header, but rather is added when that particular Request- 475 URI is retargeted. Note, that this does appear to complicate 476 the security problem, however, retargeting only occurs when the 477 Request-URI indicates a domain for which the processing entity 478 is responsible, thus it would be the same processing entity that 479 initially added the Request-URI to the header that would be 480 updating it with the Reason. 482 o Privacy: An optional parameter for History-info, reflected in 483 the History-Info header by including the Privacy Header 484 [RFC3323] with a priv-value of "history" escaped in the Request 485 URI or by adding the Privacy header with a priv-value of 486 "history" to the Request. The use of the Privacy Header with a 487 priv-value of "history" indicates whether a specific or all 488 History-Info headers SHOULD NOT be forwarded. 490 o Extension (hi-extension): An optional parameter to allow for 491 future optional extensions. As per the [RFC3261], any 492 implementation not understanding an extension SHOULD ignore it. 494 The following summarizes the syntax of the History-Info header, based 495 upon the standard SIP syntax [RFC3261]: 497 History-Info = "History-Info" HCOLON 499 hist-info *(COMMA hist-info) 501 hist-info = hi-targeted-to-uri *( SEMI hi-param ) 503 hi-targeted-to-uri= name-addr 505 hi-param = hi-index / hi-extension 507 hi-index = "index" EQUAL 1*DIGIT *(DOT 1*DIGIT) 509 hi-extension = generic-param 511 This document adds the following entry to Table 2 of [RFC3261]. 512 Additions to this table are also provided for extension methods 513 at the time of publication of this document. This is provided as a 514 courtesy to the reader and is not normative in any way. 516 Header field where proxy ACK BYE CAN INV OPT REG MSG 517 ------------ ----- ----- --- --- --- --- --- --- --- 518 History-Info amdr - - - o o o o 520 SUB NOT REF INF UPD PRA PUB 521 --- --- --- --- --- --- --- 522 History-Info amdr - o o - - - - 524 4.2 Protocol Examples 526 The following provides some examples of the History-Info header. Note 527 that the backslash, CRLF, and spacing between the fields in the 528 examples below are for readability purposes only. 530 History-Info:; index=1; foo=bar 533 History-Info: ; index=1.1, 535 ;index=1.2, 537 ;index=1.3 539 4.3 Protocol usage 541 This section describes the processing specific to UAs and Proxies for 542 the History-Info header, the Histinfo option tag and the priv-value 543 of "history". As discussed in section 1, the fundamental objective is 544 to capture the target Request-URIs as a request is forwarded. This 545 allows for the capturing of the history of a request that would be 546 lost due to subsequent (re)targeting and forwarding. To accomplish 547 this for the entire history of a request, either the UAC must capture 548 the Request-URI in the initial request or a proxy must add History- 549 Info headers for both the Request-URI in the initial request and the 550 target Request-URI as the request is forwarded. The basic processing 551 is for each entity forwarding a request to add a History-Info header 552 for the target Request-URI, updating the index and adding the Reason 553 as appropriate for any retargeted Request-URI. 555 4.3.1 UAC Behavior 557 The UAC SHOULD include the Histinfo option tag in the Supported 558 header in any request not associated with an established dialog for 559 which the UAC would like the History-Info in the Response. In 560 addition, the UAC SHOULD initiate the capturing of the History 561 Information by adding a History-Info header using the Request-URI of 562 the request as the hi-targeted-to-uri and initializing the index to 563 the RECOMMENDED value of 1 in the History-Info header. 565 In the case where the request is routed to a redirect server and the 566 UAC receives a 3xx response with a Contact header, the UAC MAY 567 maintain the previous History-Info entry(-ies) in the request. A new 568 History-Info entry MAY then be added for the URI from the Contact 569 header (which will become the new Request-URI). In this case, the 570 index is created by reading and incrementing the value of the index 571 from the previous history entry, thus following the same rules as 572 those prescribed for a proxy in retargeting, described in section 573 4.3.3.1.3. An example of this scenario can be found in Appendix D. 575 A UAC that does not want History-Info headers added due to privacy 576 considerations SHOULD include a Privacy header with a priv-value(s) 577 of "session", "header" or "history" in the request. 579 The processing of the History-Info header received in the Response is 580 application specific and outside the scope of this draft. However, 581 the validity of the information SHOULD be ensured prior to any 582 application usage. For example, the entries MAY be evaluated to 583 determine gaps in indices, which could indicate that an entry has 584 been maliciously removed or removed for privacy reasons. Either way, 585 an application MAY want to be notified of potentially missing 586 information. 588 4.3.2 UAS Behavior 590 The processing of the History-Info header by a UAS in a Request 591 depends upon local policy and specific applications at the UAS which 592 might make use of the information. Prior to any application usage of 593 the information, the validity SHOULD be ascertained. For example, 594 the entries MAY be evaluated to determine gaps in indices, which 595 could indicate that an entry has been maliciously removed or removed 596 for privacy reasons. Either way, an application MAY want to be 597 notified of potentially missing information. 599 If the Histinfo option tag is received in a request, the UAS should 600 include any History-Info received in the request in the subsequent 601 response. 603 4.3.3 Proxy Behavior 605 The inclusion of the History-Info header in a Request does not alter 606 the fundamental processing of proxies for determining request targets 607 as defined in section 16.5 of [RFC3261]. Whether a proxy adds the 608 the History-Info header as it forwards a Request depends upon the 609 following considerations: 610 1. Whether the Request contains the Histinfo option tag in the 611 Supported header. 612 2. Whether the proxy supports the History-Info header. 613 3. Whether the Request contains a Privacy header with a priv- 614 value of "session", "header" or "history". 615 4. Whether any History-Info header added for a proxy/domain 616 should go outside that domain. An example being the use of 617 the History-Info header within the specific domain in which 618 it is retargeted, however, policies (for privacy, user and 619 network security, etc.) prohibit the exposure of that 620 information outside that domain. A proxy MAY insert the 621 Privacy header with a priv-value of "history" to indicate 622 this. An example of such an application is provided in 623 Appendix C. 624 5. Whether the History-Info header is added for a specific 625 Request URI due to local privacy policy considerations. A 626 proxy MAY add the Privacy header with a priv-value of 627 "history" associated with the specific hi-targeted-to-uri. 629 An example policy would be a proxy that only adds the History-Info 630 header if the Histinfo option tag is in the Supported header. Other 631 proxies may have a policy that they always add the header, but never 632 forward it outside a particular domain, accomplishing this by adding 633 a Privacy header with a priv-value of "history" to allow the 634 information to be collected for internal retargeting only. 636 Each application making use of the History-Info header SHOULD address 637 the impacts of the local policies on the specific application (e.g. 638 what specification of local policy is optimally required for a 639 specific application and any potential limitations imposed by local 640 policy decisions). 642 Consistent with basic SIP processing of optional headers, proxies 643 SHOULD maintain History-Info headers, received in messages being 644 forwarded, independent of whether local policy supports History-Info. 646 The specific processing by proxies for adding the History-Info 647 headers in Requests and Responses is described in detail in the 648 following sections. 650 4.3.3.1 Adding the History-Info header to Requests 652 Upon evaluation of the considerations under which the History-Info 653 header is to be included in requests (e.g. no Privacy header 654 overriding inclusion, local policy supports, etc.), detailed in 655 section 4.3.3, a proxy SHOULD add a History-Info header as it 656 forwards a Request. Section 16.6 of [4] defines the steps to be 657 followed as the proxy forwards a Request. Step 5 prescribes the 658 addition of optional headers. Although, this would seem the 659 appropriate step for adding the History-info header, the interaction 660 with Step 6 "Postprocess routing information" and the impact of a 661 strict route in the Route header could result in the Request-URI 662 being changed, thus adding the History-info header between steps 8 663 (adding Via header) and 9 (adding Content-Length) is RECOMMENDED. 664 Note, that in the case of loose routing, the Request-URI does not 665 change during the forwarding of a Request, thus the capturing of 666 History-Info for such a request would result in duplicate Request- 667 URIs with different indices. The History-Info header SHOULD be added 668 following any History-Info header received in the request being 669 forwarded. Additionally, if a request is received that doesn't 670 include a History-Info header, the proxy MAY add an additional 671 History-Info header preceding the one being added for the current 672 request being forwarded. The index for this entry is RECOMMENDED to 673 start at 1. The following subsections define the details of creating 674 the information associated with and in the History-Info header. 676 4.3.3.1.1 Privacy in the History-Info header 678 If the proxy's local policies, per consideration 4 in section 4.3.3, 679 indicate that this History-Info entry and any entries added due to 680 subsequent retargeting should not be forwarded beyond the domain for 681 which this intermediary is responsible, then a Privacy header with a 682 priv-value of "history" SHOULD be added to the request, if there is 683 not already one, provided the request is being forwarded to a 684 specific URI associated with the domain(s) for which this entity is 685 responsible. 687 If a request is being forwarded to a Request URI associated with a 688 domain for which the proxy is not responsible, the proxy needs to 689 determine if there are any entries to be removed prior to forwarding. 690 Any headers associated with the domain(s) for which this proxy is 691 responsible SHOULD be removed prior to forwarding. 693 If through local policy, there is knowledge of privacy associated 694 with a specific URI being captured as the hi-targeted-to-uri, a 695 Privacy header with a priv-value of "history" SHOULD be associated 696 with this specific URI as the request is forwarded, if it is being 697 forwarded to a Request URI associated with a domain for which the 698 processing entity is responsible. 700 If a request is being forwarded to a Request URI, for which the 701 processing entity is not responsible, the proxy needs to determine if 702 there are any entries, that need to be removed prior to forwarding. 703 The proxy needs to determine if any of the specific URIs that have 704 been captured in the History-Info entries, associated with the 705 domain(s) for which it is responsible, have a priv-value of 706 "history". Each of these header entries SHOULD be removed from the 707 Request prior to forwarding. 709 4.3.3.1.2 Reason in the History-Info header 711 For retargets that are the result of an explicit SIP response, the 712 SIP Response Code that triggered the retargeting MUST be included in 713 the Reason header field of the Request URI that has been retargeted. 714 This should occur prior to the forwarding of the request, as it 715 associated with the previous hi-targeted-to-uri, since it reflects 716 the reason why the Request to that specific URI was not successful. 718 For retargets as a result of timeouts or internal events, a Reason 719 MAY be included in the Reason header field of the Request URI that 720 has been retargeted. 722 4.3.3.1.3 Indexing in the History-Info header 724 In order to maintain ordering and accurately reflect the nesting and 725 retargeting of the request, an index MUST be included along with the 726 Targeted-to-URI being captured. Per the ABNF in section 4.1, the 727 index consists of a dot delimited series of digits (e.g. 1.1.2), with 728 each dot reflecting the number of hops or level of nesting of the 729 request. Within each level, the number reflects the number of peer 730 entities to which the request has been routed. Thus, the indexing 731 results in a logical tree representation for the history of the 732 Request. It is recommended that for each level of indexing, the index 733 start at 1. It is recommended that an increment of 1 is used for 734 advancing to a new branch. For retargets within a proxy, the proxy 735 MUST maintain the current level of nesting by incrementing by 1 the 736 lowest/last digit of the index for each instance of retargeting, thus 737 reflecting the number of retargets (branches) within the proxy. 739 The basic rules for adding the index are summarized as follows: 741 1. Basic Forwarding: In the case of a Request that is being 742 forwarded, the index is determined by adding another level of 743 indexing since the depth/length of the branch is increasing. To 744 accomplish this, the proxy reads the value from the History-Info 745 header in the received request, if available, and adds another 746 level of indexing by appending the DOT delimiter followed by an 747 initial index for the new level RECOMMENDED to be 1. For example, 748 if the index in the last History-Info header field in the received 749 request is 1.1, this proxy would initialize its index to 1.1.1 and 750 forward the request. 752 2. Retargeting within a Proxy - 1st instance: For the first 753 instance of retargeting within a Proxy, the calculation of the 754 index follows that prescribed for basic forwarding. 756 3. Retargeting within a Proxy - subsequent instance: For each 757 subsequent retargeting of a request by the same proxy, another 758 branch is added. With the index for each new branch calculated by 759 incrementing the last/lowest digit at the current level, thus the 760 index in the next request forwarded by this same proxy, following 761 the example above, would be 1.1.2. 763 4. Retargeting based upon a Response: In the case of retargeting 764 due to a specific response (e.g. 302), the index would be 765 calculated per rule 3. That is, the lowest/last digit of the index 766 is incremented (i.e. a new branch is created), with the increment 767 RECOMMENDED to be 1. For example, if the index in the History-Info 768 header of the received request was 1.2, then the index in the 769 History-Info header field for the new hi-targeted-to-URI would be 770 1.3. 772 5. Retargeting the request in parallel: If the request forwarding 773 is done in parallel, the index MUST be captured for each forked 774 request per the rules above, with each new Request having a unique 775 index. The only difference in the messaging for this scenario and 776 the messaging produced per basic proxy retargeting in rules 2 and 3 777 is these forwarded requests do not have History-Info entries 778 associated with their peers. The proxy builds the subsequent 779 response (or request) using the amalgamated information associated 780 with each of those requests and including the header entries in the 781 order indicated by the indexing. Section 4.5 provides an example 782 of a parallel request scenario, highlighting this indexing 783 mechanism. 785 4.3.3.2 Processing History-Info in Responses 787 A proxy that receives a Request with the Histinfo option tag in the 788 Supported header, and depending upon a local policy supporting the 789 capture of History-Info, SHOULD return captured History-Info in 790 subsequent, provisional and final responses to the Request. 792 It should be noted that local policy considerations, for network and 793 intermediary privacy, MAY restrict the sending of the History-Info 794 headers added by the intermediary in subsequent responses. Thus, in 795 such cases, the proxy MAY remove from these responses the History- 796 Info headers which it inserted in the original forwarded request. 798 4.3.4 Redirect Server Behavior 800 A redirect server SHOULD NOT add any new History-Info, as that would 801 be done by the entity receiving the 3xx response. However, a redirect 802 server MAY include History-Info in responses by adding any History- 803 Info headers received in a request to a subsequent response. 805 4.4 Security for History-Info 807 As discussed in Section 1, the security requirements are partially 808 met by recommending the use of TLS (a basic SIP requirement per 809 [RFC3261]) for hop by hop security. In addition, the use of the 810 middle-to-end security solution discussed in [SIPIISEC] allows the 811 integrity of the History-Info to be ascertained as it traverses the 812 intermediaries. 814 4.5 Example Applications using History-Info 816 This scenario highlights an example where the History-Info in the 817 response is primarily of use in not retrying routes that have already 818 been tried by another proxy. Note, that this is just an example and 819 that there may be valid reasons why a Proxy would want to retry the 820 routes and thus, this would likely be a local proxy or even user 821 specific policy. 823 UA 1 sends a call to "Bob" to proxy 1. Proxy 1 forwards the request 824 to Proxy 2. Proxy 2 sends the requests in parallel and tries several 825 places (UA2, UA3 and UA4) before sending a response to Proxy 1 that 826 all the places are busy. Proxy 1, without the History-Info, would 827 try several some of the same places (e.g. UA3) based upon registered 828 contacts for "Bob", before completing at UA5. However, with the 829 History-Info, Proxy 1 determines that UA3 has already received the 830 invite, thus the INVITE goes directly to UA5. 832 Section 4.5.1 provides this same scenario using one of the privacy 833 mechanism, with Proxy2 adding the Privacy header indicating that the 834 History-Info header is not to be propagated outside P2's domain. This 835 scenario highlights the potential functionality lost with the use of 836 "history" privacy in the Privacy header for the entire request and 837 the need for careful consideration on the use of privacy for History- 838 Info. 840 Section 4.5.2 also provides the same scenario using one of the 841 privacy mechanisms, however, due to local policy at Proxy2, only one 842 of the Request-URIs (UA4) in the History-Info contains a priv-value 843 of "history", thus allowing some optimized functionality in the 844 routing of the request, but still maintaining privacy for specific 845 URIs. 847 Additional detailed scenarios are available in the appendix. 849 UA1 Proxy1 Proxy2 UA2 UA3 UA4 UA5 851 | | | | | | | 852 |--INVITE -->| | | | | | 853 | |-INVITE->| | | | | 854 Supported: Histinfo 855 History-Info: ;index=1, 856 ; index=2 857 | | | | | | | 858 | | |-INVITE>| | | | 859 History-Info: ;index=1, 860 ;index=2, 861 ;index=2.1 862 | | | | | | | 863 | | |-----INVITE ---->| | | 864 History-Info: ;index=1, 865 ; index=2, 866 ; index=2.2 867 | | | | | | | 868 | | |-------INVITE------------>| | 869 History-Info: ;index=1, 870 ; index=2, 871 ; index=2.3 873 /* All Responses from the INVITEs indicate non-success/non- 874 availability*/ 875 | | | | | | | 876 | |<-480 ---| | | | | 877 History-Info: ;index=1, 878 ; index=2, 879 ;index=2.1, 881 ; index=2.2, 883 ; index=2.3 885 | | | | | | | 886 /* Upon receipt of the response, P1 determines another route for the 887 INVITE, but finds that it matches a route already attempted 888 (e.g. UA3, thus the INVITE is only forwarded to UA5, where 889 the session is successfully established */ 890 | | | | | | | 891 | |----------------INVITE --------------------->| 892 History-Info: ;index=1, 893 ; index=2, 894 ;index=2.1, 896 ; index=2.2, 898 ; index=2.3 900 ;index=1.1 901 | | | | | | | 902 | |<-----200 OK---------------------------------| 903 |<--200 OK---| | | | | | 904 | | | | | | | 905 |--ACK --------------------------------------------------->| 906 4.5.1 Example with Privacy header for entire request at Proxy2 908 UA1 Proxy1 Proxy2 UA2 UA3 UA4 UA5 910 | | | | | | | 911 |--INVITE -->| | | | | | 912 | |-INVITE->| | | | | 913 Supported: Histinfo 914 History-Info: ;index=1, 915 ; index=2 916 | | | | | | | 917 | | |-INVITE>| | | | 918 Privacy: history 919 History-Info: ;index=1, 920 ;index=2, 921 ;index=2.1 922 | | | | | | | 923 | | |-----INVITE ---->| | | 924 Privacy: history 925 History-Info: ;index=1, 926 ; index=2, 927 ; index=2.2 928 | | | | | | | 929 | | |-------INVITE------------>| | 930 Privacy: history 931 History-Info: ;index=1, 932 ; index=2, 933 ; index=2.3 935 /* All Responses from the INVITEs indicate non-success/non- 936 availability and only the initial, received History-Info entries 937 are NOT returned to P1 due to the Privacy header value.*/ 938 | | | | | | | 939 | |<-480 ---| | | | | 940 History-Info: ;index=1, 941 ; index=2 942 | | | | | | | 943 /* Upon receipt of the response, P1 determines another route for the 944 INVITE, including UA3 which was attempted by P2, but due to 945 Privacy P1 is not aware of this, so UA3 is re-attempted prior to 946 forwarding the INVITE to UA5, where the session is successfully 947 established */ 948 | | | | | | | 949 | |--------------INVITE ----->| | | 950 History-Info: ;index=1, 951 ; index=2, 952 ; index=1.1 953 | | | | | | | 954 | |<-- 486 -------------------| | | 955 History-Info: ;index=1, 956 ; index=2, 957 ; index=1.1 958 | | | | | | | 959 | |----------------INVITE --------------------->| 960 History-Info: ;index=1, 961 ; index=2, 962 ;index=1.1, 964 ;index=1.2 965 | | | | | | | 966 | |<-----200 OK---------------------------------| 967 |<--200 OK---| | | | | | 968 | | | | | | | 969 |--ACK --------------------------------------------------->| 971 4.5.2 Example with Privacy header for specific URI (UA4) at Proxy2 973 UA1 Proxy1 Proxy2 UA2 UA3 UA4 UA5 975 | | | | | | | 976 |--INVITE -->| | | | | | 977 | |-INVITE->| | | | | 978 Supported: Histinfo 979 History-Info: ;index=1, 980 ; index=2 981 | | | | | | | 982 | | |-INVITE>| | | | 983 History-Info: ;index=1, 984 ;index=2, 985 ;index=2.1 986 | | | | | | | 987 | | |-----INVITE ---->| | | 988 History-Info: ;index=1, 989 ; index=2, 990 ; index=2.2 991 | | | | | | | 992 | | |-------INVITE------------>| | 993 History-Info: ;index=1, 994 ; index=2, 995 ; index=2.3 998 /* All Responses from the INVITEs indicate non-success/non- 999 availability. The History-Info associated with UA4 is not returned 1000 in the response due to the privacy header associated with that URI */ 1001 | | | | | | | 1002 | |<-480 ---| | | | | 1003 History-Info: ;index=1, 1004 ; index=2, 1005 ;index=2.1, 1007 ; index=2.2, 1009 | | | | | | | 1010 /* Upon receipt of the response, P1 determines another route for the 1011 INVITE, but finds that it matches a route already attempted 1012 (e.g. UA3), thus the INVITE is only forwarded to UA5, where 1013 the session is successfully established */ 1014 | | | | | | | 1015 | |----------------INVITE --------------------->| 1016 History-Info: ;index=1, 1017 ; index=2, 1018 ;index=2.1, 1020 ; index=2.2, 1022 ;index=1.1 1023 | | | | | | | 1024 | |<-----200 OK---------------------------------| 1025 |<--200 OK---| | | | | | 1026 | | | | | | | 1027 |--ACK --------------------------------------------------->| 1029 5. Application Considerations 1031 As seen by the example scenarios in the appendix, History-Info 1032 provides a very flexible building block that can be used by 1033 intermediaries and UAs for a variety of services. As such, any 1034 services making use of History-Info must be designed with the 1035 following considerations: 1036 1) History-Info is optional, thus a service should define default 1037 behavior for requests and responses not containing History-Info 1038 headers. 1039 2) History-Info may be impacted by privacy considerations. 1040 Applications requiring History-Info need to be aware that if 1041 Header, Session or History level privacy is requested by a UA (or 1042 imposed by an intermediary) that History-Info may not be 1043 available in a request or response. This would be addressed by 1044 an application in the same manner as the previous consideration 1045 by ensuring there is reasonable default behavior should the 1046 information not be available. 1047 3) History-Info may be impacted by local policy. Each application 1048 making use of the History-Info header SHOULD address the impacts 1049 of the local policies on the specific application (e.g. what 1050 specification of local policy is optimally required for a 1051 specific application and any potential limitations imposed by 1052 local policy decisions). Note, that this is related to the 1053 optionality and privacy considerations identified in 1 and 2 1054 above, but goes beyond that. For example, due to the optionality 1055 and privacy considerations, an entity may receive only partial 1056 History-Info entries; will this suffice? Note, that this would be 1057 a limitation for debugging purposes, but might be perfectly 1058 satisfactory for some models whereby only the information from a 1059 specific intermediary is required. 1060 4) The security associated with the Request History Information is 1061 optional. Whether there is security applied to the entries 1062 depends upon local policy. The impact of lack of having the 1063 information compromised depends upon the nature of the specific 1064 application (e.g. is the information something that appears on a 1065 display or is it processed by automata which could have negative 1066 impacts on the subsequent processing of a request?). It is 1067 suggested that the impact of an intermediary not supporting the 1068 security recommendations should be evaluated by the application 1069 to ensure that the impacts have been sufficiently addressed by 1070 the application. 1072 6. Security Considerations 1074 This draft provides a proposal in sections 3.2 and 4.4 for addressing 1075 the Security requirements identified in section 2.1 by mandating the 1076 use of TLS between entities. With TLS, History-Info headers are no 1077 less, nor no more, secure than other SIP headers, which generally 1078 have even more impact on the subsequent processing of SIP sessions 1079 than the History-Info header. A more robust security solution, which 1080 would secure headers added by proxies, SHOULD be used for History- 1081 Info implementations once there is a solution to the requirements 1082 identified in [SIPIISEC]. 1084 7. IANA Considerations 1086 (Note to RFC Editor: Please fill in all occurrences of XXXX in this 1087 section with the RFC number of this specification). 1089 7.1 Registration of new SIP History-Info header 1091 This document defines a new SIP header field name: History-Info and a 1092 new option tag: Histinfo. 1094 The following changes should be made to 1095 http:///www.iana.org/assignments/sip-parameters 1097 The following row should be added to the header field section: 1099 Header Name Compact Form Reference 1100 ----------- ------------ --------- 1101 History-Info none [RFCXXXX] 1103 The following should be added to the Options Tags section: 1105 Name Description Reference 1106 ---- ----------- --------- 1107 Histinfo When used with the Supported header, [RFCXXXX] 1108 this option tag indicates support 1109 for the History Information to be 1110 captured for requests and returned in 1111 subsequent responses. This tag is not 1112 used in a Proxy-Require or Require 1113 header field since support of 1114 History-Info is optional. 1116 7.2 Registration of "history" for SIP Privacy header 1118 This document defines a new priv-value for the SIP Privacy header: 1119 history 1121 The following changes should be made to 1122 http://www.iana.org/assignments/sip-priv-values 1124 The following should be added to the registration for the SIP 1125 Privacy header: 1127 Name Description Registrant Reference 1128 ---- ----------- ---------- --------- 1129 history Privacy requested for Mary Barnes [RFCXXXX] 1130 History-Info header(s) mary.barnes@nortelnetworks.com 1132 Changes since last version 1134 Changes from the �02 to the �03 version: 1135 o Editorial changes: Updating to the new template to reflect new 1136 IPR guidelines, ensuring that the normative text is complete 1137 and accurate in section 4.1, removing "Editor's Notes", etc. 1138 o Section 4.5: Fixed error in cause (408 -> 480). 1139 o Examples: changed the domain to "example.com", IP addresses to 1140 the 192.0.2.0/24 range, changed occurrences of "Reason:" to 1141 "Reason=", added use of Privacy header to examples. 1142 o Added text to reflect WG consensus on Issue-1: Privacy 1143 indication for History-Info entries. Proposed an extension to 1144 the priv-values defined in RFC 3323 in abstract and section 1145 3.3, impacting the protocol structure in section 4.1 and 1146 processing in 4.3.3 (and 4.3.3.1 and 4.3.3.2). In addition, 1147 the new priv-value needs to be registered with IANA, per 1148 section 7. 1149 o Removed Open Issues section. For Issue-2, there was not WG 1150 consensus to define an algorithm for bounding the number of 1151 History-Info entries, but rather that is left as an 1152 implementation decision. 1153 o Updated Security discussions to reflect WG consensus that TLS 1154 is mandatory and sufficient for general History-Info 1155 implementation. The e2m and m2m security solutions can be 1156 applied to History-Info when they become available to provide a 1157 more robust SIP solution. 1158 o Section 4.1: Added additional text to ensure that all the 1159 information in the History-Info header is appropriately and 1160 normatively described (in text). 1161 o Added text in section 4.3.1 and an example to the appendices to 1162 address the UAC having added multiple History-Info headers for 1163 the case where the 3xx response goes back to the UAC and it's 1164 the UAC that retargets the INVITE request. 1165 o Clarified the addition of the Reason header in section 1166 4.3.3.1.2. 1167 o Further delineated the basic rules in section 4.3.3.1.3 for 1168 calculating the index for various scenarios, as this was still 1169 causing some confusion. 1171 Changes from the �01 to the �02 version: 1173 o Merged the SIPPING WG requirements draft into this document. 1174 Note that this increments the section references in the 1175 remainder of the document by 2 (and by 3 for Security and IANA 1176 considerations due to new section added). Also, removed 1177 redirect server from ISSUER-req since the solution identified 1178 this as not being required (or desirable). 1179 o Added an explicit privacy requirement (PRIV-req-3) for the 1180 proxy's role in recognizing and maintaining privacy associated 1181 with a Request-URI being captured in History-Info due to local 1182 policy. (Note, that the text was already there, it just wasn't 1183 highlighted as an explicit requirement). 1184 o Clarified the use of CRLF and spacing in the example headers in 1185 section 4.2. 1186 o Removed the compact form for the header since unknown headers 1187 with multiple entries would not be recognized (i.e. this may 1188 cause parsing problems). 1189 o Added a summary of Application Considerations to address 1190 concerns about the optional usage of History-Info. 1191 o Converted the references from numbers to labels to avoid the 1192 continual problem of renumbering. 1193 o Minor editorial changes (per NITS highlighted by Rohan and Eric 1194 and some minor rewording for clarity). 1196 Changes from the �00 to the �01 version: 1198 o Attempted to be more explicit about the fundamental processing 1199 associated with the header. Removed definitions of new terms, 1200 only referencing the terms from the requirements in the context 1201 of the fundamental SIP processing implied by the terms. 1202 o Attempted to clarify the Index and the related processing. 1203 o Added more detail addressing the privacy requirements. 1204 o Added a bit more detail on security. The security solution 1205 remains in a separate document and this document will need 1206 updating once that is completed. 1207 o Updated the examples (in section 2.5 and appendix) and clarified 1208 the definition and the maintenance of the Index in sections 2.1 1209 and 2.3.3.1. 1210 o Clarified the Reason description in section 2.1. There had been 1211 an error in the description of the processing that was a remnant 1212 of the change to include only a single URI for each History-Info 1213 header. 1214 o Miscellaneous editorial changes (i.e. HistInfo -> Histinfo, 1215 etc.) 1217 Changes from individual draft-barnes-sipping-history-info-02 to the � 1218 00 WG version: 1219 o Updated references and added reference to Security solution 1220 draft. 1221 o Removed appendix D which included background on analysis of 1222 solution options. 1223 o Cleaned up the document format per rfc2223bis. 1224 o Strengthened the inclusion of the INDEX as a MUST (per 1225 discussion at IETF-56). 1226 o Added text around the capturing of the Reason (SHOULD be 1227 captured for SIP responses and MAY be captured for other things 1228 such as timeouts). 1229 o Clarified the response processing 2.3.3.2 to include 1230 provisional responses and the sending of a 183 to convey 1231 History-Info. 1232 o Added section 2.3.4 to address Redirect Server behavior. 1234 Normative References 1236 [RFC3261] J. Rosenberg et al, "SIP: Session initiation protocol," RFC 1237 3261, June, 2002. 1239 [RFC3326] H. Schulzrinne, D. Oran, G. Camarillo, "The Reason Header 1240 Field for the Session Initiation Protocol", RFC 3326, December, 2002. 1242 [RFC3323] J. Peterson, "A Privacy Mechanism for the Session 1243 Initiation Protocol (SIP)", RFC 3323, November, 2002. 1245 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1246 Requirement Levels", RFC 2119, March 1997. 1248 [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1249 Specifications: ABNF", RFC 2234, November 1997. 1251 [SIPIISEC] M. Barnes, "A Mechanism to Secure SIP Headers Inserted by 1252 Intermediaries", draft-barnes-sipping-inserted-info-01.txt, October, 1253 2003. 1255 Informational References 1257 [SIPSVCEX] A. Johnson, "SIP Service Examples", draft-ietf-sipping- 1258 service-examples-05.txt, November, 2002. 1260 [SIPATHID] J. Peterson, "Enhancements for Authenticated Identity 1261 Management in the Session Initiation Protocol (SIP)", draft-ietf-sip- 1262 identity-01.txt, February, 2003. 1264 [RFC3665] A. Johnson et al, "SIP Basic Call Flow Examples", RFC 3665, 1265 BCP 75, December, 2003. 1267 Acknowledgements 1269 The editor would like to acknowledge the constructive feedback 1270 provided by Robert Sparks, Paul Kyzivat, Scott Orton, John Elwell, 1271 Nir Chen, Francois Audet, Palash Jain, Brian Stucker, Norma Ng, 1272 Anthony Brown, Jayshree Bharatia, Jonathan Rosenberg, Eric Burger and 1273 Martin Dolly. 1275 The editor would like to acknowledge the significant input from 1276 Rohan Mahy on some of the normative aspects of the ABNF, particularly 1277 around the need for and format of the index and around the enhanced 1278 SIP security aspects enabled by this draft. 1280 Contributors' Addresses 1282 Cullen, Mark and Jon contributed to the development of the initial 1283 requirements. 1285 Cullen and Mark provided substantial input in the form of email 1286 discussion in the development of the initial version of the 1287 individual solution document. 1289 Cullen Jennings 1290 Cisco Systems 1291 170 West Tasman Dr 1292 MS: SJC-21/3 1294 Tel: +1 408 527 9132 1295 Email: fluffy@cisco.com 1297 Jon Peterson 1298 NeuStar, Inc. 1299 1800 Sutter Street, Suite 570 1300 Concord, CA 94520 1301 USA 1303 Phone: +1 925-363-8720 1304 EMail: Jon.Peterson@NeuStar.biz 1306 Mark Watson 1307 Nortel Networks (UK) 1308 Maidenhead Office Park (Bray House) 1309 Westacott Way 1310 Maidenhead, 1311 Berkshire 1312 England 1314 Tel: +44 (0)1628-434456 1315 Email: mwatson@nortelnetworks.com 1317 Author's Address 1319 Mary Barnes 1320 Nortel Networks 1321 2380 Performance Drive 1322 Richardson, TX USA 1324 Phone: 1-972-684-5432 1325 Email: mary.barnes@nortelnetworks.com 1327 Appendix A Forking Scenarios 1329 A.1 Sequentially forking (History-Info in Response) 1331 This scenario highlights an example where the History-Info in the 1332 response is useful to an application or user that originated the 1333 request. 1335 UA 1 sends a call to "Bob" via proxy 1. Proxy 1 sequentially tries 1336 several places (UA2, UA3 and UA4) unsuccessfully before sending a 1337 response to UA1. 1339 This scenario is provided to show that by providing the History-Info 1340 to UA1, the end user or an application at UA1 could make a decision 1341 on how best to attempt finding "Bob". Without this mechanism UA1 1342 might well attempt UA3 (and thus UA4) and then re-attempt UA4 on a 1343 third manual attempt at reaching "Bob". With this mechanism, either 1344 the end user or application could know that "Bob" is busy on his home 1345 phone and is physically not in the office. If there were an 1346 alternative address for "Bob" known to this end user or application, 1347 that hasn't been attempted, then either the application or the end 1348 user could attempt that. The intent here is to highlight an example 1349 of the flexibility of this mechanism that enables applications well 1350 beyond SIP as it is certainly well beyond the scope of this draft to 1351 prescribe detailed applications. 1353 UA1 Proxy1 UA2 UA3 UA4 1354 | | | | | 1355 |--INVITE -->| | | | 1356 | | | | | 1357 | |--INVITE -------->| | | 1358 |<--100 -----| | | | 1359 | |<-302 ------------| | | 1360 | | | | | 1361 | |-------INVITE ------------>| | 1362 | | | | | 1363 | |<-------180 ---------------| | 1364 |<---180 ----| | | | 1365 | . . |-------INVITE------------->| | 1366 | | timeout | | | 1367 | | | | | 1368 | |------INVITE ---------------------->| 1369 |<--100 -----| | | | 1370 | | | | | 1371 | |<-486 ------------------------------| 1372 | | | | | 1373 | |-- ACK ---------------------------->| 1374 |<--486------| | | | 1375 | | | | | 1376 |--ACK ----->| | | | 1377 | | | | | 1379 [Editor's Note: Need to detail the message flow.] 1381 A.2 Sequential Forking (with Success) 1383 This scenario highlights an example where the History-Info in the 1384 request is primarily of use in not retrying routes that have already 1385 been tried by another proxy. Note, that this is just an example and 1386 that there may be valid reasons why a Proxy would want to retry the 1387 routes and thus, this would like be a local proxy or even user 1388 specific policy. 1390 UA 1 sends a call to "Bob" to proxy 1. Proxy 1 sequentially tries 1391 several places (UA2, UA3 and UA4) before retargeting the call to 1392 Proxy 2. Proxy 2, without the History-Info, would try several of the 1393 same places (UA3 and UA4)based upon registered contacts for "Bob", 1394 before completing at UA5. However, with the History-Info, Proxy 2 1395 determines that UA3 and UA4 have already received the invite, thus 1396 the INVITE goes directly to UA5. 1398 UA1 Proxy1 Proxy2 UA2 UA3 UA4 UA5 1400 | | | | | | | 1401 |--INVITE -->| | | | | | 1402 | | | | | | | 1403 | |--INVITE -------->| | | | 1404 |<--100 -----| | | | | | 1405 | |<-302 ------------| | | | 1406 | | | | | | | 1407 | |-------INVITE ------------>| | | 1408 | | | | | | | 1409 | |<-------180 ---------------| | | 1410 |<---180 ----| | | | | | 1411 | . . |-------INVITE------------->| | | 1412 | | timeout | | | | 1413 | | | | | | | 1414 | |------INVITE ---------------------->| | 1415 |<--100 -----| | | | | | 1416 | |<-302 ------------------------------| | 1417 | | | | | | | 1418 | |-INVITE->| | | | | 1419 | | | | | | | 1420 | | | | | | | 1421 | | |------INVITE --------------------->| 1422 | | | | | | | 1423 | | |<-----200 OK---------------------->| 1424 |<--200 OK-------------| | | | | 1425 | | | | | | | 1426 |--ACK --------------------------------------------------->| 1428 [Editor's Note: Need to add the details of the messages here.] 1430 Appendix B Voicemail 1432 This scenario highlights an example where the History-Info in the 1433 request is primarily of use by an edge service (e.g. Voicemail 1434 Server). It should be noted that this isn't intended to be a complete 1435 specification for this specific edge service as it is quite likely 1436 that additional information is need by the edge service. History-Info 1437 is just one building block that this service makes use of. 1439 UA 1 called UA A which had been forwarded to UA B which forwarded to 1440 a UA VM (voicemail server). Based upon the retargeted URIs and 1441 Reasons (and other information) in the INVITE, the VM server makes a 1442 policy decision about what mailbox to use, which greeting to play 1443 etc. 1445 UA1 Proxy UA-A UA-B UA-VM 1447 | | | | | 1448 |--INVITE F1-->| | | | 1449 | | | | | 1450 | |--INVITE F2-->| | | 1451 |<--100 F3-----| | | | 1452 | |<-302 F4------| | | 1453 | | | | | 1454 | |--------INVITE F5---------->| | 1455 | | | | | 1456 | |<--------180 F6-------------| | 1457 |<---180 F7----| | | | 1458 | . . . | | | | 1459 | |------retransmit INVITE---->| | 1460 | . . . | | | | 1461 | | (timeout) | | 1462 | | | | | 1463 | |-------INVITE F8---------------------->| 1464 | | | | | 1465 | |<-200 F9-------------------------------| 1466 | | | | | 1467 |<-200 F10-----| | | | 1468 | | | | | 1469 |--ACK F11-------------------------------------------->| 1471 Message Details 1473 INVITE F1 UA1->Proxy 1475 INVITE sip:UserA@example.com SIP/2.0 1476 Via: SIP/2.0/UDP here.com:5060 1477 From: BigGuy 1478 To: LittleGuy 1479 Call-Id: 12345600@here.com 1480 CSeq: 1 INVITE 1481 Contact: BigGuy 1482 Content-Type: application/sdp 1483 Content-Length: 1485 v=0 1486 o=UserA 2890844526 2890844526 IN IP4 client.here.com 1487 s=Session SDP 1488 c=IN IP4 192.0.2.3 1489 t=0 0 1490 m=audio 49170 RTP/AVP 0 1491 a=rtpmap:0 PCMU/8000 1493 /*Client for UA1 prepares to receive data on port 49170 1494 from the network. */ 1496 INVITE F2 Proxy->UA-A 1498 INVITE sip:UserA@ims.example.com SIP/2.0 1499 Via: SIP/2.0/UDPims.example.com:5060;branch=1 1500 Via: SIP/2.0/UDP here.com:5060 1501 Record-Route: 1502 From: BigGuy 1503 To: LittleGuy 1504 Call-Id: 12345600@here.com 1505 CSeq: 1 INVITE 1506 History-Info: ; index=1 1507 Contact: BigGuy 1508 Content-Type: application/sdp 1509 Content-Length: 1511 v=0 1512 o=UserA 2890844526 2890844526 IN IP4 client.here.com 1513 s=Session SDP 1514 c=IN IP4 192.0.2.3 1515 t=0 0 1516 m=audio 49170 RTP/AVP 0 1517 a=rtpmap:0 PCMU/8000 1519 100 Trying F3 Proxy->UA1 1521 SIP/2.0 100 Trying 1522 Via: SIP/2.0/UDP here.com:5060 1523 From: BigGuy 1524 To: LittleGuy 1525 Call-Id: 12345600@here.com 1526 CSeq: 1 INVITE 1527 Content-Length: 0 1529 302 Moved Temporarily F4 UserA->Proxy 1530 SIP/2.0 302 Moved Temporarily 1531 Via: SIP/2.0/UDP ims.example.com:5060;branch=1 1532 Via: SIP/2.0/UDP here.com:5060 1533 From: BigGuy 1534 To: LittleGuy ;tag=3 1535 Call-Id: 12345600@here.com 1536 CSeq: 1 INVITE 1537 Contact: 1538 Content-Length: 0 1540 INVITE F5 Proxy-> UA-B 1542 INVITE sip:UserB@example.com SIP/2.0 1543 Via: SIP/2.0/UDP ims.example.com:5060;branch=2 1544 Via: SIP/2.0/UDP here.com:5060 1545 From: BigGuy 1546 To: LittleGuy 1547 Call-Id: 12345600@here.com 1548 History-Info: ; index=1, 1550 ;index=2 1551 CSeq: 1 INVITE 1552 Contact: BigGuy 1553 Content-Type: application/sdp 1554 Content-Length: 1556 v=0 1557 o=User1 2890844526 2890844526 IN IP4 client.here.com 1558 s=Session SDP 1559 c=IN IP4 192.0.2.3 1560 t=0 0 1561 m=audio 49170 RTP/AVP 0 1562 a=rtpmap:0 PCMU/8000 1564 180 Ringing F6 UA-B ->Proxy 1566 SIP/2.0 180 Ringing 1567 Via: SIP/2.0/UDP there.com:5060 1568 From: BigGuy 1569 To: LittleGuy ;tag=5 1570 Call-ID: 12345600@here.com 1571 CSeq: 1 INVITE 1572 Content-Length: 0 1574 180 Ringing F7 Proxy-> UA1 1576 SIP/2.0 180 Ringing 1577 SIP/2.0/UDP here.com:5060 1578 From: BigGuy 1579 To: LittleGuy 1580 Call-Id: 12345600@here.com 1581 CSeq: 1 INVITE 1582 Content-Length: 0 1584 /* User B is not available. INVITE is sent multiple 1585 times until it times out. */ 1587 /* The proxy forwards the INVITE to UA-VM after adding the 1588 additional History Information entry. */ 1590 INVITE F8 Proxy-> UA-VM 1592 INVITE sip:VM@example.com SIP/2.0 1593 Via: SIP/2.0/UDP ims.example.com:5060;branch=3 1594 Via: SIP/2.0/UDP here.com:5060 1595 From: BigGuy 1596 To: LittleGuy 1597 Call-Id: 12345600@here.com 1598 History-Info:;index=1, 1600 ;index=2, 1602 ;index=3 1603 CSeq: 1 INVITE 1604 Contact: BigGuy 1605 Content-Type: application/sdp 1606 Content-Length: 1608 v=0 1609 o=User1 2890844526 2890844526 IN IP4 client.here.com 1610 s=Session SDP 1611 c=IN IP4 192.0.2.3 1612 t=0 0 1613 m=audio 49170 RTP/AVP 0 1614 a=rtpmap:0 PCMU/8000 1615 200 OK F9 1617 SIP/2.0 200 OK UA-VM->Proxy 1619 Via: SIP/2.0/UDP ims.example.com:5060;branch=3 1620 Via: SIP/2.0/UDP here.com:5060 1621 From: BigGuy 1622 To: LittleGuy ;tag=3 1623 Call-Id: 12345600@here.com 1624 CSeq: 1 INVITE 1625 Contact: TheVoiceMail 1626 Content-Type: application/sdp 1627 Content-Length: 1629 v=0 1630 o=UserA 2890844527 2890844527 IN IP4 vm.example.com 1631 s=Session SDP 1632 c=IN IP4 192.0.2.4 1633 t=0 0 1634 m=audio 3456 RTP/AVP 0 1635 a=rtpmap:0 PCMU/8000 1637 200 OK F10 Proxy->UA1 1639 SIP/2.0 200 OK 1640 Via: SIP/2.0/UDP ims.example.com:5060;branch=3 1641 Via: SIP/2.0/UDP here.com:5060 1642 From: BigGuy 1643 To: LittleGuy ;tag=3 1644 Call-Id: 12345600@here.com 1645 CSeq: 1 INVITE 1646 Contact: TheVoiceMail 1647 Content-Type: application/sdp 1648 Content-Length: 1650 v=0 1651 o=UserA 2890844527 2890844527 IN IP4 vm.example.com 1652 s=Session SDP 1653 c=IN IP4 192.0.2.4 1654 t=0 0 1655 m=audio 3456 RTP/AVP 0 1656 a=rtpmap:0 PCMU/8000 1658 ACK F11 UA1-> UA-VM 1660 ACK sip:VM@example.com SIP/2.0 1661 Via: SIP/2.0/UDP here.com:5060 1662 From: BigGuy 1663 To: LittleGuy;tag=3 1664 Call-Id: 12345600@here.com 1665 CSeq: 1 ACK 1666 Content-Length: 0 1668 /* RTP streams are established between UA1 and 1669 UA-VM. UA-VM starts announcement for UA1 */ 1671 Appendix C Automatic Call Distribution Example 1673 This scenario highlights an example of an Automatic Call Distribution 1674 service, where the agents are divided into groups based upon the type 1675 of customers they handle. In this example, the Gold customers are 1676 given higher priority than Silver customers, so a Gold call would get 1677 serviced even if all the agents servicing the Gold group (ACDGRP1) 1678 were busy, by retargeting the request to the Silver Group. Upon 1679 receipt of the call at the agent assigned to handle the incoming 1680 call, based upon the History-Info header in the message, the 1681 application at the agent can provide an indication that this is a 1682 Gold call, from how many groups it might have overflowed before 1683 reaching the agent, etc. and thus can be handled appropriately by the 1684 agent. 1686 For scenarios whereby calls might overflow from the Silver to the 1687 Gold, clearly the alternate group identification, internal routing or 1688 actual agent that handles the call SHOULD not be sent to UA1, thus 1689 for this scenario, one would expect that the Proxy would not support 1690 the sending of the History-Info in the response, even if requested by 1691 the calling UA. 1693 As with the other examples, this is not prescriptive of how one would 1694 do this type of service but an example of a subset of processing that 1695 might be associated with such a service. In addition, this example 1696 is not addressing any aspects of Agent availability, which might also 1697 be done via a SIP interface. 1699 UA1 Proxy ACDGRP1 Svr ACDGRP2 Svr UA2-ACDGRP2 1701 | | | | | 1702 |--INVITE F1-->| | | | 1703 Supported:Histinfo 1704 | | | | | 1705 | |--INVITE F2-->| | | 1706 Supported:Histinfo 1707 History-Info: ; index=1 1708 History-Info: ; index=1.1 1709 | | | | | 1710 | |<-302 F3------| | | 1711 Contact: 1712 | | | | | 1713 | |--------INVITE F4---------->| | 1714 History-Info: ; index=1 1715 History-Info: ; index=1.1 1716 History-Info: ; index=1.2 1717 | | | | | 1718 | | | | | 1719 | | | |INVITE F5>| 1720 History-Info: ; index=1 1721 History-Info: ; index=1.1 1722 History-Info: ; index=1.2 1723 | | | | | 1724 | | | |<-200 F6--| 1725 | | | | | 1726 | |<-200 F7--------------------| | 1727 History-Info: ; index=1 1728 History-Info: ; index=1.1 1729 History-Info: ; index=1.2 1730 |<-200 F8------| | | | 1731 < No History-Info included in the response due to Local Policy> 1732 | | | | | 1733 |--ACK F9--------------------------------------------->| 1735 Message Details 1737 [To be completed] 1739 Appendix D Session via Redirect and Proxy Servers 1741 In this scenario, Alice places a call to Bob using first a Redirect 1742 server then a Proxy Server. The INVITE message is first sent to the 1743 Redirect Server. The Server returns a 302 Moved Temporarily response 1744 (F2) containing a Contact header with Bob's current SIP address. 1745 Alice then generates a new INVITE with Bob's current SIP address 1746 included in another History-Info entry. The INVITE is then sent to 1747 Bob via the Proxy Server, with Bob receiving the complete History 1748 information; the call then proceeds normally. The complete call flow 1749 for this scenario, without the use of History-Info is described in 1750 the SIP Basic Call Flow Examples [RFC3665]. 1752 Alice Redirect Server Proxy 3 Bob 1753 | | | | 1754 | INVITE F1 | | | 1755 |--------------->| | | 1756 | 302 F2 | | | 1757 |<---------------| | | 1758 | ACK F3 | | | 1759 |--------------->| | | 1760 | INVITE F4 | | 1761 |-------------------------------->| INVITE F5 | 1762 | 100 F6 |--------------->| 1764 Message Details 1766 F1 INVITE Alice -> Redirect Server 1768 INVITE sip:bob@biloxi.example.com SIP/2.0 1769 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKbf9f44 1770 Max-Forwards: 70 1771 From: Alice ;tag=9fxced76sl 1772 To: Bob 1773 Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com 1774 CSeq: 1 INVITE 1775 History-Info: ; index=1 1776 Contact: 1777 Content-Length: 0 1779 F2 302 Moved Temporarily Redirect Proxy -> Alice 1781 SIP/2.0 302 Moved Temporarily 1782 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKbf9f44 1783 ;received=192.0.2.1 1784 From: Alice ;tag=9fxced76sl 1785 To: Bob ;tag=53fHlqlQ2 1786 Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com 1787 CSeq: 1 INVITE 1788 History-Info: ; index=1 1789 Contact: 1790 Content-Length: 0 1792 F3 ACK Alice -> Redirect Server 1794 ACK sip:bob@biloxi.example.com SIP/2.0 1795 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKbf9f44 1796 Max-Forwards: 70 1797 From: Alice ;tag=9fxced76sl 1798 To: Bob ;tag=53fHlqlQ2 1799 Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com 1800 CSeq: 1 ACK 1801 Content-Length: 0 1803 F4 INVITE Alice -> Proxy 3 1805 INVITE sip:bob@chicago.example.com SIP/2.0 1806 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 1807 Max-Forwards: 70 1808 From: Alice ;tag=9fxced76sl 1809 To: Bob 1810 Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com 1811 CSeq: 2 INVITE 1812 History-Info: \ 1813 text="Moved Temporarily">; index=1, 1814 ; index=2 1815 Contact: 1816 Content-Length: 0 1818 F5 INVITE Proxy 3 -> Bob 1820 INVITE sip:bob@client.chicago.example.com SIP/2.0 1821 Via: SIP/2.0/TCP ss3.chicago.example.com:5060;branch=z9hG4bK721e.1 1822 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 1823 ;received=192.0.2.1 1824 Max-Forwards: 69 1825 Record-Route: 1826 From: Alice ;tag=9fxced76sl 1827 To: Bob 1828 Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com 1829 CSeq: 2 INVITE 1830 History-Info: \ 1831 text="Moved Temporarily">; index=1, 1832 ; index=2, 1833 ; index=2.1 1834 Contact: 1835 Content-Length: 0 1837 Detailed Call Flow continues per section 6.3 in [RFC 3665]. 1839 Intellectual Property Statement 1841 The IETF takes no position regarding the validity or scope of any 1842 intellectual property or other rights that might be claimed to 1843 pertain to the implementation or use of the technology described 1844 in this document or the extent to which any license under such 1845 rights might or might not be available; neither does it represent 1846 that it has made any effort to identify any such rights. 1847 Information on the IETF's procedures with respect to rights in 1848 IETF Documents can be found in BCP 78 and 79. 1850 Copies of IPR disclosures made to the IETF Secretariat and any 1851 assurances of licenses to be made available, or the result of an 1852 attempt made to obtain a general license or permission for the use 1853 of such proprietary rights by implementers or users of this 1854 specification can be obtained from the IETF on-line IPR repository 1855 at http://www.ietf.org/ipr. 1857 The IETF invites any interested party to bring to its attention 1858 any copyrights, patents or patent applications, or other 1859 proprietary rights which may cover technology that may be required 1860 to implement this standard. Please address the information to the 1861 IETF at ietf-ipr.org. 1863 Disclaimer of Validity 1865 This document and the information contained herein are provided on 1866 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1867 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 1868 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 1869 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 1870 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 1871 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 1872 PARTICULAR PURPOSE. 1874 Full Copyright Statement 1876 Copyright (C) The Internet Society (2004). This document is subject 1877 to the rights, licenses and restrictions contained in BCP 78, and 1878 except as set forth therein, the authors retain all their rights.