idnits 2.17.1 draft-ietf-sip-history-info-00.txt: -(536): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 75 characters in excess of 72. == There are 9 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == 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.) -- The document date (June 2003) is 7611 days in the past. Is this intentional? -- 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) -- Looks like a reference, but probably isn't: 'REQNAME-req' on line 104 -- Looks like a reference, but probably isn't: 'CAPABILITY-req' on line 128 -- Looks like a reference, but probably isn't: 'CONTENT-req' on line 130 -- Looks like a reference, but probably isn't: 'REQUEST-VALIDITY-req' on line 134 -- Looks like a reference, but probably isn't: 'ISSUER-req' on line 135 -- Looks like a reference, but probably isn't: 'GENERATION-req' on line 143 -- Looks like a reference, but probably isn't: 'FORWARDS-req' on line 143 -- Looks like a reference, but probably isn't: 'BACKWARDS-req' on line 150 -- Looks like a reference, but probably isn't: 'OPTIONALITY-req' on line 159 -- Looks like a reference, but probably isn't: 'SEC-req-4' on line 179 -- Looks like a reference, but probably isn't: 'PRIV-req-1' on line 199 -- Looks like a reference, but probably isn't: 'PRIV-req-2' on line 199 -- Looks like a reference, but probably isn't: 'SEC-req-2' on line 244 -- Looks like a reference, but probably isn't: 'RFCXXXX' on line 525 == Unused Reference: '8' is defined on line 577, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 581, but no explicit reference was found in the text -- Possible downref: Normative reference to a draft: ref. '1' == Outdated reference: A later version (-15) exists of draft-ietf-sipping-service-examples-03 -- No information found for draft-barnes-sipping-inserted-info - is the name correct? -- Possible downref: Normative reference to a draft: ref. '5' == Outdated reference: A later version (-06) exists of draft-ietf-sip-identity-01 ** Obsolete normative reference: RFC 2234 (ref. '9') (Obsoleted by RFC 4234) Summary: 4 errors (**), 0 flaws (~~), 8 warnings (==), 20 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft M. Barnes 2 Document: draft-ietf-sip-history-info-00.txt Editor 3 Category: Standards Track Nortel Networks 5 Expires: December, 2003 June 2003 7 An Extension to the Session Initiation Protocol for Request History 8 Information 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Copyright Notice 32 Copyright (C) The Internet Society (2003). All Rights Reserved. 34 Abstract 36 This draft defines a standard mechanism for capturing the history 37 information associated with a SIP request. This capability enables 38 many enhanced services by providing the information as to how and why 39 a call arrives at a specific application or user. This draft defines 40 a new optional SIP header, History-Info, for capturing the history 41 information in requests. A new option tag, HistInfo, to be included 42 in the Supported header is defined to allow UAs to indicate whether 43 the HistInfo should be returned in responses to a request which has 44 captured the history information. 46 Table of Contents 48 1 Request History Information Description.........................3 49 1.1 Optionality of History-Info................................4 50 1.2 Securing History-Info......................................4 51 1.3 Ensuring the Privacy of History-Info.......................5 52 2 Request History Information Protocol Details....................5 53 2.1 Protocol Structure of History-Info.........................5 54 2.2 Protocol Examples..........................................6 55 2.3 Protocol usage.............................................6 56 2.4 Security for History-Info..................................9 57 2.5 Example Applications using History-Info...................10 58 3. Security Considerations.......................................11 59 References.......................................................12 60 Appendix A Forking Scenarios....................................14 61 A.1 Sequentially forking (Hist-Info in Response)..............14 62 A.2 Sequential Forking (with Success).........................15 63 Appendix B Voicemail............................................16 64 Appendix C Automatic Call Distribution Example..................21 65 Full Copyright Statement.........................................22 67 Overview 69 This document provides the solution for the Request History 70 requirements as defined in [1]. 72 The fundamental functionality provided by the request history 73 information is the ability to inform proxies and UAs involved in 74 processing a request about the history or progress of that request. 75 This functionality provides a standard mechanism for capturing the 76 request history information to enable a wide variety of services for 77 networks and end users, without prescribing the operation of those 78 services. 80 Section 1 provides an overall description of the solution, providing 81 references to the appropriate requirements met by each aspect of the 82 solution. 84 Section 2 provides the details of the additions to the SIP protocol, 85 which are required to capture the Request History information. An 86 example use of the request history information is included in Section 87 2, with additional scenarios included in the Appendix. It is 88 anticipated that these would be moved and progressed in the Service 89 examples draft [2] or individual informational drafts describing 90 these specific services, since History-Info is just one of the 91 building blocks for implementing these services. Individual drafts 92 would be particularly useful for documenting services for which there 93 are multiple solutions, since the use of the request history 94 information isn't prescriptive. 96 Conventions used in this document 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in RFC 2119 [7]. 101 In order to provide a cross reference of the solution description to 102 the requirements defined in [1] without reiterating the entirety of 103 the requirements in this document, the requirements are referenced as 104 [REQNAME-req] following the text or paragraph which explicitly 105 satisfies the requirement. 107 Definitions 109 The following terminology is used in this document: 111 Retarget (as defined in [1]): The process of a Proxy Server/UAC 112 changing a URI in a request and thus changing the target of the 113 request. 115 Retargeted: past of Retarget. 117 Retargeted-from-URI: The URI or address from which the request was 118 retargeted. 120 Retargeted-to-URI: The new URI or address to which the request is in 121 the process of being retargeted. 123 1 Request History Information Description 125 The fundamental functionality provided by the request history 126 information is the ability to inform proxies and UAs involved in 127 processing a request about the history or progress of that request 128 [CAPABILITY-req]. The solution for the capture of the Request 129 History Information defines a new header for SIP messages: History- 130 Info [CONTENT-req]. 132 The Request History Information can appear in any request not 133 associated with an established dialog, which includes INVITE, 134 REGISTER, MESSAGE and OPTIONS [REQUEST-VALIDITY-req] and any valid 135 response to these requests.[ISSUER-req] 137 Request History Information is captured when a request is retargeted. 138 In some scenarios, it might be possible for more than one instance of 139 retargeting to occur within the same Proxy. A proxy SHOULD also 140 generate request history information for the 'internal retargeting'. 141 An entity (UA or proxy) retargeting in response to a redirect or 142 REFER SHOULD include any Request History information from the 143 redirect/REFER in the new request [GENERATION-req, FORWARDS-req]. 145 1.1 Optionality of History-Info 147 The Request History Information is optional in that neither UAs nor 148 Proxies are required to support it. The requirement for Request 149 History information to be returned in Responses is indicated using a 150 new Supported header: HistInfo [BACKWARDS-req]. In addition, local 151 policy can define whether or not the information is captured by the 152 retargeting entity for any request, or a specific Request-URI, being 153 retargeted. In many instances, it is likely that this could restrict 154 the applicability of services which make use of the Request History 155 Information to be limited to retargeting within domain(s) controlled 156 by the same local policy, or between domain(s) which negotiate 157 policies with other domains to ensure support of the given policy, or 158 services for which "complete" History Information isn't required to 159 provide the service. [OPTIONALITY-req] Thus, it is highly 160 recommended that all applications making use of the request history 161 information clearly define the impact of the information not being 162 available and specify the processing of such a request. 164 1.2 Securing History-Info 166 This draft defines a new header for SIP. Since, the Request History 167 information is being inserted by an entity as it targets a Request, 168 the resulting security requirements introduce a slightly different 169 problem than the basic SIP header or Identity problem. For History- 170 Info, the general requirement is to secure information that is 171 inserted by a proxy. It is primarily the captured Request-URIs that 172 are the security concern, since they can reflect some aspect of a 173 user's identity and service routing. Thus, the primary objective of 174 the security solution is to ensure that the information being 175 captured is protected from being accessed or manipulated by non- 176 authorized entities, with the fundamental assumption that retargeting 177 entities are implicitly authorized. The draft does suggest the use 178 of a secure transport mechanism such as TLS to ensure the overall 179 confidentiality of the History-Info[SEC-req-4]. However, the 180 complete security solution for History-Info depends upon a general 181 solution for protecting the captured information, which is addressed 182 in a separate solution draft [5]. Details of the use of this proposed 183 mechanism to satisfy the security requirements are provided in 184 section 2.4. 186 The security associated with the Request History Information is 187 optional and depends upon local policy and the impact on specific 188 applications of having the information compromised. Since, the 189 Request History Information itself is also optional and it has been 190 recommended that applications document the impact of the information 191 not being available, it is also suggested that the impact of not 192 supporting the security recommendations also be documented to ensure 193 that it is sufficiently addressed by the application. 195 1.3 Ensuring the Privacy of History-Info 197 In order to satisfy the requirements of ensuring that the privacy 198 associated with a retargeted request is maintained by the retargeting 199 entity [PRIV-req-1] and by the receiving entity [PRIV-req-2], the 200 retargeting entity must determine if there is any privacy associated 201 with a request being retargeted. In some scenarios, the Privacy 202 header would indicate whether the headers in a message should be 203 privacy protected. However, the basic assumption is that local policy 204 would be used to determine whether a specific request should have its 205 privacy maintained and whether maintaining that privacy means that a 206 specific request URI would NOT be captured or that it would be 207 appropriately Privacy protected if it were captured. The proposal for 208 ensuring that the privacy is protected is to recommend the use of a 209 Privacy Service as defined by [6] for headers. 211 It is recognized that meeting the privacy requirements can impact the 212 functionality of this solution by overriding the request to generate 213 the information. As with the optionality and security requirements, 214 applications making use of History-Info should address any impact 215 this may have. 217 2 Request History Information Protocol Details 219 This section contains the details and usage of the proposed new SIP 220 protocol elements. It also discusses the security aspects of the 221 solution and provides some examples. 223 2.1 Protocol Structure of History-Info 225 History-Info is a header field as defined by [4]. It can appear in 226 any request not associated with an established dialog, which includes 227 INVITE, REGISTER, MESSAGE and OPTIONS and any valid response to these 228 requests. 230 It carries the following information: 232 o Targeted-to-URI: the Request URI captured as the Request is 233 targeted. By capturing a copy of the Request URI in the initial 234 request, the Retargeted-from-URI is already captured when a 235 request is retargeted and the Retargeted-to-URI is being 236 captured. 238 o Reason: An optional parameter for History-info. The reason for 239 the retargeting is captured by including the Reason Header [3] 240 as part of the captured Request URI. 242 o Index: An optional parameter for History-Info reflecting the 243 chronological order of the information, indexed to also reflect 244 the forking and nesting of requests. [SEC-req-2] 246 The semantics of the captured Targeted-to-URIs are derived from the 247 current context of the request as follows: 249 o Retargeted-from-URI: this is the Request URI that is being 250 changed due to the retargeting. It is the Targeted-to-URI in the 251 request received by the retargeting entity. If it was not 252 explicitly captured by the original sender/forwarder of the 253 request, it would be captured and added to the request prior to 254 the Targeted-to-URI currently being captured. If the 255 sender/forwarder supported History-Info, it would have been 256 added prior to sending/forwarding the Request. 258 o Retargeted-to-URI: this is the Targeted-to-URI being captured in 259 the request being retargeted. 261 The following summarizes the syntax of the History-Info header, based 262 upon the standard SIP syntax [4]: 264 History-Info = ("History-Info" / "h") HCOLON 266 hist-info *(COMMA hist-info) 268 hist-info = hi-targeted-to-uri *( SEMI HI-param ) 270 hi-targeted-to-uri= name-addr 272 hi-param = hi-index / hi-extension 274 hi-index = "index" EQUAL 1*DIGIT *(DOT 1*DIGIT) 276 hi-extension = generic-param 278 2.2 Protocol Examples 280 History-Info:; foo=bar 283 History-Info: ; index=1.1.2 286 2.3 Protocol usage 287 This section describes the processing specific to UAs and Proxies for 288 the History-Info and the HistInfo option tag. 290 [Editor's note: Once the Security solution is fully fleshed out, it 291 may be reasonable to move this section 2.3 after section 2.4 and 292 provide the detailed security related processing prior to this 293 section, so that security aspects can be highlighted in this section, 294 as well.] 296 2.3.1 UAC Behavior 298 The UAC SHOULD include the HistInfo option tag in the Supported 299 header in any request not associated with an established dialog for 300 which the UAC would like the History-Info in the Response. In 301 addition, the UAC should initiate the capturing of the History 302 Information by capturing the Request-URI as the hi-targeted-to-uri 303 and initializing the index to 1. 305 The processing of the History-Info received in the response is 306 application specific and outside the scope of this draft. 308 2.3.2 UAS Behavior 310 The processing of History-Info by a UAS in a Request depends upon 311 local policy and specific applications at the UAS which might make 312 use of the information. If the HistInfo option tag is received in a 313 request, the UAS should include any History-Info received in the 314 request in the subsequent response. 316 2.3.3 Proxy Behavior 318 The use of History-Info does not alter the fundamental processing of 319 proxies for determining request targets as defined in section 16.5 of 320 [4]. Whether a proxy captures the History-Info depends upon several 321 factors: 322 o Whether the Request contains the HistInfo option tag in the 323 Supported header. 324 o Local Policy 325 The following are further considerations for refinement of a 326 local policy supporting History-Info: 327 o Whether retargeting within a Proxy is captured 328 o Whether the History-Info captured for a proxy/domain 329 should go outside that domain (e.g. a Proxy knows that 330 the information is potentially useful within that domain, 331 however, policies (for privacy, user and network 332 security, etc.) prohibit the exposure of that information 333 outside that domain). 335 Each application making use of History-Info should address the 336 applicability and impacts of the local policies. 338 Consistent with basic SIP processing of optional headers, proxies 339 should maintain History-Info captured by other domains, received in 340 messages which they forward, independent of whether local policy 341 supports History-Info. 343 The specific processing by proxies for capturing the History-Info in 344 Requests and Responses is described in detail in the following 345 sections. 347 2.3.3.1 Capturing History-Info in Requests 349 If the proxy supports History-Info, the proxy SHOULD add any History- 350 Info collected as it retargets a Request. For retargets that are the 351 result of an explicit SIP response, the SIP Response Code that 352 triggered the retargeting MUST be included in the Reason header of 353 the Targeted-to-URI. For retargets as a result of timeouts or 354 internal events, a Reason header MAY be included in the Reason header 355 of the Targeted-to-URI. The History-Info SHOULD be added following 356 any History-Info received in the request being forwarded. 357 Additionally, if a request is received that doesn't include a 358 captured Request URI from the previous entity, the proxy MAY add an 359 additional entry, effectively capturing the retargeted-from-URI in 360 the Request. 362 In order to maintain ordering and accurately reflect the nesting and 363 retargeting of the request, an index MUST be included along with the 364 Targeted-to-URI being captured. The basic rule for adding the index 365 are to read the value from the previous History-Info, if available, 366 and capture the index.n as the index for the History-Info being 367 captured, where n would typically be 1 for a forwarded request. Thus, 368 the level of nesting of the index reflects the number of hops. For 369 retargets within a proxy, the proxy MUST maintain the current level 370 of nesting by incrementing the lowest/last digit of the index for 371 each instance of retargeting, thus reflecting the number of retargets 372 within the proxy. If there is no previous History-Info entry, the 373 index included for the current entry is RECOMMENDED to start at 1, 374 indicating a new thread of History-Info. An index MUST NOT be added 375 in the scenario whereby the received request had no History-Info 376 header and the retargeted-from-URI is being captured for 377 completeness. This allows the entities making use of the History- 378 Info to detect any gaps in History-Info captured in the request. 380 Parallel forking, as with basic SIP processing, does introduce 381 somewhat of a special case. In the case of parallel forking, the 382 proxy SHOULD capture each of the Request-URIs to which the Request is 383 forked in the manner previously described. However, since the forking 384 is parallel, it's recommended that rather than attempt to send the 385 logical order of the requests being sent, that the information for 386 subsequent requests or responses is built upon receipt of the initial 387 response to ensure that the series of any subsequent forking and 388 retargeting of any of the forked requests accurately reflects the 389 logical sequence. Again, it is recommended that the index be 390 captured for each forked request following a similar model as that 391 previously described, with each new Request having a unique index. 392 The lack of Reason headers in the captured Request-URIs should be 393 indicative of the parallel nature of forking (i.e the Request-URIs 394 are not the result of retargets, but are rather all simultaneous 395 Targeted-To URIs.) 397 2.3.3.2 Processing History-Info in Responses 399 A proxy that receives a Request with the HistInfo option tag in the 400 Supported header, and depending upon a local policy supporting the 401 capture of History-Info, SHOULD return captured History-Info in 402 subsequent, provisional and final responses to the Request. A 183 403 response MAY be sent explicitly for the purposes of conveying 404 History-Info prior to the final response. 406 2.3.4 Redirect Server Behavior 408 It MAY be advantageous for redirect servers to support the receipt of 409 History-Info in requests. By receiving it in the request, the 410 Redirect Server MAY be able to optimize the information it sends in 411 responses by looking at the already targeted-to-URIs. However, a 412 redirect server SHOULD NOT add any new History-Info, as that would be 413 done by the entity receiving the 3xx response. Thus, a redirect 414 server SHOULD have local policy defined such that History-Info is not 415 captured, which should be the default. However, a redirect server 416 MAY include History-Info in responses to reflect retargets that have 417 already taken place by including any History-Info received in a 418 request in a subsequent response. 420 2.4 Security for History-Info 422 As discussed in Section 1, the security requirements are met by 423 recommending the use of TLS (a basic SIP requirement per [4]) and 424 through the use of the security solution defined in [5]. 426 2.4.1 Security examples 428 [Editor's Note: Need to add some protocol details for protecting 429 History-Info once [5] is further along]. 431 2.5 Example Applications using History-Info 433 This scenario highlights an example where the History-Info in the 434 response is primarily of use in not retrying routes that have already 435 been tried by another proxy. Note, that this is just an example and 436 that there may be valid reasons why a Proxy would want to retry the 437 routes and thus, this would like be a local proxy or even user 438 specific policy. 440 UA 1 sends a call to "Bob" to proxy 1. Proxy 1 forwards the request 441 to Proxy 2. Proxy 2 parallel forks and tries several places (UA2, 442 UA3 and UA4) before sending a response to Proxy 1 that all the places 443 are busy. Proxy 1, without the History-Info, would try several of 444 the same places (UA3 and UA4)based upon registered contacts for 445 "Bob", before completing at UA5. However, with the History-Info, 446 Proxy 1 determines that UA3 and UA4 have already received the invite, 447 thus the INVITE goes directly to UA5. 449 UA1 Proxy1 Proxy2 UA2 UA3 UA4 UA5 451 | | | | | | | 452 |--INVITE -->| | | | | | 453 | |-INVITE->| | | | | 454 Supported: HistInfo 455 History-Info: , ; index=1 456 | | | | | | | 457 | | |-INVITE>| | | | 458 History-Info: , ; index=1, 459 ; index=1.1 460 | | | | | | | 461 | | |-----INVITE ---->| | | 462 History-Info: , ; index=1, 463 ; index=1.2 464 | | | | | | | 465 | | |-------INVITE------------>| | 466 History-Info: , ; index=1, 467 ; index=1.3 469 /* All Responses from the INVITEs indicate Busy. */ 470 | | | | | | | 471 | |<-486 ---| | | | | 472 History-Info: , ; index=1, 473 ; index=1.1, 474 ; index=1.2, 475 ; index=1.3 476 | | | | | | | 478 /* Upon receipt of the response, P1 determines another route for the 479 INVITE, but finds that it matches some routes already attempted (e.g. 480 UA2 and UA3, thus the INVITE is only forwarded to UA5, where the session 481 is successfully established */ 482 | | | | | | | 483 | |----------------INVITE --------------------->| 484 History-Info: , ; index=1, 485 ; index=1.1, 486 ; index=1.2, 487 ; index=1.3, 488 489 | | | | | | | 490 | |<-----200 OK---------------------------------| 491 |<--200 OK---| | | | | | 492 | | | | | | | 493 |--ACK --------------------------------------------------->| 495 Additional detailed scenarios are available in the appendix. 497 3. Security Considerations 499 This draft provides a proposal for addressing the Security 500 requirements identified in [1] in sections 1.2 and 2.4 of this draft 501 by proposing the use of TLS between entities. The protection of the 502 History-Info is dependent upon a general solution for securing 503 headers added by proxies. This general solution is described in [5]. 505 4. IANA Considerations 507 (Note to RFC Editor: Please fill in all occurrences of XXXX in this 508 section with the RFC number of this specification). 510 This document defines a new SIP header field name with a compact 511 form: History-Info and h respectively, and a new option tag: 512 HistInfo. 514 The following changes should be made to http:///www.iana.org/ 515 assignments/sip-parameters 517 The following row should be added to the header field section: 519 Header Name Compact Form Reference 520 History-Info h [RFCXXXX] 522 The following should be added to the Options Tags section: 524 Name Description Reference 525 HistInfo When used with the Supported header, [RFCXXXX] 526 this option tag indicates support 527 for the History Information to be 528 captured for requests and returned in 529 subsequent responses. This tag is not 530 used in a Proxy-Require or Requires 531 header field since support of 532 History-Info is optional. 534 5. Changes since last version 536 Changes from individual draft-barnes-sipping-history-info-02 to the �00 537 WG version: 538 o Updated references and added reference to Security solution 539 draft. 540 o Removed appendix D which included background on analysis of 541 solution options. 542 o Cleaned up the document format per rfc2223bis. 543 o Strengthened the inclusion of the INDEX as a MUST (per discussion 544 at IETF-56). 545 o Added text around the capturing of the Reason (SHOULD be captured 546 for SIP responses and MAY be captured for other things such as 547 timeouts). 548 o Clarified the response processing 2.3.3.2 to include provisional 549 responses and the sending of a 183 to convey History-Info. 550 o Added section 2.3.4 to address Redirect Server behavior. 552 References 554 [1] M. Barnes, M. Watson, C. Jennings, J. Peterson, "SIP Generic 555 Request History Capability Requirements", draft-ietf-sipping-req- 556 history-04.txt, June, 2003. 558 [2] A. Johnson, "SIP Service Examples", draft-ietf-sipping-service- 559 examples-03.txt, November, 2002. 561 [3] H. Schulzrinne, D. Oran, G. Camarillo, "The Reason Header Field 562 for the Session Initiation Protocol", RFC 3326, December, 2002. 564 [4] J. Rosenberg et al, "SIP: Session initiation protocol," RFC 3261, 565 June, 2002. 567 [5] M. Barnes, "A Mechanism to Secure SIP Identity Headers Inserted 568 by Intermediaries", draft-barnes-sipping-inserted-info-00.txt, June, 569 2003. 571 [6] J. Peterson, "A Privacy Mechanism for the Session Initiation 572 Protocol (SIP)", RFC 3323, November, 2002. 574 [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement 575 Levels", RFC 2119, March 1997. 577 [8] J. Peterson, "Enhancements for Authenticated Identity Management 578 in the Session Initiation Protocol (SIP)", draft-ietf-sip-identity- 579 01.txt, February, 2003. 581 [9] Crocker, D. and P. Overell, "Augmented BNF for Syntax 582 Specifications: ABNF", RFC 2234, November 1997. 584 Acknowledgements 586 The editor would like to acknowledge the constructive feedback 587 provided by Robert Sparks, Paul Kyzivat, Scott Orton, John Elwell, 588 Nir Chen, Francois Audet, Anthony Brown, and Jayshree Bharatia. 590 The editor would like to acknowledge the significant input from 591 Rohan Mahy on some of the normative aspects of the ABNF, particularly 592 around the need for and format of the index. 594 Contributors' Addresses 596 Cullen and Mark provided substantial input in the form of email 597 discussion in the development of the initial version of this 598 individual solution document. 600 Cullen Jennings 601 Cisco Systems 602 170 West Tasman Dr 603 MS: SJC-21/3 605 Tel: +1 408 527 9132 606 Email: fluffy@cisco.com 608 Mark Watson 609 Nortel Networks (UK) 610 Maidenhead Office Park (Bray House) 611 Westacott Way 612 Maidenhead, 613 Berkshire 614 England 616 Tel: +44 (0)1628-434456 617 Email: mwatson@nortelnetworks.com 619 Authors' Address 621 Mary Barnes 622 Nortel Networks 623 2380 Performance Drive 624 Richardson, TX USA 626 Phone: 1-972-684-5432 627 Email: mbarnes@nortelnetworks.com 629 Appendix A Forking Scenarios 631 A.1 Sequentially forking (Hist-Info in Response) 633 This scenario highlights an example where the History-Info in the 634 response is useful to an application or user that originated the 635 request. 637 UA 1 sends a call to "Bob" via proxy 1. Proxy 1 sequentially tries 638 several places (UA2, UA3 and UA4) unsuccessfully before sending a 639 response to UA1. 641 This scenario is provided to show that by providing the History-Info 642 to UA1, the end user or an application at UA1 could make a decision 643 on how best to attempt finding "Bob". Without this mechanism UA1 644 might well attempt UA3 (and thus UA4) and then re-attempt UA4 on a rd 3 manual attempting at reaching "Bob". With this mechanism, either 645 the end user or application could know that "Bob" is busy on his home 646 phone and is physically not in the office. If there were an 647 alternative address for "Bob" known to this end user or application, 648 that hasn't been attempted, then either the application or the end 649 user could attempt that. The intent here is to highlight an example 650 of the flexibility of this mechanism that enables applications well 651 beyond SIP as it is certainly well beyond the scope of this draft to 652 prescribe detailed applications. 654 UA1 Proxy1 UA2 UA3 UA4 655 | | | | | 656 |--INVITE -->| | | | 657 | | | | | 658 | |--INVITE -------->| | | 659 |<--100 -----| | | | 660 | |<-302 ------------| | | 661 | | | | | 662 | |-------INVITE ------------>| | 663 | | | | | 664 | |<-------180 ---------------| | 665 |<---180 ----| | | | 666 | . . |-------INVITE------------->| | 667 | | timeout | | | 668 | | | | | 669 | |------INVITE ---------------------->| 670 |<--100 -----| | | | 671 | | | | | 672 | |<-486 ------------------------------| 673 | | | | | 674 | |-- ACK ---------------------------->| 675 |<--486------| | | | 676 | | | | | 677 |--ACK ----->| | | | 678 | | | | | 680 [Editor's Note: Need to detail the message flow.] 682 A.2 Sequential Forking (with Success) 684 This scenario highlights an example where the History-Info in the 685 request is primarily of use in not retrying routes that have already 686 been tried by another proxy. Note, that this is just an example and 687 that there may be valid reasons why a Proxy would want to retry the 688 routes and thus, this would like be a local proxy or even user 689 specific policy. 691 UA 1 sends a call to "Bob" to proxy 1. Proxy 1 sequentially tries 692 several places (UA2, UA3 and UA4) before retargeting the call to 693 Proxy 2. Proxy 2, without the History-Info, would try several of the 694 same places (UA3 and UA4)based upon registered contacts for "Bob", 695 before completing at UA5. However, with the History-Info, Proxy 2 696 determines that UA3 and UA4 have already received the invite, thus 697 the INVITE goes directly to UA5. 699 UA1 Proxy1 Proxy2 UA2 UA3 UA4 UA5 701 | | | | | | | 702 |--INVITE -->| | | | | | 703 | | | | | | | 704 | |--INVITE -------->| | | | 705 |<--100 -----| | | | | | 706 | |<-302 ------------| | | | 707 | | | | | | | 708 | |-------INVITE ------------>| | | 709 | | | | | | | 710 | |<-------180 ---------------| | | 711 |<---180 ----| | | | | | 712 | . . |-------INVITE------------->| | | 713 | | timeout | | | | 714 | | | | | | | 715 | |------INVITE ---------------------->| | 716 |<--100 -----| | | | | | 717 | |<-302 ------------------------------| | 718 | | | | | | | 719 | |-INVITE->| | | | | 720 | | | | | | | 721 | | | | | | | 722 | | |------INVITE --------------------->| 723 | | | | | | | 724 | | |<-----200 OK---------------------->| 725 |<--200 OK-------------| | | | | 726 | | | | | | | 727 |--ACK --------------------------------------------------->| 729 [Editor's Note: Need to add the details of the messages here.] 731 Appendix B Voicemail 733 This scenario highlights an example where the History-Info in the 734 request is primarily of use by an edge service (e.g. Voicemail 735 Server). It should be noted that this isn't intended to be a complete 736 specification for this specific edge service as it is quite likely 737 that additional information is need by the edge service. History-Info 738 is just one building block that this service makes use of. 740 UA 1 called UA A which had been forwarded to UA B which forwarded to 741 a UA VM (voicemail server). Based upon the retargeted URIs and 742 Reasons (and other information) in the INVITE, the VM server makes a 743 policy decision about what mailbox to use, which greeting to play 744 etc. 746 UA1 Proxy UA-A UA-B UA-VM 748 | | | | | 749 |--INVITE F1-->| | | | 750 | | | | | 751 | |--INVITE F2-->| | | 752 |<--100 F3-----| | | | 753 | |<-302 F4------| | | 754 | | | | | 755 | |--------INVITE F5---------->| | 756 | | | | | 757 | |<--------180 F6-------------| | 758 |<---180 F7----| | | | 759 | . . . | | | | 760 | |------retransmit INVITE---->| | 761 | . . . | | | | 762 | | (timeout) | | 763 | | | | | 764 | |-------INVITE F8---------------------->| 765 | | | | | 766 | |<-200 F9-------------------------------| 767 | | | | | 768 |<-200 F10-----| | | | 769 | | | | | 770 |--ACK F11-------------------------------------------->| 772 Message Details 774 INVITE F1 UA1->Proxy 776 INVITE sip:UserA@nortelnetworks.com SIP/2.0 777 Via: SIP/2.0/UDP here.com:5060 778 From: BigGuy 779 To: LittleGuy 780 Call-Id: 12345600@here.com 781 CSeq: 1 INVITE 782 Contact: BigGuy 783 Content-Type: application/sdp 784 Content-Length: 786 v=0 787 o=UserA 2890844526 2890844526 IN IP4 client.here.com 788 s=Session SDP 789 c=IN IP4 100.101.102.103 790 t=0 0 791 m=audio 49170 RTP/AVP 0 792 a=rtpmap:0 PCMU/8000 794 /*Client for UA1 prepares to receive data on port 49170 795 from the network. */ 797 INVITE F2 Proxy->UA-A 799 INVITE sip:UserA@ims.nortelnetworks.com SIP/2.0 800 Via: SIP/2.0/UDPims.nortelnetworks.com:5060;branch=1 801 Via: SIP/2.0/UDP here.com:5060 802 Record-Route: 803 From: BigGuy 804 To: LittleGuy 805 Call-Id: 12345600@here.com 806 CSeq: 1 INVITE 807 History-Info: ; index=1 808 Contact: BigGuy 809 Content-Type: application/sdp 810 Content-Length: 812 v=0 813 o=UserA 2890844526 2890844526 IN IP4 client.here.com 814 s=Session SDP 815 c=IN IP4 100.101.102.103 816 t=0 0 817 m=audio 49170 RTP/AVP 0 818 a=rtpmap:0 PCMU/8000 820 100 Trying F3 Proxy->UA1 822 SIP/2.0 100 Trying 823 Via: SIP/2.0/UDP here.com:5060 824 From: BigGuy 825 To: LittleGuy 826 Call-Id: 12345600@here.com 827 CSeq: 1 INVITE 828 Content-Length: 0 830 302 Moved Temporarily F4 UserA->Proxy 831 SIP/2.0 302 Moved Temporarily 832 Via: SIP/2.0/UDP ims.nortelnetworks.com:5060;branch=1 833 Via: SIP/2.0/UDP here.com:5060 834 From: BigGuy 835 To: LittleGuy ;tag=3 836 Call-Id: 12345600@here.com 837 CSeq: 1 INVITE 838 Contact: 839 Content-Length: 0 841 INVITE F5 Proxy-> UA-B 843 INVITE sip:UserB@nortelnetworks.com SIP/2.0 844 Via: SIP/2.0/UDP ims.nortelnetworks.com:5060;branch=2 845 Via: SIP/2.0/UDP here.com:5060 846 From: BigGuy 847 To: LittleGuy 848 Call-Id: 12345600@here.com 849 History-Info: ; index=1, 850 ;index=2 852 CSeq: 1 INVITE 853 Contact: BigGuy 854 Content-Type: application/sdp 855 Content-Length: 857 v=0 858 o=User1 2890844526 2890844526 IN IP4 client.here.com 859 s=Session SDP 860 c=IN IP4 100.101.102.103 861 t=0 0 862 m=audio 49170 RTP/AVP 0 863 a=rtpmap:0 PCMU/8000 865 180 Ringing F6 UA-B ->Proxy 867 SIP/2.0 180 Ringing 868 Via: SIP/2.0/UDP there.com:5060 869 From: BigGuy 870 To: LittleGuy ;tag=5 871 Call-ID: 12345600@here.com 872 CSeq: 1 INVITE 873 Content-Length: 0 875 180 Ringing F7 Proxy-> UA1 877 SIP/2.0 180 Ringing 878 SIP/2.0/UDP here.com:5060 879 From: BigGuy 880 To: LittleGuy 881 Call-Id: 12345600@here.com 882 CSeq: 1 INVITE 883 Content-Length: 0 885 /* User B is not available. INVITE is sent multiple 886 times until it times out. */ 888 /* The proxy forwards the INVITE to UA-VM after adding the 889 additional History Information entry. */ 891 INVITE F8 Proxy-> UA-VM 893 INVITE sip:VM@nortelnetworks.com SIP/2.0 894 Via: SIP/2.0/UDP ims.nortelnetworks.com:5060;branch=3 895 Via: SIP/2.0/UDP here.com:5060 896 From: BigGuy 897 To: LittleGuy 898 Call-Id: 12345600@here.com 899 History-Info: ;index=1, 900 ;index=2, 902 ;index=3 904 CSeq: 1 INVITE 905 Contact: BigGuy 906 Content-Type: application/sdp 907 Content-Length: 909 v=0 910 o=User1 2890844526 2890844526 IN IP4 client.here.com 911 s=Session SDP 912 c=IN IP4 100.101.102.103 913 t=0 0 914 m=audio 49170 RTP/AVP 0 915 a=rtpmap:0 PCMU/8000 917 200 OK F9 919 SIP/2.0 200 OK UA-VM->Proxy 921 Via: SIP/2.0/UDP ims.nortelnetworks.com:5060;branch=3 922 Via: SIP/2.0/UDP here.com:5060 923 From: BigGuy 924 To: LittleGuy ;tag=3 925 Call-Id: 12345600@here.com 926 CSeq: 1 INVITE 927 Contact: TheVoiceMail 928 Content-Type: application/sdp 929 Content-Length: 931 v=0 932 o=UserA 2890844527 2890844527 IN IP4 vm.nortelnetworks.com 933 s=Session SDP 934 c=IN IP4 110.111.112.114 935 t=0 0 936 m=audio 3456 RTP/AVP 0 937 a=rtpmap:0 PCMU/8000 939 200 OK F10 Proxy->UA1 941 SIP/2.0 200 OK 942 Via: SIP/2.0/UDP ims.nortelnetworks.com:5060;branch=3 943 Via: SIP/2.0/UDP here.com:5060 944 From: BigGuy 945 To: LittleGuy ;tag=3 946 Call-Id: 12345600@here.com 947 CSeq: 1 INVITE 948 Contact: TheVoiceMail 949 Content-Type: application/sdp 950 Content-Length: 952 v=0 953 o=UserA 2890844527 2890844527 IN IP4 vm.nortelnetworks.com 954 s=Session SDP 955 c=IN IP4 110.111.112.114 956 t=0 0 957 m=audio 3456 RTP/AVP 0 958 a=rtpmap:0 PCMU/8000 960 ACK F11 UA1-> UA-VM 962 ACK sip:VM@nortelnetworks.com SIP/2.0 963 Via: SIP/2.0/UDP here.com:5060 964 From: BigGuy 965 To: LittleGuy;tag=3 966 Call-Id: 12345600@here.com 967 CSeq: 1 ACK 968 Content-Length: 0 970 /* RTP streams are established between UA1 and 971 UA-VM. UA-VM starts announcement for UA1 */ 973 Appendix C Automatic Call Distribution Example 975 This scenario highlights an example of an Automatic Call Distribution 976 service, where the agents are divided into groups based upon the type 977 of customers they handle. In this example, the Gold customers are 978 given higher priority than Silver customers, so a Gold call would get 979 serviced even if all the agents servicing the Gold group (ACDGRP1) 980 were busy, by retargeting the request to the Silver Group. Upon 981 receipt of the call at the agent assigned to handle the incoming 982 call, based upon the History-Info in the message, the application at 983 the agent can provide an indication that this is a Gold call, from 984 how many groups it might have overflowed before reaching the agent, 985 etc. thus can be handled appropriately by the agent. 987 For scenarios whereby calls might overflow from the Silver to the 988 Gold, clearly the alternate group identification, internal routing or 989 actual agent that handles the call SHOULD not be sent to UA1, thus 990 for this scenario, one would expect that the Proxy would not support 991 the sending of the History-Info in the response, even if requested by 992 the calling UA. 994 As with the other examples, this is not prescriptive of how one would 995 do this type of service but an example of a subset of processing that 996 might be associated with such a service. In addition, this example 997 is not addressing any aspects of Agent availability, which might also 998 be done via a SIP interface. 1000 UA1 Proxy ACDGRP1 Svr ACDGRP2 Svr UA2-ACDGRP2 1002 | | | | | 1003 |--INVITE F1-->| | | | 1004 Supported:HistInfo 1005 | | | | | 1006 | |--INVITE F2-->| | | 1007 Supported:HistInfo 1008 History-Info: ; index=1 1009 History-Info: ; index=1.1 1010 | | | | | 1011 | |<-302 F3------| | | 1012 Contact: 1013 | | | | | 1014 | |--------INVITE F4---------->| | 1015 History-Info: ; index=1 1016 History-Info: ; index=1.1 1017 History-Info: ; index=1.2 1018 | | | | | 1019 | | | | | 1020 | | | |INVITE F5>| 1021 History-Info: ; index=1 1022 History-Info: ; index=1.1 1023 History-Info: ; index=1.2 1024 | | | | | 1025 | | | |<-200 F6--| 1026 | | | | | 1027 | |<-200 F7--------------------| | 1028 History-Info: ; index=1 1029 History-Info: ; index=1.1 1030 History-Info: ; index=1.2 1031 |<-200 F8------| | | | 1032 < No History-Info included in the response due to Local Policy> 1033 | | | | | 1034 |--ACK F9--------------------------------------------->| 1036 Message Details 1038 [To be completed] 1040 Full Copyright Statement 1042 Copyright (C) The Internet Society (2003). All Rights Reserved. 1044 This document and translations of it may be copied and furnished to 1045 others, and derivative works that comment on or otherwise explain it 1046 or assist in its implementation may be prepared, copied, published 1047 and distributed, in whole or in part, without restriction of any 1048 kind, provided that the above copyright notice and this paragraph are 1049 included on all such copies and derivative works. However, this 1050 document itself may not be modified in any way, such as by removing 1051 the copyright notice or references to the Internet Society or other 1052 Internet organizations, except as needed for the purpose of 1053 developing Internet standards in which case the procedures for 1054 copyrights defined in the Internet Standards process must be 1055 followed, or as required to translate it into languages other than 1056 English. The limited permissions granted above are perpetual and 1057 will not be revoked by the Internet Society or its successors or 1058 assigns. This document and the information contained herein is 1059 provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 1060 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 1061 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1062 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1063 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."