idnits 2.17.1 draft-ietf-sip-history-info-02.txt: -(960): 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 are 3 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 12 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: Since the History-Info header can inadvertently reveal information about the requestor as described in [RFC3323], the Privacy header SHOULD be used to determine whether an intermediary can include the History-Info header in a Request that it receives and forwards [PRIV-req-2] or that it retargets [PRIV-req-1]. Thus, the History-Info header SHOULD not be included in Requests where the requestor has indicated a priv-value of Session or Header level privacy. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: For scenarios whereby calls might overflow from the Silver to the Gold, clearly the alternate group identification, internal routing or actual agent that handles the call SHOULD not be sent to UA1, thus for this scenario, one would expect that the Proxy would not support the sending of the History-Info in the response, even if requested by the calling UA. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'REQNAME-req' is mentioned on line 122, but not defined -- Looks like a reference, but probably isn't: '4' on line 596 == Missing Reference: 'CAPABILITY-req' is mentioned on line 309, but not defined == Missing Reference: 'CONTENT-req' is mentioned on line 311, but not defined == Missing Reference: 'REQUEST-VALIDITY-req' is mentioned on line 320, but not defined == Missing Reference: 'ISSUER-req' is mentioned on line 321, but not defined == Missing Reference: 'GENERATION-req' is mentioned on line 342, but not defined == Missing Reference: 'FORWARDS-req' is mentioned on line 342, but not defined == Missing Reference: 'BACKWARDS-req' is mentioned on line 349, but not defined == Missing Reference: 'OPTIONALITY-req' is mentioned on line 358, but not defined == Missing Reference: 'SEC-req-4' is mentioned on line 366, but not defined == Missing Reference: 'PRIV-req-1' is mentioned on line 397, but not defined == Missing Reference: 'PRIV-req-3' is mentioned on line 407, but not defined == Missing Reference: 'SEC-req-2' is mentioned on line 446, but not defined == Missing Reference: 'RFCXXXX' is mentioned on line 870, but not defined == Unused Reference: 'RFC2234' is defined on line 991, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) -- No information found for draft-barnes-sipping-inserted-info - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'SIPIISEC' == Outdated reference: A later version (-15) exists of draft-ietf-sipping-service-examples-05 == Outdated reference: A later version (-06) exists of draft-ietf-sip-identity-01 Summary: 2 errors (**), 0 flaws (~~), 22 warnings (==), 6 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-02.txt Editor 3 Category: Standards Track Nortel Networks 5 Expires: August, 2004 February, 2004 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 (2004). 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 History-Info should be returned in responses to a request which 44 has captured the history information. 46 Table of Contents 48 1.Background: Why define a Generic "Request History" capability?.3 49 2. "Request History" Requirements.................................4 50 2.1 Security Requirements.........................................6 51 2.2 Privacy Requirements.......................................6 52 3. Request History Information Description........................7 53 3.1 Optionality of History-Info................................8 54 3.2 Securing History-Info......................................8 55 3.3 Ensuring the Privacy of History-Info.......................9 56 4 Request History Information Protocol Details....................9 57 4.1 Protocol Structure of History-Info.........................9 58 4.2 Protocol Examples.........................................11 59 4.3 Protocol usage............................................11 60 4.4 Security for History-Info.................................15 61 4.5 Example Applications using History-Info...................16 62 5. Application Considerations....................................17 63 6. Security Considerations.......................................18 64 7. IANA Considerations...........................................18 65 Normative References.............................................21 66 Informational References.........................................22 67 Appendix A Forking Scenarios....................................23 68 A.1 Sequentially forking (History-Info in Response)...........23 69 A.2 Sequential Forking (with Success).........................24 70 Appendix B Voicemail............................................25 71 Appendix C Automatic Call Distribution Example..................30 72 Full Copyright Statement.........................................32 74 Overview 76 Many services that SIP is anticipated to support require the ability 77 to determine why and how the call arrived at a specific application. 78 Examples of such services include (but are not limited to) sessions 79 initiated to call centers via "click to talk" SIP URLs on a web page, 80 "call history/logging" style services within intelligent "call 81 management" software for SIP UAs and calls to voicemail servers and 82 call centers. While SIP implicitly provides the redirect/retarget 83 capabilities that enable calls to be routed to chosen applications, 84 there is currently no standard mechanism within SIP for communicating 85 the history of such a request. This "request history" information 86 allows the receiving application to determine hints about how and why 87 the call arrived at the application/user. This draft defines a new 88 SIP header, History-Info, to provide a standard mechanism for 89 capturing the request history information to enable a wide variety of 90 services for networks and end users. The History-Info header 91 provides a building block for development of new services. 93 Section 1 provides additional background motivation for the Request 94 History capability. Section 2 identifies the requirements for a 95 solution, with Section 3 providing an overall description of the 96 solution. 98 Section 4 provides the details of the additions to the SIP protocol. 99 An example use of the new header is included in Section 4.5, with 100 additional scenarios included in the Appendix. It is anticipated that 101 these would be moved and progressed in a general Service examples 102 draft such as [SIPSVCEX] or individual informational drafts 103 describing these specific services, since the History-Info header is 104 just one of the building blocks for implementing these services. 105 Individual drafts would be particularly useful for documenting 106 services for which there are multiple solutions, as it is not the 107 intent, nor is it within the scope, of this draft to prescribe a 108 complete solution for any of these applications. 110 Section 5 summarizes the application considerations identified in the 111 previous sections. Section 6 summarizes the security solution as 112 described in section 4.4. 114 Conventions used in this document 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 118 document are to be interpreted as described in RFC 2119 [RFC2119]. 120 In order to provide a cross reference of the solution description to 121 the requirements without reiterating the entirety of the requirements 122 inline, the requirements are referenced as [REQNAME-req] following 123 the text or paragraph which explicitly satisfies the requirement. 125 1.Background: Why define a Generic "Request History" capability? 127 SIP implicitly provides redirect/retarget capabilities that enable 128 calls to be routed to specific applications as defined in [RFC3261]. 129 The term retarget will be used henceforth in this draft to refer to 130 the process of a Proxy Server/UAC changing a URI in a request and 131 thus changing the target of the request. This term is chosen to 132 avoid associating this request history only with the specific SIP 133 Redirect Server capability that provides for a response to be sent 134 back to a UAC requesting that the UAC should retarget the original 135 request to an alternate URI. The rules for determining request 136 targets as described in section 16.5 of [RFC3261] are consistent with 137 the use of the retarget term in this draft. 139 The motivation for the request history is that in the process of 140 retargeting old routing information can be forever lost. This lost 141 information may be important history that allows elements to which 142 the call is retargeted to process the call in a locally defined, 143 application specific manner. The proposal in this draft is to provide 144 a mechanism for transporting the request history. It is not 145 proposing any application specific behavior for a Proxy or UA upon 146 receipt of the information. Indeed, such behavior should be a local 147 decision for the recipient application. 149 Current network applications provide the ability for elements 150 involved with the call to exchange additional information relating to 151 how and why the call was routed to a particular destination. The 152 following are examples of such applications: 154 1. Web "referral" applications, whereby an application residing 155 within a web server determines that a visitor to a website has 156 arrived at the site via an "associate" site which will receive 157 some "referral" commission for generating this traffic, 159 2. Email forwarding whereby the forwarded-to user obtains a "history" 160 of who sent the email to whom and at what time 162 3. Traditional telephony services such as Voicemail, call-center 163 "automatic call distribution", and "follow-me" style services. 165 Several of the aforementioned applications currently define 166 application specific mechanisms through which it is possible to 167 obtain the necessary history information. 169 In addition, request history information could be used to enhance 170 basic SIP functionality by providing the following: 172 4. Some diagnostic information for debugging SIP requests. 174 5. A stronger security solution for SIP. A side effect is that each 175 proxy which captures the "request history" information in a secure 176 manner provides an additional means (without requiring signed keys) 177 for the original requestor to be assured that the request was 178 properly retargeted. 180 2. "Request History" Requirements 182 The following list constitutes a set of requirements for a "Request 183 History" capability. 185 1) CAPABILITY-req: The "Request History" capability provides a 186 capability to inform proxies and UAs involved in processing a request 187 about the history/progress of that request. While this is inherently 188 provided when the retarget is in response to a SIP redirect, it is 189 deemed useful for non-redirect retargeting scenarios, as well. 191 2) OPTIONALITY-req: The "Request History" information is optional. 193 2.1) In many cases, it is anticipated that whether the history is 194 added to the Request would be a local policy decision enforced by the 195 specific application, thus no specific protocol element is needed. 197 2.2) Due to the capability being "optional" from the SIP protocol 198 perspective, the impact to an application of not having the "Request 199 History" must be described. Applicability guidelines to be addressed 200 by applications using this capability must be provided as part of the 201 solution to these requirements. 203 3) GENERATION-req: "Request History" information is generated when 204 the request is retargeted. 206 3.1) In some scenarios, it might be possible for more than one 207 instance of retargeting to occur within the same Proxy. A proxy 208 should also generate Request History information for the 'internal 209 retargeting'. 211 3.2) An entity (UA or proxy) retargeting in response to a redirect or 212 REFER should include any Request History information from the 213 redirect/REFER in the new request. 215 4) ISSUER-req: "Request History" information can be generated by a UA 216 or proxy. It can be passed in both requests and responses. 218 5) CONTENT-req: The "Request History" information for each 219 occurrence of retargeting, shall include the following: 221 5.1) The new URI or address to which the request is in the process 222 of being retargeted, 224 5.2) The URI or address from which the request was retargeted, 226 5.3) The reason for the Request-URI or address modification, 228 5.4) Chronological ordering of the Request History information. 230 6) REQUEST-VALIDITY-req: Request-History is applicable to requests 231 not sent within an established dialog. (i.e. INVITE, REGISTER, 232 MESSAGE, and OPTIONS). 234 7) BACKWARDS-req: Request-History information may be passed from the 235 generating entity backwards towards the UAC. This is needed to enable 236 services that inform the calling party about the dialog establishment 237 attempts. 239 8) FORWARDS-req: Request-History information may also be included by 240 the generating entity in the request, if it is forwarded onwards. 242 2.1 Security Requirements 244 The Request History information is being inserted by a network 245 element retargeting a Request, resulting in a slightly different 246 problem than the basic SIP header problem, thus requiring specific 247 consideration. It is recognized that these security requirements can 248 be generalized to a basic requirement of being able to secure 249 information that is inserted by proxies. 251 The potential security problems include the following: 252 1) A rogue application could insert a bogus Request History entry 253 either by adding an additional entry as a result of retargeting or 254 entering invalid information. 256 2) A rogue application could re-arrange the Request History 257 information to change the nature of the end application or to mislead 258 the receiver of the information. 260 Thus, a security solution for "Request History" must meet the 261 following requirements: 263 1) SEC-req-1: The entity receiving the Request History must be able 264 to determine whether any of the previously added Request History 265 content has been altered. 267 2) SEC-req-2: The ordering of the Request History information must be 268 preserved at each instance of retargeting. 270 3) SEC-req-3: The entity receiving the information conveyed by the 271 Request History must be able to authenticate the source of the 272 information. 274 4) SEC-req-4: To ensure the confidentiality of the Request History 275 information, only entities which process the request should have 276 visibility to the information. 278 It should be noted that these security requirements apply to any 279 entity making use of the Request History information, either by 280 retargeting and capturing the information, or as an application 281 making use of the information received in either a Request or 282 Response. 284 2.2 Privacy Requirements 285 Since the Request URI that is captured could inadvertently reveal 286 information about the originator, there are general privacy 287 requirements that MUST be met: 289 1) PRIV-req-1: The entity retargeting the Request must ensure that it 290 maintains the network-provided privacy (as described in [4]) 291 associated with the Request as it is retargeted. 293 2) PRIV-req-2: The entity receiving the Request History must maintain 294 the privacy associated with the information. 296 In addition, local policy at a proxy may identify privacy 297 requirements associated with the Request URI being captured in the 298 Request History information. 300 3) PRIV-req-3: Request History information subject to privacy 301 requirements shall not be included in outgoing messages unless it is 302 protected as described in [RFC3323]. 304 3. Request History Information Description 306 The fundamental functionality provided by the request history 307 information is the ability to inform proxies and UAs involved in 308 processing a request about the history or progress of that request 309 [CAPABILITY-req]. The solution is to capture the Request-URIs as a 310 request is forwarded in a new header for SIP messages: History-Info 311 [CONTENT-req]. This allows for the capturing of the history of a 312 request that would be lost with the normal SIP processing involved in 313 the subsequent forwarding of the request. This solution proposes no 314 changes in the fundamental determination of request targets or in the 315 request forwarding as defined in sections 16.5 and 16.6 of the SIP 316 protocol specification [RFC3261]. 318 The History-Info header can appear in any request not associated with 319 an established dialog, which includes INVITE, REGISTER, MESSAGE, 320 REFER and OPTIONS [REQUEST-VALIDITY-req] and any valid response to 321 these requests.[ISSUER-req] 323 The History-Info header is added to a Request when a new request is 324 created by a UAC or Proxy, or when the target of a request is 325 changed. The term 'retarget' is introduced to refer to this changing 326 of the target of a request and the subsequent forwarding of that 327 request. It should be noted that retargeting only occurs when the 328 Request-URI indicates a domain for which the processing entity is 329 responsible. In terms of the SIP protocol, the processing associated 330 with retargeting is described in sections 16.5, and 16.6 of 331 [RFC3261]. As described in section 16.5 of [RFC3261], it is possible 332 for the target of a request to be changed by the same proxy multiple 333 times (referred to as 'internal retargeting' in section 2), as the 334 proxy MAY add targets to the target set after beginning Request 335 Forwarding. Section 16.6 of [RFC3261] describes Request Forwarding. 336 It is during this process of Request Forwarding, that the History 337 Information is captured as an optional, additional header field. 338 Thus, the addition of the History-Info header does not impact 339 fundamental SIP Request Forwarding. An entity (UA or proxy) changing 340 the target of a request in response to a redirect or REFER SHOULD 341 also propagate any History-Info header from the initial Request in 342 the new request [GENERATION-req, FORWARDS-req]. 344 3.1 Optionality of History-Info 346 The History-Info header is optional in that neither UAs nor Proxies 347 are required to support it. A new Supported header, Histinfo, is 348 included in the Request to indicate whether the History-Info header 349 is returned in Responses [BACKWARDS-req]. In addition to the Histinfo 350 Supported header, local policy determines whether or not the header 351 is added to any request, or for a specific Request-URI, being 352 retargeted. It is possible that this could restrict the applicability 353 of services which make use of the Request History Information to be 354 limited to retargeting within domain(s) controlled by the same local 355 policy, or between domain(s) which negotiate policies with other 356 domains to ensure support of the given policy, or services for which 357 "complete" History Information isn't required to provide the service. 358 [OPTIONALITY-req] All applications making use of the History-info 359 header MUST clearly define the impact of the information not being 360 available and specify the processing of such a request. 362 3.2 Securing History-Info 364 This draft defines a new header for SIP. The draft does RECOMMEND the 365 use of a secure transport mechanism such as TLS to ensure the overall 366 confidentiality of the History-Info headers[SEC-req-4]. However, the 367 problem is slightly different than the hop by hop security problem 368 solved by TLS, as each hop is not required to add the History-Info 369 header. Since the History-Info header is being inserted by an entity 370 as it targets and forwards a Request, the resulting security 371 requirements also introduce a slightly different problem than the 372 basic SIP header or Identity [SIPATHID] problems, which are focused 373 on securing the information in the initial request end to end. 374 However, the requirements for the security solution are similar to 375 the Via and Record-Route headers. For the History-Info header, the 376 general requirement is to secure a header that is inserted by an 377 intermediary and then subsequently referenced, by other 378 intermediaries to build the next header entry, or by an end 379 application using the information to provide a service. Thus, the 380 general requirement takes the form of a middle to middle and middle 381 to end security solution, which is addressed in a separate document 382 [SIPIISEC]. The use of the middle-to-end security solution discussed 383 in [SIPIISEC] allows the integrity of the History-Info to be 384 ascertained as it traverses the intermediaries. Thus, including the 385 History-Info header in SIP Requests and securing in this manner adds 386 an additional level of security end to end, assuring the initiator of 387 a Request that it has indeed reached the intended recipient. Further 388 discussion of the security mechanism for History-Info is provided in 389 section 2.4. 391 3.3 Ensuring the Privacy of History-Info 393 Since the History-Info header can inadvertently reveal information 394 about the requestor as described in [RFC3323], the Privacy header 395 SHOULD be used to determine whether an intermediary can include the 396 History-Info header in a Request that it receives and forwards [PRIV- 397 req-2] or that it retargets [PRIV-req-1]. Thus, the History-Info 398 header SHOULD not be included in Requests where the requestor has 399 indicated a priv-value of Session or Header level privacy. 401 In addition, the History-Info header can reveal general routing 402 information, which may be viewed by a specific intermediary or 403 network, to be subject to privacy restrictions. Thus, local policy 404 MAY also be used to determine whether to include the History-Info 405 header at all, whether to capture a specific Request-URI in the 406 header, or whether it be included only in the Request as it is 407 retargeted within a specific domain. [PRIV-req-3] 408 [Issue-1: It has been proposed on the mailing list that there is a 409 protocol requirement to support this functionality. It has been 410 suggested that adding an additional field to the History-Info header 411 (or extending the priv-values defined in RFC 3323) would facilitate 412 the implementation of this functionality.] 414 It is recognized that satisfying the privacy requirements can impact 415 the functionality of this solution by overriding the request to 416 generate the information. As with the optionality and security 417 requirements, applications making use of History-Info SHOULD address 418 any impact this may have. 420 4 Request History Information Protocol Details 422 This section contains the details and usage of the proposed new SIP 423 protocol elements. It also discusses the security aspects of the 424 solution and provides some examples. 426 4.1 Protocol Structure of History-Info 427 History-Info is a header field as defined by [RFC3261]. It can 428 appear in any request or response not associated with a dialog or 429 which starts a dialog. For example, History-Info can appear in 430 INVITE, REGISTER, MESSAGE, REFER and OPTIONS and any valid responses, 431 plus NOTIFY requests which initiate a dialog . 433 The History-Info header carries the following information: 435 o Targeted-to-URI: the Request URI captured as the Request is 436 forwarded. 438 o Index: A mandatory parameter for History-Info reflecting the 439 chronological order of the information, indexed to also reflect 440 the forking and nesting of requests. The format for this 441 parameter is a string of digits, separated by dots to indicate 442 the number of forward hops and retargets. This results in a tree 443 representation of the history of the request, with the lowest 444 level index reflecting a branch of the tree. By including the 445 index and securing the header, the ordering of the History-info 446 headers in the request is assured.[SEC-req-2] 448 o Reason: An optional parameter for History-info. The reason for 449 the retargeting is captured by including the Reason Header 450 [RFC3326] associated with the Request URI being retargeted. 451 Thus, a reason is not included for a Request URI when it is 452 first added in a History-info header, but rather is added when 453 that particular Request-URI is retargeted. Note, that this does 454 appear to complicate the security problem, however, retargeting 455 only occurs when the Request-URI indicates a domain for which 456 the processing entity is responsible, thus it would be the same 457 processing entity that initially added the Request-URI to the 458 header that would be updating it with the Reason. 460 The following summarizes the syntax of the History-Info header, based 461 upon the standard SIP syntax [RFC3261]: 463 History-Info = "History-Info" HCOLON 465 hist-info *(COMMA hist-info) 467 hist-info = hi-targeted-to-uri *( SEMI hi-param ) 469 hi-targeted-to-uri= name-addr 471 hi-param = hi-index / hi-extension 473 hi-index = "index" EQUAL 1*DIGIT *(DOT 1*DIGIT) 475 hi-extension = generic-param 477 4.2 Protocol Examples 479 The following provides some examples of the History-Info header. Note 480 that the backslash, CRLF, and spacing between the fields in the 481 examples below are for readability purposes only. 483 History-Info:; index=1; foo=bar 486 History-Info: ; index=1.1, 488 ;index=1.2, 490 ; index=1.3 492 [Editor's note: need to insert row for Table 2]. 494 4.3 Protocol usage 496 This section describes the processing specific to UAs and Proxies for 497 the History-Info header and the Histinfo option tag. As discussed in 498 section 1, the fundamental objective is to capture the target 499 Request-URIs as a request is forwarded. This allows for the 500 capturing of the history of a request that would be lost due to 501 subsequent (re)targeting and forwarding. To accomplish this for the 502 entire history of a request, either the UAC must capture the Request- 503 URI in the initial request or a proxy must add History-Info headers 504 for both the Request-URI in the initial request and the target 505 Request-URI as the request is forwarded. The basic processing is for 506 each entity forwarding a request to add a History-Info header for the 507 target Request-URI, updating the index and adding the Reason as 508 appropriate for any retargeted Request-URI. 510 [Editor's note: Once the Security solution is fully fleshed out, it 511 may be reasonable to move this section 4.3 after section 4.4 and 512 provide the detailed security related processing prior to this 513 section, so that security aspects can be detailed in this section, as 514 well.] 516 4.3.1 UAC Behavior 518 The UAC SHOULD include the Histinfo option tag in the Supported 519 header in any request not associated with an established dialog for 520 which the UAC would like the History-Info in the Response. In 521 addition, the UAC SHOULD initiate the capturing of the History 522 Information by adding a History-Info header using the Request-URI of 523 the request as the hi-targeted-to-uri and initializing the index to 1 524 in the History-Info header 526 The processing of the History-Info header received in the Response is 527 application specific and outside the scope of this draft. However, 528 the validity of the information SHOULD be ensured prior to any 529 application usage. [Editor's note: Further detail to be provided once 530 the security solution is available.] 532 4.3.2 UAS Behavior 534 The processing of the History-Info header by a UAS in a Request 535 depends upon local policy and specific applications at the UAS which 536 might make use of the information. Prior to any application usage of 537 the information, the validity SHOULD be ascertained. [Editor's note: 538 Further detail to be provided once the security solution is 539 available.] 541 If the Histinfo option tag is received in a request, the UAS should 542 include any History-Info received in the request in the subsequent 543 response. 545 4.3.3 Proxy Behavior 547 The inclusion of the History-Info header in a Request does not alter 548 the fundamental processing of proxies for determining request targets 549 as defined in section 16.5 of [RFC3261]. Whether a proxy adds the 550 the History-Info header as it forwards a Request depends upon local 551 policy, with the following being considerations in the definition of 552 that policy: 553 o Whether the Request contains the Histinfo option tag in the 554 Supported header. 555 o Whether the proxy supports the History-Info header. 556 o Whether any History-Info header added for a proxy/domain 557 should go outside that domain. An example being the use of 558 the History-Info header within the specific domain in which 559 it is retargeted, however, policies (for privacy, user and 560 network security, etc.) prohibit the exposure of that 561 information outside that domain. An example of such an 562 application is provided in Appendix C. 563 o Whether the History-Info header is added for a specific 564 Request URI due to local privacy policy considerations. 565 o Within a given domain, whether there is a limit on the number 566 of History-Info entries and the mechanism for applying the 567 limit. [Issue-2: It has been highlighted that messages 568 carrying History-Info entries can become quite large in cases 569 where there is a lot of retargeting. It seems that a 570 reasonable recommendation could be provided for pruning the 571 entries (albeit only entries added by that intermediary MAY 572 be removed)]. 574 An example policy would be a proxy that only adds the History-Info 575 header if the Histinfo option tag is in the Supported header. Other 576 proxies may have a policy that they always add the header, but never 577 forward it outside a particular domain. 579 Each application making use of the History-Info header SHOULD address 580 the impacts of the local policies on the specific application (e.g. 581 what specification of local policy is optimally required for a 582 specific application and any potential limitations imposed by local 583 policy decisions). 585 Consistent with basic SIP processing of optional headers, proxies 586 SHOULD maintain History-Info headers, received in messages being 587 forwarded, independent of whether local policy supports History-Info. 589 The specific processing by proxies for adding the History-Info 590 headers in Requests and Responses is described in detail in the 591 following sections. 593 4.3.3.1 Adding the History-Info header to Requests 595 If the proxy supports the History-Info header, the proxy SHOULD add a 596 History-Info header as it forwards a Request. Section 16.6 of [4] 597 defines the steps to be followed as the proxy forwards a Request. 598 Step 5 prescribes the addition of optional headers. Although, this 599 would seem the appropriate step for adding the History-info header, 600 the interaction with Step 6 "Postprocess routing information" and the 601 impact of a strict route in the Route header could result in the 602 Request-URI being changed, thus adding the History-info header 603 between steps 8 (adding Via header) and 9 (adding Content-Length) is 604 RECOMMENDED. Note, that in the case of loose routing, the Request-URI 605 does not change during the forwarding of a Request, thus the 606 capturing of History-Info for such a request would result in 607 duplicate Request-URIs with different indices. The History-Info 608 header SHOULD be added following any History-Info header received in 609 the request being forwarded. Additionally, if a request is received 610 that doesn't include a History-Info header, the proxy MAY add an 611 additional History-Info header preceding the one being added for the 612 current request being forwarded. The index for this entry is 613 RECOMMENDED to start at 1. 615 For retargets that are the result of an explicit SIP response, the 616 SIP Response Code that triggered the retargeting MUST be included in 617 the Reason header field of the Request URI that has been retargeted. 618 For retargets as a result of timeouts or internal events, a Reason 619 MAY be included in the Reason header field of the Request URI that 620 has been retargeted. 622 In order to maintain ordering and accurately reflect the nesting and 623 retargeting of the request, an index MUST be included along with the 624 Targeted-to-URI being captured. Per the ABNF in section 4.1, the 625 index consists of a dot delimited series of digits (e.g. 1.1.2), with 626 each dot reflecting the number of hops or level of nesting of the 627 request. Thus, the indexing results in a logical tree representation 628 for the history of the Request. It is recommended that for each level 629 of indexing, the index start at 1. For retargets within a proxy, the 630 proxy MUST maintain the current level of nesting by incrementing the 631 lowest/last digit of the index for each instance of retargeting, thus 632 reflecting the number of retargets within the proxy. 634 The basic rules for adding the index are summarized as follows: 636 1. If the Request-URI in the original request indicates a resource 637 for which this proxy is responsible, then the proxy reads the value 638 from the History-Info header in the received request, if available, 639 and adds another level of indexing by appending the DOT delimiter 640 followed by an initial index for the new level of 1. For example, 641 if the index in the last History-Info header field in the received 642 request is 1.1, this proxy would initialize its index to 1.1.1. 643 For each subsequent target that is forwarded by the same proxy, 644 theindex is calculated by incrementing the last/lowest digit at the 645 current level. 647 2. If the Request-URI indicates a resource that this proxy is not 648 responsible for, then the lowest/last digit of the index is 649 incremented (i.e. a new level is not created). For example, if the 650 index in the History-Info header of the received request was 1.2, 651 then the index in the History-Info header field added by this proxy 652 would be 1.3. 654 If the request forwarding is done in parallel, the proxy MUST capture 655 each of the Request-URIs to which the Request is forwarded in the 656 manner previously described per rule 1 above. The index MUST be 657 captured for each forked request per the rules above, with each new 658 Request having a unique index. The proxy builds the subsequent 659 requests and responses using the amalgamated information associated 660 with each of those requests and including the header entries in the 661 order indicated by the indexing. Section 4.5 provides an example of 662 a parallel request scenario, highlighting this indexing mechanism. 664 4.3.3.2 Processing History-Info in Responses 665 A proxy that receives a Request with the Histinfo option tag in the 666 Supported header, and depending upon a local policy supporting the 667 capture of History-Info, SHOULD return captured History-Info in 668 subsequent, provisional and final responses to the Request. 670 It should be noted that local policy considerations, for network and 671 intermediary privacy, MAY restrict the sending of the History-Info 672 headers added by the intermediary in subsequent responses. Thus, in 673 such cases, the proxy MAY remove from these responses the History- 674 Info headers which it inserted in the original forwarded request. 676 4.3.4 Redirect Server Behavior 678 A redirect server SHOULD NOT add any new History-Info, as that would 679 be done by the entity receiving the 3xx response. However, a redirect 680 server MAY include History-Info in responses by adding any History- 681 Info headers received in a request to a subsequent response. 683 4.4 Security for History-Info 685 As discussed in Section 1, the security requirements are partially 686 met by recommending the use of TLS (a basic SIP requirement per 687 [RFC3261]) for hop by hop security. In addition, the use of the 688 middle-to-end security solution discussed in [SIPIISEC] allows the 689 integrity of the History-Info to be ascertained as it traverses the 690 intermediaries. 691 For the History-Info header, the general requirement is to secure a 692 header that is inserted by an intermediary and then subsequently 693 referenced, by other intermediaries to build the next header entry or 694 by an end application using the information to provide a service. In 695 terms of exactly what is being secured, it is primarily the captured 696 Request-URIs that are the security concern, since they can reflect 697 some aspect of a user's identity and service routing. However, the 698 indices are also important in that they can be used to determine if 699 specific Request-URIs have been removed from the header. Thus, the 700 primary objective of the security solution is to ensure that the 701 entire History-Info header is protected from being accessed or 702 manipulated by non-authorized entities, with the fundamental 703 assumption that retargeting entities are implicitly authorized. 705 The security associated with the Request History Information is 706 optional and depends upon local policy and the impact on specific 707 applications of having the information compromised. Since, the 708 Request History Information itself is also optional and it has been 709 recommended that applications document the impact of the information 710 not being available, it is also suggested that the impact of not 711 supporting the security recommendations also be documented by the 712 application to ensure that the impacts have been sufficiently 713 addressed by the application. 715 4.4.1 Security examples 717 [Editor's Note: Need to add some protocol details for protecting 718 History-Info once [SIPIISEC] is further along]. 720 4.5 Example Applications using History-Info 722 This scenario highlights an example where the History-Info in the 723 response is primarily of use in not retrying routes that have already 724 been tried by another proxy. Note, that this is just an example and 725 that there may be valid reasons why a Proxy would want to retry the 726 routes and thus, this would likely be a local proxy or even user 727 specific policy. 729 UA 1 sends a call to "Bob" to proxy 1. Proxy 1 forwards the request 730 to Proxy 2. Proxy 2 sends the requests in parallel and tries several 731 places (UA2, UA3 and UA4) before sending a response to Proxy 1 that 732 all the places are busy. Proxy 1, without the History-Info, would 733 try several of the same places (UA3 and UA4) based upon registered 734 contacts for "Bob", before completing at UA5. However, with the 735 History-Info, Proxy 1 determines that UA3 and UA4 have already 736 received the invite, thus the INVITE goes directly to UA5. 738 UA1 Proxy1 Proxy2 UA2 UA3 UA4 UA5 740 | | | | | | | 741 |--INVITE -->| | | | | | 742 | |-INVITE->| | | | | 743 Supported: Histinfo 744 History-Info: ;index=1, 745 ; index=2 746 | | | | | | | 747 | | |-INVITE>| | | | 748 History-Info: ;index=1, 749 ; index=2, 750 ; index=2.1 751 | | | | | | | 752 | | |-----INVITE ---->| | | 753 History-Info: ;index=1, 754 ; index=2, 755 ; index=2.2 756 | | | | | | | 757 | | |-------INVITE------------>| | 758 History-Info: ;index=1, 759 ; index=2, 760 ; index=2.3 762 /* All Responses from the INVITEs indicate non-success/non- 763 availability*/ 764 | | | | | | | 765 | |<-480 ---| | | | | 766 History-Info: ;index=1, 767 ; index=2, 768 ;index=2.1, 770 ; index=2.2, 772 ; index=2.3 775 | | | | | | | 776 /* Upon receipt of the response, P1 determines another route for the 777 INVITE, but finds that it matches some routes already attempted 778 (e.g. UA2 and UA3, thus the INVITE is only forwarded to UA5, where 779 the session is successfully established */ 780 | | | | | | | 781 | |----------------INVITE --------------------->| 782 History-Info: ;index=1, 783 ; index=2, 784 ;index=2.1, 786 ; index=2.2, 788 ; index=2.3 790 ;index=1.1 791 | | | | | | | 792 | |<-----200 OK---------------------------------| 793 |<--200 OK---| | | | | | 794 | | | | | | | 795 |--ACK --------------------------------------------------->| 797 Additional detailed scenarios are available in the appendix. 799 5. Application Considerations 801 As seen by the example scenarios in the appendix, History-Info 802 provides a very flexible building block that can be used by 803 intermediaries and UAs for a variety of services. As such, any 804 services making use of History-Info must be designed with the 805 following considerations: 807 1) History-Info is optional, thus a service should define default 808 behavior for requests and responses not containing History-Info 809 headers. 810 2) History-Info may be impacted by privacy considerations. 811 Applications requiring History-Info need to be aware that if 812 Header or Session level privacy is requested by a UA (or imposed 813 by an intermediary) that History-Info may not be available in a 814 request or response. This would be addressed by an application 815 in the same manner as the previous consideration by ensuring 816 there is reasonable default behavior should the information not 817 be available. 818 3) History-Info may be impacted by local policy. Each application 819 making use of the History-Info header SHOULD address the impacts 820 of the local policies on the specific application (e.g. what 821 specification of local policy is optimally required for a 822 specific application and any potential limitations imposed by 823 local policy decisions). Note, that this is related to the 824 optionality and privacy considerations identified in 1 and 2 825 above, but goes beyond that. For example, due to the optionality 826 and privacy considerations, an entity may receive only partial 827 History-Info entries; will this suffice? Note, that this would be 828 a limitation for debugging purposes, but might be perfectly 829 satisfactory for some models whereby only the information from a 830 specific intermediary is required. 831 4) The security associated with the Request History Information is 832 optional. Whether there is security applied to the entries 833 depends upon local policy. The impact of lack of having the 834 information compromised depends upon the nature of the specific 835 application (e.g. is the information something that appears on a 836 display or is it processed by automata which could have negative 837 impacts on the subsequent processing of a request?). It is 838 suggested that the impact of an intermediary not supporting the 839 security recommendations should be evaluated by the application 840 to ensure that the impacts have been sufficiently addressed by 841 the application. For the display example, a visual indicator 842 could be applied highlighting that the information has not been, 843 or could not be, validated. 845 6. Security Considerations 847 This draft provides a proposal in sections 3.2 and 4.4 for addressing 848 the Security requirements identified in section 2.1 by proposing the 849 use of TLS between entities, and by securing the History-Info headers 850 added by proxies as described in [SIPIISEC]. 852 7. IANA Considerations 853 (Note to RFC Editor: Please fill in all occurrences of XXXX in this 854 section with the RFC number of this specification). 856 This document defines a new SIP header field name: History-Info and a 857 new option tag: Histinfo. 859 The following changes should be made to 860 http:///www.iana.org/assignments/sip-parameters 862 The following row should be added to the header field section: 864 Header Name Compact Form Reference 865 History-Info none [RFCXXXX] 867 The following should be added to the Options Tags section: 869 Name Description Reference 870 Histinfo When used with the Supported header, [RFCXXXX] 871 this option tag indicates support 872 for the History Information to be 873 captured for requests and returned in 874 subsequent responses. This tag is not 875 used in a Proxy-Require or Require 876 header field since support of 877 History-Info is optional. 879 Open Issues 881 The following summarizes the current open issues in this document: 883 o Issue-1: Privacy indication for specific History-Info entries. 884 It has been proposed on the mailing list that there is a 885 requirement beyond the basic Header or Session privacy provided 886 by RFC 3323 for History-Info entries in terms of supporting 887 local policy based privacy requirements. It has been suggested 888 that adding an additional field to the History-Info header (or 889 extending the priv-values defined in RFC 3323) would facilitate 890 the implementation of this functionality. Adding such 891 information to the HI entries would impact the protocol 892 structure in section 4.1 and processing in 4.3.3 (and 4.3.3.1 893 and 4.3.3.2) 895 o Issue-2: Bounding the History-Info entries and a mechanism for 896 applying the limit. It has been highlighted by developers that 897 messages carrying History-Info entries can become quite large 898 in cases where there is a lot of retargeting. It seems that a 899 reasonable recommendation could be provided for pruning the 900 entries (albeit only entries added by that intermediary should 901 be removed). For example: 903 . Keeping only the first and last entries 904 . Keeping only the last leaf of each of the branches. 905 . Restricting the breadth and depth of the History-Info 906 tree. 907 Such bounding would require normative processing guidelines 908 in section 4.3.3 and introduce an additional application 909 consideration in section 5. 911 Changes since last version 913 Changes from the �01 to the �02 version: 915 o Merged the SIPPING WG requirements draft into this document. 916 Note that this increments the section references in the 917 remainder of the document by 2 (and by 3 for Security and IANA 918 considerations due to new section added). Also, removed 919 redirect server from ISSUER-req since the solution identified 920 this as not being required (or desirable). 921 o Added an explicit privacy requirement (PRIV-req-3) for the 922 proxy's role in recognizing and maintaining privacy associated 923 with a Request-URI being captured in History-Info due to local 924 policy. (Note, that the text was already there, it just wasn't 925 highlighted as an explicit requirement). 926 o Clarified the use of CRLF and spacing in the example headers in 927 section 4.2. 928 o Removed the compact form for the header since unknown headers 929 with multiple entries would not be recognized (i.e. this may 930 cause parsing problems). 931 o Added a summary of Application Considerations to address 932 concerns about the optional usage of History-Info. 933 o Converted the references from numbers to labels to avoid the 934 continual problem of renumbering. 935 o Minor editorial changes (per NITS highlighted by Rohan and Eric 936 and some minor rewording for clarity). 938 Changes from the �00 to the �01 version: 940 o Attempted to be more explicit about the fundamental processing 941 associated with the header. Removed definitions of new terms, 942 only referencing the terms from the requirements in the context 943 of the fundamental SIP processing implied by the terms. 944 o Attempted to clarify the Index and the related processing. 945 o Added more detail addressing the privacy requirements. 946 o Added a bit more detail on security. The security solution 947 remains in a separate document and this document will need 948 updating once that is completed. 950 o Updated the examples (in section 2.5 and appendix) and clarified 951 the definition and the maintenance of the Index in sections 2.1 952 and 2.3.3.1. 953 o Clarified the Reason description in section 2.1. There had been 954 an error in the description of the processing that was a remnant 955 of the change to include only a single URI for each History-Info 956 header. 957 o Miscellaneous editorial changes (i.e. HistInfo -> Histinfo, 958 etc.) 960 Changes from individual draft-barnes-sipping-history-info-02 to the � 961 00 WG version: 962 o Updated references and added reference to Security solution 963 draft. 964 o Removed appendix D which included background on analysis of 965 solution options. 966 o Cleaned up the document format per rfc2223bis. 967 o Strengthened the inclusion of the INDEX as a MUST (per 968 discussion at IETF-56). 969 o Added text around the capturing of the Reason (SHOULD be 970 captured for SIP responses and MAY be captured for other things 971 such as timeouts). 972 o Clarified the response processing 2.3.3.2 to include 973 provisional responses and the sending of a 183 to convey 974 History-Info. 975 o Added section 2.3.4 to address Redirect Server behavior. 977 Normative References 979 [RFC3261] J. Rosenberg et al, "SIP: Session initiation protocol," RFC 980 3261, June, 2002. 982 [RFC3326] H. Schulzrinne, D. Oran, G. Camarillo, "The Reason Header 983 Field for the Session Initiation Protocol", RFC 3326, December, 2002. 985 [RFC3323] J. Peterson, "A Privacy Mechanism for the Session 986 Initiation Protocol (SIP)", RFC 3323, November, 2002. 988 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 989 Requirement Levels", RFC 2119, March 1997. 991 [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 992 Specifications: ABNF", RFC 2234, November 1997. 994 [SIPIISEC] M. Barnes, "A Mechanism to Secure SIP Headers Inserted by 995 Intermediaries", draft-barnes-sipping-inserted-info-01.txt, October, 996 2003. 998 Informational References 1000 [SIPSVCEX] A. Johnson, "SIP Service Examples", draft-ietf-sipping- 1001 service-examples-05.txt, November, 2002. 1003 [SIPATHID] J. Peterson, "Enhancements for Authenticated Identity 1004 Management in the Session Initiation Protocol (SIP)", draft-ietf-sip- 1005 identity-01.txt, February, 2003. 1007 Acknowledgements 1009 The editor would like to acknowledge the constructive feedback 1010 provided by Robert Sparks, Paul Kyzivat, Scott Orton, John Elwell, 1011 Nir Chen, Francois Audet, Palash Jain, Brian Stucker, Norma Ng, 1012 Anthony Brown, Jayshree Bharatia, Jonathan Rosenberg and Eric Burger. 1014 The editor would like to acknowledge the significant input from 1015 Rohan Mahy on some of the normative aspects of the ABNF, particularly 1016 around the need for and format of the index and around the enhanced 1017 SIP security aspects enabled by this draft. 1019 Contributors' Addresses 1021 Cullen, Mark and Jon contributed to the development of the initial 1022 requirements. 1024 Cullen and Mark provided substantial input in the form of email 1025 discussion in the development of the initial version of the 1026 individual solution document. 1028 Cullen Jennings 1029 Cisco Systems 1030 170 West Tasman Dr 1031 MS: SJC-21/3 1033 Tel: +1 408 527 9132 1034 Email: fluffy@cisco.com 1036 Jon Peterson 1037 NeuStar, Inc. 1038 1800 Sutter Street, Suite 570 1039 Concord, CA 94520 1040 USA 1042 Phone: +1 925-363-8720 1043 EMail: Jon.Peterson@NeuStar.biz 1044 Mark Watson 1045 Nortel Networks (UK) 1046 Maidenhead Office Park (Bray House) 1047 Westacott Way 1048 Maidenhead, 1049 Berkshire 1050 England 1052 Tel: +44 (0)1628-434456 1053 Email: mwatson@nortelnetworks.com 1055 Author's Address 1057 Mary Barnes 1058 Nortel Networks 1059 2380 Performance Drive 1060 Richardson, TX USA 1062 Phone: 1-972-684-5432 1063 Email: mary.barnes@nortelnetworks.com 1065 Appendix A Forking Scenarios 1067 A.1 Sequentially forking (History-Info in Response) 1069 This scenario highlights an example where the History-Info in the 1070 response is useful to an application or user that originated the 1071 request. 1073 UA 1 sends a call to "Bob" via proxy 1. Proxy 1 sequentially tries 1074 several places (UA2, UA3 and UA4) unsuccessfully before sending a 1075 response to UA1. 1077 This scenario is provided to show that by providing the History-Info 1078 to UA1, the end user or an application at UA1 could make a decision 1079 on how best to attempt finding "Bob". Without this mechanism UA1 1080 might well attempt UA3 (and thus UA4) and then re-attempt UA4 on a 1081 third manual attempt at reaching "Bob". With this mechanism, either 1082 the end user or application could know that "Bob" is busy on his home 1083 phone and is physically not in the office. If there were an 1084 alternative address for "Bob" known to this end user or application, 1085 that hasn't been attempted, then either the application or the end 1086 user could attempt that. The intent here is to highlight an example 1087 of the flexibility of this mechanism that enables applications well 1088 beyond SIP as it is certainly well beyond the scope of this draft to 1089 prescribe detailed applications. 1091 UA1 Proxy1 UA2 UA3 UA4 1092 | | | | | 1093 |--INVITE -->| | | | 1094 | | | | | 1095 | |--INVITE -------->| | | 1096 |<--100 -----| | | | 1097 | |<-302 ------------| | | 1098 | | | | | 1099 | |-------INVITE ------------>| | 1100 | | | | | 1101 | |<-------180 ---------------| | 1102 |<---180 ----| | | | 1103 | . . |-------INVITE------------->| | 1104 | | timeout | | | 1105 | | | | | 1106 | |------INVITE ---------------------->| 1107 |<--100 -----| | | | 1108 | | | | | 1109 | |<-486 ------------------------------| 1110 | | | | | 1111 | |-- ACK ---------------------------->| 1112 |<--486------| | | | 1113 | | | | | 1114 |--ACK ----->| | | | 1115 | | | | | 1117 [Editor's Note: Need to detail the message flow.] 1119 A.2 Sequential Forking (with Success) 1121 This scenario highlights an example where the History-Info in the 1122 request is primarily of use in not retrying routes that have already 1123 been tried by another proxy. Note, that this is just an example and 1124 that there may be valid reasons why a Proxy would want to retry the 1125 routes and thus, this would like be a local proxy or even user 1126 specific policy. 1128 UA 1 sends a call to "Bob" to proxy 1. Proxy 1 sequentially tries 1129 several places (UA2, UA3 and UA4) before retargeting the call to 1130 Proxy 2. Proxy 2, without the History-Info, would try several of the 1131 same places (UA3 and UA4)based upon registered contacts for "Bob", 1132 before completing at UA5. However, with the History-Info, Proxy 2 1133 determines that UA3 and UA4 have already received the invite, thus 1134 the INVITE goes directly to UA5. 1136 UA1 Proxy1 Proxy2 UA2 UA3 UA4 UA5 1138 | | | | | | | 1139 |--INVITE -->| | | | | | 1140 | | | | | | | 1141 | |--INVITE -------->| | | | 1142 |<--100 -----| | | | | | 1143 | |<-302 ------------| | | | 1144 | | | | | | | 1145 | |-------INVITE ------------>| | | 1146 | | | | | | | 1147 | |<-------180 ---------------| | | 1148 |<---180 ----| | | | | | 1149 | . . |-------INVITE------------->| | | 1150 | | timeout | | | | 1151 | | | | | | | 1152 | |------INVITE ---------------------->| | 1153 |<--100 -----| | | | | | 1154 | |<-302 ------------------------------| | 1155 | | | | | | | 1156 | |-INVITE->| | | | | 1157 | | | | | | | 1158 | | | | | | | 1159 | | |------INVITE --------------------->| 1160 | | | | | | | 1161 | | |<-----200 OK---------------------->| 1162 |<--200 OK-------------| | | | | 1163 | | | | | | | 1164 |--ACK --------------------------------------------------->| 1166 [Editor's Note: Need to add the details of the messages here.] 1168 Appendix B Voicemail 1170 This scenario highlights an example where the History-Info in the 1171 request is primarily of use by an edge service (e.g. Voicemail 1172 Server). It should be noted that this isn't intended to be a complete 1173 specification for this specific edge service as it is quite likely 1174 that additional information is need by the edge service. History-Info 1175 is just one building block that this service makes use of. 1177 UA 1 called UA A which had been forwarded to UA B which forwarded to 1178 a UA VM (voicemail server). Based upon the retargeted URIs and 1179 Reasons (and other information) in the INVITE, the VM server makes a 1180 policy decision about what mailbox to use, which greeting to play 1181 etc. 1183 UA1 Proxy UA-A UA-B UA-VM 1185 | | | | | 1186 |--INVITE F1-->| | | | 1187 | | | | | 1188 | |--INVITE F2-->| | | 1189 |<--100 F3-----| | | | 1190 | |<-302 F4------| | | 1191 | | | | | 1192 | |--------INVITE F5---------->| | 1193 | | | | | 1194 | |<--------180 F6-------------| | 1195 |<---180 F7----| | | | 1196 | . . . | | | | 1197 | |------retransmit INVITE---->| | 1198 | . . . | | | | 1199 | | (timeout) | | 1200 | | | | | 1201 | |-------INVITE F8---------------------->| 1202 | | | | | 1203 | |<-200 F9-------------------------------| 1204 | | | | | 1205 |<-200 F10-----| | | | 1206 | | | | | 1207 |--ACK F11-------------------------------------------->| 1209 Message Details 1211 INVITE F1 UA1->Proxy 1213 INVITE sip:UserA@nortelnetworks.com SIP/2.0 1214 Via: SIP/2.0/UDP here.com:5060 1215 From: BigGuy 1216 To: LittleGuy 1217 Call-Id: 12345600@here.com 1218 CSeq: 1 INVITE 1219 Contact: BigGuy 1220 Content-Type: application/sdp 1221 Content-Length: 1223 v=0 1224 o=UserA 2890844526 2890844526 IN IP4 client.here.com 1225 s=Session SDP 1226 c=IN IP4 100.101.102.103 1227 t=0 0 1228 m=audio 49170 RTP/AVP 0 1229 a=rtpmap:0 PCMU/8000 1231 /*Client for UA1 prepares to receive data on port 49170 1232 from the network. */ 1234 INVITE F2 Proxy->UA-A 1236 INVITE sip:UserA@ims.nortelnetworks.com SIP/2.0 1237 Via: SIP/2.0/UDPims.nortelnetworks.com:5060;branch=1 1238 Via: SIP/2.0/UDP here.com:5060 1239 Record-Route: 1240 From: BigGuy 1241 To: LittleGuy 1242 Call-Id: 12345600@here.com 1243 CSeq: 1 INVITE 1244 History-Info: ; index=1 1245 Contact: BigGuy 1246 Content-Type: application/sdp 1247 Content-Length: 1249 v=0 1250 o=UserA 2890844526 2890844526 IN IP4 client.here.com 1251 s=Session SDP 1252 c=IN IP4 100.101.102.103 1253 t=0 0 1254 m=audio 49170 RTP/AVP 0 1255 a=rtpmap:0 PCMU/8000 1257 100 Trying F3 Proxy->UA1 1259 SIP/2.0 100 Trying 1260 Via: SIP/2.0/UDP here.com:5060 1261 From: BigGuy 1262 To: LittleGuy 1263 Call-Id: 12345600@here.com 1264 CSeq: 1 INVITE 1265 Content-Length: 0 1267 302 Moved Temporarily F4 UserA->Proxy 1268 SIP/2.0 302 Moved Temporarily 1269 Via: SIP/2.0/UDP ims.nortelnetworks.com:5060;branch=1 1270 Via: SIP/2.0/UDP here.com:5060 1271 From: BigGuy 1272 To: LittleGuy ;tag=3 1273 Call-Id: 12345600@here.com 1274 CSeq: 1 INVITE 1275 Contact: 1276 Content-Length: 0 1277 INVITE F5 Proxy-> UA-B 1279 INVITE sip:UserB@nortelnetworks.com SIP/2.0 1280 Via: SIP/2.0/UDP ims.nortelnetworks.com:5060;branch=2 1281 Via: SIP/2.0/UDP here.com:5060 1282 From: BigGuy 1283 To: LittleGuy 1284 Call-Id: 12345600@here.com 1285 History-Info: ; index=1, 1287 ;index=2 1288 CSeq: 1 INVITE 1289 Contact: BigGuy 1290 Content-Type: application/sdp 1291 Content-Length: 1293 v=0 1294 o=User1 2890844526 2890844526 IN IP4 client.here.com 1295 s=Session SDP 1296 c=IN IP4 100.101.102.103 1297 t=0 0 1298 m=audio 49170 RTP/AVP 0 1299 a=rtpmap:0 PCMU/8000 1301 180 Ringing F6 UA-B ->Proxy 1303 SIP/2.0 180 Ringing 1304 Via: SIP/2.0/UDP there.com:5060 1305 From: BigGuy 1306 To: LittleGuy ;tag=5 1307 Call-ID: 12345600@here.com 1308 CSeq: 1 INVITE 1309 Content-Length: 0 1311 180 Ringing F7 Proxy-> UA1 1313 SIP/2.0 180 Ringing 1314 SIP/2.0/UDP here.com:5060 1315 From: BigGuy 1316 To: LittleGuy 1317 Call-Id: 12345600@here.com 1318 CSeq: 1 INVITE 1319 Content-Length: 0 1321 /* User B is not available. INVITE is sent multiple 1322 times until it times out. */ 1324 /* The proxy forwards the INVITE to UA-VM after adding the 1325 additional History Information entry. */ 1326 INVITE F8 Proxy-> UA-VM 1328 INVITE sip:VM@nortelnetworks.com SIP/2.0 1329 Via: SIP/2.0/UDP ims.nortelnetworks.com:5060;branch=3 1330 Via: SIP/2.0/UDP here.com:5060 1331 From: BigGuy 1332 To: LittleGuy 1333 Call-Id: 12345600@here.com 1334 History-Info:;index=1, 1336 ;index=2, 1338 ;index=3 1339 CSeq: 1 INVITE 1340 Contact: BigGuy 1341 Content-Type: application/sdp 1342 Content-Length: 1344 v=0 1345 o=User1 2890844526 2890844526 IN IP4 client.here.com 1346 s=Session SDP 1347 c=IN IP4 100.101.102.103 1348 t=0 0 1349 m=audio 49170 RTP/AVP 0 1350 a=rtpmap:0 PCMU/8000 1352 200 OK F9 1354 SIP/2.0 200 OK UA-VM->Proxy 1356 Via: SIP/2.0/UDP ims.nortelnetworks.com:5060;branch=3 1357 Via: SIP/2.0/UDP here.com:5060 1358 From: BigGuy 1359 To: LittleGuy ;tag=3 1360 Call-Id: 12345600@here.com 1361 CSeq: 1 INVITE 1362 Contact: TheVoiceMail 1363 Content-Type: application/sdp 1364 Content-Length: 1366 v=0 1367 o=UserA 2890844527 2890844527 IN IP4 vm.nortelnetworks.com 1368 s=Session SDP 1369 c=IN IP4 110.111.112.114 1370 t=0 0 1371 m=audio 3456 RTP/AVP 0 1372 a=rtpmap:0 PCMU/8000 1374 200 OK F10 Proxy->UA1 1376 SIP/2.0 200 OK 1377 Via: SIP/2.0/UDP ims.nortelnetworks.com:5060;branch=3 1378 Via: SIP/2.0/UDP here.com:5060 1379 From: BigGuy 1380 To: LittleGuy ;tag=3 1381 Call-Id: 12345600@here.com 1382 CSeq: 1 INVITE 1383 Contact: TheVoiceMail 1384 Content-Type: application/sdp 1385 Content-Length: 1387 v=0 1388 o=UserA 2890844527 2890844527 IN IP4 vm.nortelnetworks.com 1389 s=Session SDP 1390 c=IN IP4 110.111.112.114 1391 t=0 0 1392 m=audio 3456 RTP/AVP 0 1393 a=rtpmap:0 PCMU/8000 1395 ACK F11 UA1-> UA-VM 1397 ACK sip:VM@nortelnetworks.com SIP/2.0 1398 Via: SIP/2.0/UDP here.com:5060 1399 From: BigGuy 1400 To: LittleGuy;tag=3 1401 Call-Id: 12345600@here.com 1402 CSeq: 1 ACK 1403 Content-Length: 0 1405 /* RTP streams are established between UA1 and 1406 UA-VM. UA-VM starts announcement for UA1 */ 1408 Appendix C Automatic Call Distribution Example 1410 This scenario highlights an example of an Automatic Call Distribution 1411 service, where the agents are divided into groups based upon the type 1412 of customers they handle. In this example, the Gold customers are 1413 given higher priority than Silver customers, so a Gold call would get 1414 serviced even if all the agents servicing the Gold group (ACDGRP1) 1415 were busy, by retargeting the request to the Silver Group. Upon 1416 receipt of the call at the agent assigned to handle the incoming 1417 call, based upon the History-Info header in the message, the 1418 application at the agent can provide an indication that this is a 1419 Gold call, from how many groups it might have overflowed before 1420 reaching the agent, etc. and thus can be handled appropriately by the 1421 agent. 1423 For scenarios whereby calls might overflow from the Silver to the 1424 Gold, clearly the alternate group identification, internal routing or 1425 actual agent that handles the call SHOULD not be sent to UA1, thus 1426 for this scenario, one would expect that the Proxy would not support 1427 the sending of the History-Info in the response, even if requested by 1428 the calling UA. 1430 As with the other examples, this is not prescriptive of how one would 1431 do this type of service but an example of a subset of processing that 1432 might be associated with such a service. In addition, this example 1433 is not addressing any aspects of Agent availability, which might also 1434 be done via a SIP interface. 1436 UA1 Proxy ACDGRP1 Svr ACDGRP2 Svr UA2-ACDGRP2 1438 | | | | | 1439 |--INVITE F1-->| | | | 1440 Supported:Histinfo 1441 | | | | | 1442 | |--INVITE F2-->| | | 1443 Supported:Histinfo 1444 History-Info: ; index=1 1445 History-Info: ; index=1.1 1446 | | | | | 1447 | |<-302 F3------| | | 1448 Contact: 1449 | | | | | 1450 | |--------INVITE F4---------->| | 1451 History-Info: ; index=1 1452 History-Info: ; index=1.1 1453 History-Info: ; index=1.2 1454 | | | | | 1455 | | | | | 1456 | | | |INVITE F5>| 1457 History-Info: ; index=1 1458 History-Info: ; index=1.1 1459 History-Info: ; index=1.2 1460 | | | | | 1461 | | | |<-200 F6--| 1462 | | | | | 1463 | |<-200 F7--------------------| | 1464 History-Info: ; index=1 1465 History-Info: ; index=1.1 1466 History-Info: ; index=1.2 1467 |<-200 F8------| | | | 1468 No History-Info included in the response due to Local Policy> 1469 | | | | | 1470 |--ACK F9--------------------------------------------->| 1472 Message Details 1474 [To be completed] 1476 Full Copyright Statement 1478 Copyright (C) The Internet Society (2004). All Rights Reserved. 1480 This document and translations of it may be copied and furnished to 1481 others, and derivative works that comment on or otherwise explain it 1482 or assist in its implementation may be prepared, copied, published 1483 and distributed, in whole or in part, without restriction of any 1484 kind, provided that the above copyright notice and this paragraph are 1485 included on all such copies and derivative works. However, this 1486 document itself may not be modified in any way, such as by removing 1487 the copyright notice or references to the Internet Society or other 1488 Internet organizations, except as needed for the purpose of 1489 developing Internet standards in which case the procedures for 1490 copyrights defined in the Internet Standards process must be 1491 followed, or as required to translate it into languages other than 1492 English. The limited permissions granted above are perpetual and 1493 will not be revoked by the Internet Society or its successors or 1494 assigns. This document and the information contained herein is 1495 provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 1496 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 1497 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1498 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1499 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."