Session Initiation Protocol (SIP) Cause URI parameter for Service Number translation
draft-mohali-dispatch-cause-for-service-number-12
The information below is for an old version of the document.
Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 8119.
|
|
---|---|---|---|
Authors | Marianne Mohali , Mary Barnes | ||
Last updated | 2017-01-20 (Latest revision 2016-12-13) | ||
RFC stream | Internet Engineering Task Force (IETF) | ||
Formats | |||
Reviews |
OPSDIR Last Call review
by Lionel Morand
Has issues
GENART Last Call review
by Joel Halpern
Ready w/issues
|
||
Stream | WG state | (None) | |
Document shepherd | Jean Mahoney | ||
Shepherd write-up | Show Last changed 2016-12-13 | ||
IESG | IESG state | Became RFC 8119 (Informational) | |
Consensus boilerplate | Yes | ||
Telechat date | (None) | ||
Responsible AD | Ben Campbell | ||
Send notices to | (None) | ||
IANA | IANA review state | IANA OK - Actions Needed |
draft-mohali-dispatch-cause-for-service-number-12
Network Working Group M. Mohali Internet-Draft Orange Updates: 4458 (if approved) M. Barnes Intended status: Informational MLB@Realtime Communications Expires: June 17, 2017 December 14, 2016 Session Initiation Protocol (SIP) Cause URI parameter for Service Number translation draft-mohali-dispatch-cause-for-service-number-12.txt Abstract RFC4458 defines a "cause" URI parameter, which may appear in the Request-URI of a SIP request, that is used to indicate a reason why the request arrived to the User Agent Server (UAS) receiving the message. This document creates a new predefined value for the "cause" URI parameter to cover service number translation for cases of retargeting due to specific service action leading to the translation of a called service access number. This document also provides guidance, which was missing in RFC4458, for using the "cause" URI parameter within the History-Info header field since this use is mandatory in some IP networks' implementations. This document updates RFC4458. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. 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 June 17, 2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. Mohali & Barnes Expires June 17, 2017 [Page 1] Internet-Draft Cause for service number translation December 2016 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 carefully, as they describe your rights and restrictions with respect to this document. Table of Contents 1. Introduction, Terminology and Overview . . . . . . . . . . . 2 2. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Interaction with Request History Information . . . . . . 4 2.2. Handling and Processing the Service Number Translation "cause" URI parameter value . . . . . . . . . . . . . . . 5 3. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 7.2. Informative References . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction, Terminology and Overview [RFC4458] defines a mechanism to identify retargeting due to call forwarding supplementary services. The "cause" URI parameter in the target URI identifies the reason for retargeting and has defined values equivalent to the TDM (Time Division Multiplexing) Redirecting Reasons [ITU-T_Q.763]. The concept of "retargeting" is defined in [RFC7044]. In the Public Switched Telephone Network (PSTN)/ Integrated Services Digital Network (ISDN), there is another kind of retargeting introduced by the Intelligent Network (IN) services based on a translation of the called number as mentioned in [ITU-T_Q.1214]. Indeed, IN aims to ease the introduction of new services (i.e. Universal Personal Telecommunication (UPT), Virtual Private Network (VPN), Freephone, etc.) based on greater flexibility and new capabilities as described in [ITU-T_I.312_Q.1201]. For these IN services, ISUP introduced the "called IN number" and the "original called IN number" parameters to capture the information of the requested service access number prior its translation [ITU-T_Q.763]. The term "service access number" is used in this specification to refer to the dialable number by which a specific service is reached. This special number is not a globally routable number and therefore Mohali & Barnes Expires June 17, 2017 [Page 2] Internet-Draft Cause for service number translation December 2016 needs to be translated into a routable SIP or tel URI to process the session establishment. This specification proposes a solution to allow the identification of well-known services such as premium or toll free services that perform service access number translation, and to enable interworking with SIP signaling with the ISUP Called IN number and Original Called IN numbers parameters. The mechanism will allow a SIP network to insert and convey the service access number requested prior its translation to the final destination. In order to provide full call forwarding or access number translation services, usage of the "cause" URI parameter is only relevant within the History-Info header field defined in [RFC7044]. Because this relation has not been described in [RFC4458], this document provides guidance for using the "cause" URI parameter in conjunction with the History-Info header field. This document also answers a need expressed by the 3rd-Generation Partnership Project (3GPP) [TS.3GPP.24.229]. 2. Solution A new value for the "cause" URI parameter of the 'sip:' or 'sips:' URI schemes is defined. This value may be used in a 'sip:' or 'sips:' URI inserted in the Request-URI and in the History-Info header field [RFC7044] when the URI is issued from a retargeting or a service access number translation by a specific service similar to PSTN/ISDN IN services that is not a call forwarding service. As defined in [RFC4458], the cause URI parameter must be encoded in the new target URI when generated by the service. The ABNF grammar [RFC5234] for the cause-param and target-param parameters is summarized below as it has been subject to Errata [ID: 1409] in [RFC4458]. The Status-Code is defined in [RFC3261]. target-param = "target=" pvalue cause-param = "cause=" Status-Code The following value for this URI parameter is added to the existing ones: Mohali & Barnes Expires June 17, 2017 [Page 3] Internet-Draft Cause for service number translation December 2016 +---------------------------------+-------+ | Cause | Value | +---------------------------------+-------+ | Service number translation | 380 | +---------------------------------+-------+ 2.1. Interaction with Request History Information The History-Info header field defined in [RFC7044] specifies a means of providing the UAS and UAC with information about the retargeting of a request. This information includes the initial Request-URI and any retargeted URIs. This information is placed in History-Info headers as the request is retargeted and, upon reaching the UAS, is returned in certain responses. The History-Info header field enables many enhanced services by providing the information as to how and why a SIP request arrives at a specific application or user and to keep this information throughout the signaling path even when successive applications are involved. When a proxy inserts a URI containing the "cause" URI parameter defined in [RFC4458] into the Request-URI of a forwarded request, per [RFC7044], the proxy must also copy this new Request-URI within a History-Info header field entry into the forwarded request, and so the URI in that entry includes the "cause" URI parameter. Therefore, even if the Request-URI is replaced as a result of rerouting by a downstream proxy, the History-Info header field will still contain these parameters, which can be of use to the UAS. Note that if a proxy does not support generation of the History-Info header field or if a downstream proxy removes the History-Info header fields, an application will only have access to the "cause" URI parameter if the request is not subsequently retargeted (i.e., it will be contained only in the Request-URI in the incoming request). The implications of this are further discussed in section Section 2.2. In order to be able to filter specific entries among the history information, header field parameters have been defined in [RFC7044]. In particular, the "mp" and "rc" header field parameters having the following definitions: The "mp" header field parameter is added when the new target was determined based on a mapping to a user other than the target user associated with the Request-URI being retargeted. This allows identifying retargets that are the result of a decision made by a particular type of application or that an initial request has been retargeted as a result of an application decision in a general manner. The "rc" header field parameter is added when the new target represents a change in Request-URI, while the target user remains the same. These header field parameters can be used in conjunction with the new "cause" URI parameter for certain applications, an example of which is provided in section Section 3. Mohali & Barnes Expires June 17, 2017 [Page 4] Internet-Draft Cause for service number translation December 2016 When using the History-Info header field in conjunction with the "cause" URI parameter in a Request-URI, it is important to consider that the "cause" URI parameter is not the same parameter as the "cause" header field parameter included in the Reason header [RFC3326]. The "cause" header field parameter of the Reason header field should be added to a History-Info entry only when the retargeting is due to a received SIP response. 2.2. Handling and Processing the Service Number Translation "cause" URI parameter value At the Application Server: When an application receiving a request that is addressed to a service access number changes the Request-URI into a routable number it should insert within this new Request-URI a "cause" URI parameter value set to 380. Following the process described in [RFC7044], the application must add a new History-Info header field entry including the new Request-URI value including the "cause" URI parameter. It is also possible for an application to add a "target" URI parameter as defined in [RFC4458] with the initial value of the Request-URI received by the application. Note that if the new Request-URI is further replaced by a downstream proxy for any reason and if the History-Info header field is not supported, the information of the service access number initially requested would be lost. Thus, it is strongly recommended to support the History-Info header field all along the signaling path. At the UAS: When the UAS receiving the request wants to retrieve the service access number by which it has been reached, first it should look for the "cause" URI parameter value 380 in the History-Info header field. This History-Info entry should also contain an "mp" or "rc" header field parameter and then the UAS can find the requested service number in the History-Info entry having an index parameter value that match this "mp" or "rc" header field parameter value. If for any reason, there is no "mp" or "rc" header field parameter in the identified History-Info entry, the UAS can find the requested service number in the preceding History-Info entry. If the History-Info header is not supported or has been removed by a proxy for any reason, the UAS might be able to find the requested service access number before translation in either of the following ways, but there is no guarantee: Mohali & Barnes Expires June 17, 2017 [Page 5] Internet-Draft Cause for service number translation December 2016 o If the UAS is the direct target of the request coming from the application, the UAS ought to be able to find the service access number in the "target" URI parameter of the Request-URI if there is also a "cause" URI parameter set to 380 in this Request-URI. o If there is no "cause" URI parameter set to 380 in the Request-URI and there is no History-Info header field, the UAS will not be able to reliably retrieve the service access number before translation. Some existing implementations are known to extract the number from the "To" header field. While that approach may work in some situations, it will not work in the general case because the To header field value is sometimes changed by intermediaries, and such a change is not always detectable. 3. Example In this section an example is provided to illustrate the application of the new cause-param value. In this example, Alice calls her bank customer care. John is the person at the call center that answers the call. John is in a call center that manages several toll-free services and he needs to know for which service Alice is calling to provide the appropriate welcome speech. Alice Toll-Free Service Atlanta.com John | | | | | INVITE F1 | | | |--------------->| INVITE F2 | | | |------------->| | | | | INVITE F3 | | | |------------------>| * Rest of flow not shown * Figure 1: Service Access Number Translation Example Message Details F1 INVITE 192.0.2.1 -> Toll-Free Service In the initial request, the Request-URI contains the Toll-Free number dialed by Alice. INVITE sip:+18005551002@example.com;user=phone SIP/2.0 Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK74bf From: Alice <sip:+15551001@example.com;user=phone>;tag=9fxced76sl To: <sip:+18005551002@example.com;user=phone> Mohali & Barnes Expires June 17, 2017 [Page 6] Internet-Draft Cause for service number translation December 2016 Call-ID: c3x842276298220188511 CSeq: 1 INVITE Max-Forwards: 70 Contact: <sip:alice@192.0.2.1> Content-Type: application/sdp Content-Length: <appropriate value> [SDP Not Shown] F2 INVITE Toll-Free Service -> Atlanta.com The Toll-Free application receives the request and translates the service number into a routable number toward the call center. The Request-URI is changed and, in the new Request-URI, the "cause" URI parameter set to 380 is added. As there was no History-Info header field in the received request, the application creates a History-Info header with two entries: one for the received Request-URI and one for the new Request-URI. INVITE sip:+15555551002@atlanta.com;cause=380;user=phone SIP/2.0 Via: SIP/2.0/TCP 192.0.2.4:5060;branch=z9hG4bK-ik8 Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK74bf From: Alice <sip:+15551001@example.com;user=phone>;tag=9fxced76sl To: <sip:+18005551002@example.com;user=phone> Call-ID: c3x842276298220188511 CSeq: 1 INVITE Max-Forwards: 69 Supported: histinfo History-Info: <sip:+18005551002@example.com;user=phone>;index=1 History-Info: <sip:+15555551002@atlanta.com;cause=380;user=phone>; index=1.1;mp=1 Contact: <sip:alice@192.0.2.1> Content-Type: application/sdp Content-Length: <appropriate value> [SDP Not Shown] F3 INVITE Atlanta.com -> John The call center proxy routes the received request to John's IP address by changing the Request-URI. When changing the Request-URI, the proxy adds a new entry in the History-Info header field. INVITE sip:john@198.51.100.2 SIP/2.0 Via: SIP/2.0/TCP 198.51.100.1:5060;branch=z9hG4bKpxk7g Mohali & Barnes Expires June 17, 2017 [Page 7] Internet-Draft Cause for service number translation December 2016 Via: SIP/2.0/TCP 192.0.2.4:5060;branch=z9hG4bK-ik8 Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK74bf From: Alice <sip:+15551001@example.com;user=phone>;tag=9fxced76sl To: <sip:+18005551002@example.com;user=phone> Call-ID: c3x842276298220188511 CSeq: 1 INVITE Max-Forwards: 68 Supported: histinfo History-Info: <sip:+18005551002@example.com;user=phone>;index=1 History-Info: <sip:+15555551002@atlanta.com;cause=380;user=phone>; index=1.1;mp=1 History-Info: <sip:john@198.51.100.2>;index=1.1.1;rc=1.1 Contact: <sip:alice@192.0.2.1> Content-Type: application/sdp Content-Length: <appropriate value> [SDP Not Shown] NOTE: Line breaks for display purpose only 4. IANA Considerations [RFC4458] defines a "cause" parameter specified as having predefined values. This document defines a new value for the "cause" parameter: 380. This document requests IANA to modify the existing row for the "cause" parameter to add a reference to this document under the "SIP/ SIPS URI Parameters" subregistry within the "Session Initiation Protocols" registry: Parameter Name Predefined Values References -------------- ----------------- ------------------------- cause Yes [RFC4458][TBD:thisdocument] 5. Security Considerations The security considerations in [RFC4458] apply. A privacy service that performs the "Privacy: header" Service [RFC3323] must remove the cause URI parameter from the URI. Privacy of the parameters, when they form part of a URI within the History- Info header field, is covered in [RFC7044]. Mohali & Barnes Expires June 17, 2017 [Page 8] Internet-Draft Cause for service number translation December 2016 6. Acknowledgements The authors wish to thank the 3GPP community for providing guidance, input, and comments on the document. Thanks also to Paul Kyzivat, Dale Worley, Ben Campbell and to Jean Mahoney for her careful review of the document. 7. References 7.1. Normative References [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <http://www.rfc-editor.org/info/rfc3261>. [RFC3323] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, DOI 10.17487/RFC3323, November 2002, <http://www.rfc-editor.org/info/rfc3323>. [RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason Header Field for the Session Initiation Protocol (SIP)", RFC 3326, DOI 10.17487/RFC3326, December 2002, <http://www.rfc-editor.org/info/rfc3326>. [RFC7044] Barnes, M., Audet, F., Schubert, S., van Elburg, J., and C. Holmberg, "An Extension to the Session Initiation Protocol (SIP) for Request History Information", RFC 7044, DOI 10.17487/RFC7044, February 2014, <http://www.rfc-editor.org/info/rfc7044>. [TS.3GPP.24.229] 3GPP TS 24.229 13.0.0, "IP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP);Stage 3", December 2014. 7.2. Informative References [ITU-T_I.312_Q.1201] ITU-T Recommendation I312/Q.1201, "Principles of Intelligent Network Architecture", October 1992. [ITU-T_Q.1214] ITU-T Recommendation Q.1214, "Distributed Functional Plane For Intellignet Network CS-1", October 1995. Mohali & Barnes Expires June 17, 2017 [Page 9] Internet-Draft Cause for service number translation December 2016 [ITU-T_Q.763] ITU-T Recommendation Q.763, "Signalling System No. 7 - ISDN User Part formats and codes.", December 1999. [RFC4458] Jennings, C., Audet, F., and J. Elwell, "Session Initiation Protocol (SIP) URIs for Applications such as Voicemail and Interactive Voice Response (IVR)", RFC 4458, DOI 10.17487/RFC4458, April 2006, <http://www.rfc-editor.org/info/rfc4458>. [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <http://www.rfc-editor.org/info/rfc5234>. Authors' Addresses Marianne Mohali Orange 44 Avenue de la Republique Chatillon 92320 France Email: marianne.mohali@orange.com Mary Barnes MLB@Realtime Communications TX US Email: mary.ietf.barnes@gmail.com Mohali & Barnes Expires June 17, 2017 [Page 10]