[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 RFC 8119

Network Working Group                                          M. Mohali
Internet-Draft                                                    Orange
Updates: RFC4458 (if approved)                             July 21, 2015
Intended status: Informational
Expires: January 22, 2016


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

Abstract

   [RFC4458] defines a "cause" URI parameter as having predefined values
   for Redirecting reasons as a mapping from ITU-T Q.732.2-5 Redirecting
   Reasons.  The "cause" URI parameter is to be used in SIP or SIPs URI.
   In particular, it may appear in the Request-URI of a SIP request.
   This specification creates a new predefined value for the "cause" URI
   parameter for cases when the retargeting is due to specific service
   action leading to a called service access number translation.
   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 January 22, 2016.

Copyright Notice

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



Mohali                  Expires January 22, 2016                [Page 1]


Internet-Draft    Cause for service number translation         July 2015


   carefully, as they describe your rights and restrictions with respect
   to this document.

Table of Contents

   1.  Introduction and Overview . . . . . . . . . . . . . . . . . .   2
   2.  Solution  . . . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Interaction with Request History Information  . . . . . .   3
     2.2.  Handling and Processing the new "cause" URI parameter
           value . . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Example . . . . . . . . . . . . . . . . . . . . . . . . . . .   5
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     6.2.  Informative References  . . . . . . . . . . . . . . . . .   9
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction and Overview

   A mechanism has been defined in [RFC4458] to add a "cause" URI
   parameter in the target URI to be able to identify retargeting due to
   the call forwarding supplementary services from other retargetings.
   This "cause" URI parameter has defined values equivalent to the TDM
   (Time Division Multiplexing) Redirecting reasons.

   In PSTN/ISDN there is another kind of retargeting introduced by the
   Intelligent Network (IN) services in [ITU-T_I.312_Q.1201].  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.  For these
   IN services, it was introduced in ISUP the "called IN number" and the
   "original called IN number" parameters that enable to keep the
   information of the service access number requested prior its
   translation.

   This specification proposes a solution to allow the identification of
   well-known services such as premium or toll free services that are
   doing access number translation.

   A mechanism is required to identify URIs that are issued from a
   retargeting or number translation by a specific service similar to
   PSTN/ISDN IN services.

   The mechanism covers the IN services that can be identified in the
   ISUP signaling in the "called IN number" and "original called IN
   number" optional parameters defined in [ITU-T_Q.763] and used in
   ISUP/INAP interworking as described in [ITU-T_Q.1600].



Mohali                  Expires January 22, 2016                [Page 2]


Internet-Draft    Cause for service number translation         July 2015


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
   "mp" or "rc" tag is present and the URI is issued from a retargeting
   or an 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:



                   +---------------------------------+-------+
                   | Service Type                    | Value |
                   +---------------------------------+-------+
                   | Service number translation      | 380   |
                   +---------------------------------+-------+

2.1.  Interaction with Request History Information

   The Request History mechanism initially defined in [RFC4244] and then
   obsoleted by [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 retarget-to
   URIs.  This information is placed in the History-Info header field,
   which, except where prevented by privacy considerations, is built up
   as the request progresses and, upon reaching the UAS, is returned in
   certain responses.

   The History-Info header field [RFC7044] provides a mechanism to
   capture the history information associated with a Session Initiation
   Protocol (SIP) request.  This capability enables many enhanced
   services by providing the information as to how and why a SIP request



Mohali                  Expires January 22, 2016                [Page 3]


Internet-Draft    Cause for service number translation         July 2015


   arrives at a specific application or user and to keep this
   information throughout the signaling path even when successive
   applications are involved.  Thus, it is reasonable to have systems in
   which both the information in the Request-URI and the History
   information are included and one or both are used.

   In particular, when a proxy inserts a URI containing the "cause" URI
   parameter defined in [RFC4458] into the Request-URI of a forwarded
   request, 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 will incorporate these parameters.  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 may be of use to the UAS.  Consequently,
   UASes that make use of this information may find the information in
   the History-Info header and/or in the Request-URI, depending on the
   capability of the proxy to support generation of History-Info or on
   the behavior of downstream proxies; therefore, applications need to
   take this into account (see section 2.2).

   In order to be able to filter specific entries among the history
   information, tags have been defined in [RFC7044].  In particular, the
   "mp" and "rc" tags having the following definitions: The "mp" tag 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, retargeting that are 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" tag is added when the new
   target represents a change in Request-URI, while the target user
   remains the same.

   Using the History-Info header field, it is necessary to pay attention
   not to get the "cause" URI parameter defined in [RFC4458] and the
   "cause" header parameter included in the Reason header field mixed
   up.  The "cause" parameter of the Reason header 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 new "cause" URI parameter value

   At the application:

      When an application receiving a request that is addressed to a
      service access number changes the Request-URI into a routeable
      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



Mohali                  Expires January 22, 2016                [Page 4]


Internet-Draft    Cause for service number translation         July 2015


      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" tag and then the UAS will find the requested service number
      in the History-Info entry having an index parameter value that
      match this "mp" or "rc" tag value.  If for any reason, there is no
      "mp" or "rc" tag in the identified History-Info entry, the UAS
      will find the requested service number in the History-Info entry
      that precede.

   Following are other means for the UAS to find the requested service
   access number before translation but there is no guaranty on it:

   o  If the UAS is the direct target of the request coming from the
      application, the UAS should 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 the History-Info has been removed by a proxy for any reason,
      the UAS may be able to find the requested service access number as
      described in the previous bullet.

   o  If there is no "cause" URI parameter set to 380 in the Request-URI
      and there is no Histroy-Info header field, the UAS may find the
      service access number before translation in the To header only if
      the To header 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.





Mohali                  Expires January 22, 2016                [Page 5]


Internet-Draft    Cause for service number translation         July 2015


   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 for to tell 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]


   F2 INVITE Toll-Free Service -> Atlanta.com

      The Toll-Free application receives the request and translates the
      service number into a routeable number toward the call-center.
      The Request-URI is changed and in the new Request-URI it is added the
      "cause" URI parameter set to 380. 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



Mohali                  Expires January 22, 2016                [Page 6]


Internet-Draft    Cause for service number translation         July 2015


      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 IP address
      by changing the Request-URI. By changing the Request-URI, the proxy
      adds a new entry in the History-Info header filed.

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





Mohali                  Expires January 22, 2016                [Page 7]


Internet-Draft    Cause for service number translation         July 2015


4.  IANA Considerations

   [RFC3969] defines a 'sip:' or 'sips:' URI Parameter sub registry.
   [RFC4458] defines a "cause" parameter specified as having predefined
   values.  This RFC defines a new value for the "cause" parameter: 380.
   This RFC has been added to the references listed for the "cause" the
   "SIP/SIPS URI Parameters" sub-registry in
   <http:/www.iana.org/assignments/sip-parameters> for the "cause"
   parameter.


    Parameter Name         Predefined Values            References
    --------------         -----------------        ------------------
       cause                      Yes               [RFC4458][RFCxxxx]

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

6.1.  Normative References

   [RFC2119]  "Key words for use in RFCs to Indicate Requirement
              Levels", RFC 2119, March 1997.

   [RFC3261]  "SIP: Session Initiation Protocol", RFC 3261, June 2002.

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

   [RFC3969]  "The Internet Assigned Number Authority (IANA) Uniform
              Resource Identifier (URI) Parameter Registry for the
              Session Initiation Protocol (SIP)", December 2004.

   [RFC4244]  "An Extension to the Session Initiation Protocol (SIP) for
              Request History Information", RFC 4244, November 2005.

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






Mohali                  Expires January 22, 2016                [Page 8]


Internet-Draft    Cause for service number translation         July 2015


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

Author's Address

   Marianne Mohali
   Orange
   38-40 rue du General Leclerc
   Issy-Les-Moulineaux Cedex 9  92794
   France

   Phone: +33 1 45 29 45 14
   Email: marianne.mohali@orange.com




















Mohali                  Expires January 22, 2016                [Page 9]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/