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