From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc8119.txt | 675 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 675 insertions(+) create mode 100644 doc/rfc/rfc8119.txt (limited to 'doc/rfc/rfc8119.txt') diff --git a/doc/rfc/rfc8119.txt b/doc/rfc/rfc8119.txt new file mode 100644 index 0000000..6437f23 --- /dev/null +++ b/doc/rfc/rfc8119.txt @@ -0,0 +1,675 @@ + + + + + + +Internet Engineering Task Force (IETF) M. Mohali +Request for Comments: 8119 Orange +Updates: 4458 M. Barnes +Category: Informational MLB@Realtime Communications +ISSN: 2070-1721 March 2017 + + + SIP "cause" URI Parameter for Service Number Translation + +Abstract + + RFC 4458 (regarding SIP URIs for applications) 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 updates RFC + 4458 by creating 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 RFC 4458, for using the "cause" URI parameter within + the History-Info header field, since this use is mandatory in some IP + networks' implementations. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Not all documents + approved by the IESG are a candidate for any level of Internet + Standard; see Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc8119. + + + + + + + + + + + + + +Mohali & Barnes Informational [Page 1] + +RFC 8119 Cause for Service Number Translation March 2017 + + +Copyright Notice + + Copyright (c) 2017 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 + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction, Terminology, and Overview . . . . . . . . . . . 2 + 2. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 3. Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 3.1. Interaction with Request History Information . . . . . . 4 + 3.2. Handling and Processing the Service Number Translation + "cause" URI Parameter Value . . . . . . . . . . . . . . . 5 + 4. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 + 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 7.1. Normative References . . . . . . . . . . . . . . . . . . 10 + 7.2. Informative References . . . . . . . . . . . . . . . . . 11 + Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 + +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 + + + +Mohali & Barnes Informational [Page 2] + +RFC 8119 Cause for Service Number Translation March 2017 + + + capabilities as described in [ITU-T_I.312_Q.1201]. For these IN + services, ISDN User Part (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; therefore, it + 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 number parameters. + + The mechanism will allow a SIP network to insert and convey the + service access number requested before 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 Third Generation + Partnership Project (3GPP) [TS.3GPP.24.229] to identify the service + access number. The procedures it defines are intended for networks + that use 3GPP-defined services. Their use is undefined for other + networks. + +2. Solution + + A new value for the "cause" URI parameter of the 'sip:' or 'sips:' + URI schemes is defined for the "Service number translation" use case. + 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. + + + + +Mohali & Barnes Informational [Page 3] + +RFC 8119 Cause for Service Number Translation March 2017 + + + The ABNF grammar [RFC5234] for the cause-param and target-param + parameters from [RFC4458] is summarized below (including updates + described in [Err1409]). 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: + + +---------------------------------+-------+ + | Cause | Value | + +---------------------------------+-------+ + | Service number translation | 380 | + +---------------------------------+-------+ + +3. Guidelines + + In order to help implementation of this solution for conveyance of + the service access number, this document proposes guidance for usage + of the "cause" URI parameter: guidance for the usage of the "cause" + URI parameter in the request history information (in Section 3.1) and + guidance for processing a service number translation service using + the new "cause" URI parameter value (in Section 3.2). + +3.1. Interaction with Request History Information + + The History-Info header field defined in [RFC7044] specifies a means + of providing the UAS and User Agent Client (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; thus, 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 + + + +Mohali & Barnes Informational [Page 4] + +RFC 8119 Cause for Service Number Translation March 2017 + + + 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 the solution are further discussed in Section 3.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 have the + following definitions: + + o 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, the "mp" header field parameter is added. This allows + the identification of retargets that are the result of an + application decision on a user's behalf and also retargets that + are the result of an internal decision made by an application. + + o 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 4. + + 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. + +3.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 "Service number translation". + Following the process described in [RFC7044], the application + server adds a new History-Info header field entry including the + new Request-URI value including the "cause" URI parameter. It is + + + + + +Mohali & Barnes Informational [Page 5] + +RFC 8119 Cause for Service Number Translation March 2017 + + + also possible for an application server to add a "target" URI + parameter as defined in [RFC4458] with the initial value of the + Request-URI received by the application server. + + 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 so that the UAS can find the requested + service number in the History-Info entry having an index parameter + value that matches 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: + + 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. + + + + + + + + + + +Mohali & Barnes Informational [Page 6] + +RFC 8119 Cause for Service Number Translation March 2017 + + +4. 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 in order 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 [2001:db8:9::2] -> 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 [2001:db8:9::2]:5060;branch=z9hG4bK74bf + From: Alice ;tag=9fxced76sl + To: + Call-ID: c3x842276298220188511 + CSeq: 1 INVITE + Max-Forwards: 70 + Contact: + Content-Type: application/sdp + Content-Length: + + [SDP Not Shown] + + + + + + + + + +Mohali & Barnes Informational [Page 7] + +RFC 8119 Cause for Service Number Translation March 2017 + + + 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, a + "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 [2001:db8:a::2];branch=z9hG4bK-ik8 + Via: SIP/2.0/TCP [2001:db8:9::2]:5060;branch=z9hG4bK74bf + From: Alice ;tag=9fxced76sl + To: + Call-ID: c3x842276298220188511 + CSeq: 1 INVITE + Max-Forwards: 69 + Supported: histinfo + History-Info: ;index=1 + History-Info: ; + index=1.1;mp=1 + Contact: + Content-Type: application/sdp + Content-Length: + + [SDP Not Shown] + + + + + + + + + + + + + + + + + + + + + + + + +Mohali & Barnes Informational [Page 8] + +RFC 8119 Cause for Service Number Translation March 2017 + + + 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@[2001:db8:b::2] SIP/2.0 + Via: SIP/2.0/TCP [2001:db8:b::3]:5060;branch=z9hG4bKpxk7g + Via: SIP/2.0/TCP [2001:db8:a::2];branch=z9hG4bK-ik8 + Via: SIP/2.0/TCP [2001:db8:9::2]:5060;branch=z9hG4bK74bf + From: Alice ;tag=9fxced76sl + To: + Call-ID: c3x842276298220188511 + CSeq: 1 INVITE + Max-Forwards: 68 + Supported: histinfo + History-Info: ;index=1 + History-Info: ; + index=1.1;mp=1 + History-Info: ;index=1.1.1;rc=1.1 + Contact: + Content-Type: application/sdp + Content-Length: + + [SDP Not Shown] + +NOTE: Line breaks are for display purpose only + +5. IANA Considerations + + [RFC4458] defines a "cause" URI parameter specified as having + predefined values. This document defines a new value for the "cause" + URI parameter: 380. + + IANA has modified the existing row for the "cause" URI parameter to + add a reference to this document under the "SIP/SIPS URI Parameters" + subregistry within the "Session Initiation Protocol (SIP) Parameters" + registry: + + Parameter Name Predefined Values Reference + -------------- ----------------- ---------------------- + cause Yes [RFC4458][RFC8119] + + + + + + + + +Mohali & Barnes Informational [Page 9] + +RFC 8119 Cause for Service Number Translation March 2017 + + +6. Security Considerations + + The security considerations in [RFC4458] apply. + + If a privacy level of 'header' is requested in the Privacy header + field as described in [RFC3323], the "cause" URI parameter must be + removed from the Request-URI to maintain the network-provided privacy + requested. Privacy of the parameters, when they form part of a URI + within the History-Info header field, is covered in [RFC7044]. + +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, + . + + [RFC3323] Peterson, J., "A Privacy Mechanism for the Session + Initiation Protocol (SIP)", RFC 3323, + DOI 10.17487/RFC3323, November 2002, + . + + [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, + . + + [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, + . + + [TS.3GPP.24.229] + 3GPP, "IP multimedia call control protocol based on + Session Initiation Protocol (SIP) and Session Description + Protocol (SDP); Stage 3", 3GPP TS 24.229 13.6.0.0, January + 2015. + + + + + + + + + + +Mohali & Barnes Informational [Page 10] + +RFC 8119 Cause for Service Number Translation March 2017 + + +7.2. Informative References + + [Err1409] RFC Errata, Erratum ID 1409, RFC 4458. + + [ITU-T_I.312_Q.1201] + ITU-T, "Principles of Intelligent Network Architecture", + ITU-T Recommendation I312/Q.1201, October 1992. + + [ITU-T_Q.1214] + ITU-T, "Distributed Functional Plane For Intellignet + Network CS-1", ITU-T Recommendation Q.1214, October 1995. + + [ITU-T_Q.763] + ITU-T, "Signalling System No. 7 -- ISDN User Part formats + and codes", ITU-T Recommendation Q.763, 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, + . + + [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", STD 68, RFC 5234, + DOI 10.17487/RFC5234, January 2008, + . + +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, Jean Mahoney, Robert Sparks, Joel Halpern, and Lionel + Morand for their detailed reviews of the document. Special thanks to + Ben Campbell for his help to make the work progress. + + + + + + + + + + + + + + + + + +Mohali & Barnes Informational [Page 11] + +RFC 8119 Cause for Service Number Translation March 2017 + + +Authors' Addresses + + Marianne Mohali + Orange + 44 Avenue de la Republique + Chatillon 92320 + France + + Email: marianne.mohali@orange.com + + + Mary Barnes + MLB@Realtime Communications + TX + United States of America + + Email: mary.ietf.barnes@gmail.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Mohali & Barnes Informational [Page 12] + -- cgit v1.2.3