--- 1/draft-ietf-sipcore-rfc4244bis-callflows-06.txt 2013-10-21 16:15:46.649863598 -0700 +++ 2/draft-ietf-sipcore-rfc4244bis-callflows-07.txt 2013-10-21 16:15:46.733865799 -0700 @@ -1,25 +1,25 @@ SIPCORE M. Barnes Internet-Draft Polycom Intended status: Informational F. Audet -Expires: January 2, 2014 Skype +Expires: April 23, 2014 Skype S. Schubert NTT H. van Elburg Detecon International Gmbh C. Holmberg Ericsson - Jul 2013 + Oct 20, 2013 Session Initiation Protocol (SIP) History-Info Header Call Flow Examples - draft-ietf-sipcore-rfc4244bis-callflows-06.txt + draft-ietf-sipcore-rfc4244bis-callflows-07.txt Abstract This document describes use cases and documents call flows which require the History-Info header field to capture the Request-URIs as a Session Initiation Protocol (SIP) Request is retargeted. The use cases are described along with the corresponding call flow diagrams and messaging details. Status of this Memo @@ -30,21 +30,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on January 2, 2014. + This Internet-Draft will expire on April 23, 2014. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -54,52 +54,52 @@ the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 3. Detailed call flows . . . . . . . . . . . . . . . . . . . . . 3 3.1. Sequentially Forking (History-Info in Response) . . . . . 3 3.2. History-Info with Privacy Header Field . . . . . . . . . . 11 - 3.3. Privacy for a Specific History-Info Entry . . . . . . . . 14 - 3.4. Automatic Call Distribution . . . . . . . . . . . . . . . 18 - 3.5. Determining the Alias used. . . . . . . . . . . . . . . . 23 - 3.6. PBX Voicemail Example . . . . . . . . . . . . . . . . . . 26 - 3.7. Consumer Voicemail Example . . . . . . . . . . . . . . . . 31 - 3.8. GRUU . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 - 3.9. Limited Use Address . . . . . . . . . . . . . . . . . . . 38 - 3.10. Service Invocation . . . . . . . . . . . . . . . . . . . . 41 - 3.11. Toll Free Number . . . . . . . . . . . . . . . . . . . . . 41 - 4. Security Considerations . . . . . . . . . . . . . . . . . . . 44 - 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44 - 5.1. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 44 - 6. Informative References . . . . . . . . . . . . . . . . . . . . 44 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 45 + 3.3. Privacy for a Specific History-Info Entry . . . . . . . . 16 + 3.4. Automatic Call Distribution . . . . . . . . . . . . . . . 20 + 3.5. Determining the Alias used. . . . . . . . . . . . . . . . 25 + 3.6. PBX Voicemail Example . . . . . . . . . . . . . . . . . . 28 + 3.7. Consumer Voicemail Example . . . . . . . . . . . . . . . . 33 + 3.8. GRUU . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 + 3.9. Limited Use Address . . . . . . . . . . . . . . . . . . . 40 + 3.10. Service Invocation . . . . . . . . . . . . . . . . . . . . 43 + 3.11. Toll Free Number . . . . . . . . . . . . . . . . . . . . . 43 + 4. Security Considerations . . . . . . . . . . . . . . . . . . . 45 + 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45 + 5.1. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 46 + 6. Informative References . . . . . . . . . . . . . . . . . . . . 46 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 47 1. Overview Many services that use SIP require the ability to determine why and how the call arrived at a specific application. The use cases provided in this document illustrate the use of the History-Info header [I-D.ietf-sipcore-rfc4244bis] for example applications and common scenarios. The optional "rc" and "mp" header field parameters defined in [I-D.ietf-sipcore-rfc4244bis] are required for several of the use cases. Descriptions of the example use cases, call flow diagrams and messaging details are provided. 2. Conventions and Terminology The term "retarget" is used as defined in [I-D.ietf-sipcore-rfc4244bis]. The terms "location service", - "redirect" and "AOR" are used consistent with the terminology in - [RFC3261]. + "redirect" and "address-of-record (AOR)" are used consistent with the + terminology in [RFC3261]. 3. Detailed call flows The scenarios in this section provide sample use cases for the History-Info header for informational purposes only. They are not intended to be normative. In many cases, only the relevant messaging details are included in the body of the call flow. 3.1. Sequentially Forking (History-Info in Response) @@ -109,21 +109,21 @@ Alice sends a call to Bob via sip:example.com. The proxy sip: example.com sequentially tries Bob on a SIP UA that has bound a contact with the sip:bob@example.com AOR, and then several alternate addresses (Office and Home) unsuccessfully before sending a response to Alice. The hi-entry containing the initial contact is the hi- entry just prior to the first hi-entry tagged with an "rc" header field parameter. In this example, the Office and Home are not the same AOR as sip:bob@example.com, but rather different AORs that have been configured as alternate addresses for Bob in the proxy. In - other words, Office and *Home* are not bound through SIP Registration + other words, Office and Home are not bound through SIP Registration with Bob's AOR. This type of arrangement is common for example when a "routing" rule to a PSTN number is manually configured in a proxy. These hi-entries are identified by the index contained in the hi- target-param "mp" header field parameter in the hi-entries. This scenario illustrates that by providing the History-Info to Alice, the end-user or an application at Alice could make a decision on how best to attempt finding Bob without sending multiple requests to the same destination. Upon receipt of the response containing the History-Info entries, the Request URIs for the History-Info entries @@ -391,53 +391,57 @@ Max-Forward: 70 From: Alice ;tag=sr3dds To: Bob ;tag=55rdds Call-Id: 12345600@example.com Route: CSeq: 1 ACK Content-Length: 0 3.2. History-Info with Privacy Header Field - This example provides a basic call scenario without forking. Alice - has indicated that she wants Privacy associated with the History-Info - header field entries. In addition, sip:biloxi.example.com adds - Privacy header fields indicating that the History-Info header field - information is anonymized outside the biloxi.example.com domain. - Note, that if the atlanta.example.com proxy had added privacy header - fields to all its hi-entries, then all the hi-entries in the response - would be anonymous. + This is an example of the use of the Privacy header field with a + value of "history" added by an intermediary. The intermediary + responsible for the biloxi.example.com domain adds a Privacy header + field with a value of "history" indicating that all the History-Info + header field information is anonymized outside the biloxi.example.com + domain. Thus, none of the URIs to which the request is retargeted in + the biloxi.example.com domain are sent in the final response nor are + they sent in the request as it is forwared to Bob's Home domain. - Alice atlanta.example.com biloxi.example.com Bob + Alice atlanta.example.com biloxi.example.com Bob Work Bob Home - | | | | - | INVITE F1 | | | - |--------------->| | | - | | | | - | | INVITE F2 | | - | |--------------->| | - | | | | - | | | INVITE F3 | - | | |--------------->| - | | | | - | | | 200 F4 | - | | |<---------------| - | | | | - | | 200 F5 | | - | |<---------------| | - | | | | - | 200 F6 | | | - |<---------------| | | - | | | | - | | ACK | | - |------------------------------------------------->| - | | | | + | | | | | + | INVITE F1 | | | | + |------------>| | | | + | | | | | + | | INVITE F2 | | | + | |--------------->| | | + | | | | | + | | | INVITE F3 | | + | | |---------------->| | + | | |302 Move Temporarily F4 | + | | |<----------------| | + | | | | | + | | | INVITE F5 | | + | | |--------------------------->| + | | | 200 F6 | | + | | |<---------------------------| + | | | | | + | | 200 F7 | | | + | |<---------------| | | + | | | | | + | 200 F8 | | | | + |<------------| | | | + | | | | | + | | ACK | | | + |---------------------------------------------------------->| + | | | | | Figure 2: Example with Privacy Header Fields Message Details F1 INVITE alice -> atlanta.example.com INVITE sip:bob@biloxi.example.com;p=x SIP/2.0 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 Max-Forward: 70 @@ -457,99 +461,159 @@ INVITE sip:bob@biloxi.example.com;p=x SIP/2.0 Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=z9hG4bKbst2 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 Max-Forward: 69 From: Alice ;tag=22 To: Bob Supported: histinfo Call-Id: 12345600@atlanta.example.com CSeq: 1 INVITE - History-Info: ;index=1 + History-Info: ;index=1 History-Info: ;index=1.1 Contact: Alice Content-Type: application/sdp Content-Length: - F3 INVITE biloxi.example.com -> Bob + F3 INVITE biloxi.example.com -> Bob Work INVITE sip:bob@192.0.1.11 SIP/2.0 - Via: SIP/2.0/TCP proxy.biloxi.example.com:5060;branch=z9hG4bKgs32 + Via: SIP/2.0/TCP proxy.biloxi.example.com:5060;branch=z9hG4bKgs33 Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=z9hG4bKbst2;\ received=192.0.2.3 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 Max-Forward: 68 From: Alice ;tag=22 To: Bob + Privacy: history Supported: histinfo Call-Id: 12345600@atlanta.example.com CSeq: 1 INVITE - History-Info: ;index=1 + History-Info: ;index=1 History-Info: ;index=1.1 - History-Info: ;index=1.1.1;rc=1.1 + History-Info: ;index=1.1.1;rc=1.1 Contact: Alice Content-Type: application/sdp Content-Length: + F4 302 Moved Temporarily Bob Work -> biloxi.example.com + + SIP/2.0 302 Moved Temporarily + Via: SIP/2.0/TCP proxy.biloxi.example.com:5060;branch=z9hG4bKgs33;\ + received=192.0.2.102 + Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=z9hG4bKbst2;\ + received=192.0.2.3 + Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 + Max-Forward: 68 + From: Alice ;tag=22 + To: Bob + Privacy: history + Supported: histinfo + Call-Id: 12345600@atlanta.example.com + CSeq: 1 INVITE + History-Info: ;index=1 + History-Info: ;index=1.1 + History-Info: ;index=1.1.1;rc=1.1 + Contact: ;mp=1.1 + Content-Type: application/sdp + Content-Length: + + + F5 INVITE biloxi.example.com -> Bob Home + + + INVITE sip:bob@192.0.1.15 SIP/2.0 + Via: SIP/2.0/TCP proxy.biloxi.example.com:5060;branch=z9hG4bKgs32 + Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=z9hG4bKbst2;\ + received=192.0.2.3 + Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 + Max-Forward: 68 + From: Alice ;tag=22 + To: Bob + Supported: histinfo + Call-Id: 12345600@atlanta.example.com + CSeq: 1 INVITE + History-Info: ;index=1 + History-Info: ;index=1.1 + History-Info: ;index=1.1.1;rc=1.1 + History-Info: ;index=1.2;mp=1.1 + Contact: Alice + Content-Type: application/sdp + Content-Length: + F4 200 OK Bob -> biloxi.example.com + SIP/2.0 200 OK Via: SIP/2.0/TCP proxy.biloxi.example.com:5060;branch=z9hG4bKgs32;\ received=192.0.2.101 Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=z9hG4bKbst2;\ received=192.0.2.3 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 From: Alice ;tag=22 To: Bob ;tag=33 Supported: histinfo Call-Id: 12345600@atlanta.example.com CSeq: 1 INVITE - History-Info: ;index=1 - History-Info: ;index=1.1 - History-Info: ;index=1.1.1;rc=1.1 - Contact: Bob + History-Info: ;index=1 + History-Info: ;index=1.1 + History-Info: ;index=1.1.1;rc=1.1 + History-Info: ;index=1.2;mp=1.1 + History-Info: ;index=1.2.1;rc=1.2 Content-Type: application/sdp Content-Length: + F5 200 OK biloxi.example.com -> atlanta.example.com SIP/2.0 200 OK Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=z9hG4bKbst2;\ received=192.0.2.101 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 From: Alice ;tag=22 To: Bob ;tag=33 + Privacy: history Supported: histinfo Call-Id: 12345600@atlanta.example.com CSeq: 1 INVITE History-Info: ;index=1 - History-Info: ;index=1.1 - History-Info: ;index=1.1.1;rc=1.1 - Contact: Bob + History-Info: ;index=1.1 + History-Info: ;index=1.1.1;rc=1.1 + History-Info: ;index=1.2;mp=1.1 + History-Info: ;index=1.2.1;rc=1.2 + Contact: Bob Content-Type: application/sdp Content-Length: F6 200 OK atlanta.example.com -> Alice SIP/2.0 200 OK Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 From: Alice ;tag=22 To: Bob ;tag=33 Supported: histinfo Call-Id: 12345600@atlanta.example.com CSeq: 1 INVITE History-Info: ;index=1 - History-Info: ;index=1.1 - History-Info: ;index=1.1.1;rc=1.1 - Contact: Bob + History-Info: ;index=1.1 + History-Info: ;index=1.1.1;rc=1.1 + History-Info: ;index=1.2;mp=1.1 + History-Info: ;index=1.2.1;rc=1.2 + Contact: Bob Content-Type: application/sdp Content-Length: 3.3. Privacy for a Specific History-Info Entry This example provides a basic call scenario similar to Section 3.2, however, due to local policy at sip:biloxi.example.com, only the final hi-entry in the History-Info, which is Bob's local URI, contains a privacy header field with a priv-value of "history", thus @@ -1076,27 +1140,27 @@ the request. The original target is determined by finding the first hi-entry tagged with "rc" or "mp" and using the hi-entry referenced by the index of "rc" or "mp" header field parameter as the target for determining the appropriate mailbox. This hi-entry is used to populate the "target" URI parameter as defined in [RFC4458]. The reason associated with the first hi-entry tagged with "rc" or "mp" (i.e., 302) could be used to provide a customized voicemail greeting and is used to populate the "cause" URI parameter as defined in [RFC4458]. Note that some VMSs may also (or instead) use the information available in the History-Info headers for custom handling - of the VM in terms of how and why the call arrived at the VMS. + of the VM based on how and why the call arrived at the VMS. Furthermore it is the proxy forwarding the call to VMS that determines the target of the voicemail, it is the proxy that sets the - target of voicemail which is also the entity that utilizes RFC4244bis - to find the target which is usually based on local policy installed - by the user or an administrator. + target of voicemail which is also the entity that utilizes + [I-D.ietf-sipcore-rfc4244bis] to find the target which is usually + based on local policy installed by the user or an administrator. Alice example.com Bob Carol VM | INVITE F1 | | | | |------------->| | | | | | INVITE F2 | | | | |------------->| | | | | | | | | 100 Trying | | | | |<-------------| 302 Moved Temporarily F3 | | @@ -1770,64 +1834,54 @@ [RFC3087], control of network announcements and IVR with SIP URI [RFC4240], and control of voicemail access with SIP URI [RFC4458]. A common problem with all of these mechanisms is that once a proxy has decided to rewrite the Request-URI to point to the service, it cannot be sure that the Request-URI will not be destroyed by a downstream proxy which decides to forward the request in some way, and does so by rewriting the Request-URI. Section on voicemail (Section 3.6) shows how History-Info can be used - to invocate a service. + to invoke a service. 3.11. Toll Free Number Toll free numbers, also known as 800 or 8xx numbers in the United States, are telephone numbers that are free for users to call. In the telephone network, toll free numbers are just aliases to actual numbers which are used for routing of the call. In order to process the call in the PSTN, a switch will perform a query (using a protocol called TCAP), which will return either a phone number or the identity of a carrier which can handle the call. There has been recent work on allowing such PSTN translation services to be accessed by SIP proxy servers through IP querying mechanisms. ENUM, for example [RFC6117] has already been proposed as a mechanism - for performing Local Number Portability (LNP) queries [RFC4769], and - recently been proposed for performing calling name queries - [I-D.ietf-enum-cnam]. Using it for 8xx number translations is a - logical next-step. + for performing Local Number Portability (LNP) queries [RFC4769]. + Using it for 8xx number translations is a logical next-step. - Once such a translation has been performed, the call needs to be - routed towards the target of the request. Normally, this would - happen by selecting a PSTN gateway which is a good route towards the - translated number. However, one can imagine all-IP systems where the - 8xx numbers are SIP endpoints on an IP network, in which case the - translation of the 8xx number would actually be a SIP URI and not a - phone number. Assuming for the moment it is a PSTN connected entity, - the call would be routed towards a PSTN gateway. Proper treatment of - the call in the PSTN (and in particular, correct reconciliation of - billing records) requires that the call be marked with both the - original 8xx number AND the target number for the call. However, in - our example here, since the translation was performed by a SIP proxy - upstream from the gateway, the original 8xx number would have been - lost, and the call will not interwork properly with the PSTN. - History-info would come in play here to assure original 8xx number is - not lost. + The new target from translating the 8xx number may be in PSTN or in + SIP network. If the new target is an entity in the PSTN network, the + proper treatment in the PSTN (and in particular, correct + reconciliation of billing records) requires that the call be marked + with both the originating number (8xx number) and the new target + number, History-info could be used here to ensure original 8xx number + is not lost. - Furthermore, even if the translation of the 8xx number was a SIP URI, - the enterprise or user who utilize the 8xx service would like to know - whether the call came in via 8xx number in order to treat the call - differently (for example to play a special announcement..) but if the - original R-URI is lost through translation, there is no way to tell - if the call came in via 8xx number. + Although not required to have both the originating number (8xx + number) and the new target in the SIP network, an enterprise or a + user that utilizes the 8xx service can benefit by knowing whether the + call came in via an 8xx number in order to treat the call differently + (e.g., to play a special announcement). However, if the original + R-URI is lost through translation, there is no way to tell if the + call came in via 8xx number. History-info again could be used here. Similar problems arise with other "special" numbers and services used in the PSTN, such as operator services, pay/premium numbers (9xx numbers in the U.S), and short service codes such as 311. To find the service number, the UAS can extract the hi-entry whose index matches the value of the first hi-entry with an "mp" tag. Technically the call can be forwarded to these "special" numbers from non "special" numbers, however that is uncommon based on the way these services authorize translations. @@ -1949,26 +2003,20 @@ April 2006. [RFC6117] Hoeneisen, B., Mayrhofer, A., and J. Livingood, "IANA Registration of Enumservices: Guide, Template, and IANA Considerations", RFC 6117, March 2011. [RFC4769] Livingood, J. and R. Shockey, "IANA Registration for an Enumservice Containing Public Switched Telephone Network (PSTN) Signaling Information", RFC 4769, November 2006. - [I-D.ietf-enum-cnam] - Shockey, R., "IANA Registration for an Enumservice Calling - Name Delivery (CNAM) Information and IANA Registration for - URI type 'pstndata'", draft-ietf-enum-cnam-08 (work in - progress), September 2008. - [I-D.ietf-sipcore-rfc4244bis] Barnes, M., Audet, F., Schubert, S., Elburg, H., and C. Holmberg, "An Extension to the Session Initiation Protocol (SIP) for Request History Information", draft-ietf-sipcore-rfc4244bis-11 (work in progress), January 2013. Authors' Addresses Mary Barnes