Session Initiation Protocol (SIP) Cause URI parameter for Service Number translation
draft-mohali-dispatch-cause-for-service-number-02
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.
|
|
|---|---|---|---|
| Author | Marianne Mohali | ||
| Last updated | 2015-05-11 | ||
| RFC stream | (None) | ||
| Formats | |||
| Reviews |
GENART Last Call review
(of
-12)
by Joel Halpern
Ready w/issues
|
||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | Became RFC 8119 (Informational) | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-mohali-dispatch-cause-for-service-number-02
Network Working Group M. Mohali
Internet-Draft Orange
Updates: RFC4458 (if approved) May 11, 2015
Intended status: Informational
Expires: November 12, 2015
Session Initiation Protocol (SIP) Cause URI parameter for Service Number
translation
draft-mohali-dispatch-cause-for-service-number-02
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 and in the History-
Info header field defined in [RFC7044] in some specific retargeted
requests defined in this document.
This specification creates a new predefined value for cases when the
retargeting is caused by a 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 November 12, 2015.
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
Mohali Expires November 12, 2015 [Page 1]
Internet-Draft Cause for service number translation May 2015
(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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3
3. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
7.1. Normative References . . . . . . . . . . . . . . . . . . 6
7.2. Informative References . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
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 signalinh path even when successive
applications are involved.
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.
Concurrently, 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 form
other retargetings. This "cause" URI parameter has defined values
equivalent to the TDM Redirecting reasons.
It is requested to pay attention not to get this "cause" URI
parameter and the "cause" header parameter included in the Reason
Mohali Expires November 12, 2015 [Page 2]
Internet-Draft Cause for service number translation May 2015
header field mixed up. The "cause" URI parameter may be used in the
Request-URI and in the History-info header field to indicate the
service that the UserAgent Server (UAS) receiving the message should
perform.
In PSTN/ISDN there is another kind of retargeting introduced by the
Intelligent Network (IN) services. Indeed, the [ITU-T_I.312_Q.1201]
defined the IN term to describe an architectural concept which is
intended to be applicable to all telecommunications networks. 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.
2. Problem Statement
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.
This mechanism needs to cover at least 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].
3. Solution
A new alternative 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.
Mohali Expires November 12, 2015 [Page 3]
Internet-Draft Cause for service number translation May 2015
The ABNF grammar [RFC5234] for the cause-param and target-param
parameters is reminded 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 |
+---------------------------------+-------+
4. Example
In this section an example will be provided to illustrate the
application of the new cause-param value.
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
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
Mohali Expires November 12, 2015 [Page 4]
Internet-Draft Cause for service number translation May 2015
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
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
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@atlanta.com>;index=1.1.1;rc=1.1
History-Info: <sip:john@198.51.100.2>;index=1.1.1.1;rc=1.1.1
Contact: <sip:alice@192.0.2.1>
Content-Type: application/sdp
Content-Length: <appropriate value>
Mohali Expires November 12, 2015 [Page 5]
Internet-Draft Cause for service number translation May 2015
[SDP Not Shown]
5. 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]
6. 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].
7. References
7.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.
[RFC7044] "An Extension to the Session Initiation Protocol (SIP) for
Request History Information", RFC 7044, February 2014.
Mohali Expires November 12, 2015 [Page 6]
Internet-Draft Cause for service number translation May 2015
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.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 November 12, 2015 [Page 7]