| Network Working Group | M. Mohali |
| Internet-Draft | Orange |
| Updates: RFC4458 (if approved) | October 15, 2015 |
| Intended status: Informational | |
| Expires: April 17, 2016 |
Session Initiation Protocol (SIP) Cause URI parameter for Service Number translation
draft-mohali-dispatch-cause-for-service-number-05
[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].
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 April 17, 2016.
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 carefully, as they describe your rights and restrictions with respect to this document.
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.
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.
This specification proposes a solution to allow the identification of well-known services such as premium or toll free services that are doing service 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].
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 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:
+---------------------------------+-------+
| Service Type | Value |
+---------------------------------+-------+
| Service number translation | 380 |
+---------------------------------+-------+
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 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.
At 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:
Following are other means for the UAS to find the requested service access number before translation but there is no guaranty on it:
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 routable 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
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]
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 for to tell the appropriate welcome speech.
[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]
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].
| [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. |
| [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. |