wdiff rfc8119.original rfc8119.txt

Network Working Group
Internet Engineering Task Force (IETF) M. Mohali
Internet-Draft
Request for Comments: 8119 Orange
Updates: 4458 (if approved) M. Barnes
Intended status:
Category: Informational MLB@Realtime Communications
Expires: August 4,
ISSN: 2070-1721 March 2017 January 31, 2017

Session Initiation Protocol (SIP) Cause

SIP "cause" URI parameter Parameter for Service Number
translation
draft-mohali-dispatch-cause-for-service-number-14.txt Translation

Abstract

RFC4458 (SIP

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 creates 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 RFC4458, RFC 4458, for using the "cause" URI parameter within
the History-Info header field field, since this use is mandatory in some IP
networks' implementations.

This document updates RFC4458.

Status of This Memo

This Internet-Draft document is submitted in full conformance with the
provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents not an Internet Standards Track specification; it is
published for informational purposes.

This document is a product of the Internet Engineering Task Force
(IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list It represents the consensus of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid 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 maximum candidate for any level of six months 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 updated, replaced, or obsoleted by other documents obtained 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 August 4, 2017.
http://www.rfc-editor.org/info/rfc8119.

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 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 Parameter Value . . . . . . . . . . . . . . . 5
4. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. Acknowledgements References . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.
7.1. Normative References . . . . . . . . . . . . . . . . . . 9
7.2. Informative References . . . . . . . 9
8.1. Normative References . . . . . . . . . . . 10
Acknowledgements . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10

1. Introduction, Terminology 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)/ (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. (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 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 and therefore 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 services, such as premium or toll free toll-free services that
perform service access number translation, and to enable interworking
with SIP signaling with the ISUP Called called IN number and Original Called original called
IN numbers number parameters.

The mechanism will allow a SIP network to insert and convey the
service access number requested prior 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 3rd-Generation 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 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 "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 from [RFC4458] is summarized below as it has been subject to Errata [ID:
1409] (including updates
described in [RFC4458]. [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: a guidance for the usage of the "cause"
URI parameter usage in the request history information in section 3.1 (in Section 3.1) and
a
guidance for processing a service number translation service using
the new "cause" URI parameter value in section 3.2. (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 UAC 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], 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 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
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 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 having have the
following definitions: The "mp" header field parameter is added when

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.
retargeted, the "mp" header field parameter is added. This allows identifying
the identification of retargets that are the result of a an
application decision
made by on a particular type of application or user's behalf and also retargets that an initial request
has been retargeted as a
are the result of an application internal decision in a
general manner. 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 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
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". 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
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 and then so that the UAS can find the requested
service number in the History-Info entry having an index parameter
value that match matches this "mp" or "rc" header field parameter value. If
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" 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.

4. Example

In this section 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 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 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]
F2 INVITE Toll-Free Service -> Atlanta.com

The Toll-Free toll-free application receives the request and translates
the service number into a routable number toward the call center.
The Request-URI is changed changed, and, in the new Request-URI, the 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]
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.

This document requests

IANA to modify has modified the existing row for the "cause" URI parameter to
add a reference to this document under the "SIP/
SIPS "SIP/SIPS URI Parameters"
subregistry within the "Session Initiation
Protocols" Protocol (SIP) Parameters"
registry:

Parameter Name Predefined Values References Reference
-------------- ----------------- -------------------------
cause Yes [RFC4458][TBD:thisdocument] [RFC4458][RFC8119]

6. Security Considerations

The security considerations in [RFC4458] apply.

If a privacy service that performs level of 'header' is requested in the "Privacy: header" Service
[RFC3323] must remove Privacy header
field as described in [RFC3323], the cause "cause" URI parameter must be
removed from the URI. Request-URI to maintain the network-provided privacy
requested. Privacy of the parameters, when they form part of a URI
within the History-
Info History-Info header field, is covered in [RFC7044].

7. 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 detail reviews of the document. Special thanks to
Ben Campbell for his help to make the work progress.

8. References

8.1.

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 TS 24.229 13.0.0,
3GPP, "IP multimedia call control protocol based on
Session Initiation Protocol (SIP) and Session Description
Protocol (SDP);Stage (SDP); Stage 3", December
2014.

8.2. 3GPP TS 24.229 13.6.0.0, January
2015.

7.2. Informative References

[Err1409] RFC Errata, Erratum ID 1409, RFC 4458.

[ITU-T_I.312_Q.1201]
ITU-T Recommendation I312/Q.1201,
ITU-T, "Principles of Intelligent Network Architecture",
ITU-T Recommendation I312/Q.1201, October 1992.

[ITU-T_Q.1214]
ITU-T Recommendation 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 Recommendation Q.763,
ITU-T, "Signalling System No. 7 - -- ISDN User Part formats
and codes.", 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.

Authors' Addresses

Marianne Mohali
Orange
44 Avenue de la Republique
Chatillon 92320
France

Email: marianne.mohali@orange.com

Mary Barnes
MLB@Realtime Communications
TX
US
United States of America

Email: mary.ietf.barnes@gmail.com