Skip to main content

Session Initiation Protocol (SIP) Cause URI parameter for Service Number translation
draft-mohali-dispatch-cause-for-service-number-08

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 2016-09-22
RFC stream Internet Engineering Task Force (IETF)
Formats
Reviews
Additional resources
Stream WG state (None)
Document shepherd Jean Mahoney
IESG IESG state Became RFC 8119 (Informational)
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD Ben Campbell
Send notices to "Jean Mahoney" <mahoney@nostrum.com>
draft-mohali-dispatch-cause-for-service-number-08
Network Working Group                                          M. Mohali
Internet-Draft                                                    Orange
Updates: 4458 (if approved)                                    M. Barnes
Intended status: Informational               MLB@Realtime Communications
Expires: March 26, 2017                               September 22, 2016

Session Initiation Protocol (SIP) Cause URI parameter for Service Number
                              translation
           draft-mohali-dispatch-cause-for-service-number-08

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 specification 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 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 March 26, 2017.

Copyright Notice

   Copyright (c) 2016 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

Mohali & Barnes          Expires March 26, 2017                 [Page 1]
Internet-Draft    Cause for service number translation    September 2016

   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  . . . . . .   3
     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  . . . . . . . . . . . . . . . . . . . . . .   8
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

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
   needs to be translated into a routable SIP or tel URI to process the
   session establishment.

Mohali & Barnes          Expires March 26, 2017                 [Page 2]
Internet-Draft    Cause for service number translation    September 2016

   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.

   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
   an 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:

                   +---------------------------------+-------+
                   |         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

Mohali & Barnes          Expires March 26, 2017                 [Page 3]
Internet-Draft    Cause for service number translation    September 2016

   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.

   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
   should be added to a History-Info entry only when the retargeting is
   due to a received SIP response.

Mohali & Barnes          Expires March 26, 2017                 [Page 4]
Internet-Draft    Cause for service number translation    September 2016

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:

   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 might find the
      service access number before translation in the To header field

Mohali & Barnes          Expires March 26, 2017                 [Page 5]
Internet-Draft    Cause for service number translation    September 2016

      only if the To header field has not been changed when the request
      was retargeted.

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>
      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]

Mohali & Barnes          Expires March 26, 2017                 [Page 6]
Internet-Draft    Cause for service number translation    September 2016

   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
      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>;

Mohali & Barnes          Expires March 26, 2017                 [Page 7]
Internet-Draft    Cause for service number translation    September 2016

                    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]

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 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].

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]  "SIP: Session Initiation Protocol", RFC 3261, June 2002.

   [RFC3323]  "A Privacy Mechanism for the Session Initiation Protocol
              (SIP)", RFC 3323, November 2002.

Mohali & Barnes          Expires March 26, 2017                 [Page 8]
Internet-Draft    Cause for service number translation    September 2016

   [RFC3326]  "The Reason Header Field for the Session Initiation
              Protocol (SIP)", RFC 3326, December 2002.

   [RFC7044]  "An Extension to the Session Initiation Protocol (SIP) for
              Request History Information", RFC 7044, February 2014.

   [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.

   [ITU-T_Q.1600]
              ITU-T Recommendation Q.1600, "Signalling System No. 7 -
              Interaction between ISUP and INAP", September 1997.

   [ITU-T_Q.763]
              ITU-T Recommendation Q.763, "Signalling System No. 7 -
              ISDN User Part formats and codes.", December 1999.

   [RFC4458]  "Session Initiation Protocol (SIP) URIs for Applications
              such as Voicemail and Interactive Voice Response (IVR)",
              RFC 4458, April 2006.

   [RFC5234]  "Augmented BNF for Syntax Specifications: ABNF", RFC 5234,
              January 2008.

Authors' Addresses

   Marianne Mohali
   Orange
   44 Avenue de la Republique
   Chatillon  92320
   France

   Email: marianne.mohali@orange.com

Mohali & Barnes          Expires March 26, 2017                 [Page 9]
Internet-Draft    Cause for service number translation    September 2016

   Mary Barnes
   MLB@Realtime Communications
   TX
   US

   Email: mary.ietf.barnes@gmail.com

Mohali & Barnes          Expires March 26, 2017                [Page 10]