idnits 2.17.1 draft-barnes-sipcore-rfc4244bis-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 6 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? == The 'Obsoletes: ' line in the draft header should list only the _numbers_ of the RFCs which will be obsoleted by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 290 has weird spacing: '... Alice atla...' == Line 1471 has weird spacing: '... Alice exam...' == Line 1894 has weird spacing: '... Alice atla...' == Line 1945 has weird spacing: '... Alice atla...' == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 26, 2009) is 5289 days in the past. Is this intentional? 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: 'RFCXXXX' is mentioned on line 1028, but not defined ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 4244 (Obsoleted by RFC 7044) -- Obsolete informational reference (is this intentional?): RFC 3761 (Obsoleted by RFC 6116, RFC 6117) Summary: 3 errors (**), 0 flaws (~~), 9 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Barnes 3 Internet-Draft Nortel 4 Obsoletes: RFC4244 F. Audet 5 (if approved) Skype Labs 6 Intended status: Standards Track S. Schubert 7 Expires: April 29, 2010 NTT 8 J. van Elburg 9 Detecon International Gmbh 10 C. Holmberg 11 Ericsson 12 October 26, 2009 14 An Extension to the Session Initiation Protocol (SIP) for Request 15 History Information 16 draft-barnes-sipcore-rfc4244bis-03.txt 18 Status of this Memo 20 This Internet-Draft is submitted to IETF in full conformance with the 21 provisions of BCP 78 and BCP 79. This document may contain material 22 from IETF Documents or IETF Contributions published or made publicly 23 available before November 10, 2008. The person(s) controlling the 24 copyright in some of this material may not have granted the IETF 25 Trust the right to allow modifications of such material outside the 26 IETF Standards Process. Without obtaining an adequate license from 27 the person(s) controlling the copyright in such materials, this 28 document may not be modified outside the IETF Standards Process, and 29 derivative works of it may not be created outside the IETF Standards 30 Process, except to format it for publication as an RFC or to 31 translate it into languages other than English. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF), its areas, and its working groups. Note that 35 other groups may also distribute working documents as Internet- 36 Drafts. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 The list of current Internet-Drafts can be accessed at 44 http://www.ietf.org/ietf/1id-abstracts.txt. 46 The list of Internet-Draft Shadow Directories can be accessed at 47 http://www.ietf.org/shadow.html. 49 This Internet-Draft will expire on April 29, 2010. 51 Copyright Notice 53 Copyright (c) 2009 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents in effect on the date of 58 publication of this document (http://trustee.ietf.org/license-info). 59 Please review these documents carefully, as they describe your rights 60 and restrictions with respect to this document. 62 Abstract 64 This document defines a standard mechanism for capturing the history 65 information associated with a Session Initiation Protocol (SIP) 66 request. This capability enables many enhanced services by providing 67 the information as to how and why a call arrives at a specific 68 application or user. This document defines an optional SIP header, 69 History-Info, for capturing the history information in requests. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 74 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 5 75 3. Overview of Operations . . . . . . . . . . . . . . . . . . . . 6 76 4. General User Agent Behavior . . . . . . . . . . . . . . . . . 9 77 4.1. User Agent Client (UAC) Behavior . . . . . . . . . . . . . 9 78 4.2. User Agent Server (UAS) Behavior . . . . . . . . . . . . . 10 79 4.2.1. Redirect Server Behavior . . . . . . . . . . . . . . . 11 80 5. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . . . 12 81 5.1. Adding the History-Info Header to Requests . . . . . . . . 12 82 5.1.1. Initial Request . . . . . . . . . . . . . . . . . . . 12 83 5.1.2. Re-sending based on failure response . . . . . . . . . 13 84 5.1.3. Re-sending based on redirection response . . . . . . . 14 85 5.2. Sending History-Info in Responses . . . . . . . . . . . . 15 86 6. The History-Info header field . . . . . . . . . . . . . . . . 15 87 6.1. Definition . . . . . . . . . . . . . . . . . . . . . . . . 15 88 6.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 17 89 6.3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 18 90 6.3.1. Privacy in the History-Info Header . . . . . . . . . . 18 91 6.3.2. Reason in the History-Info Header . . . . . . . . . . 19 92 6.3.3. Indexing in the History-Info Header . . . . . . . . . 19 93 6.3.4. Request Target in the History-Info Header . . . . . . 21 94 7. Application Considerations . . . . . . . . . . . . . . . . . . 21 95 8. Security Considerations . . . . . . . . . . . . . . . . . . . 22 96 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 97 9.1. Registration of New SIP History-Info Header . . . . . . . 23 98 9.2. Registration of "history" for SIP Privacy Header . . . . . 24 99 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 24 100 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 101 12. Changes from RFC 4244 . . . . . . . . . . . . . . . . . . . . 24 102 12.1. Backwards compatibility . . . . . . . . . . . . . . . . . 26 103 13. Changes since last Version . . . . . . . . . . . . . . . . . . 26 104 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 105 14.1. Normative References . . . . . . . . . . . . . . . . . . . 29 106 14.2. Informative References . . . . . . . . . . . . . . . . . . 29 107 Appendix A. Request History Requirements . . . . . . . . . . . . 30 108 A.1. Security Requirements . . . . . . . . . . . . . . . . . . 31 109 A.2. Privacy Requirements . . . . . . . . . . . . . . . . . . . 32 110 Appendix B. Detailed call flows . . . . . . . . . . . . . . . . . 32 111 B.1. Sequentially Forking (History-Info in Response) . . . . . 32 112 B.2. Voicemail . . . . . . . . . . . . . . . . . . . . . . . . 40 113 B.3. Automatic Call Distribution . . . . . . . . . . . . . . . 42 114 B.4. History-Info with Privacy Header . . . . . . . . . . . . . 44 115 B.5. Privacy Header for a Specific History-Info Entry . . . . . 45 116 B.6. Determining the Alias used. . . . . . . . . . . . . . . . 47 117 B.7. GRUU . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 118 B.8. Limited Use Address . . . . . . . . . . . . . . . . . . . 51 119 B.9. Sub-Address . . . . . . . . . . . . . . . . . . . . . . . 53 120 B.10. Service Invocation . . . . . . . . . . . . . . . . . . . . 57 121 B.11. Toll Free Number . . . . . . . . . . . . . . . . . . . . . 58 122 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 60 124 1. Introduction 126 Many services that SIP is anticipated to support require the ability 127 to determine why and how the call arrived at a specific application. 128 Examples of such services include (but are not limited to) sessions 129 initiated to call centers via "click to talk" SIP Uniform Resource 130 Locators (URLs) on a web page, "call history/logging" style services 131 within intelligent "call management" software for SIP User Agents 132 (UAs), and calls to voicemail servers. Although SIP implicitly 133 provides the redirect/retarget capabilities that enable calls to be 134 routed to chosen applications, there is a need for a standard 135 mechanism within SIP for communicating the retargeting history of 136 such a request. This "request history" information allows the 137 receiving application to determine hints about how and why the call 138 arrived at the application/user. 140 This document defines a SIP header, History-Info, to provide a 141 standard mechanism for capturing the request history information to 142 enable a wide variety of services for networks and end-users. The 143 History-Info header provides a building block for development of new 144 services. 146 The requirements for this document are described in Appendix A. 148 2. Conventions and Terminology 150 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 151 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 152 document are to be interpreted as described in [RFC2119]. 154 The term "retarget" is used in this document to refer both to the 155 process of a Proxy Server/User Agent Client (UAC) changing a Uniform 156 Resource Identifier (URI) in a request based on the rules for 157 determining request targets as described in Section 16.5 of [RFC3261] 158 and the subsequent forwarding of that request as described in section 159 16.6 of [RFC3261]. 161 The term "forward" is used consistent with the terminology in 162 [RFC3261]. Noting that [RFC3261] uses the term "forwarding" to 163 describe a proxy's handling of requests for domains for which is not 164 responsible, as well as to describe the basic "forwarding" of a 165 request (in section 16.6) once a target has been determined. 166 However, the context of the usage is sufficient to differentiate the 167 slightly different meanings. 169 The terms "location service" and "redirect" are used consistent with 170 the terminology in [RFC3261]. 172 3. Overview of Operations 174 SIP implicitly provides retargeting capabilities that enable calls to 175 be routed to specific applications as defined in [RFC3261]. The 176 motivation for capturing the request history is that in the process 177 of retargeting a request, old routing information can be forever 178 lost. This lost information may be important history that allows 179 elements to which the call is retargeted to process the call in a 180 locally defined, application-specific manner. This document defines 181 a mechanism for transporting the request history. Application- 182 specific behavior is outside the scope of this specification. 184 Current network applications provide the ability for elements 185 involved with the call to exchange additional information relating to 186 how and why the call was routed to a particular destination. The 187 following are examples of such applications: 189 1. Web "referral" applications, whereby an application residing 190 within a web server determines that a visitor to a website has 191 arrived at the site via an "associate" site that will receive 192 some "referral" commission for generating this traffic 194 2. Email forwarding whereby the forwarded-to user obtains a 195 "history" of who sent the email to whom and at what time 197 3. Traditional telephony services such as voicemail, call-center 198 "automatic call distribution", and "follow-me" style services 200 Several of the aforementioned applications currently define 201 application-specific mechanisms through which it is possible to 202 obtain the necessary history information. 204 In addition, request history information could be used to enhance 205 basic SIP functionality by providing the following: 207 o Some diagnostic information for debugging SIP requests. (Note 208 that the diagnostic utility of this mechanism is limited by the 209 fact that its use by entities that retarget is optional.) 211 o Capturing aliases and Globally Routable User Agent URIs (GRUUs) 212 [RFC5627], which can be overwritten by a home proxy upon receipt 213 of the initial request. 215 o Facilitating the use of limited use addresses (minted on demand) 216 and sub-addressing. 218 o Preserving service specific URIs that can be overwritten by a 219 downstream proxy, such as those defined in [RFC3087], and control 220 of network announcements and IVR with SIP URI [RFC4240]. 222 o A stronger security solution for SIP. A side effect is that each 223 proxy that captures the "request history" information in a secure 224 manner provides an additional means (without requiring signed 225 keys) for the original requestor to be assured that the request 226 was properly retargeted. 228 The fundamental functionality provided by the request history 229 information is the ability to inform proxies and UAs involved in 230 processing a request about the history or progress of that request 231 (CAPABILITY-req, see Appendix A). The solution is to capture the 232 Request-URIs as a request is retargeted, in a new header for SIP 233 messages: History-Info (CONTENT-req, see Appendix A). This allows 234 for the capturing of the history of a request that would be lost with 235 the normal SIP processing involved in the subsequent retargeting of 236 the request. This solution proposes no changes in the fundamental 237 determination of request targets or in the request forwarding as 238 defined in Sections 16.5 and 16.6 of the SIP protocol specification 239 [RFC3261]. 241 The History-Info header can appear in any request not associated with 242 an established dialog (e.g., INVITE, REGISTER, MESSAGE, REFER and 243 OPTIONS, PUBLISH and SUBSCRIBE, etc.) (REQUEST-VALIDITY-req, 244 seeAppendix A) and any valid response to these requests (ISSUER-req, 245 seeAppendix A). 247 This specification defines parameters (see Section 6.1) for carrying 248 the following information in the History-Info header: 250 o Targeted-to-URI: The targeted-to-URI entry captures the Request- 251 URI for the specific Request as it is forwarded. 253 o Index: The index reflects the chronological order of the 254 information, indexed to also reflect the forking and nesting of 255 requests. 257 o Reason: Reason describes why an entry was retargeted. 259 o Privacy: Privacy is used to request that entries be anonymized. 261 o Target: The target parameter indicates the mechanism by which the 262 new target is determined, i.e., a "registered contact", or a 263 "mapped URI" 265 The following is an illustrative example of usage of History-Info. 267 In this example, Alice (sip:alice@atlanta.example.com) calls Bob 268 (sip:bob@biloxi.example.com). Alice's home proxy (sip: 269 atlanta.example.com) forwards the request to Bob's proxy (sip: 270 biloxi.example.com). When the request arrives at sip: 271 biloxi.example.com, it does a location service lookup for 272 bob@biloxi.example.com and changes the target of the request to Bob's 273 Contact URIs provided as part of normal SIP registration. In this 274 example, Bob is simultaneously contacted on a PC client and on a 275 phone, and Bob answers on the PC client. 277 One important thing illustrated by this call flow is that without 278 History-Info, Bob would "lose" the target information, including any 279 parameters in the request URI. Bob can now recover that information 280 by looking for the prior entry to the last hi-entry marked as "rc" 282 The formatting in this scenario is for visual purposes; thus, 283 backslash and CRLF are used between the fields for readability and 284 the headers in the URI are not shown properly formatted for escaping. 285 Refer to Section 6.2 for the proper formatting. Additional detailed 286 scenarios are available in the Appendix B. 288 Note: This example uses loose routing procedures. 290 Alice atlanta.example.com biloxi.example.com Bob@pc Bob@phone 291 | | | | | 292 | INVITE sip:bob@biloxi.example.com;p=x | | 293 |--------------->| | | | 294 | Supported: histinfo | | | 295 | | | | | 296 | | INVITE sip:bob@biloxi.example.com;p=x 297 | |--------------->| | | 298 | History-Info: ;index=1 299 | History-Info: ;index=1.1 300 | | | | | 301 | | | INVITE sip:bob@192.0.2.3 302 | | |--------------->| | 303 | History-Info: ;index=1 304 | History-Info: ;index=1.1 305 | History-Info: ;index=1.1.1;rc 306 | | | | | 307 | | | INVITE sip:bob@192.0.2.7 308 | | |-------------------------->| 309 | History-Info: ;index=1 310 | History-Info: ;index=1.1 311 | History-Info: ;index=1.1.2;rc 312 | | | 200 | | 313 | | |<---------------| | 314 | History-Info: ;index=1 315 | History-Info: ;index=1.1 316 | History-Info: ;index=1.1.1;rc 317 | | | | | 318 | | |<===Proxy cancels INVITE==>| 319 | | 200 | | | 320 | |<---------------| | | 321 | History-Info: ;index=1 322 | History-Info: ;index=1.1 323 | History-Info: ;index=1.1.1;rc 324 | History-Info: ;\ 325 | index=1.1.2;rc 326 | | | | | 327 | 200 | | | | 328 |<---------------| | | | 329 | History-Info: ;index=1 330 | History-Info: ;index=1.1 331 | History-Info: ;\ 333 | index=1.1.2;rc 334 | | | | | 335 | ACK | | | | 336 |--------------->| ACK | | | 337 | |--------------->| ACK | | 338 | | |--------------->| | 340 Figure 1: Basic Call 342 4. General User Agent Behavior 344 This section describes the processing specific to UAs for the 345 History-Info header. 347 4.1. User Agent Client (UAC) Behavior 349 The UAC SHOULD include the "histinfo" option tag in the Supported 350 header in any request not associated with an established dialog for 351 which the UAC would like the History-Info header in the response. In 352 addition, the UAC MAY add a History-Info header, using the Request- 353 URI of the request as the hi-target-to-uri, in which case the index 354 MUST be set to a value of 1 in the hi-entry. As a result, 355 intermediaries and the UAS will know at least the original Request- 356 URI, and if the Request-URI was modified by a previous hop. 357 Normally, UACs are not expected to include a History-Info header in 358 an initial request as it is more of a Proxy function; the main reason 359 it is allowed is for B2BUAs who are performing proxy-like functions 360 like routing. 362 A UAC that does not want an hi-entry added due to privacy 363 considerations MUST include a Privacy header with a priv-value(s) of 364 "header" or "history." A UAC that wants to ensure that privacy not 365 be applied to its identity MUST include a Privacy header with a priv- 366 value of "none." 368 In the case where a UAC receives a 3xx response with a Contact header 369 and sends a new request in response to it, the UAC MUST include in 370 the outgoing request the previous hi-entry(s) received in the 371 response. The UAC MUST evaluate the last hi-entry in the 3xx 372 response and verify that they are the same (as per the procedures in 373 section Section 4.2.1); if the hi-entry is not the same as the value 374 in contact, hi-entry MUST be added using the value of Contact. 376 If the hi-entry for the redirection is not included in the 3xx 377 response, then an hi-entry MUST be added to the outgoing request. In 378 this case, the index MUST be created by reading and incrementing the 379 value of the index from the previous hi-entry, thus following the 380 same rules as those prescribed for a proxy in retargeting, described 381 in Section 6.3.3. The reason MUST be added per Section 6.3.2. The 382 hi-target and hi-aor attributes MUST NOT be added to this hi-entry 383 since there is no way to know the mechanism by which the redirecting 384 entity determined the URI in the Contact header nor whether the 385 previous hi-targeted-to-uri was an AOR. 387 If no hi-entry for redirection were included at all in the 3xx 388 response, and multiple redirection occurs, the UAC MAY attempt to 389 synthetise the missing hi-entrie(s) before inserting the last one (as 390 per the previous step). At a minimum, the last entry (as per the 391 previous step) MUST be included. 393 With the exception of the processing of a 3xx response described 394 above, the processing of the History-Info header received in the 395 Response is application specific and outside the scope of this 396 document. 398 4.2. User Agent Server (UAS) Behavior 400 Once the request terminates at the UAS, the processing of the 401 information in the History-Info header by a UAS in a Request depends 402 upon local policy and specific applications at the UAS that might 403 make use of the information. Prior to any application usage of the 404 information, the validity SHOULD be ascertained. For example, the 405 entries MAY be evaluated to determine gaps in indices, which could 406 indicate that an entry has been maliciously removed or removed for 407 privacy reasons. Either way, an application MAY want to be aware of 408 potentially missing information. 410 If the "histinfo" option tag is received in a request, the UAS MUST 411 include any History-Info received in the request in the subsequent 412 response. If privacy is required, entries MUST be anonymized using 413 [RFC3323]. The UAS MUST follow the rules for a redirect server per 414 Section 4.2.1 in generating a 3xx response. 416 The processing of History-Info in responses follows the methodology 417 described in Section 16.7 of [RFC3261], with the processing of 418 History-Info headers adding an additional step, just before Step 9, 419 "Forwarding the Response". 421 4.2.1. Redirect Server Behavior 423 A redirect server MUST include the History-Info headers received in 424 the request in the 3XX response that it sends, and it MUST perform 425 the following steps: 427 Step 1: Adding Entries on Behalf of Previous Hops 429 If an incoming request does not already have a History-Info header 430 field (e.g., the UAC does not include any History-Info header and 431 no proxies in between support History-Info), or if the Request-URI 432 of the incoming request does not match the last hi-entry (e.g., 433 the last hop proxy does not support History-Info), the redirect 434 server MUST insert an hi-entry. The redirect server MUST set the 435 hi-targeted-to-uri to the value of Request URI in the incoming 436 request, unless privacy is required. If privacy is required, the 437 procedures of Section 6.3.1 MUST be used. The proxy MUST NOT 438 include a hi-target attribute. The proxy MUST include an hi-index 439 attribute as described in Section 6.3.3. 441 Step 2: Tagging the Last Incoming Entry 443 The redirect server then examines the last hi-entry of the 444 History-Info header resulting from the previous step. If privacy 445 is required for this entry, the procedures of Section 6.3.1 MUST 446 be used for that entry. The Reason header MUST be added to that 447 entry as per the procedures of Section 6.3.2, and must be set to 448 the proper SIP 3XX response. 450 Step 3: Generating New Entries for the Response 452 The redirect servert MUST add a new hi-entry for each of the 453 Contact header URIs, which becomes the new Request-URIs when the 454 recipient forwards the new Request. The index is created as 455 described in Section 6.3.3. If privacy is required, the 456 procedures of Section 6.3.1 MUST be used. A hi-target parameter 457 MUST be included if the new Request-URI either represents another 458 user or registered contact as per the procedures of Section 6.3.4. 460 Redirection is an iterative process, i.e., a redirect server may 461 redirect "internally " more than one time. A typical example would 462 be a redirect server that redirects a request first to a different 463 user (i.e., it maps to a different AOR), and then redirects again to 464 a registered contact bound to that new AOR. A redirect server that 465 uses such mechamism SHOULD add multiple hi-entry fields to provide a 466 logical description of retargeting process (e.g., bob@example.com to 467 office@example.com to office@192.0.2.5). A Reason MAY be associated 468 with the hi-targeted-to-uri that has been retargeted. See the 469 example inAppendix B.1) for an example. 471 5. Proxy Behavior 473 The specific processing by proxies for adding the History-Info 474 headers in Requests and Responses is described in this section for 475 the following cases: 477 o Forwarding of initial request (see Section 5.1.1) 479 o Resending based on failure response (see Section 5.1.2) 481 o Resending based on redirection response (see Section 5.1.3) 483 5.1. Adding the History-Info Header to Requests 485 This section describes the process of adding the History-Info Header 486 to Requests. 488 Retargeting is an iterative process, i.e., a proxy may redirect 489 "internally " more than one time. A typical example would be a proxy 490 that redirects a request first to a different user (i.e., it maps to 491 a different AOR), and then forwards to a registered contact bound to 492 that new AOR. A proxy that uses such mechamism SHOULD add multiple 493 hi-entry fields to provide a logical description of the retargeting 494 process. 496 5.1.1. Initial Request 498 Upon receipt of an initial request for a dialog, or a standalone 499 request, a proxy forwarding the request MUST perform the following 500 steps. Note that those steps below do not apply if the request is 501 being re-sent as a result of failure (i.e., timeout, reception of an 502 error response), or redirection caused by receipt of a 3XX message). 504 Step 1: Adding Entries on Behalf of Previous Hops 506 If an incoming request does not already have a History-Info header 507 field (e.g., the UAC does not include any History-Info header and 508 no proxies in between support History-Info), or if the Request-URI 509 of the incoming request does not match the last hi-entry (e.g., 510 the last proxy does not support History-Info), the proxy MUST 511 insert an hi-entry. The proxy MUST set the hi-targeted-to-uri 512 based to the value of Request URI in the incoming request, unless 513 privacy is required. If privacy is required, the procedures of 514 Section 6.3.1 MUST be used. The proxy MUST NOT include a hi- 515 target attribute. The proxy MUST include an hi-index attribute as 516 described in Section 6.3.3. 518 Step 2: Generating New Entries for Each Outgoing Requests 520 The proxy then proceeds to determining the request targets as per 521 16.5/[RFC3261] and request forwarding as per 16.6/[RFC3261]. The 522 proxy MUST add a separate hi-entry in each separate outgoing 523 request for each of the current (outgoing) targets in the target 524 set. The proxy MUST set the hi-targeted-to-uri in those separate 525 hi-entry(s) to the value of the Request-URI of the current 526 (outgoing) request, unless privacy is required. If privacy is 527 required, the procedures of Section 6.3.1 MUST be used. The proxy 528 MUST include a hi-target attribute for each of the separate 529 entry(s) as described in Section 6.3.4. The proxy MUST include an 530 hi-index for each of the separate hi-entry(s) as described in 531 Section 6.3.3. 533 5.1.2. Re-sending based on failure response 535 When re-sending a request as a result of retargeting because of 536 failure (i.e., either reception of error responses or a timeout which 537 is considered to be an implicit 487 error response), the proxy MUST 538 perform the following steps: 540 Step 1: Including the Entries from Error Responses & Timeouts 542 The proxy MUST build the History-Info header field(s) sent in the 543 outgoing request using the aggregate information associated with 544 the received error responses(s) and timeout(s) for all the 545 branches that are generating failures, including the header 546 entries in the order indicated by the indexing (see 547 Section 6.3.3). If the received error response did not include 548 any History-Info header fields, the proxy MUST use the same 549 History-Info header fields that were sent in the outgoing request 550 that failed to build the outgoing request. 552 Step 2: Tagging the Last Entries 554 The proxy then examines the last hi-entry of the History-Info that 555 was just generated in Step 1 for each one of the branches that 556 generated failures or timeouts and MUST add a Reason header for 557 each one of those entries as per the procedures of Section 6.3.2. 559 Step 3: Generating New Entries for Each Outgoing Requests 561 Same as per Step 3 above for the normal forwarding case. 563 5.1.3. Re-sending based on redirection response 565 When re-sending a request as a result of retargeting because of 566 redirection (i.e., receipt of a 3XX response), the following steps 567 apply: 569 Step 1: Including Previous Entries 571 If the received 3XX response does not include any History-Info 572 header fields, the proxy MUST include the History-Info header 573 fields that were sent in the outgoing request that is being 574 redirected. The proxy MUST then perform Steps 2 and 3. 576 If the 3XX response contains a History-Info Header field, but the 577 last entries does not correspond to the current target (i.e., they 578 do not correspond to the Contact(s) in the 3XX), the proxy MUST 579 include in the outgoing request the same History-Info header 580 fields that were received in the 3XX response. The proxy MUST 581 then perform Steps 2 and 3. 583 If the 3XX response contains a History-Info Header field and the 584 last entries correspond to the current target (i.e., they 585 correspond to the Contact(s) in the 3XX), the proxy MUST include 586 in the outgoing request the same History-Info header fields that 587 were received in the 3XX response. No other entries need to be 588 added as this is the complete set: the proxy MUST NOT perform 589 Steps 2 and 3. 591 Step 2: Tagging the Last Entry 593 The proxy then examines the last hi-entry of the History-Info that 594 was just generated in Step 1 and MUST add a Reason header this 595 entry as per the procedures of Section 6.3.2. 597 Step 3: Generating New Entries for Each Outgoing Requests 599 Same as per Step 3 above for the normal forwarding case, except 600 that the hi-target parameter MUST NOT be set when the proxy 601 receiving the 3xx does not know the mechanism by which this target 602 was determined. For example, the proxy can not determine the hi- 603 target mechanism when the domain of the Contact is not under the 604 control of the proxy. However, if it under the control of the 605 proxy, then it may be able to determine the mechanism (e.g., Bob 606 can deflect a call to his SIP PC client to his cell phone). 608 5.2. Sending History-Info in Responses 610 A proxy that receives a Request with the "histinfo" option tag in the 611 Supported header, SHOULD forward captured History-Info in subsequent, 612 provisional, and final responses to the Request sent by the ultimate 613 UAS (see Section 4.2). 615 A proxy MAY anonymize any hi-entry whose domain corresponds to a 616 domain for which it is responsible (as per [RFC3323]). For example, 617 anonymity may be required when responses are forwarded to a domain 618 for which it is not responsible. 620 The processing of History-Info in responses follows the methodology 621 described in Section 16.7 of [RFC3261], with the processing of 622 History-Info headers adding an additional step, just before Step 9, 623 "Forwarding the Response". 625 6. The History-Info header field 627 6.1. Definition 629 History-Info is a header field as defined by [RFC3261]. "It may 630 appear in any initial request for a dialog, standalone request or 631 responses associated with these requests. For example, History-Info 632 may appear in INVITE, REGISTER, MESSAGE, REFER, OPTIONS, SUBSCRIBE, 633 and PUBLISH and any valid responses, plus NOTIFY requests that 634 initiate a dialog. 636 The History-Info header carries the following information, with the 637 mandatory parameters required when the header is included in a 638 request or response: 640 o Targeted-to-URI (hi-targeted-to-uri): A mandatory parameter for 641 capturing the Request-URI for the specific Request as it is 642 forwarded. 644 o Index (hi-index): A mandatory parameter for History-Info 645 reflecting the chronological order of the information, indexed to 646 also reflect the forking and nesting of requests. The format for 647 this parameter is a string of digits, separated by dots to 648 indicate the number of forward hops and retargets. This results 649 in a tree representation of the history of the request, with the 650 lowest-level index reflecting a branch of the tree. By adding the 651 new entries in order (i.e., following existing entries per the 652 details in Section 5.1), including the index and securing the 653 header, the ordering of the History-Info headers in the request is 654 assured (SEC-req-2, see Appendix A.1). In addition, applications 655 may extract a variety of metrics (total number of retargets, total 656 number of retargets from a specific branch, etc.) based upon the 657 index values. 659 o Reason: An optional parameter for History-Info, reflected in the 660 History-Info header by including the Reason Header [RFC3326] 661 escaped in the hi-targeted-to-uri. A reason is included for the 662 hi-targeted-to-uri that was retargeted as opposed to the hi- 663 targeted-to-uri to which it was retargeted. 665 o Privacy: An optional parameter for History-Info, reflected in the 666 History-Info header field values by including the Privacy Header 667 [RFC3323] escaped in the hi- targeted-to-uri or by adding the 668 Privacy header to the Request. The latter case indicates that the 669 History-Info entries for the domain MUST be anonymized prior to 670 forwarding, whereas the use of the Privacy header escaped in the 671 hi-targeted-to-uri means that a specific hi-entry MUST be 672 anonymized. 674 o Target (hi-target): An optional parameter for the History-Info 675 indicating the mechanism by which the new target is determined, 676 based on the procedures of 16.5 [RFC3261]. The hi-target is added 677 for a hi-entry when it is first added in a History-Info header 678 field, and only one value is permitted. Upon receipt of a request 679 or response containing the History-Info header, a UA can determine 680 the nature of the target. The following values are defined for 681 this parameter: 683 * "rc": The entry is a contact that is bound to an AOR in an 684 abstract location service. The AOR-to-contact binding has been 685 placed into the location service by a SIP Registrar that 686 received a SIP REGISTER request. 688 * "mp": The entry is a URI that represents another user. This 689 occurs in cases where a request is statically or dynamically 690 retargeted to another user. The index entry of the target of 691 the original target is added as a parameter to the "mp" (i.e., 692 it represents the "mapped from" target). 694 o Extension (hi-extension): A parameter to allow for future optional 695 extensions. As per [RFC3261], any implementation not 696 understanding an extension should ignore it. 698 The following summarizes the syntax of the History-Info header, based 699 upon the standard SIP syntax [RFC3261]: 701 History-Info = "History-Info" HCOLON hi-entry *(COMMA hi-entry) 703 hi-entry = hi-targeted-to-uri *(SEMI hi-param) 705 hi-targeted-to-uri = name-addr 707 hi-param = hi-index / hi-target / hi-extension 709 hi-index = "index" EQUAL 1*DIGIT *("." 1*DIGIT) 711 hi-target = "rc" / mp-param 713 mp-param = "mp" EQUAL 1*DIGIT *("." 1*DIGIT) 715 hi-extension = generic-param 717 The following rules apply: 719 o There MUST exactly 1 hi-index parameter per hi-entry. 721 o There MUST be no more than 1 hi-target parameter. 723 o They MAY be any number of hi-extension parameters. 725 o The ABNF definitions for "generic-param" and "name-addr" are from 726 [RFC3261]. 728 6.2. Examples 730 The following provides some examples of the History-Info header. 731 Note that the backslash and CRLF between the fields in the examples 732 below are for readability purposes only. 734 History-Info: ;index=1;foo=bar 736 History-Info: ;index=1.1,\ 738 ;index=1.2;mp=1.1,\ 740 ;index=1.3;rc 742 6.3. Procedures 744 The following sections defines procedures for different parameters in 745 the History-Info header. These procedures may be applicable to 746 "processing entities" such as Proxies, Redirect Servers or User 747 Agents. 749 6.3.1. Privacy in the History-Info Header 751 The privacy requirements for this document are described in 752 Appendix A.2. 754 Since the History-Info header can inadvertently reveal information 755 about the requestor as described in [RFC3323], the Privacy header can 756 be used to determine whether an intermediary can include the Request- 757 URI in a Request that it receives (PRIV-req-2, see Appendix A.2) or 758 that it retargets (PRIV-req-1, see Appendix A.2) as an entry in a 759 History-Info header. Thus, the History- Info entry for that identity 760 can be anonymized where the requestor has indicated a priv-value of 761 Session- or Header-level privacy. 763 Privacy is associated with a specific history information entry, and 764 perhaps any entry that corresponds to that same user, and not the 765 History-Info header itself. This allows for anonymizing some 766 entries, but not others, as required. For example, if Alice sends a 767 request to Bob without any privacy, and Bob redirects to Carol with 768 privacy setup for himself, Carol should receive a request where 769 Alice's history information is present, but Bob's has been 770 anonymized. 772 In addition, the History-Info header can reveal general routing 773 information which may be viewed by a specific intermediary or 774 network. Thus, a proxy can use local policy to determine whether the 775 History-Info header entries for it's whole domain are private or not 776 when exiting the domain through retargeting (PRIV-req-3). This is 777 accomplished by adding a new priv-value, history, to the Privacy 778 header [RFC3323] indicating that a specific History-Info header entry 779 can not be forwarded outside the domain. 781 It is recognized that satisfying the privacy requirements can impact 782 the functionality of this solution by overriding the request to 783 generate the information. 785 If there is a Privacy header in the request with a priv-value of 786 "session", "header", or "history", an hi-entry SHOULD be added if the 787 request is being retargeted to a URI associated with a domain for 788 which the processing entity is responsible. If there is no Privacy 789 header, but the processing entity's local policies indicate that the 790 hi-entry(s) cannot be forwarded beyond the domain for which this 791 intermediary is responsible, then a Privacy header with a priv-value 792 of "history" SHOULD be associated with each hi-entry added by the 793 proxy as the request is forwarded within the domain. 795 If a request is being retargeted to a URI associated with a domain 796 for which the processing identity is not responsible and there is a 797 Privacy header in the request with a priv-value of "session", 798 "header", or "history", the processing entity MUST anonymize hi- 799 entry(s) as per [RFC3323] prior to forwarding, unless the processing 800 entity knows a priori that it can rely on a downstream processing 801 entity within its domain to apply the requested privacy or local 802 policy allows the forwarding. 804 6.3.2. Reason in the History-Info Header 806 For retargets that are the result of an explicit SIP response, a 807 Reason MUST be associated with the hi-targeted-to-uri. If the SIP 808 response does not include a Reason header (see [RFC3326]), the SIP 809 Response Code that triggered the retargeting MUST be included as the 810 Reason associated with the hi-targeted-to-uri that has been 811 retargeted. If the response contains a Reason header for a protocol 812 that is not SIP (e.g., Q.850), it MUST be captured as an additional 813 Reason associated with the hi-targeted-to- uri that has been 814 retargeted, along with the SIP Response Code. If the Reason header 815 is a SIP reason, then it MUST be used as the Reason associated with 816 the hi-targeted-to-uri rather than the SIP response code. 818 If a request has timed out (instead of being explicitly rejected), it 819 SHOULD be treated as if a 487 "Request Terminated" error response 820 code was received. 822 6.3.3. Indexing in the History-Info Header 824 In order to maintain ordering and accurately reflect the nesting and 825 retargeting of the request, an index MUST be included along with the 826 Targeted-to-URI being captured. Per the syntax in Section 6, the 827 index consists of a dot-delimited series of digits (e.g., 1.1.2). 828 Each dot reflects a hop or level of nesting; thus, the number of hops 829 is determined by the total number of dots. Within each level, the 830 integer reflects the number of peer entities to which the request has 831 been routed. Thus, the indexing results in a logical tree 832 representation for the history of the Request. For each level of 833 indexing, the index MUST start at 1. An increment of 1 MUST be used 834 for advancing to a new branch. The first entry MUST be set to 1. 836 The basic rules for adding the index are summarized as follows: 838 1. Basic Forwarding: In the case of a Request that is being 839 forwarded, the index is determined by adding another sub-level of 840 indexing since the depth/length of the branch is increasing. To 841 accomplish this, the processing entity reads the value from the 842 History-Info header in the received request, if available, and 843 adds another level of indexing by appending the dot delimiter 844 followed by an initial index for the new level of 1. For 845 example, if the index in the last History-Info header field in 846 the received request is 1.1, this proxy would initialize its 847 index to 1.1.1 and forward the request. 849 2. Retargeting within a processing entity - 1st instance: For the 850 first instance of retargeting within a processing entity, the 851 calculation of the index follows that prescribed for basic 852 forwarding. 854 3. Retargeting within a processing entity - subsequent instance: For 855 each subsequent retargeting of a request by the same processing 856 entity, another branch is added. With the index for each new 857 branch calculated by incrementing the last/lowest digit at the 858 current level, the index in the next request forwarded by this 859 same processing entity, following the example above, would be 860 1.1.2. 862 4. Retargeting based upon a Response: In the case of retargeting due 863 to a specific response (e.g., 302), the index would be calculated 864 per rule 3. That is, the lowest/last digit of the index is 865 incremented (i.e., a new branch is created), with the increment 866 of 1. For example, if the index in the History-Info header of 867 the received request was 1.2, then the index in the History-Info 868 header field for the new hi-targeted- to-URI would be 1.3. 870 5. Forking requests: If the request forwarding is done in multiple 871 forks (sequentially or in parallel), the index MUST be captured 872 for each forked request per the rules above, with each new 873 Request having a unique index. Each index are sequentially 874 assigned. For example, if the index in the last History-Info 875 header field in the received request is 1.1, this processing 876 entity would initialize its index to 1.1.1 for the first fork, 877 1.1.2 for the second, and so forth (see Figure 1 for an example). 879 Note that for each individual fork, only the entry corresponding 880 that that fork is included (e.g., the entry for fork 1.1.1 is not 881 included in the request sent to fork 1.1.2, and vice-versa). 883 6. When a response is built and it represents the aggregate of 884 multiple forks (e.g., multiple forks that fail), the processing 885 entity builds the subsequent response using the aggregated 886 information associated with each of those forks and including the 887 header entries in the order indicated by the indexing. For 888 example, if a procesing entity received failure responses for 889 forks 1.1.1 and 1.1.2, it would forward both the 1.1.1 and 1.1.2 890 entries to 1.1. See Appendix B.1 for an example. Responses are 891 processed as described in Section 16.7 of [RFC3261] with the 892 aggregated History-Info entries processed similar to Step 7 893 "Aggregate Authentication Header Field Values". 895 6.3.4. Request Target in the History-Info Header 897 The value for the hi-target attribute is based upon the mechanism by 898 which the new target has been determined per the procedures described 899 in 16.5/[RFC3261]. The following describes how the specific values 900 for the hi-target attribute are determined: 902 o If the Request-URI is a contact that is bound to an AOR in an 903 abstract location service for the domain for which the processing 904 entity is responsible, and the AOR-to-contact binding has been 905 placed into the location service by a SIP Registrar that received 906 a REGISTER request, the hi-target attribute MUST be added to the 907 hi-entry with a value of "rc." 909 o If the Request-URI is a URI that represents another user than the 910 one indicated by the incoming Request-URI, as this would occur in 911 cases where a request is statically or dynamically retargeted to 912 another user, the hi-target attribute MUST be added to the hi- 913 entry with a value of "mp." The index of the entry corresponding 914 to the original target (i.e., the "mapped-from" target) MUST be 915 added as a parameter to "mp". 917 7. Application Considerations 919 As seen by the example scenarios in the Appendix B, History-Info 920 provides a very flexible building block that can be used by 921 intermediaries and UAs for a variety of services. As such, any 922 services making use of History-Info must be designed with the 923 following considerations: 925 1. History-Info is optional; thus, a service MUST define default 926 behavior for requests and responses not containing History-Info 927 headers. 929 2. History-Info may be impacted by privacy considerations. 930 Applications requiring History-Info need to be aware that if 931 Header-, Session-, or History-level privacy is requested by a UA 932 (or imposed by an intermediary) that History-Info may not be 933 available in a request or response. This would be addressed by 934 an application in the same manner as the previous consideration 935 by ensuring there is reasonable default behavior should the 936 information not be available. 938 3. History-Info may be impacted by local policy. Each application 939 making use of the History-Info header SHOULD address the impacts 940 of the local policies on the specific application (e.g., what 941 specification of local policy is optimally required for a 942 specific application and any potential limitations imposed by 943 local policy decisions). Note that this is related to the 944 optionality and privacy considerations identified in 1 and 2 945 above, but goes beyond that. For example, due to the optionality 946 and privacy considerations, an entity may receive only partial 947 History-Info entries; will this suffice? Note that this would be 948 a limitation for debugging purposes, but might be perfectly 949 satisfactory for some models whereby only the information from a 950 specific intermediary is required. 952 8. Security Considerations 954 The security requirements for this document are specified in 955 Appendix A.1. 957 This document defines a header for SIP. The use of the Transport 958 Layer Security (TLS) protocol [RFC5246] as a mechanism to ensure the 959 overall confidentiality of the History-Info headers (SEC-req-4) is 960 strongly RECOMMENDED. This results in History-Info having at least 961 the same level of security as other headers in SIP that are inserted 962 by intermediaries. With TLS, History-Info headers are no less, nor 963 no more, secure than other SIP headers, which generally have even 964 more impact on the subsequent processing of SIP sessions than the 965 History-Info header. 967 With the level of security provided by TLS (SEC-req-3), the 968 information in the History-Info header can thus be evaluated to 969 determine if information has been removed by evaluating the indices 970 for gaps (SEC-req-1, SEC-req-2). It would be up to the application 971 to define whether it can make use of the information in the case of 972 missing entries. 974 Note that while using the SIPS scheme (as per [RFC5630]) protects 975 History-Info from tampering by arbitrary parties outside the SIP 976 message path, all the intermediaries on the path are trusted 977 implicitly. A malicious intermediary could arbitrarily delete, 978 rewrite, or modify History-Info. This specification does not attempt 979 to prevent or detect attacks by malicious intermediaries. 981 9. IANA Considerations 983 This document requires several IANA registrations detailed in the 984 following sections. 986 This document updates [RFC4244] but uses the same SIP header field 987 name and option tag. The IANA registry needs to update the 988 references to [RFC4244] witht [RFCXXXX]. 990 9.1. Registration of New SIP History-Info Header 992 This document defines a SIP header field name: History-Info and an 993 option tag: histinfo. The following changes have been made to 994 http:///www.iana.org/assignments/sip-parameters The following row has 995 been added to the header field section:. 997 The following row has been added to the header field section: 999 Header Name Compact Form Reference 1000 ----------- ------------ --------- 1001 History-Info none [RFCXXXX] 1003 The following has been added to the Options Tags section: 1005 Name Description Reference 1006 ---- ----------- --------- 1007 histinfo When used with the Supported header, [RFCXXXX] 1008 this option tag indicates the UAC 1009 supports the History Information to be 1010 captured for requests and returned in 1011 subsequent responses. This tag is not 1012 used in a Proxy-Require or Require 1013 header field since support of 1014 History-Info is optional. 1016 Note to RFC Editor: Please replace RFC XXXX with the RFC number of 1017 this specification. 1019 9.2. Registration of "history" for SIP Privacy Header 1021 This document defines a priv-value for the SIP Privacy header: 1022 history The following changes have been made to 1023 http://www.iana.org/assignments/sip-priv-values The following has 1024 been added to the registration for the SIP Privacy header: 1026 Name Description Registrant Reference 1027 ---- ----------- ---------- --------- 1028 history Privacy requested for Mary Barnes [RFCXXXX] 1029 History-Info header(s) mary.barnes@nortel.com 1031 Note to RFC Editor: Please replace RFC XXXX with the RFC number of 1032 this specification. 1034 10. Contributors 1036 Cullen Jennings, Mark Watson, and Jon Peterson contributed to the 1037 development of the initial requirements for [RFC4244]. 1039 Jonathan Rosenberg, Christer Holmberg, Hans Erik van Elburg and Shida 1040 Schubert produced the document that provided much of the content for 1041 this specification. 1043 11. Acknowledgements 1045 The editor would like to acknowledge the constructive feedback 1046 provided by Robert Sparks, Paul Kyzivat, Scott Orton, John Elwell, 1047 Nir Chen, Palash Jain, Brian Stucker, Norma Ng, Anthony Brown, 1048 Jayshree Bharatia, Jonathan Rosenberg, Eric Burger, Martin Dolly, 1049 Roland Jesske, Takuya Sawada, Sebastien Prouvost, and Sebastien 1050 Garcin in the development of [RFC4244]. The editor would like to 1051 acknowledge the significant input from Rohan Mahy on some of the 1052 normative aspects of the ABNF for [RFC4244], particularly around the 1053 need for and format of the index and around the security aspects. 1055 Thanks to Ian Elz for his feedback on privacy. 1057 12. Changes from RFC 4244 1059 This RFC replaces [RFC4244]. 1061 Deployment experience with [RFC4244] over the years has shown a 1062 number of issues, warranting an update: 1064 o In order to make [RFC4244] work in "real life", one needs to make 1065 "assumptions" on how History-Info is used. For example, many 1066 implementations filter out many entries, and only leave specific 1067 entries corresponding, for example, to first and last redirection. 1068 Since vendors uses different rules, it causes significant 1069 interoperability isssues. 1071 o [RFC4244] is overly permissive and evasive about recording 1072 entries, causing interoperability issues. 1074 o The examples in the call flows had errors, and confusing because 1075 they often assume "loose routing." 1077 o [RFC4244] has lots of repetitive and unclear text 1079 o [RFC4244] gratuitly mandates the use of TLS on every hop. No 1080 existing implementation enforces this rule, and instead, the use 1081 of TLS or not is a general SIP issue, not an [RFC4244] issue per 1082 se. 1084 o [RFC4244] does not include clear procedures on how to deliver 1085 current target URI information to the UAS when the Request-URI is 1086 replaced with a contact. 1088 o [RFC4244] does not allow for marking History-Info entries for easy 1089 processing by User Agents. 1091 This specification is backwards compatible with [RFC4244]. The 1092 following summarizes the functional changes: 1094 1. Added a tag to indicate the mechanism by which the target for an 1095 outgoing request is determined. 1097 2. Rather than recommending that entries be removed in the case of 1098 certain values of the privacy header, recommend that the entries 1099 are anonymized. 1101 3. Updated processing/handling for 3xx responses to ensure accuracy 1102 of the new tags - i.e., the redirecting entity must add the new 1103 entry since the proxy does not have access to the information as 1104 to how the Contact was determined. 1106 4. Updated the security section to be equivalent to the security 1107 recommendations for other SIP headers inserted by intermediaries. 1109 The first 2 changes are intended to facilitate application usage of 1110 the History-Info header and eliminate the need to make assumptions 1111 based upon the order of the entries and ensure that the most complete 1112 set of information is available to the applications. 1114 In addition, editorial changes were done to both condense and clarify 1115 the text and examples were simplified and updated to reflect the 1116 protocol changes. 1118 12.1. Backwards compatibility 1120 Proxies conforming to this specification tag the hi-entry parameters 1121 with an hi-target parameter. The hi-target parameter did not exist 1122 in [RFC4244]; therefore, [RFC4244] implementations do not tag the hi- 1123 entry parameters. This tagging allows for distinguishing entries 1124 that were added by an [RFC4244] entity, versus one that was added by 1125 an entity conforming to this specification. 1127 13. Changes since last Version 1129 NOTE TO THE RFC-Editor: Please remove this section prior to 1130 publication as an RFC. 1132 Changes from barnes-sipcore-4244bis-02 to 03: 1134 1. Fixed problem with indices in example in Appendix B.2. 1136 2. Removed oc and rt from the Hi-target parameter. 1138 3. Removed aor tag 1140 4. Added index parameter to "mp" 1142 5. Added use-cases and call-flows from target-uri into appendix. 1144 Changes from barnes-sipcore-4244bis-01 to 02: 1146 1. Added hi-aor parameter that gets marked on the "incoming" hi- 1147 entry. 1149 2. Hi-target parameter defined to be either rc, oc, mp, rt, and now 1150 gets included when adding an entry. 1152 3. Added section on backwards compatibility, as well as added the 1153 recognition and handling of requests that do not support this 1154 specification in the appropriate sections. 1156 4. Updated redirect server/3xx handling to support the new 1157 parameters - i.e., the redirecting entity must add the new entry 1158 since the proxy does not have access to the information as to how 1159 the Contact was determined. 1161 5. Added section on normative differences between this document and 1162 RFC 4244. 1164 6. Restructuring of document to be more in line with current IETF 1165 practices. 1167 7. Moved Requirements section into an Appendix. 1169 8. Fixed ABNF to remove unintended ordering requirement on hi-index 1170 that was introduced in attempting to illustrate it was a 1171 mandatory parameter. 1173 Changes from barnes-sipcore-4244bis-00 to 01 : 1175 1. Clarified "retarget" definition. 1177 2. Removed privacy discussion from optionality section - just refer 1178 to privacy section. 1180 3. Removed extraneous text from target-parameter (leftover from sip- 1181 4244bis). Changed the terminology from the "reason" to the 1182 "mechanism" to avoid ambiguity with parameter. 1184 4. Various changes to clarify some of the text around privacy. 1186 5. Reverted proxy response handling text to previous form - just 1187 changing the privacy aspects to anonymize, rather than remove. 1189 6. Other editorial changes to condense and simplify. 1191 7. Moved Privacy examples to Appendix. 1193 8. Added forking to Basic call example. 1195 Changes from barnes-sip-4244bis-00 to barnes-sipcore-4244bis-00: 1197 1. Added tags for each type of retargeting including proxy hops, 1198 etc. - i.e., a tag is defined for each specific mechanism by 1199 which the new Request-URI is determined. Note, this is 1200 extremely helpful in terms of backwards compatibility. 1202 2. Fixed all the examples. Made sure loose routing was used in all 1203 of them. 1205 3. Removed example where a proxy using strict routing is using 1206 History-Info for avoiding trying same route twice. 1208 4. Remove redundant Redirect Server example. 1210 5. Index are now mandated to start at "1" instead of recommended. 1212 6. Clarified 3xx behavior as the entity sending the 3XX response 1213 MUST add the hi-target attribute to the previous hi-entry to 1214 ensure that it is appropriately tagged (i.e., it's the only one 1215 that knows how the contact in the 3xx was determined.) 1217 7. Removed lots of ambiguity by making many "MAYs" into "SHOULDs" 1218 and "some "SHOULDs" into "MUSTs". 1220 8. Privacy is now recommended to be done by anonymizing entries as 1221 per RFC 3323 instead of by removing or omitting hi-entry(s). 1223 9. Requirement for TLS is now same level as per RFC 3261. 1225 10. Clarified behavior for "Privacy" (i.e., that Privacy is for Hi- 1226 entries, not headers). 1228 11. Removed "OPTIONALITY" as specific requirements, since it's 1229 rather superflous. 1231 12. Other editorial changes to remove redundant text/sections. 1233 Changes from RFC4244 to barnes-sip-4244bis-00: 1235 1. Clarified that HI captures both retargeting as well as cases of 1236 just forwarding a request. 1238 2. Added descriptions of the usage of the terms "retarget", 1239 "forward" and "redirect" to the terminology section. 1241 3. Added additional examples for the functionality provided by HI 1242 for core SIP. 1244 4. Added hi-target parameter values to HI header to ABNF and 1245 protocol description, as well as defining proxy, UAC and UAS 1246 behavior for the parameter. 1248 5. Simplified example call flow in section 4.5. Moved previous call 1249 flow to appendix. 1251 6. Fixed ABNF per RFC4244 errata "dot" -> "." and added new 1252 parameter. 1254 14. References 1256 14.1. Normative References 1258 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1259 A., Peterson, J., Sparks, R., Handley, M., and E. 1260 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1261 June 2002. 1263 [RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason 1264 Header Field for the Session Initiation Protocol (SIP)", 1265 RFC 3326, December 2002. 1267 [RFC3323] Peterson, J., "A Privacy Mechanism for the Session 1268 Initiation Protocol (SIP)", RFC 3323, November 2002. 1270 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1271 Requirement Levels", BCP 14, RFC 2119, March 1997. 1273 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1274 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1276 [RFC4244] Barnes, M., "An Extension to the Session Initiation 1277 Protocol (SIP) for Request History Information", RFC 4244, 1278 November 2005. 1280 14.2. Informative References 1282 [RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User 1283 Agent URIs (GRUUs) in the Session Initiation Protocol 1284 (SIP)", RFC 5627, October 2009. 1286 [RFC5630] Audet, F., "The Use of the SIPS URI Scheme in the Session 1287 Initiation Protocol (SIP)", RFC 5630, October 2009. 1289 [RFC3087] Campbell, B. and R. Sparks, "Control of Service Context 1290 using SIP Request-URI", RFC 3087, April 2001. 1292 [RFC4240] Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network 1293 Media Services with SIP", RFC 4240, December 2005. 1295 [RFC5039] Rosenberg, J. and C. Jennings, "The Session Initiation 1296 Protocol (SIP) and Spam", RFC 5039, January 2008. 1298 [RFC4458] Jennings, C., Audet, F., and J. Elwell, "Session 1299 Initiation Protocol (SIP) URIs for Applications such as 1300 Voicemail and Interactive Voice Response (IVR)", RFC 4458, 1301 April 2006. 1303 [RFC3761] Faltstrom, P. and M. Mealling, "The E.164 to Uniform 1304 Resource Identifiers (URI) Dynamic Delegation Discovery 1305 System (DDDS) Application (ENUM)", RFC 3761, April 2004. 1307 [RFC4769] Livingood, J. and R. Shockey, "IANA Registration for an 1308 Enumservice Containing Public Switched Telephone Network 1309 (PSTN) Signaling Information", RFC 4769, November 2006. 1311 [I-D.ietf-enum-cnam] 1312 Shockey, R., "IANA Registration for an Enumservice Calling 1313 Name Delivery (CNAM) Information and IANA Registration 1314 for URI type 'pstndata'", draft-ietf-enum-cnam-08 (work in 1315 progress), September 2008. 1317 Appendix A. Request History Requirements 1319 The following list constitutes a set of requirements for a "Request 1320 History" capability. 1322 1. CAPABILITY-req: The "Request History" capability provides a 1323 capability to inform proxies and UAs involved in processing a 1324 request about the history/progress of that request. Although 1325 this is inherently provided when the retarget is in response to a 1326 SIP redirect, it is deemed useful for non-redirect retargeting 1327 scenarios, as well. 1329 2. GENERATION-req: "Request History" information is generated when 1330 the request is retargeted. 1332 A. In some scenarios, it might be possible for more than one 1333 instance of retargeting to occur within the same Proxy. A 1334 proxy should also generate Request History information for 1335 the 'internal retargeting'. 1337 B. An entity (UA or proxy) retargeting in response to a redirect 1338 or REFER should include any Request History information from 1339 the redirect/REFER in the new request. 1341 3. ISSUER-req: "Request History" information can be generated by a 1342 UA or proxy. It can be passed in both requests and responses. 1344 4. CONTENT-req: The "Request History" information for each 1345 occurrence of retargeting shall include the following: 1347 A. The new URI or address to which the request is in the process 1348 of being retargeted, 1350 B. The URI or address from which the request was retargeted, and 1351 wether the retarget URI was an AOR 1353 C. The mechanism by which the new URI or address was determined, 1355 D. The reason for the Request-URI or address modification, 1357 E. Chronological ordering of the Request History information. 1359 5. REQUEST-VALIDITY-req: Request History is applicable to requests 1360 not sent within an established dialog (e.g., INVITE, REGISTER, 1361 MESSAGE, and OPTIONS). 1363 6. BACKWARDS-req: Request History information may be passed from the 1364 generating entity backwards towards the UAC. This is needed to 1365 enable services that inform the calling party about the dialog 1366 establishment attempts. 1368 7. FORWARDS-req: Request History information may also be included by 1369 the generating entity in the request, if it is forwarded onwards. 1371 A.1. Security Requirements 1373 The Request History information is being inserted by a network 1374 element retargeting a Request, resulting in a slightly different 1375 problem than the basic SIP header problem, thus requiring specific 1376 consideration. It is recognized that these security requirements can 1377 be generalized to a basic requirement of being able to secure 1378 information that is inserted by proxies. 1380 The potential security problems include the following: 1382 1. A rogue application could insert a bogus Request History entry 1383 either by adding an additional entry as a result of retargeting 1384 or entering invalid information. 1386 2. A rogue application could re-arrange the Request History 1387 information to change the nature of the end application or to 1388 mislead the receiver of the information. 1390 3. A rogue application could delete some or all of the Request 1391 History information. 1393 Thus, a security solution for "Request History" must meet the 1394 following requirements: 1396 1. SEC-req-1: The entity receiving the Request History must be able 1397 to determine whether any of the previously added Request History 1398 content has been altered. 1400 2. SEC-req-2: The ordering of the Request History information must 1401 be preserved at each instance of retargeting. 1403 3. SEC-req-3: The entity receiving the information conveyed by the 1404 Request History must be able to authenticate the entity providing 1405 the request. 1407 4. SEC-req-4: To ensure the confidentiality of the Request History 1408 information, only entities that process the request should have 1409 visibility to the information. 1411 It should be noted that these security requirements apply to any 1412 entity making use of the Request History information. 1414 A.2. Privacy Requirements 1416 Since the Request-URI that is captured could inadvertently reveal 1417 information about the originator, there are general privacy 1418 requirements that MUST be met: 1420 1. PRIV-req-1: The entity retargeting the Request must ensure that 1421 it maintains the network-provided privacy (as described in 1422 [RFC3323]) associated with the Request as it is retargeted. 1424 2. PRIV-req-2: The entity receiving the Request History must 1425 maintain the privacy associated with the information. In 1426 addition, local policy at a proxy may identify privacy 1427 requirements associated with the Request-URI being captured in 1428 the Request History information. 1430 3. PRIV-req-3: Request History information subject to privacy shall 1431 not be included in ougoing messages unless it is protected as 1432 described in [RFC3323]. 1434 Appendix B. Detailed call flows 1436 The scenarios in this section provide sample use cases for the 1437 History-Info header for informational purposes only. They are not 1438 intended to be normative. 1440 B.1. Sequentially Forking (History-Info in Response) 1442 This scenario highlights an example where the History-Info in the 1443 response is useful to an application or user that originated the 1444 request. 1446 Alice sends a call to Bob via sip:example.com. The proxy sip: 1447 example.com sequentially tries Bob on a SIP UA that has bound a 1448 contact with the sip:bob@example.com AOR, and then several alternate 1449 addresses (Office and Home) unsuccessfully before sending a response 1450 to Alice. In this example, note that Office and Home are not the 1451 same AOR as sip:bob@example.com, but rather different AORs that have 1452 been configured as alternate addresses for Bob in the proxy. In 1453 other words, Office and Bob are not bound through SIP Registration 1454 with Bob's AOR. This type of arrangement is common for example when 1455 a "routing" rule to a PSTN number is manually configured in a Proxy. 1457 This scenario is provided to show that by providing the History-Info 1458 to Alice, the end-user or an application at Alice could make a 1459 decision on how best to attempt finding Bob. Without this mechanism, 1460 Alice might well attempt Office (and thus Home) and then re-attempt 1461 Home on a third manual attempt at reaching Bob. With this mechanism, 1462 either the end-user or application could know that Bob is not 1463 answering in the Office, and his busy on his home phone. If there 1464 were an alternative address for Bob known to this end-user or 1465 application, that hasn't been attempted, then either the application 1466 or the end- user could attempt that. The intent here is to highlight 1467 an example of the flexibility of this mechanism that enables 1468 applications well beyond SIP as it is certainly well beyond the scope 1469 of this document to prescribe detailed applications. 1471 Alice example.com Bob Office Home 1472 | | | | | 1473 | INVITE F1 | | | | 1474 |----------->| INVITE F2 | | | 1475 | |----------------->| | | 1476 | 100 Trying F3 | | | 1477 |<-----------| 302 Move Temporarily F4 | | 1478 | |<-----------------| | | 1479 | | ACK F5 | | | 1480 | |----------------->| | | 1481 | | INVITE F6 | | 1482 | |-------------------------->| | 1483 | | 180 Ringing F7 | | 1484 | |<--------------------------| | 1485 | 180 Ringing F8 | | 1486 |<-----------| retransmit INVITE | | 1487 | |-------------------------->| | 1488 | | ( timeout ) | | 1489 | | INVITE F9 | 1490 | |----------------------------------->| 1491 | | 100 Trying F10 | 1492 | |<-----------------------------------| 1493 | | 486 Busy Here F11 | 1494 | |<-----------------------------------| 1495 | 486 Busy Here F12 | 1496 |<-----------| ACK F13 | 1497 | |----------------------------------->| 1498 | ACK F14 | | 1499 |----------->| | 1501 Message Details 1503 F1 INVITE alice -> example.com 1505 INVITE sip:alice@example.com SIP/2.0 1506 Via: SIP/2.0/TCP 192.0.2.3:5060 1507 From: Alice 1508 To: Bob 1509 Supported: histinfo 1510 Call-Id: 12345600@example.com 1511 CSeq: 1 INVITE 1512 Contact: Alice 1513 Content-Type: application/sdp 1514 Content-Length: 1515 1516 F2 INVITE example.com -> Bob 1518 INVITE sip:bob@192.0.2.4 SIP/2.0 1519 Via: SIP/2.0/TCP proxy.example.com:5060 1520 Via: SIP/2.0/TCP 192.0.2.3:5060 1521 From: Alice 1522 To: Bob 1523 Supported: histinfo 1524 Call-Id: 12345600@example.com 1525 CSeq: 1 INVITE 1526 Record-Route: 1527 History-Info: ;index=1 1528 History-Info: ;index=1.1;rc 1529 Contact: Alice 1530 Content-Type: application/sdp 1531 Content-Length: 1532 1534 F3 100 Trying example.com -> alice 1536 SIP/2.0 100 Trying 1537 Via: SIP/2.0/TCP 192.0.2.3:5060 1538 From: Alice 1539 To: Bob 1540 Call-Id: 12345600@example.com 1541 CSeq: 1 INVITE 1542 Content-Length: 0 1544 F4 302 Moved Temporarily Bob -> example.com 1546 SIP/2.0 302 Moved Temporarily 1547 Via: SIP/2.0/TCP proxy.example.com:5060 1548 Via: SIP/2.0/TCP 192.0.2.3:5060 1549 From: Alice 1550 To: Bob ;tag=3 1551 Call-Id: 12345600@example.com 1552 CSeq: 1 INVITE 1553 Record-Route: 1554 History-Info: ;index=1 1555 History-Info: ;\ 1556 index=1.1;rc 1557 History-Info: ;index=1.2 1558 Contact: 1559 Content-Length: 0 1560 F5 ACK 192.0.2.4 -> Bob 1562 ACK sip:home@example.com SIP/2.0 1563 Via: SIP/2.0/TCP proxy.example.com:5060 1564 From: Alice 1565 To: Bob 1566 Call-Id: 12345600@example.com 1567 CSeq: 1 ACK 1568 Content-Length: 0 1570 F6 INVITE example.com -> office 1572 INVITE sip:office@192.0.2.3.com SIP/2.0 1573 Via: SIP/2.0/TCP proxy.example.com:5060;branch=2 1574 Via: SIP/2.0/TCP 192.0.2.3:5060 1575 From: Alice 1576 To: Bob 1577 Supported: histinfo 1578 Call-Id: 12345600@example.com 1579 Record-Route: 1580 History-Info: ;index=1 1581 History-Info: ;\ 1582 index=1.1;rc 1583 History-Info: ;index=1.2;mp=1 1584 History-Info: ;index=1.2.1 1585 CSeq: 1 INVITE 1586 Contact: Alice 1587 Content-Type: application/sdp 1588 Content-Length: 1589 1590 F7 180 Ringing office -> example.com 1592 SIP/2.0 180 Ringing 1593 Via: SIP/2.0/TCP proxy.example.com:5060;branch=2 1594 Via: SIP/2.0/TCP 192.0.2.3:5060 1595 From: Alice 1596 To: Bob ;tag=5 1597 Supported: histinfo 1598 Call-ID: 12345600@example.com 1599 Record-Route: 1600 History-Info: ;index=1 1601 History-Info: ;\ 1602 index=1.1;rc 1603 History-Info: ;index=1.2;mp=1 1604 History-Info: ;index=1.2.1 1605 CSeq: 1 INVITE 1606 Content-Length: 0 1608 F8 180 Ringing example.com -> alice 1610 SIP/2.0 180 Ringing 1611 Via: SIP/2.0/TCP example.com:5060 1612 From: Alice 1613 To: Bob 1614 Supported: histinfo 1615 Call-Id: 12345600@example.com 1616 History-Info: ;index=1 1617 History-Info: ;\ 1618 index=1.1;rc 1619 History-Info: ;index=1.2;mp=1 1620 History-Info: ;index=1.2.1 1621 CSeq: 1 INVITE 1622 Content-Length: 0 1623 F9 INVITE example.com -> home 1625 INVITE sip:home@192.0.2.6 SIP/2.0 1626 Via: SIP/2.0/TCP proxy.example.com:5060;branch=3 1627 Via: SIP/2.0/TCP 192.0.2.3:5060 1628 From: Alice 1629 To: Bob 1630 Supported: histinfo 1631 Call-Id: 12345600@example.com 1632 Record-Route: 1633 History-Info: ;index=1 1634 History-Info: ;\ 1635 index=1.1;rc 1636 History-Info: ;index=1.2;mp=1 1637 History-Info: ;\ 1638 index=1.2.1>;index=1.2.1 1639 History-Info: ;index=1.3;mp=1.2 1640 History-Info: ;index=1.3.1 1641 CSeq: 1 INVITE 1642 Contact: Alice 1643 Content-Type: application/sdp 1644 Content-Length: 1645 1647 F10 100 Trying home -> example.com 1649 SIP/2.0 100 Trying 1650 Via: SIP/2.0/TCP proxy.example.com:5060;branch=3 1651 Via: SIP/2.0/TCP 192.0.2.3:5060 1652 From: Alice 1653 To: Bob 1654 Call-Id: 12345600@example.com 1655 CSeq: 1 INVITE 1656 Content-Length: 0 1657 F11 486 Busy Here home -> example.com 1659 SIP/2.0 486 Busy Here 1660 Via: SIP/2.0/TCP proxy.example.com:5060;branch=3 1661 Via: SIP/2.0/TCP 192.0.2.3:5060 1662 From: Alice 1663 To: Bob 1664 Call-Id: 12345600@example.com 1665 Record-Route: 1666 History-Info: ;index=1 1667 History-Info: ;\ 1668 index=1.1;rc 1669 History-Info: ;index=1.2;mp=1 1670 History-Info: ;\ 1671 index=1.2.1>;index=1.2.1 1672 History-Info: ;index=1.3;mp=1.2 1673 History-Info: ;index=1.3.1 1674 CSeq: 1 INVITE 1675 Content-Length: 0 1677 F12 486 Busy Here example.com -> alice 1679 SIP/2.0 486 Busy Here 1680 Via: SIP/2.0/TCP 192.0.2.3:5060 1681 From: Alice 1682 To: Bob 1683 Call-Id: 12345600@example.com 1684 History-Info: ;index=1 1685 History-Info: ;\ 1686 index=1.1;rc 1687 History-Info: ;index=1.2;mp=1 1688 History-Info: ;\ 1689 index=1.2.1>;index=1.2.1 1690 History-Info: ;index=1.3;mp=1.2 1691 History-Info: ;index=1.3.1 1692 CSeq: 1 INVITE 1693 Content-Length: 0 1694 F13 ACK example.com -> home 1696 ACK sip:home@example.com SIP/2.0 1697 Via: SIP/2.0/TCP proxy.example.com:5060 1698 From: Alice 1699 To: Bob 1700 Call-Id: 12345600@example.com 1701 CSeq: 1 ACK 1702 Content-Length: 0 1704 F14 ACK alice -> example.com 1706 ACK sip:bob@example.com SIP/2.0 1707 Via: SIP/2.0/TCP 192.0.2.3:5060 1708 From: Alice 1709 To: Bob 1710 Call-Id: 12345600@example.com 1711 Route: 1712 CSeq: 1 ACK 1713 Content-Length: 0 1715 B.2. Voicemail 1717 This scenario highlights an example where the History-Info in the 1718 request is primarily of use by an edge service (e.g., voicemail 1719 server). It should be noted that this is not intended to be a 1720 complete specification for this specific edge service as it is quite 1721 likely that additional information is needed by the edge service. 1722 History-Info is just one building block that this service can use. 1724 Alice called Bob, which had been forwarded to Carol, which forwarded 1725 to VM (voicemail server). Based upon the retargeted URIs and Reasons 1726 (and other information) in the INVITE, the VM server makes a policy 1727 decision about what mailbox to use, which greeting to play, etc. 1729 Alice example.com Bob Carol VM 1731 | INVITE sip:bob@example.com | | | 1732 |------------->| | | | 1733 | | INVITE sip:bob@192.0.2.3 | | 1734 | |------------->| | | 1735 History-Info: ;index=1 1736 History-Info: ;index=1.1;rc 1737 | | | | | 1738 | 100 Trying | | | | 1739 |<-------------| 302 Moved Temporarily | | 1740 | |<-------------| | | 1741 History-Info: ;index=1 1742 History-Info: ;\ 1743 index=1.1;rc 1744 History-Info: ;index=1.2 1745 | | | | | 1746 | | INVITE sip:Carol@192.0.2.4 | | 1747 | |--------------------------->| | 1748 History-Info: ;index=1 1749 History-Info: ;\ 1750 index=1.1;rc 1751 History-Info: ;index=1.2;mp=1 1752 History-Info: ;index=1.2.1;rc 1753 | | | | | 1754 | | 180 Ringing | | 1755 | |<---------------------------| | 1756 History-Info: ;index=1 1757 History-Info: ;\ 1758 index=1.1;rc 1759 History-Info: ;index=1.2;mp=1 1760 History-Info: ;index=1.2.1;rc 1761 | | | | | 1762 | 180 Ringing | | | | 1763 |<-------------| | | | 1764 | | | | | 1765 | . . . | | | | 1766 | | (timeout) | | 1767 | | | | | 1768 | | INVITE sip:vm@192.0.2.5 | 1769 | |-------------------------------------->| 1770 History-Info: ;index=1 1771 History-Info: ;\ 1772 index=1.1;rc 1773 History-Info: ;index=1.2;mp=1 1774 History-Info: ;index=1.2.1;rc 1775 History-Info: ;index=1.3;mp=1.2 1776 History-Info: ;index=1.3.1 1777 | | | | | 1778 | | 200 OK | 1779 | |<--------------------------------------| 1780 History-Info: ;index=1 1781 History-Info: ;\ 1782 index=1.1;rc 1783 History-Info: ;index=1.2;mp=1 1784 History-Info: ;index=1.2.1;rc 1785 History-Info: ;index=1.3;mp=1.2 1786 History-Info: ;index=1.3.1 1788 | 200 OK | | | | 1789 |<-------------| | | | 1790 | | | | | 1791 | ACK | | | | 1792 |------------->| ACK | 1793 | |-------------------------------------->| 1795 B.3. Automatic Call Distribution 1797 This scenario highlights an example of an Automatic Call Distribution 1798 service, where the agents are divided into groups based upon the type 1799 of customers they handle. In this example, the Gold customers are 1800 given higher priority than Silver customers, so a Gold call would get 1801 serviced even if all the agents servicing the Gold group were busy, 1802 by retargeting the request to the Silver Group for delivery to an 1803 agent. Upon receipt of the call at the agent assigned to handle the 1804 incoming call, based upon the History-Info header in the message, the 1805 application at the agent can provide an indication that this is a 1806 Gold call, from how many groups it might have overflowed before 1807 reaching the agent, etc. and thus can be handled appropriately by the 1808 agent. 1810 For scenarios whereby calls might overflow from the Silver to the 1811 Gold, clearly the alternate group identification, internal routing, 1812 or actual agent that handles the call should not be sent to UA1. 1813 Thus, for this scenario, one would expect that the Proxy would not 1814 support the sending of the History-Info in the response, even if 1815 requested by Alice. 1817 As with the other examples, this is not prescriptive of how one would 1818 do this type of service but an example of a subset of processing that 1819 might be associated with such a service. In addition, this example 1820 is not addressing any aspects of Agent availability, which might also 1821 be done via a SIP interface. 1823 Alice example.com Gold Silver Agent 1825 | | | | | 1826 | INVITE sip:Gold@example.com | | | 1827 |------------->| | | | 1828 | Supported: histinfo 1829 | | | | | 1830 | | INVITE sip:Gold@example.com | 1831 | |------------->| | | 1832 History-Info: ;index=1 1833 History-Info: ;index=1.1 1834 | | | | | 1835 | | 302 Moved Temporarily | | 1836 | |<-------------| | | 1837 History-Info: ;index=1 1838 History-Info: ;\ 1839 index=1.1 1840 Contact: 1841 | | | | 1842 | | INVITE sip:Silver@example.com | 1843 | |--------------------------->| | 1844 History-Info: ;index=1 1845 History-Info: ;\ 1846 index=1.1 1847 History-Info: ;index=2;mp=1 1848 History-Info: ;index=2.1 1849 | | | | | 1850 | | | INVITE sip:Silver@192.0.2.7 1851 | | | |----------->| 1852 History-Info: ;index=1 1853 History-Info: ;\ 1854 index=1.1 1855 History-Info: ;index=2;mp=1 1856 History-Info: ;index=2.1 1857 History-Info: ;index=2.1.1;rc 1858 | | | | | 1859 | | | | 200 OK | 1860 | | | |<-----------| 1861 History-Info: ;index=1 1862 History-Info: ;\ 1863 index=1.1 1864 History-Info: ;index=2;mp=1 1865 History-Info: ;index=2.1 1866 History-Info: ;index=2.1.1;rc 1867 | | | | | 1868 | | 200 OK | | 1869 | |<---------------------------| | 1870 History-Info: ;index=1 1871 History-Info: ;\ 1872 index=1.1 1873 History-Info: ;index=2;mp=1 1874 History-Info: ;index=2.1 1875 History-Info: ;index=2.1.1;rc 1876 | | | | | 1877 200 OK | | | | 1878 |<-------------| | | | 1879 | | | | | 1880 | ACK | | | | 1881 |------------->| ACK | 1882 | |---------------------------------------->| 1884 B.4. History-Info with Privacy Header 1886 This example provides a basic call scenario such as the one in 1887 Figure 1 but without forking, with sip:biloxi.example.com adding the 1888 Privacy header indicating that the History-Info header information is 1889 anonymized outside the biloxi.example.com domain. This scenario 1890 highlights the potential functionality lost with the use of "history" 1891 privacy in the Privacy header for the entire request and the need for 1892 careful consideration on the use of privacy for History-Info. 1894 Alice atlanta.example.com biloxi.example.com Bob 1895 | | | | 1896 | INVITE sip:bob@biloxi.example.com;p=x | 1897 |--------------->| | | 1898 | Supported: histinfo | | 1899 | | | | 1900 | | INVITE sip:bob@biloxi.example.com;p=x 1901 | |--------------->| | 1902 | History-Info: ;index=1 1903 | History-Info: ;index=1.1 1904 | | | | 1905 | | | INVITE sip:bob@192.0.2.3 1906 | | |--------------->| 1907 | History-Info: ;index=1 1908 | History-Info: ;index=1.1 1909 | History-Info: ;index=1.1.1;rc 1910 | | | | 1911 | | | 200 | 1912 | | |<---------------| 1913 | History-Info: ;index=1 1914 | History-Info: ;index=1.1 1915 | History-Info: ;index=1.1.1;rc 1916 | | | | 1917 | | 200 | | 1918 | |<---------------| | 1919 | History-Info: ;index=1 1920 | History-Info: ;index=1.1 1921 | History-Info: ;index=1.1.1;rc 1922 | | | | 1923 | 200 | | | 1924 |<---------------| | | 1925 | History-Info: ;index=1 1926 | History-Info: ;index=1.1 1927 | History-Info: ;index=1.1.1;rc 1928 | | | | 1929 | ACK | | | 1930 |--------------->| ACK | | 1931 | |--------------->| ACK | 1932 | | |--------------->| 1934 Figure 2: Example with Privacy Header 1936 B.5. Privacy Header for a Specific History-Info Entry 1938 This example also provides a basic call scenario such as the one in 1939 Figure 1 but without forking, however, due to local policy at sip: 1940 biloxi.example.com, only the final hi-entry in the History-Info, 1941 which is Bob's local URI, contains a priv-value of "history", thus 1942 providing Alice with some information about the history of the 1943 request, but anonymizing Bob's local URI. 1945 Alice atlanta.example.com biloxi.example.com Bob 1946 | | | | 1947 | INVITE sip:bob@biloxi.example.com;p=x | 1948 |--------------->| | | 1949 | Supported: histinfo | | 1950 | | | | 1951 | | INVITE sip:bob@biloxi.example.com;p=x 1952 | |--------------->| | 1953 | History-Info: ;index=1 1954 | History-Info: ;index=1.1 1955 | | | | 1956 | | | INVITE sip:bob@192.0.2.3 1957 | | |--------------->| 1958 | History-Info: ;index=1 1959 | History-Info: ;index=1.1 1960 | History-Info: ;index=1.1.1;rc 1961 | | | | 1962 | | | 200 | 1963 | | |<---------------| 1964 | History-Info: ;index=1 1965 | History-Info: ;index=1.1 1966 | History-Info: ;index=1.1.1;rc 1967 | | | | 1968 | | 200 | | 1969 | |<---------------| | 1970 | History-Info: ;index=1 1971 | History-Info: ;index=1.1 1972 | History-Info: ;index=1.1.1;rc 1973 | | | | 1974 | 200 | | | 1975 |<---------------| | | 1976 | History-Info: ;index=1 1977 | History-Info: ;index=1.1 1978 | History-Info: ;index=1.1.1;rc 1979 | | | | 1980 | ACK | | | 1981 |--------------->| ACK | | 1982 | |--------------->| ACK | 1983 | | |--------------->| 1985 Figure 3: Example with Privacy Header for Specific URI 1987 B.6. Determining the Alias used. 1989 SIP user agents are associated with an address-of-record (AOR). It 1990 is possible for a single UA to actually have multiple AOR associated 1991 with it. One common usage for this is aliases. For example, a user 1992 might have an AOR of sip:john@example.com but also have the AORs 1993 sip:john.smith@example.com and sip:jsmith@example.com. Rather than 1994 registering against each of these AORs individually, the user would 1995 register against just one of them, and the home proxy would 1996 automatically accept incoming calls for any of the aliases, treating 1997 them identically and ultimately forwarding them towards the UA. This 1998 is common practice in the Internet Multimedia Subsystem (IMS), where 1999 it is called implicit registrations and each alias is called a public 2000 identity. 2002 It is a common requirement for a UAS, on receipt of a call, to know 2003 which of its aliases was used to reach it. This knowledge can be 2004 used to choose ringtones to play, determine call treatment, and so 2005 on. For example, a user might give out one alias to friends and 2006 family only, resulting in a special ring that alerts the user to the 2007 importance of the call. 2009 Following call-flow and example messages show how History-Info can be 2010 used to find out the alias used to reach the callee. 2012 UAS can see which alias was used in the call by looking at the hi- 2013 entry prior to the last hi-entry with the "rc" tag. 2015 Alice Example.com John 2016 | | REGISTER F1 | 2017 | |<--------------------| 2018 | | 200 OK F2 | 2019 | |-------------------->| 2020 | INVITE F3 | | 2021 |-------------------->| | 2022 | | INVITE F4 | 2023 | |-------------------->| 2024 * Rest of flow not shown * 2026 F1 REGISTER John -> Example.com 2028 REGISTER sip:example.com SIP/2.0 2029 Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bKnashds7 2030 Max-Forwards: 70 2031 From: John ;tag=a73kszlfl 2032 To: John 2033 Call-ID: 1j9FpLxk3uxtm8tn@192.0.2.1 2034 CSeq: 1 REGISTER 2035 Contact: 2036 Content-Length: 0 2038 F2 200 OK Example.com -> John 2040 SIP/2.0 200 OK 2041 Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bKnashds7 2042 From: John ;tag=a73kszlfl 2043 To: John 2044 Call-ID: 1j9FpLxk3uxtm8tn@192.0.2.1 2045 CSeq: 1 REGISTER 2046 Contact: ;expires=3600 2047 Content-Length: 0 2049 F3 INVITE Alice -> Example.com 2051 INVITE sip:john.smith@example.com SIP/2.0 2052 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=232sxxeserg 2053 From: Alice 2054 To: John 2055 Supported: histinfo 2056 Call-Id: 12345600@example.com 2057 CSeq: 1 INVITE 2058 History-Info: ;index=1; 2059 Contact: Alice 2060 Content-Type: application/sdp 2061 Content-Length: 2063 [SDP Not Shown] 2065 F4 INVITE Example.com -> Bob 2067 INVITE sip:john@192.0.2.1 SIP/2.0 2068 Via: SIP/2.0/TCP proxy.example.com:5060;branch=as2334se 2069 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=232sxxeserg 2070 From: Alice 2071 To: John 2072 Supported: histinfo 2073 Call-Id: 12345600@example.com 2074 CSeq: 1 INVITE 2075 Record-Route: 2076 History-Info: ;index=1; 2077 History-Info: ;index=1.1;rc 2078 Contact: Alice 2079 Content-Type: application/sdp 2080 Content-Length: 2082 [SDP Not Shown] 2084 Figure 4: Alias Example 2086 B.7. GRUU 2088 A variation on the problem in Appendix B.6 occurs with Globally 2089 Routable User Agent URI (GRUU) [RFC5627]. A GRUU is a URI assigned 2090 to a UA instance which has many of the same properties as the AOR, 2091 but causes requests to be routed only to that specific instance. It 2092 is desirable for a UA to know whether it was reached because a 2093 correspondent sent a request to its GRUU or to its AOR. This can be 2094 used to drive differing authorization policies on whether the request 2095 should be accepted or rejected, for example. However, like the AOR 2096 itself, the GRUU is lost in translation at the home proxy. Thus, the 2097 UAS cannot know whether it was contacted via the GRUU or its AOR. 2099 Following call-flow and example messages show how History-Info can be 2100 used to find out the GRUU used to reach the callee. 2102 GRUU is merely an AoR with a URI parameter that distinguishes the 2103 target instance, and as any URI parameters are preserved in history- 2104 info as Request-URI is trasnlated, UA can see if the request was 2105 addressed to a specific instance (gruu) by evaluating the presence of 2106 "gr" parameter in the hi-entry prior to the last hi-entry with the 2107 "rc" tag. 2109 Alice Example.com John 2110 | | REGISTER F1 | 2111 | |<--------------------| 2112 | | 200 OK F2 | 2113 | |-------------------->| 2114 | INVITE F3 | | 2115 |-------------------->| | 2116 | | INVITE F4 | 2117 | |-------------------->| 2118 * Rest of flow not shown * 2120 F1 REGISTER John -> Example.com 2122 REGISTER sip:example.com SIP/2.0 2123 Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bKnashds7 2124 Max-Forwards: 70 2125 From: John ;tag=a73kszlfl 2126 Supported: gruu 2127 To: John 2128 Call-ID: 1j9FpLxk3uxtm8tn@192.0.2.1 2129 CSeq: 1 REGISTER 2130 Contact: 2131 ;+sip.instance="" 2132 Content-Length: 0 2134 F2 200 OK Example.com -> John 2136 SIP/2.0 200 OK 2137 Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bKnashds7 2138 From: John ;tag=a73kszlfl 2139 To: John ;tag=b88sn 2140 Call-ID: 1j9FpLxk3uxtm8tn@192.0.2.1 2141 CSeq: 1 REGISTER 2142 Contact: 2143 ;pub-gruu="sip:john@example.com 2144 ;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6" 2145 ;temp-gruu= 2146 "sip:tgruu.7hs==jd7vnzga5w7fajsc7-ajd6fabz0f8g5@example.com;gr" 2147 ;+sip.instance="" 2148 ;expires=3600 2149 Content-Length: 0 2151 Assuming Alice has a knowledge of a gruu either through 2152 prior communication or through other means such as presence 2153 places a call to John's gruu. 2155 F3 INVITE Alice -> Example.com 2157 INVITE sip:john@example.com 2158 ;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 SIP/2.0 2159 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=232sxxeserg 2160 From: Alice ;tag=kkaz- 2161 To: 2163 Supported: gruu, histinfo 2164 Call-Id: 12345600@example.com 2165 CSeq: 1 INVITE 2166 History-Info: ;index=1 2168 Contact: Alice 2169 Content-Length: 2171 F4 INVITE Example.com -> John 2173 INVITE sip:john@192.0.2.1 SIP/2.0 2174 Via: SIP/2.0/TCP proxy.example.com:5060;branch=as2334se 2175 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=232sxxeserg 2176 From: Alice ;tag=kkaz- 2177 To: John 2178 Supported: gruu, histinfo 2179 Call-Id: 12345600@example.com 2180 CSeq: 1 INVITE 2181 Record-Route: 2182 History-Info: ;index=1 2184 History-Info: ;index=1.1;rc 2185 Contact: Alice 2186 Content-Type: application/sdp 2187 Content-Length: 2189 Figure 5: GRUU Example 2191 B.8. Limited Use Address 2193 A limited use address is a SIP URI that is minted on-demand, and 2194 passed out to a small number (usually one) remote correspondent. 2195 Incoming calls targeted to that limited use address are accepted as 2196 long as the UA still desires communications from the remote target. 2197 Should they no longer wish to be bothered by that remote 2198 correspondent, the URI is invalidated so that future requests 2199 targeted to it are rejected. 2201 Limited use addresses are used in battling voice spam [RFC5039]. The 2202 easiest way to provide them would be for a UA to be able to take its 2203 AOR, and "mint" a limited use address by appending additional 2204 parameters to the URI. It could then give out the URI to a 2205 particular correspondent, and remember that URI locally. When an 2206 incoming call arrives, the UAS would examine the parameter in the URI 2207 and determine whether or not the call should be accepted. 2208 Alternatively, the UA could push authorization rules into the 2209 network, so that it need not even see incoming requests that are to 2210 be rejected. 2212 This approach, especially when executed on the UA, requires that 2213 parameters attached to the AOR, but not used by the home proxy in 2214 processing the request, will survive the translation at the home 2215 proxy and be presented to the UA. This will not be the case with the 2216 logic in RFC 3261, since the Request-URI is replaced by the 2217 registered contact, and any such parameters are lost. 2219 Using the history-info John's UA can easily see if the call was 2220 addressed to its AoR, GRUU or a temp-gruu and treat the call 2221 accordingly by looking at the hi-entry prior to the last hi-entry 2222 with the "rc" tag. 2224 Alice Example.com John 2225 | | REGISTER F1 | 2226 | |<--------------------| 2227 | | 200 OK F2 | 2228 | |-------------------->| 2229 | INVITE F3 | | 2230 |-------------------->| | 2231 | | INVITE F4 | 2232 | |-------------------->| 2233 * Rest of flow not shown * 2235 F1 REGISTER John -> Example.com 2237 REGISTER sip:example.com SIP/2.0 2238 Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bKnashds7 2239 Max-Forwards: 70 2240 From: John ;tag=a73kszlfl 2241 Supported: gruu 2242 To: John 2243 Call-ID: 1j9FpLxk3uxtm8tn@192.0.2.1 2244 CSeq: 1 REGISTER 2245 Contact: 2246 ;+sip.instance="" 2247 Content-Length: 0 2249 F2 200 OK Example.com -> John 2251 SIP/2.0 200 OK 2252 Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bKnashds7 2253 From: John ;tag=a73kszlfl 2254 To: John ;tag=b88sn 2255 Call-ID: 1j9FpLxk3uxtm8tn@192.0.2.1 2256 CSeq: 1 REGISTER 2257 Contact: 2258 ;pub-gruu="sip:john@example.com 2259 ;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6" 2260 ;temp-gruu= 2261 "sip:tgruu.7hs==jd7vnzga5w7fajsc7-ajd6fabz0f8g5@example.com;gr" 2262 ;+sip.instance="" 2263 ;expires=3600 2264 Content-Length: 0 2266 Assuming Alice has a knowledge of a temp-gruu, she places a 2267 call to the temp-gruu. 2269 F3 INVITE Alice -> Example.com 2270 INVITE sip:tgruu.7hs==jd7vnzga5w7fajsc7-ajd6fabz0f8g5@example.com 2271 ;gr SIP/2.0 2272 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=232sxxeserg 2273 From: Alice ;tag=kkaz- 2274 To: 2276 Supported: gruu, histinfo 2277 Call-Id: 12345600@example.com 2278 CSeq: 1 INVITE 2279 History-Info: 2280 2281 ;index=1 2282 Contact: Alice 2283 Content-Length: 2285 F4 INVITE Example.com -> John 2287 INVITE sip:john@192.0.2.1 SIP/2.0 2288 Via: SIP/2.0/TCP proxy.example.com:5060;branch=as2334se 2289 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=232sxxeserg 2290 From: Alice ;tag=kkaz- 2291 To: John 2292 Supported: gruu, histinfo 2293 Call-Id: 12345600@example.com 2294 CSeq: 1 INVITE 2295 Record-Route: 2296 History-Info: 2297 2298 ;index=1 2299 History-Info: ;index=1.1;rc 2300 Contact: Alice 2301 Content-Type: application/sdp 2302 Content-Length: 2304 Figure 6: Limited Use Address Example 2306 B.9. Sub-Address 2308 Sub-Addressing is very similar to limited use addresses. Sub- 2309 addresses are addresses within a subdomain that are multiplexed into 2310 a single address within a parent domain. The concept is best 2311 illustrated by example. Consider a VoIP service provided to 2312 consumers. A consumer obtains a single address from its provider, 2313 say sip:family@example.com. However, Joe is the patriarch of a 2314 family with four members, and would like to be able to have a 2315 separate identifier for each member of his family. One way to do 2316 that, without requiring Joe to purchase new addresses for each member 2317 from the provider, is for Joe to mint additional URI by adding a 2318 parameter to the AOR. For example, his wife Judy with have the URI 2319 sip:family@example.com;member=judy, and Joe himself would have the 2320 URI sip:family@example.com;member=joe. The SIP server provider would 2321 receive requests to these URI, and ignoring the unknown parameters 2322 (as required by [RFC3261]) route the request to the registered 2323 contact, which corresponds to a SIP server in Joes home. That 2324 server, in turn, can examine the URI parameters and determine which 2325 phone in the home to route the call to. 2327 This feature is not specific to VoIP, and has existing in Integrated 2328 Services Digital Networking (ISDN) for some time. It is particularly 2329 useful for small enterprises, in addition to families. It is also 2330 similar in spirit (though not mechanism) to the ubiquitous home 2331 routers used by consumers, which allow multiple computers in the home 2332 to "hide" behind the single IP address provided by the service 2333 provider, by using the TCP and UDP port as a sub-address. 2335 The sub-addressing feature is not currently feasible in SIP because 2336 of the fact that any SIP URI parameter used to convey the sub-address 2337 would be lost at the home proxy, due to the fact that the Request-URI 2338 is rewritten there. 2340 Call-flow and example messages below show the how History-Info can be 2341 used to deliver the sub-address. UAS or Proxy can determine the sub- 2342 address by looking at the hi-entry prior to the last hi-entry with 2343 the "rc" tag. 2345 Alice Example.com John's Home Judy John 2346 | | REGISTER F1 | | | 2347 | |<-------------| | | 2348 | | 200 OK F2 | | | 2349 | |------------->| | | 2350 | | | REGISTER F3 | | 2351 | | |<-------------| | 2352 | | | 200 OK F4 | | 2353 | | |------------->| | 2354 | | | | REGISTER F5 | 2355 | | |<----------------------------| 2356 | | | | 200 OK F6 | 2357 | | |---------------------------->| 2358 | INVITE F7 | | | | 2359 |----------->| | | | 2360 | | INVITE F8 | | | 2361 | |------------->| | | 2362 | | | INVITE F9 | | 2363 | | |------------->| | 2364 * Rest of flow not shown * 2366 F1 REGISTER John's Home Server -> Example.com 2368 REGISTER sip:example.com SIP/2.0 2369 Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bKnashds7 2370 Max-Forwards: 70 2371 From: John ;tag=a73kszlfl 2372 To: John 2373 Call-ID: 1j9FpLxk3uxtm8tn@192.0.2.1 2374 CSeq: 1 REGISTER 2375 Contact: 2376 Content-Length: 0 2378 F2 200 OK Example.com -> John's Home Server 2380 SIP/2.0 200 OK 2381 Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bKnashds7 2382 From: John ;tag=a73kszlfl 2383 To: John ;tag=b88sn 2384 Call-ID: 1j9FpLxk3uxtm8tn@192.0.2.1 2385 CSeq: 1 REGISTER 2386 Contact: ;expires=3600 2387 Content-Length: 0 2389 We assume that John's server acts as a proxy allowing 2390 each of the device in the house to register. 2392 F3 REGISTER Judy's phone -> John's Home Server 2394 REGISTER sip:192.168.1.1 SIP/2.0 2395 Via: SIP/2.0/UDP 192.168.1.2;branch=z9hG4bKnasdds 2396 Max-Forwards: 70 2397 From: Judy ;tag=a73kszlfl 2398 To: Judy 2399 Call-ID: 12345pLxk3uxtm8tn@192.168.1.2 2400 CSeq: 1 REGISTER 2401 Contact: 2402 Content-Length: 0 2404 F4 200 OK John's Home Server -> Judy's phone 2406 SIP/2.0 200 OK 2407 Via: SIP/2.0/UDP 192.168.1.2;branch=z9hG4bKnashds7 2408 From: Judy ;tag=a73kszlfl 2409 To: Judy tag=b88sn 2410 Call-ID: 12345pLxk3uxtm8tn@192.168.1.2 2411 CSeq: 1 REGISTER 2412 Contact: ;expires=3600 2413 Content-Length: 0 2414 F5 REGISTER John's phone -> John's Home Server 2416 REGISTER sip:192.168.1.1 SIP/2.0 2417 Via: SIP/2.0/UDP 192.168.1.3;branch=z9hG4bKnasdds 2418 Max-Forwards: 70 2419 From: Judy ;tag=a73kszlfl 2420 To: Judy 2421 Call-ID: 12346pLxk3uxtm8tn@192.168.1.3 2422 CSeq: 1 REGISTER 2423 Contact: 2424 Content-Length: 0 2426 F6 200 OK John's Home Server -> John's phone 2428 SIP/2.0 200 OK 2429 Via: SIP/2.0/UDP 192.168.1.3;branch=z9hG4bKnashds7 2430 From: John ;tag=a73kszlfl 2431 To: John ;tag=b88sn 2432 Call-ID: 12346pLxk3uxtm8tn@192.168.1.3 2433 CSeq: 1 REGISTER 2434 Contact: ;expires=3600 2435 Content-Length: 0 2437 F7 INVITE Alice -> Example.com 2439 INVITE sip:johnhome@example.com;member=judy SIP/2.0 2440 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=232sxxeserg 2441 From: Alice 2442 To: Judy 2443 Supported: histinfo 2444 Call-Id: 12345600@example.com 2445 CSeq: 1 INVITE 2446 History-Info: ;index=1; 2447 Contact: Alice 2448 Content-Type: application/sdp 2449 Content-Length: 2451 [SDP Not Shown] 2453 F8 INVITE Example.com -> John's Home 2455 INVITE sip:johnhome@192.0.2.1 SIP/2.0 2456 Via: SIP/2.0/TCP proxy.example.com:5060;branch=as2334se 2457 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=232sxxeserg 2458 From: Alice 2459 To: Judy 2460 Supported: histinfo 2461 Call-Id: 12345600@example.com 2462 CSeq: 1 INVITE 2463 Record-Route: 2464 History-Info: ;index=1; 2465 History-Info: ;index=1.1;rc 2466 Contact: Alice 2467 Content-Type: application/sdp 2468 Content-Length: 2470 [SDP Not Shown] 2472 John's Home server can see that the call was addressed to 2473 Judy by evaluating the entry prior to the last entry with the 2474 "rc" tag and forwards the call accordingly. 2476 F9 INVITE John's Home -> Judy 2478 INVITE sip:judy@192.168.1.2 SIP/2.0 2479 Via: SIP/2.0/TCP 192.168.1.1:5060;branch=abc2334se 2480 Via: SIP/2.0/TCP proxy.example.com:5060;branch=as2334se 2481 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=232sxxeserg 2482 From: Alice 2483 To: Judy 2484 Supported: histinfo 2485 Call-Id: 12345600@example.com 2486 CSeq: 1 INVITE 2487 Record-Route: 2488 History-Info: ;index=1; 2489 History-Info: ;index=1.1;rc 2490 History-Info: ;index=1.1.1;mp=1.1 2491 History-Info: ;index=1.1.1.1;rc 2492 Contact: Alice 2493 Content-Type: application/sdp 2494 Content-Length: 2496 [SDP Not Shown] 2498 Figure 7: Sub-Address Example 2500 B.10. Service Invocation 2502 Several SIP specifications have been developed which make use of 2503 complex URIs to address services within the network rather than 2504 subscribers. The URIs are complex because they contain numerous 2505 parameters that control the behavior of the service. Examples of 2506 this include the specification which first introduced the concept, 2507 [RFC3087], control of network announcements and IVR with SIP URI 2508 [RFC4240], and control of voicemail access with SIP URI [RFC4458]. 2510 A common problem with all of these mechanisms is that once a proxy 2511 has decided to rewrite the Request-URI to point to the service, it 2512 cannot be sure that the Request-URI will not be destroyed by a 2513 downstream proxy which decides to forward the request in some way, 2514 and does so by rewriting the Request-URI. 2516 Section on voicemail (Appendix B.2) shows how History-Info can be 2517 used to invocate a service. 2519 B.11. Toll Free Number 2521 Toll free numbers, also known as 800 or 8xx numbers in the United 2522 States, are telephone numbers that are free for users to call. 2524 In the telephone network, toll free numbers are just aliases to 2525 actual numbers which are used for routing of the call. In order to 2526 process the call in the PSTN, a switch will perform a query (using a 2527 protocol called TCAP), which will return either a phone number or the 2528 identity of a carrier which can handle the call. 2530 There has been recent work on allowing such PSTN translation services 2531 to be accessed by SIP proxy servers through IP querying mechanisms. 2532 ENUM, for example [RFC3761] has already been proposed as a mechanism 2533 for performing Local Number Portability (LNP) queries [RFC4769], and 2534 recently been proposed for performing calling name queries 2535 [I-D.ietf-enum-cnam]. Using it for 8xx number translations is a 2536 logical next-step. 2538 Once such a translation has been performed, the call needs to be 2539 routed towards the target of the request. Normally, this would 2540 happen by selecting a PSTN gateway which is a good route towards the 2541 translated number. However, one can imagine all-IP systems where the 2542 8xx numbers are SIP endpoints on an IP network, in which case the 2543 translation of the 8xx number would actually be a SIP URI and not a 2544 phone number. Assuming for the moment it is a PSTN connected entity, 2545 the call would be routed towards a PSTN gateway. Proper treatment of 2546 the call in the PSTN (and in particular, correct reconciliation of 2547 billing records) requires that the call be marked with both the 2548 original 8xx number AND the target number for the call. However, in 2549 our example here, since the translation was performed by a SIP proxy 2550 upstream from the gateway, the original 8xx number would have been 2551 lost, and the call will not interwork properly with the PSTN. 2553 Furthermore, even if the translation of the 8xx number was a SIP URI, 2554 the enterprise or user who utilize the 8xx service would like to know 2555 whether the call came in via 8xx number in order to treat the call 2556 differently (for example to play a special announcement..) but if the 2557 original R-URI is lost through translation, there is no way to tell 2558 if the call came in via 8xx number. 2560 Similar problems arise with other "special" numbers and services used 2561 in the PSTN, such as operator services, pay numbers (9xx numbers in 2562 the U.S), and short service codes such as 311. 2564 To find the service number, the UAS can look at the hi-entry prior to 2565 the first hi-entry with "mp" tag. Technically call can be forwarded 2566 to these "special" numbers from non "special" numbers, but with the 2567 way these services authorize trasnlation, it is not common. 2569 Alice Toll Free Service Atlanta.com John 2570 | | | | 2571 | INVITE F1 | | | 2572 |--------------->| INVITE F2 | | 2573 | |------------->| | 2574 | | | INVITE F3 | 2575 | | |------------------>| 2577 * Rest of flow not shown * 2579 F1: INVITE 192.0.2.1 -> proxy.example.com 2581 INVITE sip:+18005551002@example.com;user=phone SIP/2.0 2582 Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9 2583 From: Alice ;tag=9fxced76sl 2584 To: sip:+18005551002@example.com;user=phone 2585 Call-ID: c3x842276298220188511 2586 CSeq: 1 INVITE 2587 Max-Forwards: 70 2588 Supported: histinfo 2589 History-Info: ;index=1 2590 Contact: 2591 Content-Type: application/sdp 2592 Content-Length: 2594 [SDP Not Shown] 2596 F2: INVITE proxy.example.com -> atlanta.com 2598 INVITE sip:+15555551002@atlanta.com SIP/2.0 2599 Via: SIP/2.0/TCP 192.0.2.4:5060;branch=z9hG4bK-ik80k7g-1 2600 Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9 2601 From: Alice ;tag=9fxced76sl 2602 To: sip:+18005551002@example.com;user=phone 2603 Call-ID: c3x842276298220188511 2604 CSeq: 1 INVITE 2605 Max-Forwards: 70 2606 Supported: histinfo 2607 History-Info: ;index=1, 2608 ;index=1.1;mp=1 2609 Contact: 2610 Content-Type: application/sdp 2611 Content-Length: 2613 [SDP Not Shown] 2615 F3: INVITE atlanta.com -> Joe 2617 INVITE sip:joe@192.168.1.2 SIP/2.0 2618 Via: SIP/2.0/TCP 192.168.1.1:5060;branch=z9hG4bK-pxk7g-3 2619 Via: SIP/2.0/TCP 192.0.2.4:5060;branch=z9hG4bK-ik80k7g-1 2620 Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9 2621 From: Alice ;tag=9fxced76sl 2622 To: sip:+18005551002@example.com;user=phone 2623 Call-ID: c3x842276298220188511 2624 CSeq: 1 INVITE 2625 Max-Forwards: 70 2626 Supported: histinfo 2627 History-Info: ;index=1, 2628 ;index=1.1;mp=1, 2629 ;index=1.1.1;mp=1.1, 2630 ;index=1.1.2;rc 2631 Contact: 2632 Content-Type: application/sdp 2633 Content-Length: 2635 [SDP Not Shown] 2637 Figure 8: Service Number Example 2639 Authors' Addresses 2641 Mary Barnes 2642 Nortel 2643 Richardson, TX 2645 Email: mary.barnes@nortel.com 2646 Francois Audet 2647 Skype Labs 2649 Email: francois.audet@skypelabs.com 2651 Shida Schubert 2652 NTT 2654 Email: shida@ntt.com 2656 Hans Erik van Elburg 2657 Detecon International Gmbh 2658 Oberkasseler str. 2 2659 Bonn, 53227 2660 Germany 2662 Email: ietf.hanserik@gmail.com 2664 Christer Holmberg 2665 Ericsson 2666 Hirsalantie 11, Jorvas 2667 Finland 2669 Email: christer.holmberg@ericsson.com