doc: Add RFC documents

1 files changed, 675 insertions, 0 deletions

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 <sip:+15551001@example.com;user=phone>;tag=9fxced76sl
+      To: <sip:+18005551002@example.com;user=phone>
+      Call-ID: c3x842276298220188511
+      CSeq: 1 INVITE
+      Max-Forwards: 70
+      Contact: <sip:alice@[2001:db8:9::2]>
+      Content-Type: application/sdp
+      Content-Length: <appropriate value>
+
+      [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 <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@[2001:db8:9::2]>
+      Content-Type: application/sdp
+      Content-Length: <appropriate value>
+
+      [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 <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@[2001:db8:b::2]>;index=1.1.1;rc=1.1
+      Contact: <sip:alice@[2001:db8:9::2]>
+      Content-Type: application/sdp
+      Content-Length: <appropriate value>
+
+      [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,
+              <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, "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,
+              <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>.
+
+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]
+