Network Working Group M. Mohali
Internet-Draft Orange Labs
Intended status: Informational February 2, 2010
Expires: August 6, 2010
Mapping and interworking of Diversion information Between Diversion and
History-Info Headers in the Session Initiation Protocol (SIP)
draft-mohali-diversion-history-info-05
Abstract
Although the SIP History-Info header is the solution adopted in IETF,
the non-standard Diversion header is nevertheless widely implemented
and used for conveying call diversion related information in the
Session Initiation Protocol (SIP) signaling.
This document describes a recommended interworking guideline between
the Diversion header and the History-Info header to handle call
diversion information. In addition, an interworking policy is
proposed to manage the headers coexistence. The History-Info header
is described in [RFC4244] and the non-standard Diversion header is
described, as Historic, in the [draft-levy-sip-diversion-11].
Note to the RFC-Editor: The reference to this draft should be
replaced by the Historic RFC reference (work in progress).
Since the Diversion header is used in many existing network
implementations for the transport of call diversion information, its
interworking with the SIP History-Info standardized solution is
needed.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
Mohali Expires August 6, 2010 [Page 1]
Internet-Draft Mapping Diversion and History-Info February 2010
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 6, 2010.
Copyright Notice
Copyright (c) 2010 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. 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 BSD License.
Mohali Expires August 6, 2010 [Page 2]
Internet-Draft Mapping Diversion and History-Info February 2010
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Background . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Interworking requirements and scope . . . . . . . . . . . 5
2.2. Interworking recommendations . . . . . . . . . . . . . . . 7
2.2.1. SIP network/terminal using Diversion to SIP
network/terminal using History-Info header . . . . . . 7
2.2.2. SIP network/terminal using History-Info header to
SIP network/terminal using Diversion header . . . . . 9
3. Headers syntaxes reminder . . . . . . . . . . . . . . . . . . 10
3.1. History-Info header syntax . . . . . . . . . . . . . . . . 10
3.2. Diversion header syntax . . . . . . . . . . . . . . . . . 12
4. Headers in SIP Method . . . . . . . . . . . . . . . . . . . . 13
5. Diversion header to History-Info header . . . . . . . . . . . 14
6. History-Info header to Diversion header . . . . . . . . . . . 17
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
7.1. Example with Diversion header changed into
History-Info header . . . . . . . . . . . . . . . . . . . 19
7.2. Example with History-Info header changed into
Diversion header . . . . . . . . . . . . . . . . . . . . . 19
7.3. Example with two SIP networks using History-Info
header interworking with a SIP network using Diversion
header . . . . . . . . . . . . . . . . . . . . . . . . . . 19
7.4. Additional interworking Cases . . . . . . . . . . . . . . 21
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
9. Security Considerations . . . . . . . . . . . . . . . . . . . 22
10. Acknowlegements . . . . . . . . . . . . . . . . . . . . . . . 23
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
11.1. Normative References . . . . . . . . . . . . . . . . . . . 23
11.2. Informative References . . . . . . . . . . . . . . . . . . 23
Appendix A. Interworking between Diversion header and
Voicemail URI . . . . . . . . . . . . . . . . . . . . 24
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 25
Mohali Expires August 6, 2010 [Page 3]
Internet-Draft Mapping Diversion and History-Info February 2010
1. Introduction
1.1. Overview
For some VoIP-based services (eg. Voicemail, Interactive Voice
Recognition (IVR) or automatic call distribution), it is helpful for
the called SIP user agent to identify from whom and why the session
was diverted. For this information to be used in various service
providers or by applications, it needs to pass through the network.
This is possible with two different SIP headers: History-Info header
defined in [RFC4244] and the historic Diversion header defined in
[draft-levy-sip-diversion-11] which are both able to transport
diversion information in SIP signaling.
Note to the RFC-Editor: The reference to this draft should be
replaced by the Historic RFC reference (work in progress).
Although the Diversion header is not standardized, it is widely used.
Therefore, it is useful to have guidelines to make this header
interwork with the standard History-Info header.
This document provides a mechanism for header content translation
between the Diversion header and the History-Info header.
1.2. Background
The History-Info header [RFC4244] and its extension for forming SIP
service URIs (including Voicemail URI) [RFC4458] are recommended by
IETF to convey redirection information. They are also recommended in
the "Communication Diversion (CDIV) service" 3GPP specification
[TS_24.604].
Originally, the Diversion header was described in an Internet Draft
that was submitted to the SIP Working Group. It has been published
now as [draft-levy-sip-diversion-11] for the historical record and to
provide a reference for this RFC.
Note to the RFC-Editor: The reference to this draft should be
replaced by the Historic RFC reference (work in progress).
This header contains a list of diverting URIs and associated
information providing specific information as the reason for the call
diversion. Most of existing SIP-based implementations have
implemented the Diversion header when no standard solution was ready
to deploye. The IETF has finally standardized the History-Info
header partly because it can transport general history information.
This allows the receiving part to determine how and why the session
is received. As the History-Info header may contain further
information than call diversion information, it is critical to avoid
losing information and be able to extract the relevant data using the
retargeting cause URI parameter described in [RFC4458] for the
Mohali Expires August 6, 2010 [Page 4]
Internet-Draft Mapping Diversion and History-Info February 2010
transport of the diversion reason.
The Diversion header and the History-Info header have different
syntaxes described below. Note that the main difference is that the
History-Info header is a chronological writing header whereas the
Diversion header applies a reverse chronology (i.e. the first
diversion entry read corresponds to the last diverting user).
The Appendix A provides an interworking guideline between the
Diversion header and the Voicemail URI which is another way to convey
diversion information. The Voicemail URI is defined in [RFC4458].
2. Problem Statement
2.1. Interworking requirements and scope
This section provides the baseline terminology used in the rest of
the document and defines the scope of interworking between the
Diversion header and the History-Info header.
They are many ways in which SIP signaling can be used to modify a
session destination before it is established and many reasons for
doing so. The behavior of the SIP entities that will have to further
process the session downstream will sometimes vary depending on the
reasons that lead to changing the destination. For example, whether
it is for a simple proxy to route the session or for an application
server to provide a supplementary service. The Diversion header and
the History-Info header differ in the approach and scope of
addressing this problem.
For clarity, the following vocabulary is used in this document:
o Retargeting/redirecting: retargeting/redirecting refer to the
process of a Proxy Server/User Agent Client (UAC) changing a
Uniform Resource Identifier (URI) in a request and thus changing
the target of the request. These terms are defined in [RFC4244].
The History-Info header is used to capture retargeting
information.
o Call forwarding/call diversion/communication diversion: these
terms are equivalent and refer to the Communications Diversion
(CDIV) supplementary services, based on the ISDN Communication
diversion supplementary services and defined in 3GPP [TS_24.604].
They are applicable to entities which are intended to modify the
original destination of an IP multimedia session during or prior
Mohali Expires August 6, 2010 [Page 5]
Internet-Draft Mapping Diversion and History-Info February 2010
to the session establishment.
This document does not intend to describe when or how History-Info or
Diversion headers should be used. Hereafter is provided
clarification on the context in which the interworking is required.
The Diversion header has exactly the same scope as the call diversion
service and each header entry reflects a call diversion invocation.
The Diversion header is used for recording call forwarding
information which could be useful to network entities downstream.
Today, this SIP header is implemented by several manufacturers and
deployed in networks.
The History-Info header is used to store all retargeting information
including call diversion information. In practice, the History-Info
header [RFC4244] is used to convey call diversion related information
by using a cause URI parameter [RFC4458] in the relevant entry.
Note, however, that the use of cause URI parameter [RFC4458] in a
History-Info entry for a call diversion is specific to the 3GPP
specification [TS_24.604]. [RFC4458] focuses on retargeting toward
voicemail server and does not specify whether the cause URI parameter
should be added in a URI for other cases. As a consequence,
implementations that do not use the cause URI parameter for call
forwarding information, are not considered for the mapping described
in this document. Nevertheless, some recommendations are given in
the next sections on how to avoid the loss of non-mapped information
at the boundary between a network region using History-Info header
and one using the Diversion header.
Since both headers address call forwarding needs, diverting
information could be mixed-up or be inconsistent if both are present
in an uncoordinated fashion in the INVITE request. So, Diversion and
History-Info headers must not independently coexist in the same
session signaling. This document addresses how to convert
information between the Diversion header and the History-Info header,
and when and how to preserve both headers to cover additional cases.
For the transportation of consistent diversion information
downstream, it is necessary to make the two headers interwork.
Interworking between the Diversion header and the History-Info header
is introduced in sections 5 and 6. Since coexistence scenario may
vary from one use case to another one, guidelines regarding headers
interaction are proposed.
Mohali Expires August 6, 2010 [Page 6]
Internet-Draft Mapping Diversion and History-Info February 2010
2.2. Interworking recommendations
Interworking function:
In a normal case, the network topology assumption is that the
interworking described in this document should be performed by a
specific SIP border device which is aware, by configuration, that
it is at the border between two regions, one using History-Info
header and one using Diversion header.
As History-Info header is a standard solution, a network using the
Diversion header must be able to provide information to a network
using the History-Info header. In this case, to avoid headers
coexistence it is recommended to replace, as often as possible, the
Diversion header with the History-Info header in the INVITE request
during the interworking.
Since, the History-Info header has a wider scope than the Diversion
header, it may be used for other needs and services than call
diversion. In addition to trace call diversion information, History-
Info header also acts as a session history and can store all
successive R-URI values. Consequently, even if it should be better
to remove the History-Info header after the creation of the Diversion
header avoiding confusion, the History-Info header must remain
unmodified in the SIP signaling if it contains supplementary (non-
diversion) information. It is possible to have History-Info headers
that do not have values that can be mapped into the Diversion header.
In this case, no interworking with Diversion header should be
performed and it must be defined per implementation what to do in
this case. This point is left out of the scope of this document.
As a conclusion, it is recommended to have local policies minimizing
the loss of information and find the best way to keep it up to the
terminating user agent.
The following sections describe the basic common use case.
Additional interworking cases are described in section 7.5.
2.2.1. SIP network/terminal using Diversion to SIP network/terminal
using History-Info header
When the Diversion header is used to create a History-Info header,
the Diversion header must be removed in the outgoing INVITE. It is
considered that all the information present in the Diversion header
is transferred in the History-Info header.
Mohali Expires August 6, 2010 [Page 7]
Internet-Draft Mapping Diversion and History-Info February 2010
If a History-Info header is present in the incoming INVITE (in
addition to Diversion header), the Diversion header and History-Info
header present must be mixed and only the diversion information not
yet present in the History-Info header must be inserted as a last
entry (more recent) in the existing History-Info header, as
recommended in [RFC4244].
As an example, this could be the case of an INVITE coming from
network_2 using Diversion header but previously passed through
network_1 using History-Info header (or the network_2 uses History-
Info header to transport successive URI information) and going to
network_3 using History-Info header.
IWF* IWF*
network1 | network_2 |network_3
History-Info | Diversion |using
| |Hist-Info
| |
UA A P1 AS B | P2 AS C UA C AS D | UA E
| | | | | | | | | |
|INVITE | | | | | | | | |
|------>| | | | | | | | |
| | | | | | | | | |
| |INVITE | | | | | | | |
| |------>| | | | | | | |
| |Supported: histinfo | | | | | |
| | History-Info: | | | | | |
| | <sip:proxyP1>; index=1, | | | | |
| | <sip:userB >; index=1.1 | | | | |
| | | | | | | | | |
| | |INVITE | | | | | | |
| | |------>| | | | | | |
| | |History-Info: | | | | | |
| | |<sip:proxyP1>; index=1,| | | | |
| | |<sip:userB>; index=1.1 | | | | |
| | |<sip:userC>; cause=302; index=1.1.1 | | |
In this case, the incoming INVITE contains a Diversion header and a
History-Info header. Therefore, as recommended in this document, it
is necessary to create for network_3, a single History-Info header
gathering existing information from both the History-Info and the
Diversion headers received. Then network_3 could use call forwarding
information that is present in a single header and add its own
diversion information if necessary.
Mohali Expires August 6, 2010 [Page 8]
Internet-Draft Mapping Diversion and History-Info February 2010
Notes:
1. If a network is not able either to use only one header each time,
or to maintain both headers up to date, the chronological order
can not be certified.
2. It is not possible to have only Diversion header when the
History-Info header contains more than call diversion
information. If previous policy recommendations are applied, the
chronological order is respected as Diversion entries are
inserted at the end of the History-Info header taking into
account the Diversion internal chronology.
2.2.2. SIP network/terminal using History-Info header to SIP network/
terminal using Diversion header
When the History-Info header is interpreted to create a Diversion
header, some precautions must be taken.
If the History-Info header contains only call forwarding information,
then it must be deleted after the interworking.
If the History-Info header contains other information, then only the
information of concern to the diverting user must be used to create
entries in the Diversion header and the History-Info header must be
kept as received in the INVITE and forwarded downstream.
Note: The History-Info header could be used for other reasons than
call diversion services, for example by a service which need to know
if a specific AS had yet been invoked in the signaling path. If the
call is later forwarded to a network using History-Info header, it
would be better to not lose history information due to passing though
the network which only support Diversion header. A recommended
solution must not disrupt the standard behavior and networks which do
not implement the History-Info header must be transparent to a
received History-Info header.
If a Diversion header is present in the incoming INVITE (in addition
to History-Info header), only diversion information present in the
History-Info header but not in the Diversion header must be inserted
from the last entry (more recent) into the existing Diversion header
as recommended in the[draft-levy-sip-diversion-11].
Note to the RFC-Editor: The reference to this draft should be
replaced by the Historic RFC reference (work in progress).
Note that the chronological order could not be certified. If
previous policy recommendations are respected, this case should not
happen.
Mohali Expires August 6, 2010 [Page 9]
Internet-Draft Mapping Diversion and History-Info February 2010
Forking case:
The History-Info header enables the recording of sequential
forking for the same served-user. During an interworking, from
the History-Info header to Diversion header, the History-Info
entries containing a forking situation (with an incremented
"index" parameter) could possibly be mapped if it contains a call
forwarding "cause" parameter. The interworking entity could
choose to create only a Diversion entry or not apply the
interworking. The choice could be done according a local policy.
The same logic is applied for an interworking with Voicemail URI (see
the Appendix).
3. Headers syntaxes reminder
3.1. History-Info header syntax
History-Info = "History-Info" HCOLON hi-entry *(COMMA hi-entry)
hi-entry = hi-targeted-to-uri *( SEMI hi-param )
hi-targeted-to-uri = name-addr
hi-param = hi-index / hi-extension
hi-index = "index" EQUAL 1*DIGIT *(DOT 1*DIGIT)
hi-extension = generic-param
The History-Info header is specified in [RFC4244].
The top-most History-Info entry (first in the list) corresponds to
the oldest history information.
A hi-entry may contain a cause URI parameter expressing the diversion
reason. This optional cause URI parameter is defined in [RFC4458]
with the following syntax:
cause-param = "cause" EQUAL Status-Code.
This parameter is also named cause-param and should be inserted in
the History-Info entry (URI) of the diverted-to user in case of call
diversion as recommended in the 3GPP CDIV specification [TS_24.604].
The cause values used in the cause-param for the diverting reason are
listed in the RFC and because it is a parameter dedicated to call
forwarding service, its presence is used to determine that a hi-entry
is a diverting user. More precisely, each diverting user is located
Mohali Expires August 6, 2010 [Page 10]
Internet-Draft Mapping Diversion and History-Info February 2010
in the hi-entry before the one containing a cause-param with cause
value as listed in RFC 4458.
Moreover, the Reason header defined in [RFC3326] should be escaped in
the hi-entry of the diverting user when the call diversion is due to
a received SIP response. The Reason header contains a cause
parameter set to the true SIP response code received (Status-Code).
Therefore, in case of call diversion due to a SIP response, both
cause parameters should be used. The complexity is that these
parameters could be used at the same time in the History-Info header
but not in the same hi-entry and not with the same meaning. Only the
cause-param is dedicated to call diversion service. The 'cause'
Reason header parameter is not taken into account in the mapping with
a Diversion header.
The [RFC4458] also defines the 'target' URI parameter which could be
inserted in a R-URI and consequently in the hi-targeted-to-uri. This
parameter is used to keep the diverting user address in the
downstream INVITE request in Voicemail URI implementation. As this
information is already present in the hi-entries, the 'target' URI
parameter is not taken into account regarding the interworking with
the Diversion header. From the Diversion header, it could be
possible to create the 'target' URI parameter in the hi-entries
and/or in the R-URI but this possibility is based on local policies
not described in this document.
A Privacy header as defined in [RFC3323] could also be included in
hi-entries with the 'history' value defined in the [RFC4244].
The index parameter is a string of digits, separated by dots to
indicate the number of forward hops and retargets.
Note: A history entry could contain the "gr" parameter. Regardless
the rules concerning "gr" parameter defined in [TS_24.604] which must
be applied, this parameter has no impact on the mapping and must only
be copied with the served user address.
Example:
History-Info:
<sip: diverting_user1_addr?Privacy=none?Reason=SIP%3Bcause%
3D302>;index=1,
<sip: diverting_user2_addr;cause=480?Privacy=history>;index=1.1,
<sip:last_diversion_target;cause=486>; index=1.1.1,
Policy concerning "histinfo" option tag in Supported header:
Mohali Expires August 6, 2010 [Page 11]
Internet-Draft Mapping Diversion and History-Info February 2010
According to [RFC4244], a proxy that receives a Request with the
"histinfo" option tag in the Supported header should return captured
History-Info in subsequent, provisional and final responses to the
Request. The behavior depends upon whether the local policy supports
the capture of History-Info or not.
3.2. Diversion header syntax
The current document is not written to define again the Diversion
header and its use but to be sure that the syntax is interpreted in
the same way by everyone. So that, the Diversion syntax is slightly
modified here to correspond to the current ABNF [RFC5234]:
Diversion = "Diversion" HCOLON diversion-params
*(COMMA diversion-params)
diversion-params = name-addr *(SEMI (diversion-reason /
diversion-counter / diversion-limit /
diversion-privacy / diversion-screen /
diversion-extension))
diversion-reason = "reason" EQUAL ("unknown" / "user-busy" /
"no-answer" / "unavailable" / "unconditional"
/ "time-of-day" / "do-not-disturb" /
"deflection" / "follow-me" / "out-of-service"
/ "away" / token / quoted-string)
diversion-counter = "counter" EQUAL 1*2DIGIT
diversion-limit = "limit" EQUAL 1*2DIGIT
diversion-privacy = "privacy" EQUAL ("full" / "name" / "uri" /
"off" / token / quoted-string)
diversion-screen = "screen" EQUAL ("yes" / "no" / token /
quoted-string)
diversion-extension = token [EQUAL (token / quoted-string)]
Note: The Diversion header could be used in the comma-separated
format as described below and in a header-separated format. Both
formats could be combined a received INVITE as recommended in
[RFC3261].
Example:
Diversion:
Mohali Expires August 6, 2010 [Page 12]
Internet-Draft Mapping Diversion and History-Info February 2010
diverting_user2_addr; reason="user-busy"; counter=1; privacy=full,
diverting_user1_addr; reason="unconditional"; counter=1;
privacy=off
4. Headers in SIP Method
You can find here a reminder of History-Info header field and
Diversion header field in relation to methods. As those headers do
not have the same capabilities, it is necessary to clarify the
interworking.
Use of History-Info header field:
Header field where proxy ACK BYE CAN INV OPT REG MSG
------------ ----- ----- --- --- --- --- --- --- ---
History-Info amdr - - - o o o o
SUB NOT REF INF UPD PRA PUB
--- --- --- --- --- --- ---
History-Info amdr o o o - - - o
Use of Diversion header field:
Header field where enc. e-e ACK BYE CAN INV OPT REG
------------ ----- ----- --- --- --- --- --- --- ---
Diversion R h - - - o - -
Diversion 3xx h - - - o - -
The recommended interworking presented in this document should apply
only for INVITE requests.
In 3xx responses, both headers could be present.
When a proxy wants to interwork with a network supporting the other
header field, it should apply the interworking between Diversion
header and History-Info header in the 3xx response.
When a recursing proxy redirects an initial INVITE after receiving a
3xx response, it should add as a last entry either a Diversion header
or History-Info header (according to its capabilities) in the
forwarded INVITE. Local policies could apply to send the received
header in the next INVITE or not.
Other messages where History-Info could be present are not used for
the Call Forwarding service and should not be changed into Diversion
header. The destination network must be transparent to the received
Mohali Expires August 6, 2010 [Page 13]
Internet-Draft Mapping Diversion and History-Info February 2010
History-Info header.
Note : the following mapping is inspired from the ISUP to SIP
interworking described in [TS_29.163].
5. Diversion header to History-Info header
The following text is valid only if no History-Info is present in the
INVITE request. If at least one History-Info header is present, the
interworking function must adapt its behavior to respect the
chronological order. See section 2.2.
For N Diversion entries N+1 History-Info entries must be created. To
create the History-Info entries in the same order than during a
session establishment, the Diversion entries must be mapped from the
bottom-most until the top-most. Each Diversion entry shall be mapped
into a History-Info entry. An additional History-Info entry (the
last one) must be created with the diverted-to party address present
in the R-URI of the received INVITE. The mapping is described below.
The first entry created in the History-Info header contains:
- a hi-target-to-uri with the name-addr parameter of the bottom-
most Diversion header
- if a privacy parameter is present in the bottom-most Diversion
entry, then a Privacy header could be escaped in the History-Info
header as described below,
- an index set to 1.
For each following Diversion entry (from bottom to top), the History-
info entries are created as following (from top to bottom):
Mohali Expires August 6, 2010 [Page 14]
Internet-Draft Mapping Diversion and History-Info February 2010
Source Destination
Diversion header component: History-Info header component:
=======================================================================
Name-addr Hi-target-to-uri
=======================================================================
Reason of the previous cause-param (not present in
Diversion entry the first created hi-entry)
"unknown"---------------------------------404 (default 'cause' value)
"unconditional"---------------------------302
"user-busy"-------------------------------486
"no-answer"-------------------------------408
"deflection "-----------------------------480 or 487
"unavailable"-----------------------------404
"time-of-day"-----------------------------404 (default)
"do-not-disturb"--------------------------404 (default)
"follow-me"-------------------------------404 (default)
"out-of-service"--------------------------404 (default)
"away"------------------------------------404 (default)
=======================================================================
Counter Hi-index
"1" or parameter -------------------------The previous created index
no present is incremented with ".1"
Superior to "1" --------------------------Create N-1 placeholder History
(i.e. N) entry with the previous index
incremented with ".1"
Then the History-Info header
created with the Diversion
entry with the previous index
incremented with ".1"
=======================================================================
Privacy Privacy header escaped in the
hi-targeted-to-uri
"full"------------------------------------"history"
"Off"-------------------------------------Privacy header field
absent or "none"
"name"------------------------------------"history"
"uri"-------------------------------------"history"
=======================================================================
A last History-Info entry is created and contains:
- a hi-target-to-uri with the Request-URI of the INVITE request.
- a cause-param from the top-most Diversion entry, mapped from the
diversion-reason as described above.
Mohali Expires August 6, 2010 [Page 15]
Internet-Draft Mapping Diversion and History-Info February 2010
- if a privacy parameter is present in the top-most Diversion
entry, then a Privacy header could be escaped in the History-Info
header as described above,
- an index set to the previous created index and incremented with
".1"
Notes:
1. For other optional Diversion parameters, there is no
recommendation as History-Info header does not provide equivalent
parameters.
2. For values of the diversion-reason values which are mapped with a
recommended default value, it could also be possible to choose
another value. The cause-param URI parameter offers less
possible values than the diversion-reason parameter. However, it
has been considered that cause-param values list was sufficient
to implement CDIV service as defined in 3GPP[TS_24.604] as it
cover a large portion of cases.
3. The Diversion header could contain a Tel:URI in the name-addr
parameter but it seems not possible to have a Tel:URI in the
History-Info header. [RFC3261] gives an indication as to the
mapping between sip: and tel: URIs but in this particular case it
is difficult to assign a valid hostport as the diversion has
occurred in a previous network and a valid hostport is difficult
to determine. So, it is suggested that in case of Tel:URI in the
Diversion header, the History-Info header should be created with
a SIP URI with user=phone.
4. The Diversion header allows the carrying of a counter that
retains the information about the number of successive
redirections. History-Info does not have an equivalent because
to trace and count the number of diversion it is necessary to
count cause parameter containing a value associated to a call
diversion. Read the index value is not enough. With the use of
the "placeholder" entry the History-info header entries could
reflect the real number of diversion occurred.
Example of placeholder entry in the History-Info header:
<sip:unknown@unknown.invalid;cause=xxx>;index=1.1
Mohali Expires August 6, 2010 [Page 16]
Internet-Draft Mapping Diversion and History-Info February 2010
<sip:bob_addr;cause=404>;index=1.1.1
"cause=xxx" reflects the diverting reason of a previous diverting
user. For a placeholder hi-entry the value "404" must be taken for
the cause-param and so, located in the next hi-entry.
Concerning local policies recommendations about headers coexistence
in the INVITE request, see sections 2.2 and 7.5.
6. History-Info header to Diversion header
To create the Diversion entries in the same order than during a
session establishment, the History-Info entries must be mapped from
the top-most until the bottom-most. The first History-Info header
entry selected will be mapped into the last Diversion header entry
and so on. One Diversion header entry must be created for each
History-Info entry with a cause-param reflecting a diverting reason
as listed in the [RFC4458].
In this case, the History-Info header must be mapped into the
Diversion header as following:
Mohali Expires August 6, 2010 [Page 17]
Internet-Draft Mapping Diversion and History-Info February 2010
Source Destination
History-Info header component: Diversion header component:
=====================================================================
Hi-target-to-uri of the Name-addr
History-Info which precedes the one
containing a diverting cause-param
=====================================================================
Cause-param Reason
404---------------------------------------"unknown" (default value)
302---------------------------------------"unconditional"
486---------------------------------------"user-busy"
408---------------------------------------"no-answer"
480 or 487--------------------------------"deflection "
503---------------------------------------"unavailable"
=====================================================================
Hi-index Counter
Mandatory parameter for--------------------The counter is set to "1".
History-Info reflecting
the chronological order
of the information.
=====================================================================
Privacy header [RFC3323]escaped in the Privacy
hi-targeted-to-uri of the
History-Info which precedes the one
containing a diverting cause-param.
Optional parameter for History-Info,
this Privacy indicates that this
specific History-Info header should
not be forwarded.
"history"----------------------------------"full"
Privacy header field ----------------------"Off"
Absent or "none"
=====================================================================
Note: For other optional History-Info parameters, there is no
recommendation as Diversion header does not provide equivalent
parameters.
Concerning local policies recommendations about headers coexistence
in the INVITE request, see section 2.2.
Mohali Expires August 6, 2010 [Page 18]
Internet-Draft Mapping Diversion and History-Info February 2010
7. Examples
7.1. Example with Diversion header changed into History-Info header
INVITE last_diverting_target
Diversion:
diverting_user3_address;reason=unconditional;counter=1;privacy=off,
diverting_user2_address;reason=user-busy;counter=1;privacy=full,
diverting_user1_address;reason=no-answer;counter=1;privacy=off
Mapped into:
History-Info:
<sip: diverting_user1_address; privacy=none >; index=1,
<sip: diverting_user2_address; cause=408?privacy=history>;index=1.1,
<sip: diverting_user3_address; cause=486?privacy=none>;index=1.1.1,
<sip: last_diverting_target; cause=302>;index=1.1.1.1,
7.2. Example with History-Info header changed into Diversion header
History-Info:
<sip: diverting_user1_address?privacy=history >; index=1,
<sip: diverting_user2_address; cause=302? privacy=none>;index=1.1,
<sip: last_diverting_target; cause=486>;index=1.1.1
Mapped into:
Diversion:
diverting_user2_address; reason=user-busy; counter=1; privacy=off,
diverting_user1_address; reason=unconditional; counter=1;
privacy=full
7.3. Example with two SIP networks using History-Info header
interworking with a SIP network using Diversion header
A -> P1 -> B -> C -> P2 -> D-> E
A, B, C, D and E are users.
B, C and D have Call Forwarding service invoked.
P1 and P2 are proxies.
Only relevant information is shown on the following call flow.
IWF* IWF*
SIP network using | SIP network using |SIP net.
History-Info | Diversion |using
| |Hist-Info
| |
Mohali Expires August 6, 2010 [Page 19]
Internet-Draft Mapping Diversion and History-Info February 2010
UA A P1 AS B | P2 AS C UA C AS D | UA E
| | | | | | | | | |
|INV B | | | | | | | | |
|------>| | | | | | | | |
| | | | | | | | | |
| |INV B | | | | | | | |
| |------>| | | | | | | |
| |Supported: histinfo | | | | | |
| | History-Info: | | | | | |
| | <sip:proxyP1>; index=1, | | | | |
| | <sip:userB >; index=1.1 | | | | |
| | | | | | | | | |
| | |INV C | | | | | | |
| | |------>| | | | | | |
| | |History-Info: | | | | | |
| | |<sip:proxyP1>; index=1,| | | | |
| | |<sip:userB>; index=1.1 | | | | |
| | |<sip:userC; cause=302>; index=1.1.1 | | |
| | | | | | | | | |
| | | |INV C | | | | | |
| | | |------>| | | | | |
| | | |Diversion: | | | | |
| | | |B reason= unconditional counter=1 | |
| | | |History-Info: | | | | |
| | | |<sip:proxyP1>; index=1,| | | |
| | | |<sip:userB>; index=1.1 | | | |
| | | |<sip:proxyP2; cause=302>; index=1.1.1| |
| | | | | | | | | |
| | | | |INV C | | | | |
| | | | |------>| | | | |
| | | | |No modification of Diversion due to P2|
| | | | | | | | | |
| | | | | |INV C | | | |
| | | | | |------>| | | |
| | | | | | | | | |
| | | | | |<--180-| | | |
| | | | | | | | | |
| | | | | No response timer expire | |
| | | | | |---INV D --->| | |
| | | Diversion: | | |
| | | userC; reason=no-answer; counter=1; privacy=full,
| | | userB; reason=unconditional; counter=1; privacy=off,
| | | History-Info: | | |
| | | <sip:proxyP1>; index=1, | | |
| | | <sip:userB>; index=1.1 | | |
| | | <sip:proxyP2; cause=302>; index=1.1.1 | |
| | | | | | | | | |
| | | | | | | |INV E | |
Mohali Expires August 6, 2010 [Page 20]
Internet-Draft Mapping Diversion and History-Info February 2010
| | | | | | | |------>| |
| | | Diversion: | |
| | | userD; reason=time-of-day; counter=1; privacy=off|
| | | userC; reason=no-answer; counter=1; privacy=full,|
| | | userB; reason=unconditional; counter=1; privacy=off,
| | | History-Info: | |
| | | <sip:proxyP1>; index=1, | |
| | | <sip:userB>; index=1.1 | |
| | | <sip:proxyP2; cause=302>; index=1.1.1 | |
| | | | | | | | | |
| | | | | | | | | INV E |
| | | | | | | | |------->|
| | | History-Info: |
| | | <sip:proxyP1>; index=1, |
| | | <sip:userB ?privacy=none>; index=1.1, |
| | | <sip:proxyP2; cause=302>; index=1.1.1, |
| | | <sip:userC ?privacy=history>; index=1.1.1.1, |
| | | <sip:userD; cause=408 ?privacy=none>; index=1.1.1.1.1,
| | | <sip:userE; cause=404>; index=1.1.1.1.1.1 |
| | | | | | | | | |
| | | | | | | | | |
* Note: The IWF is an interworking function which could be a stand-alone
equipment not defined in this document (it could be a proxy).
7.4. Additional interworking Cases
Even if for particular cases in which both headers could coexist, it
should be the network local policy responsibility to make it work
together. Here are described some situations and some
recommendations on the behavior to follow.
In the case where there is one network which includes different
nodes, some of them supporting Diversion header and other ones
supporting History-info header, there is a problem when any node
handling a message does not know the next node that will handle the
message. This case can occur when the network has new and old nodes,
the older ones using Diversion header and the more recent History-
Info header.
While a network replacement may be occurring there will be a time
when both nodes coexist in the network. If the different nodes are
being used to support different subscriber types due to different
node capabilities then the problem is more important. In this case
there is a need to pass both History-Info header and Diversion header
within the core network.
These headers need to be equivalent to ensure that, whatever the node
receiving the message, the correct diversion information is received.
This requires that whatever the received header, there is a
Mohali Expires August 6, 2010 [Page 21]
Internet-Draft Mapping Diversion and History-Info February 2010
requirement to be able to compare the headers and to convert the
headers. Depending upon the node capability, it may be possible to
make assumptions as to how this is handled.
If it is known that the older Diversion header supporting nodes do
not pass on any received History-Info header then the interworking
becomes easier. If a message is received with only Diversion headers
then it has originated from an 'old' node. The equivalent History-
Info entries can be created and these can then be passed as well as
the Diversion header.
If the node creates a new History-Info header for a call diversion,
then an additional Diversion header must be created.
If the next node is an 'old' node then the Diversion header will be
used by that node and the History-Info entries will be removed from
the message when it is passed on.
If the next node is a new node then the presence of both Diversion
header and History-Info header means that interworking has already
occurred and the Diversion and History-Info entries must be
considered equivalent.
If both nodes pass on both History-Info header and Diversion header
but only actively use one, then both types of node need to perform
the interworking and must maintain equivalence between the headers.
This will eventually result in the use of Diversion header being
deprecated when all nodes in the network support History-Info header.
8. IANA Considerations
This document makes no request of IANA.
9. Security Considerations
The use of Diversion header or History-Info header require to apply
the requested privacy and integrity asked by each diverting user or
entity. Without integrity, the requested privacy functions could be
downgraded or eliminated, potentially exposing identity information.
Without confidentiality, eavesdroppers on the network (or any
intermediaries between the user and the privacy service) could see
the very personal information that the user has asked the privacy
service to obscure. Unauthorised insertion, deletion of modification
of those headers can provide misleading information to users and
applications. A SIP entity that can provide a redirection reason in
a History-Info header or Diversion header should be able to suppress
this in accordance with privacy requirements of the user concerned.
Mohali Expires August 6, 2010 [Page 22]
Internet-Draft Mapping Diversion and History-Info February 2010
10. Acknowlegements
The editor would like to acknowledge the constructive feedback and
support provided by Steve Norreys, Jan Van Geel, Martin Dolly,
Francisco Silva, Guiseppe Sciortino, Cinza Amenta, Christer Holmberg,
Ian Elz, Jean-Francois Mule, Mary Barnes, Francois Audet, Erick
Sasaki, Shida Schubert, Joel M. Halpern and Bob Braden. Merci a
Lionel Morand, Xavier Marjou and Philippe Fouquart.
11. References
11.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.
[RFC3326] "The Reason Header Field for the Session Initiation
Protocol (SIP)", RFC 3326, December 2002.
[RFC4244] "An Extension to the Session Initiation Protocol (SIP) for
Request History Information", RFC 4244, November 2005.
[draft-levy-sip-diversion-11]
"Diversion Indication in SIP,
draft-levy-sip-diversion-11", February 2010.
11.2. Informative References
[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.
[TS_24.604]
3rd Generation Partnership Project, "Technical
Specification Group Core Network and Terminals ;
Communication Diversion (CDIV) using IP Multimedia
(IM)Core Network (CN) subsystem ; Protocol specification
(Release 8), 3GPP TS 24.604", December 2008.
[TS_29.163]
3rd Generation Partnership Project, "Technical
Specification Group Core Network and Terminals ;
Mohali Expires August 6, 2010 [Page 23]
Internet-Draft Mapping Diversion and History-Info February 2010
Interworking between the IP Multimedia (IM) Core Network
(CN) Subsystem and Circuit Switched (CS) networks (Release
8)", December 2008.
Appendix A. Interworking between Diversion header and Voicemail URI
Voicemail URI is a mechanism described in RFC4458 to provide a simple
way to transport only one redirecting user address and the reason why
the diversion occurred in the R-URI of the INVITE request. This
mechanism is mainly used for call diversion to a voicemail.
Diversion header to Voicemail URI:
Received:
Diversion: userA-address;reason=user-busy;counter=1;privacy=full
Sent (Voicemail URI created in the R-URI line of the INVITE):
sip: voicemail@example.com;target=userA-address;cause=486 SIP/2.0
Mapping of the Redirection Reason is the same as for History-Info
header with a default value set to 404.
If the Diversion header contains more than one Diversion entry, the
choice of the redirecting user information inserted in the URI is in
charge of the network local policy. For example, the choice
criterion of the redirecting information inserted in the URI could be
the destination of forwarded INVITE request (if the voicemail serves
this user or not).
Note: This interworking could be done in addition to the interworking
of the Diversion header into the History-Info header.
Voicemail URI to Diversion header:
In case of real Voicemail, this way of interworking should not
happen. However, if for any reason it occurs, it is recommended to
do it as following:
Received:
INVITE sip: voicemail@example.com;\
target=sip:+33145454500%40example.com;user=phone;\
cause=302 SIP/2.0
Sent in the forwarded INVITE:
Diversion: sip:+
33145454500%40example.com;user=phone;reason=unconditional;counter=1
Mohali Expires August 6, 2010 [Page 24]
Internet-Draft Mapping Diversion and History-Info February 2010
Author's Address
Marianne Mohali
Orange Labs
38-40 rue du General Leclerc
Issy-Les-Moulineaux Cedex 9 92794
France
Phone: +33 1 45 29 45 14
Email: marianne.mohali@orange-ftgroup.com
Mohali Expires August 6, 2010 [Page 25]