idnits 2.17.1 draft-ietf-sip-history-info-01.txt: -(643): 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 2 instances 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 10 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 [6], 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) -- Looks like a reference, but probably isn't: 'REQNAME-req' on line 111 -- Looks like a reference, but probably isn't: 'CAPABILITY-req' on line 119 -- Looks like a reference, but probably isn't: 'CONTENT-req' on line 121 -- Looks like a reference, but probably isn't: 'REQUEST-VALIDITY-req' on line 130 -- Looks like a reference, but probably isn't: 'ISSUER-req' on line 131 -- Looks like a reference, but probably isn't: 'BACKWARDS-req' on line 159 -- Looks like a reference, but probably isn't: 'OPTIONALITY-req' on line 168 -- Looks like a reference, but probably isn't: 'SEC-req-4' on line 176 -- Looks like a reference, but probably isn't: 'PRIV-req-2' on line 204 -- Looks like a reference, but probably isn't: 'PRIV-req-1' on line 205 -- Looks like a reference, but probably isn't: 'SEC-req-2' on line 248 -- Looks like a reference, but probably isn't: 'RFCXXXX' on line 612 == Unused Reference: '9' is defined on line 689, 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-05 -- 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 (==), 18 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-01.txt Editor 3 Category: Standards Track Nortel Networks 5 Expires: April, 2004 October, 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 History-Info should be returned in responses to a request which 44 has 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.............................................7 56 2.4 Security for History-Info.................................10 57 2.5 Example Applications using History-Info...................11 58 3. Security Considerations.......................................13 59 References.......................................................14 60 Appendix A Forking Scenarios....................................16 61 A.1 Sequentially forking (Hist-Info in Response)..............16 62 A.2 Sequential Forking (with Success).........................17 63 Appendix B Voicemail............................................18 64 Appendix C Automatic Call Distribution Example..................23 65 Full Copyright Statement.........................................25 67 Overview 69 This document defines a solution for the Request History requirements 70 as defined in [1], providing the capability to inform proxies and UAs 71 involved in processing a request about the history or progress of 72 that request. This draft defines a new SIP header, History-Info, to 73 provide a standard mechanism for capturing the request history 74 information to enable a wide variety of services for networks and end 75 users. The History-Info header provides a building block for 76 development of new services. 78 Section 1 provides an overall description of the solution, providing 79 references to the appropriate requirements. 81 Section 2 provides the details of the additions to the SIP protocol. 82 An example use of the new header is included in Section 2, with 83 additional scenarios included in the Appendix. It is anticipated that 84 these would be moved and progressed in a general Service examples 85 draft such as [2] or individual informational drafts describing these 86 specific services, since the History-Info header is just one of the 87 building blocks for implementing these services. Individual drafts 88 would be particularly useful for documenting services for which there 89 are multiple solutions, since the use of the request history 90 information isn't prescriptive. As well, as these example 91 applications, the History-Info header can be used to enhance basic 92 SIP functionality by providing additional diagnostic information. In 93 addition, the inclusion of the History-Info header in messages 94 strengthens the overall SIP security solution. When the History-Info 95 header is secured as described in section 2.4, it provides an 96 additional means by which the initiator of a request can be assured 97 that the forwarding and any retargeting of that request was valid. 99 Section 3 summarizes the security solution as described in section 100 2.4. 102 Conventions used in this document 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 106 document are to be interpreted as described in RFC 2119 [7]. 108 In order to provide a cross reference of the solution description to 109 the requirements defined in [1] without reiterating the entirety of 110 the requirements in this document, the requirements are referenced as 111 [REQNAME-req] following the text or paragraph which explicitly 112 satisfies the requirement. 114 1 Request History Information Description 116 The fundamental functionality provided by the request history 117 information is the ability to inform proxies and UAs involved in 118 processing a request about the history or progress of that request 119 [CAPABILITY-req]. The solution is to capture the Request-URIs as a 120 request is forwarded in a new header for SIP messages: History-Info 121 [CONTENT-req]. This allows for the capturing of the history of a 122 request that would be lost with the normal SIP processing involved in 123 the subsequent forwarding of the request. This solution proposes no 124 changes in the fundamental determination of request targets or in the 125 request forwarding as defined in sections 16.5 and 16.6 of the SIP 126 protocol specification [4]. 128 The History-Info header can appear in any request not associated with 129 an established dialog, which includes INVITE, REGISTER, MESSAGE, 130 REFER and OPTIONS [REQUEST-VALIDITY-req] and any valid response to 131 these requests.[ISSUER-req] 133 The History-Info header is added to a Request when a new request is 134 created by a UAC or Proxy, or when the target of a request is 135 changed. The term 'retarget' was introduced in [1] to refer to this 136 changing of the target of a request and the subsequent forwarding of 137 that request. It should be noted that retargeting only occurs when 138 the Request-URI indicates a domain for which the processing entity is 139 responsible. In terms of the SIP protocol, the processing associated 140 with retargeting is described in sections 16.5, and 16.6 of [4]. As 141 described in section 16.5 of [4], it is possible for the target of a 142 request to be changed by the same proxy multiple times (referred to 143 as 'internal retargeting' in [1]), as the proxy MAY add targets to 144 the target set after beginning Request Forwarding. Section 16.6 of 145 [1] describes Request Forwarding. It is during this process of 146 Request Forwarding, that the History Information is captured as an 147 optional, additional header field. Thus, the addition of the History- 148 Info header does not impact fundamental SIP Request Forwarding. An 149 entity (UA or proxy) changing the target of a request in response to 150 a redirect or REFER SHOULD also propagate any History-Info header 151 from the initial Request in the new request [GENERATION-req, 152 FORWARDS-req]. 154 1.1 Optionality of History-Info 156 The History-Info header is optional in that neither UAs nor Proxies 157 are required to support it. A new Supported header, Histinfo, is 158 included in the Request to indicate whether the History-Info header 159 is returned in Responses [BACKWARDS-req]. In addition to the Histinfo 160 Supported header, local policy determines whether or not the header 161 is added to any request, or for a specific Request-URI, being 162 retargeted. It is possible that this could restrict the applicability 163 of services which make use of the Request History Information to be 164 limited to retargeting within domain(s) controlled by the same local 165 policy, or between domain(s) which negotiate policies with other 166 domains to ensure support of the given policy, or services for which 167 "complete" History Information isn't required to provide the service. 168 [OPTIONALITY-req] All applications making use of the History-info 169 header MUST clearly define the impact of the information not being 170 available and specify the processing of such a request. 172 1.2 Securing History-Info 174 This draft defines a new header for SIP. The draft does RECOMMEND the 175 use of a secure transport mechanism such as TLS to ensure the overall 176 confidentiality of the History-Info headers[SEC-req-4]. However, the 177 problem is slightly different than the hop by hop security problem 178 solved by TLS, as each hop is not required to add the History-Info 179 header. Since the History-Info header is being inserted by an entity 180 as it targets and forwards a Request, the resulting security 181 requirements also introduce a slightly different problem than the 182 basic SIP header or Identity [8] problem, which are focused on 183 securing the information in the initial request end to end. For the 184 History-Info header, the general requirement is to secure a header 185 that is inserted by an intermediary and then subsequently referenced, 186 by other intermediaries to build the next header entry, or by an end 187 application using the information to provide a service. Thus, the 188 general requirement takes the form of a middle to middle and middle 189 to end security solution, which is addressed in a separate draft [5]. 190 The use of the middle-to-end security solution discussed in [5] 191 allows the integrity of the History-Info to be ascertained as it 192 traverses the intermediaries. Thus, including the History-Info 193 header in SIP Requests and securing in this manner adds an additional 194 level of security end to end, assuring the initiator of a Request 195 that it has indeed reached the intended recipient. Further 196 discussion of the security mechanism for History-Info is provided in 197 section 2.4. 199 1.3 Ensuring the Privacy of History-Info 201 Since the History-Info header can inadvertently reveal information 202 about the requestor as described in [6], the Privacy header SHOULD be 203 used to determine whether an intermediary can include the History- 204 Info header in a Request that it receives and forwards [PRIV-req-2] 205 or that it retargets [PRIV-req-1]. Thus, the History-Info header 206 SHOULD not be included in Requests where the requestor has indicated 207 a priv-value of Session or Header level privacy. 209 In addition, the History-Info header can reveal general routing 210 information, which may be viewed by a specific intermediary or 211 network, to be subject to privacy restrictions. Thus, local policy 212 MAY also be used to determine whether to include the History-Info 213 header, or if it would only be included in the Request as it is 214 retargeted within a specific domain. 216 It is recognized that satisfying the privacy requirements can impact 217 the functionality of this solution by overriding the request to 218 generate the information. As with the optionality and security 219 requirements, applications making use of History-Info SHOULD address 220 any impact this may have. 222 2 Request History Information Protocol Details 224 This section contains the details and usage of the proposed new SIP 225 protocol elements. It also discusses the security aspects of the 226 solution and provides some examples. 228 2.1 Protocol Structure of History-Info 230 History-Info is a header field as defined by [4]. It can appear in 231 any request not associated with an established dialog, which includes 232 INVITE, REGISTER, MESSAGE, REFER and OPTIONS and any valid response 233 to these requests. 235 It carries the following information: 237 o Targeted-to-URI: the Request URI captured as the Request is 238 forwarded. 240 o Index: A mandatory parameter for History-Info reflecting the 241 chronological order of the information, indexed to also reflect 242 the forking and nesting of requests. The format for this 243 parameter is a string of digits, separated by dots to indicate 244 the number of forward hops and retargets. This results in a tree 245 representation of the history of the request, with the lowest 246 level index reflecting a branch of the tree. By including the 247 index and securing the header, the ordering of the History-info 248 headers in the request is assured.[SEC-req-2] 250 o Reason: An optional parameter for History-info. The reason for 251 the retargeting is captured by including the Reason Header [3] 252 associated with the Request URI being retargeted. Thus, a 253 reason is not included for a Request URI when it is first added 254 in a History-info header, but rather is added when that 255 particular Request-URI is retargeted. Note, that this does 256 appear to complicate the security problem, however, retargeting 257 only occurs when the Request-URI indicates a domain for which 258 the processing entity is responsible, thus it would be the same 259 processing entity that initially added the Request-URI to the 260 header that would be updating it with the Reason. 262 The following summarizes the syntax of the History-Info header, based 263 upon the standard SIP syntax [4]: 265 History-Info = ("History-Info" / "h") HCOLON 267 hist-info *(COMMA hist-info) 269 hist-info = hi-targeted-to-uri *( SEMI hi-param ) 271 hi-targeted-to-uri= name-addr 273 hi-param = hi-index / hi-extension 275 hi-index = "index" EQUAL 1*DIGIT *(DOT 1*DIGIT) 277 hi-extension = generic-param 279 2.2 Protocol Examples 281 History-Info:; index=1; foo=bar 284 History-Info: ; index=1.1, 286 ;index=1.2, 288 ; index=1.3 290 [Editor's note: need to insert row for Table 2]. 292 2.3 Protocol usage 294 This section describes the processing specific to UAs and Proxies for 295 the History-Info header and the Histinfo option tag. As discussed in 296 section 1, the fundamental objective is to capture the target 297 Request-URIs as a request is forwarded. This allows for the 298 capturing of the history of a request that would be lost due to 299 subsequent (re)targeting and forwarding. To accomplish this for the 300 entire history of a request, either the UAC must capture the Request- 301 URI in the initial request or a proxy must add History-Info headers 302 for both the Request-URI in the initial request and the target 303 Request-URI as the request is forwarded. The basic processing is for 304 each entity forwarding a request to add a History-Info header for the 305 target Request-URI, updating the index and adding the Reason as 306 appropriate for any retargeted Request-URI. 308 [Editor's note: Once the Security solution is fully fleshed out, it 309 may be reasonable to move this section 2.3 after section 2.4 and 310 provide the detailed security related processing prior to this 311 section, so that security aspects can be detailed in this section, as 312 well.] 314 2.3.1 UAC Behavior 316 The UAC SHOULD include the Histinfo option tag in the Supported 317 header in any request not associated with an established dialog for 318 which the UAC would like the History-Info in the Response. In 319 addition, the UAC SHOULD initiate the capturing of the History 320 Information by adding a History-Info header using the Request-URI of 321 the request as the hi-targeted-to-uri and initializing the index to 1 322 in the History-Info header 324 The processing of the History-Info header received in the Response is 325 application specific and outside the scope of this draft. However, 326 the validity of the information SHOULD be ensured prior to any 327 application usage. [Editor's note: Further detail to be provided once 328 the security solution is available.] 330 2.3.2 UAS Behavior 332 The processing of the History-Info header by a UAS in a Request 333 depends upon local policy and specific applications at the UAS which 334 might make use of the information. Prior to any application usage of 335 the information, the validity SHOULD be ascertained. [Editor's note: 336 Further detail to be provided once the security solution is 337 available.] 338 If the Histinfo option tag is received in a request, the UAS should 339 include any History-Info received in the request in the subsequent 340 response. 342 2.3.3 Proxy Behavior 344 The inclusion of the History-Info header in a Request does not alter 345 the fundamental processing of proxies for determining request targets 346 as defined in section 16.5 of [4]. Whether a proxy adds the the 347 History-Info header as it forwards a Request depends upon local 348 policy, with the following being considerations in the definition of 349 that policy: 350 o Whether the Request contains the Histinfo option tag in the 351 Supported header. 352 o Whether the proxy supports the History-Info header. 353 o Whether any History-Info header added for a proxy/domain 354 should go outside that domain. An example being the use of 355 the History-Info header within the specific domain in which 356 it is retargeted, however, policies (for privacy, user and 357 network security, etc.) prohibit the exposure of that 358 information outside that domain. An example of such an 359 application is provided in Appendix C. 360 o Whether the History-Info header is added for a specific 361 Request URI due to local privacy policy considerations. 363 An example policy would be a proxy that only adds the History-Info 364 header if the Histinfo option tag is in the Supported header. Other 365 proxies may have a policy that they always add the header, but never 366 forward it outside a particular domain. 368 Each application making use of the History-Info header SHOULD address 369 the impacts of the local policies on the specific application (e.g. 370 what specification of local policy is optimally required for a 371 specific application and any potential limitations imposed by local 372 policy decisions). 374 Consistent with basic SIP processing of optional headers, proxies 375 SHOULD maintain History-Info headers, received in messages being 376 forwarded, independent of whether local policy supports History-Info. 378 The specific processing by proxies for adding the History-Info 379 headers in Requests and Responses is described in detail in the 380 following sections. 382 2.3.3.1 Adding the History-Info header to Requests 383 If the proxy supports the History-Info header, the proxy SHOULD add a 384 History-Info header as it forwards a Request. Section 16.6 of [4] 385 defines the steps to be followed as the proxy forwards a Request. 386 Step 5 prescribes the addition of optional headers. Although, this 387 would seem the appropriate step for adding the History-info header, 388 the interaction with Step 6 "Postprocess routing information" and the 389 impact of a strict route in the Route header could result in the 390 Request-URI being changed, thus adding the History-info header 391 between steps 8 and 9 is RECOMMENDED. Note, that in the case of loose 392 routing, the Request-URI does not change during the forwarding of a 393 Request, thus the capturing of History-Info for such a request would 394 result in duplicate Request-URIs with different indices. The History- 395 Info header SHOULD be added following any History-Info header 396 received in the request being forwarded. Additionally, if a request 397 is received that doesn't include a History-Info header, the proxy MAY 398 add an additional History-Info header preceding the one being added 399 for the current request being forwarded. The index for this entry is 400 RECOMMENDED to start at 1. 402 For retargets that are the result of an explicit SIP response, the 403 SIP Response Code that triggered the retargeting MUST be included in 404 the Reason header field of the Request URI that has been retargeted. 405 For retargets as a result of timeouts or internal events, a Reason 406 MAY be included in the Reason header field of the Request URI that 407 has been retargeted. 409 In order to maintain ordering and accurately reflect the nesting and 410 retargeting of the request, an index MUST be included along with the 411 Targeted-to-URI being captured. Per the ABNF in section 2.1, the 412 index consists of a dot delimited series of digits (e.g. 1.1.2), with 413 each dot reflecting the number of hops or level of nesting of the 414 request. Thus, the indexing results in a logical tree representation 415 for the history of the Request. It is recommended that for each level 416 of indexing, the index start at 1. For retargets within a proxy, the 417 proxy MUST maintain the current level of nesting by incrementing the 418 lowest/last digit of the index for each instance of retargeting, thus 419 reflecting the number of retargets within the proxy. 421 The basic rules for adding the index are summarized as follows: 423 1. If the Request-URI in the original request indicates a resource 424 for which this proxy is responsible, then the proxy reads the value 425 from the History-Info header in the received request, if available, 426 and adds another level of indexing. For example, if the index in 427 the last History-Info header field in the received request is 1.1, 428 this proxy would initialize its index to 1.1.1. For each 429 subsequent target that is forwarded by the same proxy, a new index 430 is used by incrementing the last/lowest digit. 432 2. If the Request-URI indicates a resource that this proxy is not 433 responsible for, then the lowest/last digit of the index is 434 incremented (i.e. a new level is not created). For example, if the 435 index in the History-Info header of the received request was 1, 436 then the index in the History-Info header field added by this proxy 437 would be 2. 439 If the request forwarding is done in parallel, the proxy MUST capture 440 each of the Request-URIs to which the Request is forwarded in the 441 manner previously described per rule 1 above. The index MUST be 442 captured for each forked request per the rules above, with each new 443 Request having a unique index. The proxy builds the subsequent 444 requests and responses using the amalgamated information associated 445 with each of those requests and including the header entries in the 446 order indicated by the indexing. Section 2.5 provides an example of 447 a parallel request scenario, highlighting this indexing mechanism. 449 2.3.3.2 Processing History-Info in Responses 451 A proxy that receives a Request with the Histinfo option tag in the 452 Supported header, and depending upon a local policy supporting the 453 capture of History-Info, SHOULD return captured History-Info in 454 subsequent, provisional and final responses to the Request. 456 It should be noted that local policy considerations, for network and 457 intermediary privacy, MAY restrict the sending of the History-Info 458 headers added by the intermediary in subsequent responses. Thus, in 459 such cases, the proxy MAY remove from these responses the History- 460 Info headers which it inserted in the original forwarded request. 462 2.3.4 Redirect Server Behavior 464 A redirect server SHOULD NOT add any new History-Info, as that would 465 be done by the entity receiving the 3xx response. However, a redirect 466 server MAY include History-Info in responses by adding any History- 467 Info headers received in a request to a subsequent response. 469 2.4 Security for History-Info 471 As discussed in Section 1, the security requirements are partially 472 met by recommending the use of TLS (a basic SIP requirement per [4]) 473 for hop by hop security. In addition, the use of the middle-to-end 474 security solution discussed in [5] allows the integrity of the 475 History-Info to be ascertained as it traverses the intermediaries. 476 For the History-Info header, the general requirement is to secure a 477 header that is inserted by an intermediary and then subsequently 478 referenced, by other intermediaries to build the next header entry or 479 by an end application using the information to provide a service. In 480 terms of exactly what is being secured, it is primarily the captured 481 Request-URIs that are the security concern, since they can reflect 482 some aspect of a user's identity and service routing. However, the 483 indices are also important in that they can be used to determine if 484 specific Request-URIs have been removed from the header. Thus, the 485 primary objective of the security solution is to ensure that the 486 entire History-Info header is protected from being accessed or 487 manipulated by non-authorized entities, with the fundamental 488 assumption that retargeting entities are implicitly authorized. 490 The security associated with the Request History Information is 491 optional and depends upon local policy and the impact on specific 492 applications of having the information compromised. Since, the 493 Request History Information itself is also optional and it has been 494 recommended that applications document the impact of the information 495 not being available, it is also suggested that the impact of not 496 supporting the security recommendations also be documented by the 497 application to ensure that the impacts have been sufficiently 498 addressed by the application. 500 2.4.1 Security examples 502 [Editor's Note: Need to add some protocol details for protecting 503 History-Info once [5] is further along]. 505 2.5 Example Applications using History-Info 507 This scenario highlights an example where the History-Info in the 508 response is primarily of use in not retrying routes that have already 509 been tried by another proxy. Note, that this is just an example and 510 that there may be valid reasons why a Proxy would want to retry the 511 routes and thus, this would like be a local proxy or even user 512 specific policy. 514 UA 1 sends a call to "Bob" to proxy 1. Proxy 1 forwards the request 515 to Proxy 2. Proxy 2 sends the requests in parallel and tries several 516 places (UA2, UA3 and UA4) before sending a response to Proxy 1 that 517 all the places are busy. Proxy 1, without the History-Info, would 518 try several of the same places (UA3 and UA4) based upon registered 519 contacts for "Bob", before completing at UA5. However, with the 520 History-Info, Proxy 1 determines that UA3 and UA4 have already 521 received the invite, thus the INVITE goes directly to UA5. 523 UA1 Proxy1 Proxy2 UA2 UA3 UA4 UA5 525 | | | | | | | 526 |--INVITE -->| | | | | | 527 | |-INVITE->| | | | | 528 Supported: Histinfo 529 History-Info: ;index=1, 530 ; index=2 531 | | | | | | | 532 | | |-INVITE>| | | | 533 History-Info: ;index=1, 534 ; index=2, 535 ; index=2.1 536 | | | | | | | 537 | | |-----INVITE ---->| | | 538 History-Info: ;index=1, 539 ; index=2, 540 ; index=2.2 541 | | | | | | | 542 | | |-------INVITE------------>| | 543 History-Info: ;index=1, 544 ; index=2, 545 ; index=2.3 547 /* All Responses from the INVITEs indicate non-success/non- 548 availability*/ 549 | | | | | | | 550 | |<-480 ---| | | | | 551 History-Info: ;index=1, 552 ; index=2, 553 ;index=2.1, 555 ; index=2.2, 557 ; index=2.3 560 | | | | | | | 561 /* Upon receipt of the response, P1 determines another route for the 562 INVITE, but finds that it matches some routes already attempted 563 (e.g. UA2 and UA3, thus the INVITE is only forwarded to UA5, where 564 the session is successfully established */ 565 | | | | | | | 566 | |----------------INVITE --------------------->| 567 History-Info: ;index=1, 568 ; index=2, 569 ;index=2.1, 571 ; index=2.2, 573 ; index=2.3 576 ;index=1.1 577 | | | | | | | 578 | |<-----200 OK---------------------------------| 579 |<--200 OK---| | | | | | 580 | | | | | | | 581 |--ACK --------------------------------------------------->| 583 Additional detailed scenarios are available in the appendix. 585 3. Security Considerations 587 This draft provides a proposal for addressing the Security 588 requirements identified in [1] in sections 1.2 and 2.4 of this draft 589 by proposing the use of TLS between entities, and by securing the 590 History-Info headers added by proxies as described in [5]. 592 4. IANA Considerations 594 (Note to RFC Editor: Please fill in all occurrences of XXXX in this 595 section with the RFC number of this specification). 597 This document defines a new SIP header field name with a compact 598 form: History-Info and h respectively, and a new option tag: 599 Histinfo. 601 The following changes should be made to 602 http:///www.iana.org/assignments/sip-parameters 604 The following row should be added to the header field section: 606 Header Name Compact Form Reference 607 History-Info h [RFCXXXX] 609 The following should be added to the Options Tags section: 611 Name Description Reference 612 Histinfo When used with the Supported header, [RFCXXXX] 613 this option tag indicates support 614 for the History Information to be 615 captured for requests and returned in 616 subsequent responses. This tag is not 617 used in a Proxy-Require or Require 618 header field since support of 619 History-Info is optional. 621 5. Changes since last version 622 Changes from the �00 to the �01 version: 624 o Attempted to be more explicit about the fundamental processing 625 associated with the header. Removed definitions of new terms, 626 only referencing the terms from the requirements in the context 627 of the fundamental SIP processing implied by the terms. 628 o Attempted to clarify the Index and the related processing. 629 o Added more detail addressing the privacy requirements. 630 o Added a bit more detail on security. The security solution 631 remains in a separate document and this document will need 632 updating once that is completed. 633 o Updated the examples (in section 2.5 and appendix) and clarified 634 the definition and the maintenance of the Index in sections 2.1 635 and 2.3.3.1. 636 o Clarified the Reason description in section 2.1. There had been 637 an error in the description of the processing that was a remnant 638 of the change to include only a single URI for each History-Info 639 header. 640 o Miscellaneous editorial changes (i.e. HistInfo -> Histinfo, 641 etc.) 643 Changes from individual draft-barnes-sipping-history-info-02 to the � 644 00 WG version: 645 o Updated references and added reference to Security solution 646 draft. 647 o Removed appendix D which included background on analysis of 648 solution options. 649 o Cleaned up the document format per rfc2223bis. 650 o Strengthened the inclusion of the INDEX as a MUST (per 651 discussion at IETF-56). 652 o Added text around the capturing of the Reason (SHOULD be 653 captured for SIP responses and MAY be captured for other 654 things such as timeouts). 655 o Clarified the response processing 2.3.3.2 to include 656 provisional responses and the sending of a 183 to convey 657 History-Info. 658 o Added section 2.3.4 to address Redirect Server behavior. 660 References 662 [1] M. Barnes, M. Watson, C. Jennings, J. Peterson, "SIP Generic 663 Request History Capability Requirements", draft-ietf-sipping-req- 664 history-04.txt, June, 2003. 666 [2] A. Johnson, "SIP Service Examples", draft-ietf-sipping-service- 667 examples-05.txt, November, 2002. 669 [3] H. Schulzrinne, D. Oran, G. Camarillo, "The Reason Header Field 670 for the Session Initiation Protocol", RFC 3326, December, 2002. 672 [4] J. Rosenberg et al, "SIP: Session initiation protocol," RFC 3261, 673 June, 2002. 675 [5] M. Barnes, "A Mechanism to Secure SIP Headers Inserted by 676 Intermediaries", draft-barnes-sipping-inserted-info-01.txt, October, 677 2003. 679 [6] J. Peterson, "A Privacy Mechanism for the Session Initiation 680 Protocol (SIP)", RFC 3323, November, 2002. 682 [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement 683 Levels", RFC 2119, March 1997. 685 [8] J. Peterson, "Enhancements for Authenticated Identity Management 686 in the Session Initiation Protocol (SIP)", draft-ietf-sip-identity- 687 01.txt, February, 2003. 689 [9] Crocker, D. and P. Overell, "Augmented BNF for Syntax 690 Specifications: ABNF", RFC 2234, November 1997. 692 Acknowledgements 694 The editor would like to acknowledge the constructive feedback 695 provided by Robert Sparks, Paul Kyzivat, Scott Orton, John Elwell, 696 Nir Chen, Francois Audet, Palash Jain, Brian Stucker, Norma Ng, 697 Anthony Brown, and Jayshree Bharatia. 699 The editor would like to acknowledge the significant input from 700 Rohan Mahy on some of the normative aspects of the ABNF, particularly 701 around the need for and format of the index and around the enhanced 702 SIP security aspects enabled by this draft 704 Contributors' Addresses 706 Cullen and Mark provided substantial input in the form of email 707 discussion in the development of the initial version of this 708 individual solution document. 710 Cullen Jennings 711 Cisco Systems 712 170 West Tasman Dr 713 MS: SJC-21/3 715 Tel: +1 408 527 9132 716 Email: fluffy@cisco.com 718 Mark Watson 719 Nortel Networks (UK) 720 Maidenhead Office Park (Bray House) 721 Westacott Way 722 Maidenhead, 723 Berkshire 724 England 726 Tel: +44 (0)1628-434456 727 Email: mwatson@nortelnetworks.com 729 Author's Address 731 Mary Barnes 732 Nortel Networks 733 2380 Performance Drive 734 Richardson, TX USA 736 Phone: 1-972-684-5432 737 Email: mary.barnes@nortelnetworks.com 739 Appendix A Forking Scenarios 741 A.1 Sequentially forking (History-Info in Response) 743 This scenario highlights an example where the History-Info in the 744 response is useful to an application or user that originated the 745 request. 747 UA 1 sends a call to "Bob" via proxy 1. Proxy 1 sequentially tries 748 several places (UA2, UA3 and UA4) unsuccessfully before sending a 749 response to UA1. 751 This scenario is provided to show that by providing the History-Info 752 to UA1, the end user or an application at UA1 could make a decision 753 on how best to attempt finding "Bob". Without this mechanism UA1 754 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 755 the end user or application could know that "Bob" is busy on his home 756 phone and is physically not in the office. If there were an 757 alternative address for "Bob" known to this end user or application, 758 that hasn't been attempted, then either the application or the end 759 user could attempt that. The intent here is to highlight an example 760 of the flexibility of this mechanism that enables applications well 761 beyond SIP as it is certainly well beyond the scope of this draft to 762 prescribe detailed applications. 764 UA1 Proxy1 UA2 UA3 UA4 765 | | | | | 766 |--INVITE -->| | | | 767 | | | | | 768 | |--INVITE -------->| | | 769 |<--100 -----| | | | 770 | |<-302 ------------| | | 771 | | | | | 772 | |-------INVITE ------------>| | 773 | | | | | 774 | |<-------180 ---------------| | 775 |<---180 ----| | | | 776 | . . |-------INVITE------------->| | 777 | | timeout | | | 778 | | | | | 779 | |------INVITE ---------------------->| 780 |<--100 -----| | | | 781 | | | | | 782 | |<-486 ------------------------------| 783 | | | | | 784 | |-- ACK ---------------------------->| 785 |<--486------| | | | 786 | | | | | 787 |--ACK ----->| | | | 788 | | | | | 790 [Editor's Note: Need to detail the message flow.] 792 A.2 Sequential Forking (with Success) 794 This scenario highlights an example where the History-Info in the 795 request is primarily of use in not retrying routes that have already 796 been tried by another proxy. Note, that this is just an example and 797 that there may be valid reasons why a Proxy would want to retry the 798 routes and thus, this would like be a local proxy or even user 799 specific policy. 801 UA 1 sends a call to "Bob" to proxy 1. Proxy 1 sequentially tries 802 several places (UA2, UA3 and UA4) before retargeting the call to 803 Proxy 2. Proxy 2, without the History-Info, would try several of the 804 same places (UA3 and UA4)based upon registered contacts for "Bob", 805 before completing at UA5. However, with the History-Info, Proxy 2 806 determines that UA3 and UA4 have already received the invite, thus 807 the INVITE goes directly to UA5. 809 UA1 Proxy1 Proxy2 UA2 UA3 UA4 UA5 811 | | | | | | | 812 |--INVITE -->| | | | | | 813 | | | | | | | 814 | |--INVITE -------->| | | | 815 |<--100 -----| | | | | | 816 | |<-302 ------------| | | | 817 | | | | | | | 818 | |-------INVITE ------------>| | | 819 | | | | | | | 820 | |<-------180 ---------------| | | 821 |<---180 ----| | | | | | 822 | . . |-------INVITE------------->| | | 823 | | timeout | | | | 824 | | | | | | | 825 | |------INVITE ---------------------->| | 826 |<--100 -----| | | | | | 827 | |<-302 ------------------------------| | 828 | | | | | | | 829 | |-INVITE->| | | | | 830 | | | | | | | 831 | | | | | | | 832 | | |------INVITE --------------------->| 833 | | | | | | | 834 | | |<-----200 OK---------------------->| 835 |<--200 OK-------------| | | | | 836 | | | | | | | 837 |--ACK --------------------------------------------------->| 839 [Editor's Note: Need to add the details of the messages here.] 841 Appendix B Voicemail 843 This scenario highlights an example where the History-Info in the 844 request is primarily of use by an edge service (e.g. Voicemail 845 Server). It should be noted that this isn't intended to be a complete 846 specification for this specific edge service as it is quite likely 847 that additional information is need by the edge service. History-Info 848 is just one building block that this service makes use of. 850 UA 1 called UA A which had been forwarded to UA B which forwarded to 851 a UA VM (voicemail server). Based upon the retargeted URIs and 852 Reasons (and other information) in the INVITE, the VM server makes a 853 policy decision about what mailbox to use, which greeting to play 854 etc. 856 UA1 Proxy UA-A UA-B UA-VM 858 | | | | | 859 |--INVITE F1-->| | | | 860 | | | | | 861 | |--INVITE F2-->| | | 862 |<--100 F3-----| | | | 863 | |<-302 F4------| | | 864 | | | | | 865 | |--------INVITE F5---------->| | 866 | | | | | 867 | |<--------180 F6-------------| | 868 |<---180 F7----| | | | 869 | . . . | | | | 870 | |------retransmit INVITE---->| | 871 | . . . | | | | 872 | | (timeout) | | 873 | | | | | 874 | |-------INVITE F8---------------------->| 875 | | | | | 876 | |<-200 F9-------------------------------| 877 | | | | | 878 |<-200 F10-----| | | | 879 | | | | | 880 |--ACK F11-------------------------------------------->| 882 Message Details 884 INVITE F1 UA1->Proxy 886 INVITE sip:UserA@nortelnetworks.com SIP/2.0 887 Via: SIP/2.0/UDP here.com:5060 888 From: BigGuy 889 To: LittleGuy 890 Call-Id: 12345600@here.com 891 CSeq: 1 INVITE 892 Contact: BigGuy 893 Content-Type: application/sdp 894 Content-Length: 896 v=0 897 o=UserA 2890844526 2890844526 IN IP4 client.here.com 898 s=Session SDP 899 c=IN IP4 100.101.102.103 900 t=0 0 901 m=audio 49170 RTP/AVP 0 902 a=rtpmap:0 PCMU/8000 904 /*Client for UA1 prepares to receive data on port 49170 905 from the network. */ 907 INVITE F2 Proxy->UA-A 909 INVITE sip:UserA@ims.nortelnetworks.com SIP/2.0 910 Via: SIP/2.0/UDPims.nortelnetworks.com:5060;branch=1 911 Via: SIP/2.0/UDP here.com:5060 912 Record-Route: 913 From: BigGuy 914 To: LittleGuy 915 Call-Id: 12345600@here.com 916 CSeq: 1 INVITE 917 History-Info: ; index=1 918 Contact: BigGuy 919 Content-Type: application/sdp 920 Content-Length: 922 v=0 923 o=UserA 2890844526 2890844526 IN IP4 client.here.com 924 s=Session SDP 925 c=IN IP4 100.101.102.103 926 t=0 0 927 m=audio 49170 RTP/AVP 0 928 a=rtpmap:0 PCMU/8000 930 100 Trying F3 Proxy->UA1 932 SIP/2.0 100 Trying 933 Via: SIP/2.0/UDP here.com:5060 934 From: BigGuy 935 To: LittleGuy 936 Call-Id: 12345600@here.com 937 CSeq: 1 INVITE 938 Content-Length: 0 940 302 Moved Temporarily F4 UserA->Proxy 941 SIP/2.0 302 Moved Temporarily 942 Via: SIP/2.0/UDP ims.nortelnetworks.com:5060;branch=1 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: 949 Content-Length: 0 950 INVITE F5 Proxy-> UA-B 952 INVITE sip:UserB@nortelnetworks.com SIP/2.0 953 Via: SIP/2.0/UDP ims.nortelnetworks.com:5060;branch=2 954 Via: SIP/2.0/UDP here.com:5060 955 From: BigGuy 956 To: LittleGuy 957 Call-Id: 12345600@here.com 958 History-Info: ; index=1, 960 ;index=2 961 CSeq: 1 INVITE 962 Contact: BigGuy 963 Content-Type: application/sdp 964 Content-Length: 966 v=0 967 o=User1 2890844526 2890844526 IN IP4 client.here.com 968 s=Session SDP 969 c=IN IP4 100.101.102.103 970 t=0 0 971 m=audio 49170 RTP/AVP 0 972 a=rtpmap:0 PCMU/8000 974 180 Ringing F6 UA-B ->Proxy 976 SIP/2.0 180 Ringing 977 Via: SIP/2.0/UDP there.com:5060 978 From: BigGuy 979 To: LittleGuy ;tag=5 980 Call-ID: 12345600@here.com 981 CSeq: 1 INVITE 982 Content-Length: 0 984 180 Ringing F7 Proxy-> UA1 986 SIP/2.0 180 Ringing 987 SIP/2.0/UDP here.com:5060 988 From: BigGuy 989 To: LittleGuy 990 Call-Id: 12345600@here.com 991 CSeq: 1 INVITE 992 Content-Length: 0 994 /* User B is not available. INVITE is sent multiple 995 times until it times out. */ 996 /* The proxy forwards the INVITE to UA-VM after adding the 997 additional History Information entry. */ 999 INVITE F8 Proxy-> UA-VM 1001 INVITE sip:VM@nortelnetworks.com SIP/2.0 1002 Via: SIP/2.0/UDP ims.nortelnetworks.com:5060;branch=3 1003 Via: SIP/2.0/UDP here.com:5060 1004 From: BigGuy 1005 To: LittleGuy 1006 Call-Id: 12345600@here.com 1007 History-Info: ;index=1, 1009 ;index=2, 1011 ;index=3 1012 CSeq: 1 INVITE 1013 Contact: BigGuy 1014 Content-Type: application/sdp 1015 Content-Length: 1017 v=0 1018 o=User1 2890844526 2890844526 IN IP4 client.here.com 1019 s=Session SDP 1020 c=IN IP4 100.101.102.103 1021 t=0 0 1022 m=audio 49170 RTP/AVP 0 1023 a=rtpmap:0 PCMU/8000 1025 200 OK F9 1027 SIP/2.0 200 OK UA-VM->Proxy 1029 Via: SIP/2.0/UDP ims.nortelnetworks.com:5060;branch=3 1030 Via: SIP/2.0/UDP here.com:5060 1031 From: BigGuy 1032 To: LittleGuy ;tag=3 1033 Call-Id: 12345600@here.com 1034 CSeq: 1 INVITE 1035 Contact: TheVoiceMail 1036 Content-Type: application/sdp 1037 Content-Length: 1039 v=0 1040 o=UserA 2890844527 2890844527 IN IP4 vm.nortelnetworks.com 1041 s=Session SDP 1042 c=IN IP4 110.111.112.114 1043 t=0 0 1044 m=audio 3456 RTP/AVP 0 1045 a=rtpmap:0 PCMU/8000 1047 200 OK F10 Proxy->UA1 1049 SIP/2.0 200 OK 1050 Via: SIP/2.0/UDP ims.nortelnetworks.com:5060;branch=3 1051 Via: SIP/2.0/UDP here.com:5060 1052 From: BigGuy 1053 To: LittleGuy ;tag=3 1054 Call-Id: 12345600@here.com 1055 CSeq: 1 INVITE 1056 Contact: TheVoiceMail 1057 Content-Type: application/sdp 1058 Content-Length: 1060 v=0 1061 o=UserA 2890844527 2890844527 IN IP4 vm.nortelnetworks.com 1062 s=Session SDP 1063 c=IN IP4 110.111.112.114 1064 t=0 0 1065 m=audio 3456 RTP/AVP 0 1066 a=rtpmap:0 PCMU/8000 1068 ACK F11 UA1-> UA-VM 1070 ACK sip:VM@nortelnetworks.com SIP/2.0 1071 Via: SIP/2.0/UDP here.com:5060 1072 From: BigGuy 1073 To: LittleGuy;tag=3 1074 Call-Id: 12345600@here.com 1075 CSeq: 1 ACK 1076 Content-Length: 0 1078 /* RTP streams are established between UA1 and 1079 UA-VM. UA-VM starts announcement for UA1 */ 1081 Appendix C Automatic Call Distribution Example 1083 This scenario highlights an example of an Automatic Call Distribution 1084 service, where the agents are divided into groups based upon the type 1085 of customers they handle. In this example, the Gold customers are 1086 given higher priority than Silver customers, so a Gold call would get 1087 serviced even if all the agents servicing the Gold group (ACDGRP1) 1088 were busy, by retargeting the request to the Silver Group. Upon 1089 receipt of the call at the agent assigned to handle the incoming 1090 call, based upon the History-Info header in the message, the 1091 application at the agent can provide an indication that this is a 1092 Gold call, from how many groups it might have overflowed before 1093 reaching the agent, etc. and thus can be handled appropriately by the 1094 agent. 1096 For scenarios whereby calls might overflow from the Silver to the 1097 Gold, clearly the alternate group identification, internal routing or 1098 actual agent that handles the call SHOULD not be sent to UA1, thus 1099 for this scenario, one would expect that the Proxy would not support 1100 the sending of the History-Info in the response, even if requested by 1101 the calling UA. 1103 As with the other examples, this is not prescriptive of how one would 1104 do this type of service but an example of a subset of processing that 1105 might be associated with such a service. In addition, this example 1106 is not addressing any aspects of Agent availability, which might also 1107 be done via a SIP interface. 1109 UA1 Proxy ACDGRP1 Svr ACDGRP2 Svr UA2-ACDGRP2 1111 | | | | | 1112 |--INVITE F1-->| | | | 1113 Supported:Histinfo 1114 | | | | | 1115 | |--INVITE F2-->| | | 1116 Supported:Histinfo 1117 History-Info: ; index=1 1118 History-Info: ; index=1.1 1119 | | | | | 1120 | |<-302 F3------| | | 1121 Contact: 1122 | | | | | 1123 | |--------INVITE F4---------->| | 1124 History-Info: ; index=1 1125 History-Info: ; index=1.1 1126 History-Info: ; index=1.2 1127 | | | | | 1128 | | | | | 1129 | | | |INVITE F5>| 1130 History-Info: ; index=1 1131 History-Info: ; index=1.1 1132 History-Info: ; index=1.2 1133 | | | | | 1134 | | | |<-200 F6--| 1135 | | | | | 1136 | |<-200 F7--------------------| | 1137 History-Info: ; index=1 1138 History-Info: ; index=1.1 1139 History-Info: ; index=1.2 1140 |<-200 F8------| | | | 1141 No History-Info included in the response due to Local Policy> 1142 | | | | | 1143 |--ACK F9--------------------------------------------->| 1145 Message Details 1147 [To be completed] 1149 Full Copyright Statement 1151 Copyright (C) The Internet Society (2003). All Rights Reserved. 1153 This document and translations of it may be copied and furnished to 1154 others, and derivative works that comment on or otherwise explain it 1155 or assist in its implementation may be prepared, copied, published 1156 and distributed, in whole or in part, without restriction of any 1157 kind, provided that the above copyright notice and this paragraph are 1158 included on all such copies and derivative works. However, this 1159 document itself may not be modified in any way, such as by removing 1160 the copyright notice or references to the Internet Society or other 1161 Internet organizations, except as needed for the purpose of 1162 developing Internet standards in which case the procedures for 1163 copyrights defined in the Internet Standards process must be 1164 followed, or as required to translate it into languages other than 1165 English. The limited permissions granted above are perpetual and 1166 will not be revoked by the Internet Society or its successors or 1167 assigns. This document and the information contained herein is 1168 provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 1169 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 1170 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1171 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1172 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."