GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc8119

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc8119.txt · Last modified: 2017/03/16 00:05 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki