Network Working Group M. Mohali
Internet-Draft France Telecom
Intended status: Informational S. Norreys
Expires: August 16, 2009 British Telecom
J. Van Geel
Belgacom
M. Dolly
ATT
F. Silva
Portugal Telecom
G. Sciortino
C. Amenta
Italtel
C. Holmberg
Ericsson
February 12, 2009
Mapping and interworking of Diversion information Between Diversion and
History-Info Headers in the Session Initiation Protocol (SIP)
draft-mohali-diversion-history-info-02
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.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 16, 2009.
Mohali, et al. Expires August 16, 2009 [Page 1]
Internet-Draft Mapping Diversion and History-Info February 2009
Copyright Notice
Copyright (c) 2009 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.
Abstract
Diversion header is not standardized but widely used to convey
diverting information in Session Initiation Protocol (SIP) signaling.
This informational document proposes a way to make interwork call
diversion information contained in a Diversion header with a History-
Info header or with the Voicemail-URI which are standardized
solutions. In addition, an interworking policy is proposed to manage
the headers coexistence.
The History-Info header is described in [RFC4244] and the Voicemail
URI in [RFC4458].
Since the Diversion header is used in many existing networks
implementations for transport of diversion informationand its
interworking with standardized solutions is not obvious, an
interworking recommendation is needed.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Mohali, et al. Expires August 16, 2009 [Page 2]
Internet-Draft Mapping Diversion and History-Info February 2009
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Background . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Interworking need . . . . . . . . . . . . . . . . . . . . 5
2.2. Interworking recommendations . . . . . . . . . . . . . . . 5
3. Headers syntaxes reminder . . . . . . . . . . . . . . . . . . 8
3.1. History-Info header syntax . . . . . . . . . . . . . . . . 8
3.2. Diversion header syntax . . . . . . . . . . . . . . . . . 9
4. Headers in SIP Method . . . . . . . . . . . . . . . . . . . . 10
5. Diversion header to History-Info header . . . . . . . . . . . 11
6. History-Info header to Diversion header . . . . . . . . . . . 14
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
7.1. Example with Diversion header changed into
History-Info header . . . . . . . . . . . . . . . . . . . 16
7.2. Example with History-Info header changed into
Diversion header . . . . . . . . . . . . . . . . . . . . . 16
7.3. Example with two SIP networks using History-Info
header interworking with a SIP network using Diversion
header . . . . . . . . . . . . . . . . . . . . . . . . . . 16
7.4. Interworking between Diversion header and Voicemail URI . 18
7.5. Additional interworking Cases . . . . . . . . . . . . . . 19
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
9. Security Considerations . . . . . . . . . . . . . . . . . . . 20
10. Acknowlegements . . . . . . . . . . . . . . . . . . . . . . . 20
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
11.1. Normative References . . . . . . . . . . . . . . . . . . . 21
11.2. Informative References . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
Intellectual Property and Copyright Statements . . . . . . . . . . 23
Mohali, et al. Expires August 16, 2009 [Page 3]
Internet-Draft Mapping Diversion and History-Info February 2009
1. Introduction
1.1. Overview
For some network services (eg. Voicemail, IVR or automatic call
distribution), it is necessary for the called SIP user agent to
identify from whom and why the session was diverted. In order to be
used by various service providers or applications, redirection
information needs to pass through the network.
This is possible with two different SIP headers: History-Info
header[RFC4244] and Diversion header which are both able to transport
diversion information in SIP signaling. Because of the current
wildely use of Diversion header even if it is not a standard, it is
necessary to have a guideline to make this header interwork with
History-Info header.
This document provides a mechanism of translation between the
Diversion header and the History-Info header and between the
Diversion header and the Voicemail URI.
1.2. Background
The History-Info header [RFC4244] and a the URI extension (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].
At first, the Diversion header was described in
[draft-levy-sip-diversion-08], which is today discarded. This header
contains the list of the diverting user(s) with associated
information and the expired draft could explain why many
implementations are based on this header. It has been chosen to
standardized the History-Info header because it could transport
"request history" information which allows the receiving application
to determine hints about how and why the session arrived at the
application/user. As History-Info header information is larger than
call diversion information, it is realy important to be sure of not
loosing information and be able to extract the good data with help of
the retargeting cause described in [RFC4458] for the transport of the
diversion reason.
Those headers 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 is the opposite (i.e. the
first diversion entry read correspond to the last diverting user).
Mohali, et al. Expires August 16, 2009 [Page 4]
Internet-Draft Mapping Diversion and History-Info February 2009
2. Problem Statement
2.1. Interworking need
The Diversion header is used for recording communication diversion
information which could be useful to downstream network entities.
Today, this SIP header is implemented by several manufacturers and
deployed in several networks.
The History-Info header is standardized, among other needs, for the
transportation of diversion information.
As both are answering to call forwarding needs, according to the one
created or completed in one side and the one interpreted in the other
side, diverting information could be mixed-up if they are both
present in the INVITE request. So, Diversion and History-Info
headers MUST NOT independently coexist for the session signalling.
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 presented in sections 5 and 6. As the interworking is not obvious
and the coexistence not easy according the use cases, is it proposed
a policy to manage the headers interaction.
In addition, Voicemail URI proposes an other way to convey diversion
information in the R-URI. So, it is also necessary to describe the
interworking between Diversion header and a Voicemail URI. This
interworking is presented in section 7.4.
2.2. Interworking recommendations
History-Info header is a standardized solution, so a network using
the Diversion header MUST be able to provide information at the good
format to a network using the History-Info header. In this case, to
avoid both headers coexistence it is recommended as often as possible
to replace the Diversion header per the History-Info header in the
INVITE request during the interworking.
For some specific interworking situations (see section 7.5), it could
be needed to create a Diversion header from a received History-Info
header. Since, the History-Info header has a boarder scope than the
Diversion header and could be used for other services than call
diversion ; in addition to trace call diversion information, it is
acting as a session history and could store all successive R-URI
values. So, even if it should be better to remove the History-Info
header after the Diversion header has been created to avoid
confusion; if the History-Info header contains supplementary
information it MUST be remained and passed transparently in this
Mohali, et al. Expires August 16, 2009 [Page 5]
Internet-Draft Mapping Diversion and History-Info February 2009
network.
These are the more simple interworking situations where a header is
created from the other one. More interworking cases, like situation
where persistence of both headers is needed, are described in section
7.5.
If some information could be lost and use downstream or according the
header used per network elements, it is necessary to have a local
policy to find the best way to keep information up to the terminating
user agent.
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 information present in the Diversion header is
transferred in the History-Info header.
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 a
network_2 using Diversion header but before passed through a
network_1 using History-Info header (or the network_2 uses History-
Info header to transport successive URI information) and going to a
network_3 using History-Info header.
Mohali, et al. Expires August 16, 2009 [Page 6]
Internet-Draft Mapping Diversion and History-Info February 2009
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. So that, it is necessary to create, for
network_3, a single History-Info header gathering existing
information in the History-Info header received and those present in
the Diversion header. Then network_3 could use call forwarding
information that are present in a single header and add its own
diversion information if necessary.
Note: 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
could not be certified.
Note: 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.
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 communication diversion
information, then it MUST be suppressed after the interworking.
Mohali, et al. Expires August 16, 2009 [Page 7]
Internet-Draft Mapping Diversion and History-Info February 2009
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 forwarded downstream.
Note: The History-Info header could be used for other reasons than
CDIV services, for example by a service which need to know if a
specific AS had yet been invoked in the signalling path. If the call
is after forwarded to a network using History-Info header, it would
be better to not loose history information due to passing though the
network which only support Diversion header. A recommended solution
MUST NOT disrupt the standard behaviour and networks which not
implement History-Info header MUST be transparent to an incoming
History-Info header.
If a Diversion header is already 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 Diversion draft
[draft-levy-sip-diversion-08]. Note that the chronological order
could not be certified. If previous policy recommendations are
respected, this case SHOULD NOT happen.
Forking case:
The History-Info header enables the recording of sequential forking
for the same served-user. During a interworking from the History-
Info header to Diversion header, the History-Info entries containing
a forking situation (with an incremented "index" parameter) could be
either mapped for each entry with a call forwarding "cause"
parameter, the interworking entity could choose to create only one
Diversion entry or to 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
section 7.4).
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)
Mohali, et al. Expires August 16, 2009 [Page 8]
Internet-Draft Mapping Diversion and History-Info February 2009
hi-extension = generic-param
The History-Info header is specified in [RFC4244]. Amongst the
information contained in the header list is the diversion information
with a specific cause code mentioning the diversion reason. These
optional cause codes are defined in [RFC4458]. The RFC4244 contains
a Privacy section introducing the use of Privacy header defined in
[RFC3323] for diversion information. The top-most History-Info entry
(first in the list) corresponds to the oldest history information.
A diverting user information is identifiable by the History-Info
entry containing a cause-param with cause value as listed in
[RFC4458] and by the entry just before. The last diversion target is
identifiable by the last History-Info entries containing a cause-
param with cause value as listed in RFC 4458.
The cause-param is inserted in the hi-targeted-to-uri of the address
were the communication is diverted to. 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 define in which must be applied,
this parameter has no impact on the mapping and must only be copied
with the served user address. [TS_24.604]
Example:
History-Info:
<sip: diverting_user1_addr?Privacy=none >;index=1,
<sip: diverting_user2_addr?Privacy=history;cause=302>;index=1.1,
<sip:last_diversion_target;cause=486>; index=1.1.1,
Policy concerning "histinfo" option tag in Supported header:
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 behaviour depend whether the local policy support 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 shure that the syntax is interpreted in
the same way by everyone. So that, the Diversion syntax is here a
little changed to correspond to the current ABNF[RFC4234]:
Mohali, et al. Expires August 16, 2009 [Page 9]
Internet-Draft Mapping Diversion and History-Info February 2009
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:
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.
Mohali, et al. Expires August 16, 2009 [Page 10]
Internet-Draft Mapping Diversion and History-Info February 2009
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 the received
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 shall adapt its behaviour 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
Mohali, et al. Expires August 16, 2009 [Page 11]
Internet-Draft Mapping Diversion and History-Info February 2009
into a History-Info entry. An additional (the last one) History-Info
entry must be created wiht the diverted-to party address presents 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 bellow,
- 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, et al. Expires August 16, 2009 [Page 12]
Internet-Draft Mapping Diversion and History-Info February 2009
Source Destination
Diversion header component: History-Info header component:
=======================================================================
Name-addr Hi-target-to-uri
=======================================================================
Reason of the previous cause-param
Diversion entry
"unknown"---------------------------------404
"unconditional"---------------------------302
"user-busy"-------------------------------486
"no-answer"-------------------------------408
"deflection "-----------------------------480 or 487
"unavailable"-----------------------------404
"time-of-day"-----------------------------404 (default) or 302
"do-not-disturb"--------------------------404 (default) or 302
"follow-me"-------------------------------404 (default) or 302
"out-of-service"--------------------------404 (default)
"away"------------------------------------404 (default) or 302
=======================================================================
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, et al. Expires August 16, 2009 [Page 13]
Internet-Draft Mapping Diversion and History-Info February 2009
- 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"
Note: For other optional Diversion parameters, there is no
recommendation.
Note: For values of the "reason" parameter which are mapped with a
recommended default value, it could also be possible to choose an
other value or to omit the parameter.
Note : The Diversion header could contain a Tel:URI in the name-addr
parameter but it seems to not be 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.
Note: The Diversion header allows the carrying of a counter which had
retained the information about the number of redirections which have
occurred. History-Info does not have an equivalent because to trace
and count diversion occurred it is necessary to count cause parameter
containing a value associated to a call diversion. To 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=404>;index=1.1 For a
placeholder History entry the value "404" shall be taken.
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].
Mohali, et al. Expires August 16, 2009 [Page 14]
Internet-Draft Mapping Diversion and History-Info February 2009
In this case, the History-Info header MUST be mapped into the
Diversion header as following:
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"
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"
=====================================================================
Concerning local policies recommendations about headers coexistence
in the INVITE request, see section 2.2.
Mohali, et al. Expires August 16, 2009 [Page 15]
Internet-Draft Mapping Diversion and History-Info February 2009
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? privacy=history; cause=408>;index=1.1,
<sip: diverting_user3_address? privacy=none; cause=486>;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? privacy=none; cause=302>;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, et al. Expires August 16, 2009 [Page 16]
Internet-Draft Mapping Diversion and History-Info February 2009
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 | | |
| | | | | | | | | |
| | | |INVITE | | | | | |
| | | |------>| | | | | |
| | | |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| |
| | | | | | | | | |
| | | | |INVITE | | | | |
| | | | |------>| | | | |
| | | | |No modification of Diversion due to P2|
| | | | | | | | | |
| | | | | |INVITE | | | |
| | | | | |------>| | | |
| | | | | | | | | |
| | | | | |<--180-| | | |
| | | | | | | | | |
| | | | | No response timer expire | |
| | | | | |---INVITE--->| | |
| | | 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 | |
| | | | | | | | | |
| | | | | | | |INVITE | |
Mohali, et al. Expires August 16, 2009 [Page 17]
Internet-Draft Mapping Diversion and History-Info February 2009
| | | | | | | |------>| |
| | | 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 | |
| | | | | | | | | |
| | | | | | | | | INVITE |
| | | | | | | | |------->|
| | | History-Info: |
| | | <sip:proxyP1>; index=1, |
| | | <sip:userB>; index=1.1? privacy=none, |
| | | <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 draft (it could be a proxy).
7.4. 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
Mohali, et al. Expires August 16, 2009 [Page 18]
Internet-Draft Mapping Diversion and History-Info February 2009
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
7.5. 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 behaviour to follow.
In the case where there is one network which includes different
nodes, some of which support Diversion header and some which support
History-info header, the problem is when any node handling a message
does not know which node will next 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 exist 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 network core.
These headers need to be equivalent to ensure that whatever node
receives the message the correct diversion information is received.
This requires that whichever header is received there is a
requirement to be able to compare the headers and to convert the
headers. Depending upon node capability then 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
Mohali, et al. Expires August 16, 2009 [Page 19]
Internet-Draft Mapping Diversion and History-Info February 2009
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.
10. Acknowlegements
The editors would like to acknowledge the constructive feedback
provided by Ian Elz, Jean-Francois Mule, Lionel Morand, Xavier
Marjou, Philippe Fouquart, Mary Barnes, Francois Audet, Erick Sasaki
and Shida Schubert.
Mohali, et al. Expires August 16, 2009 [Page 20]
Internet-Draft Mapping Diversion and History-Info February 2009
11. References
11.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), BCP 99", RFC 3969,
December 2004.
[RFC4234] "Augmented BNF for Syntax Specifications: ABNF", RFC 4234,
October 2005.
11.2. Informative References
[RFC4244] "An Extension to the Session Initiation Protocol (SIP) for
Request History Information", RFC 4244, November 2005.
[RFC4458] "Session Initiation Protocol (SIP) URIs for Applications
such as Voicemail and Interactive Voice Response (IVR)",
RFC 4458, April 2006.
[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 ;
Interworking between the IP Multimedia (IM) Core Network
(CN) Subsystem and Circuit Switched (CS) networks (Release
8)", December 2008.
[draft-levy-sip-diversion-08]
"Diversion Indication in SIP,
draft-levy-sip-diversion-08", August 2004.
Mohali, et al. Expires August 16, 2009 [Page 21]
Internet-Draft Mapping Diversion and History-Info February 2009
Authors' Addresses
Marianne Mohali
France Telecom
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
Steve Norreys
British Telecom
Jan Van Geel
Belgacom
Martin Dolly
ATT
Francisco Silva
Portugal Telecom
Guiseppe Sciortino
Italtel
Cinzia Amenta
Italtel
Christer Holmberg
Ericsson
Mohali, et al. Expires August 16, 2009 [Page 22]