Network Working Group M. Mohali
Internet-Draft Orange
Obsoletes: 6044 (if approved) March 04, 2015
Intended status: Informational
Expires: September 5, 2015
Mapping and interworking of Diversion information Between Diversion and
History-Info Headers in the Session Initiation Protocol (SIP)
draft-mohali-rfc6044bis-02
Abstract
Although the SIP History-Info header field is the solution adopted in
IETF, the non-standard Diversion header field is nevertheless already
implemented and used for conveying call diversion related information
in the Session Initiation Protocol (SIP) signaling.
On one hand, the non-standard Diversion header field is described, as
Historic, in [RFC5806]. On the other hand, the History-Info header
field is described in [RFC7044] that obsoletes the original[RFC4244]
describing the History-Info header field. [RFC7044] defines the SIP
header field, History-Info, for capturing the history information in
requests and new SIP header field parameters for the History-Info and
Contact header fields to tag the method by which the target of a
request is determined. [RFC7044] also defines a value for the
Privacy header field that directs the anonymization of values in the
History-Info header field.
Since the Diversion header field is used in existing network
implementations for the transport of call diversion information, its
interworking with the SIP History-Info standardized solution is
needed. This document describes a recommended interworking guideline
between the Diversion header field and the History-Info header field
to handle call diversion information. In addition, an interworking
policy is proposed to manage the headers' coexistence. This work is
intended to enable the migration from non-standard implementations
and deployments toward IETF specification-based implementations and
deployments.
This document obsoletes [RFC6044]that describes the interworking
between the Diversion header field [RFC5806] and the obsoleted
History-Info header field as defined on [RFC4244].
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Mohali Expires September 5, 2015 [Page 1]
Internet-Draft Mapping of Diversion and History-Info March 2015
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 5, 2015.
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Background . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. From RFC4244 to RFC7044 . . . . . . . . . . . . . . . . . 4
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5
3. Interworking recommendations . . . . . . . . . . . . . . . . 7
3.1. General recommendations . . . . . . . . . . . . . . . . . 7
3.2. Privacy considerations . . . . . . . . . . . . . . . . . 7
3.3. Headers in SIP Method . . . . . . . . . . . . . . . . . . 9
3.4. SIP network/terminal using Diversion to SIP
network/terminal using History-Info header . . . . . . . 9
3.5. SIP network/terminal using History-Info header to SIP
network/terminal using Diversion header . . . . . . . . . 11
4. Header fields syntaxes reminder . . . . . . . . . . . . . . . 12
4.1. History-Info header field syntax . . . . . . . . . . . . 12
4.2. Diversion header field syntax . . . . . . . . . . . . . . 15
5. Diversion header to History-Info header . . . . . . . . . . . 15
6. History-Info header to Diversion header . . . . . . . . . . . 19
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 21
7.1. Example with Diversion header changed into History-Info
header . . . . . . . . . . . . . . . . . . . . . . . . . 21
7.2. Example with History-Info header changed into Diversion
Mohali Expires September 5, 2015 [Page 2]
Internet-Draft Mapping of Diversion and History-Info March 2015
header . . . . . . . . . . . . . . . . . . . . . . . . . 21
7.3. Example with two SIP networks using History-Info header
interworking with a SIP network using Diversion header . 21
7.4. Additional interworking Cases . . . . . . . . . . . . . . 23
8. Backward Compatibility . . . . . . . . . . . . . . . . . . . 25
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
10. Security Considerations . . . . . . . . . . . . . . . . . . . 25
11. Acknowlegements . . . . . . . . . . . . . . . . . . . . . . . 25
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
12.1. Normative References . . . . . . . . . . . . . . . . . . 26
12.2. Informative References . . . . . . . . . . . . . . . . . 26
Appendix A. Interworking between Diversion header and Voicemail
URI . . . . . . . . . . . . . . . . . . . . . . . . 27
A.1. Diversion header field to Voicemail URI . . . . . . . . . 27
A.2. Voicemail URI to Diversion header field . . . . . . . . . 27
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 28
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 header fields: History-Info
header field defined in [RFC7044] and the historic Diversion header
field defined in [RFC5806] which are both able to transport diversion
information in the SIP signaling.
Although the Diversion header field is not standardized, it has been
widely implemented. Therefore, it is useful to have guidelines to
make this header field interwork with the standard History-Info
header field.
Note that the new implementation and deployment of the Diversion
header field is strongly discouraged.
This document provides a mechanism for header fields content
translation between the Diversion header field and the History-Info
header field.
1.2. Background
The obsoleted History-Info header field [RFC4244] and its extension
for forming SIP service URIs (including Voicemail URI) [RFC4458] used
to be recommended by IETF to convey redirection information. They
also used to be recommended in the "Communication Diversion (CDIV)
service" 3GPP specification [TS_24.604].
Mohali Expires September 5, 2015 [Page 3]
Internet-Draft Mapping of Diversion and History-Info March 2015
Concerning, the Diversion header field, it was originally described
in an Internet Draft that was submitted to the SIP Working Group and
was finally published as [RFC5806] for the historical record and to
provide a reference for this RFC.
This header field contains a list of diverting URIs and associated
information providing specific information as the reason for the call
diversion. Most of the first SIP-based implementations have
implemented the Diversion header field when no standard solution was
ready to deploy. The IETF has standardized the History-Info header
field 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 field 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
transport of the call forwarding reason.
The Diversion header field and the History-Info header field have
different syntaxes reminded in this document. Note that the main
difference is that the History-Info header field is a chronological
writing header whereas the Diversion header field 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 field and the Voicemail URI which is another way to
convey diversion information without using the History-Info header
field. The Voicemail URI is defined in [RFC4458].
1.3. From RFC4244 to RFC7044
The detail of why and how [RFC4244] has been updated and replaced by
[RFC7044] is provided in section 16 of [RFC7044].
Here are the main changes for the History-Info header field
implementation:
1. Added header field parameters "mp", "rc" and "np" to capture the
specific method by which a target is determined.
2. Added a way to indicate a gap in History-Info by adding a "0" in
the index.
3. To apply privacy, entries are anonymized rather than removed.
4. Many SHOULD are changed into MUST to have a more reliable header.
Mohali Expires September 5, 2015 [Page 4]
Internet-Draft Mapping of Diversion and History-Info March 2015
Backward compatibility aspects are discussed in section 8 of this
document.
2. Problem Statement
This section provides the baseline terminology used in the rest of
the document and defines the scope of interworking between the
Diversion header field and the History-Info header field.
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
field and the History-Info header field differ in the approach and
scope of addressing this problem.
For clarity, the following vocabulary is used in this document:
o Retarget/redirect: these terms refer to the process of a Proxy
Server/User Agent Client (UAC) changing a Request-URI (Section 7.1
of [RFC3261]) in a request and thus changing the target of the
request. This includes changing the Request-URI due to a location
service lookup and redirect processing. This also includes
internal (to a proxy/SIP intermediary) changes of the URI prior to
the forwarding of the request. The retarget term is defined in
[RFC7044].
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
to the session establishment.
This document does not intend to describe when or how History-Info or
Diversion header fields should be used. Hereafter is provided
clarification on the context in which the interworking is required.
The Diversion header field has exactly the same scope as the call
diversion service and each header field entry reflects a call
diversion invocation. The Diversion header field is used for
recording call forwarding information which could be useful to
Mohali Expires September 5, 2015 [Page 5]
Internet-Draft Mapping of Diversion and History-Info March 2015
network entities downstream. Today, this SIP header field is
implemented by several manufacturers and deployed in networks.
The History-Info header field is used to store all retargeting
information including call diversion information. As such, the
History-Info header field [RFC7044] 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
field and one using the Diversion header field.
The [RFC7044] defines three header field parameters, "rc", "mp", and
"np". The header field parameters "rc" and "mp" indicate the
mechanism by which a new target for a request is determined. The
header field "np" reflects that the target has not changed. All
parameters contain an index whose value refers to the hi-index of the
hi-entry with an hi-targeted-to-uri that represents the Request-URI
that was retargeted.
Since both header fields 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 header fields must not independently coexist in the same
session signaling. This document addresses how to convert
information between the Diversion header field and the History-Info
header field, and when and how to preserve both header fields to
cover additional cases.
For the transportation of consistent diversion information
downstream, it is necessary to make the two header fields interwork.
Interworking between the Diversion header field and the History-Info
header field is introduced in sections 5 and 6. Since coexistence
scenario may vary from one use case to another one, guidelines
regarding header fields interaction are proposed in section 3.
Mohali Expires September 5, 2015 [Page 6]
Internet-Draft Mapping of Diversion and History-Info March 2015
3. Interworking recommendations
3.1. General 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 field and one using Diversion header field.
As History-Info header field is a standard solution, a network using
the Diversion header field must be able to provide information to a
network using the History-Info header field. In this case, to avoid
header fields coexistence it is required to replace, as often as
possible, the Diversion header field with the History-Info header
field in the INVITE request during the interworking.
Since, the History-Info header field has a wider scope than the
Diversion header field, it may be used for other needs and services
than call diversion. In addition to trace call diversion
information, History-Info header field also acts as a session history
and can store all successive Request-URI values. Consequently, even
if it should be better to remove the History-Info header field after
the creation of the Diversion header field avoiding confusion, the
History-Info header field must remain unmodified in the SIP signaling
if it contains supplementary (non-diversion) information. It is
possible to have History-Info header fields that do not have values
that can be mapped into the Diversion header field. In this case, no
interworking with Diversion header field 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.
3.2. Privacy considerations
When a SIP message is forwarded to a domain for which the SIP
intermediary is not responsible, a Privacy Service at the boundary of
the domain applies the appropriate privacy based on the value of the
Mohali Expires September 5, 2015 [Page 7]
Internet-Draft Mapping of Diversion and History-Info March 2015
Privacy header field in the message header or in the privacy
parameter within concerned header.
1. For the History-Info header field, it is the "headers" component
of the hi-targeted-to-uri in the individual hi-entries with the
possible priv-value "history".
2. For the Diversion header field, it is the diversion-privacy
parameter "privacy" in each Diversion header field.
o For the History-Info header field, as recommended in [RFC7044]:
- If there is a Privacy header field in the message header of a
request with a priv-value of "header" or "history", then all
the hi-targeted-to-uris (in the hi-entries associated with the
domain for which the SIP intermediary is responsible) are
anonymized by the Privacy Service. The Privacy Service must
change any hi-targeted-to-uri in these hi-entries that have not
been anonymized to the anonymous SIP URI
"anonymous@anonymous.invalid" as recommended in sections
4.1.1.3 and 4.1.1.2 of [RFC3323].
- If there is a Privacy header field in the "headers" component
of a hi-targeted-to-uri with a priv-value of "history", then
all the concerned hi-entries must be anonymized as described
above prior to forwarding.
The Privacy Service must remove the Privacy header field from the
"headers" component of the hi-targeted-to-uris of the concerned
hi-entries and the priv-value of "history" from the Privacy header
field in the message header of the request prior to forwarding.
If there are no remaining priv-values in the Privacy header field,
the Privacy Service must remove the Privacy header field from the
request.
o For the Diversion header field:
- If there is a Privacy header field in the message header of a
request with a priv-value of "header", then all the addresses
in the Diversion header fields (associated with the domain for
which the SIP intermediary is responsible) are anonymized by
the Privacy Service by changing the address to the anonymous
SIP URI "anonymous@anonymous.invalid" as recommended in
sections 4.1.1.3 and 4.1.1.2 of [RFC3323] prior to forwarding.
- For the each Diversion header field or each entry in the
Diversion header field, if there is a diversion-privacy
Mohali Expires September 5, 2015 [Page 8]
Internet-Draft Mapping of Diversion and History-Info March 2015
parameter with a value set to "full", "uri" or "name", then the
concerned Diversion header field address must be anonymized as
described above prior to forwarding.
In the concerned Diversion header field entries, the diversion-
privacy parameter must be removed from the header.
The privacy information interworking as described in sections 5 and 6
must only be considered within a trusted domain that ensure to
correctly apply the privacy requirements.
3.3. Headers in SIP Method
The recommended interworking presented in this document should apply
only for INVITE requests.
In 3xx responses:
Both History-Info and Diversion header fields could be present in
3xx responses.
When a proxy wants to interwork with a network supporting the
other header field, it should apply the interworking between
Diversion header field and History-Info header field 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 field or History-Info header field (according to its
capabilities) in the forwarded INVITE. Local policies could apply
to send the received header field in the next INVITE or not.
In SIP responses other than 100:
All SIP responses where History-Info could be present are not used
for the Call Forwarding service and should not be changed into
Diversion header field. The destination network must be
transparent to the received History-Info header field.
Note: The following mapping is inspired from the ISUP to SIP
interworking described in [TS_29.163].
3.4. SIP network/terminal using Diversion to SIP network/terminal using
History-Info header
When the Diversion header field is used to create a History-Info
header field, the Diversion header field must be removed in the
outgoing INVITE. It is considered that all the information present
in the Diversion header field is transferred in the History-Info
header field.
Mohali Expires September 5, 2015 [Page 9]
Internet-Draft Mapping of Diversion and History-Info March 2015
If a History-Info header field is also present in the incoming INVITE
(in addition to Diversion header field), the Diversion header field
and History-Info header field present must be mixed and only the
diversion information not yet present in the History-Info header
field must be inserted as a last entry (more recent) in the existing
History-Info header field, following the creation process recommended
in [RFC7044].
As an example, this could be the case of an INVITE coming from
network_2 using Diversion header field but previously passed through
network_1 using History-Info header field (or the network_2 uses
History-Info header field to transport successive URI information)
and going to network_3 using History-Info header field.
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;rc=1 | | | | |
| | | | | | | | | |
| | |INVITE | | | | | | |
| | |------>| | | | | | |
| | |History-Info: | | | | | |
| | |<sip:proxyP1>; index=1,| | | | |
| | |<sip:userB>; index=1.1;rc=1, | | | |
| | |<sip:userC; cause=302>; index=1.1.1;mp=1.1 | |
In this case, the incoming INVITE contains a Diversion header field
and a History-Info header field. Therefore, as recommended in this
document, it is necessary to create for network_3, a single History-
Info header field gathering existing information from both the
History-Info and the Diversion header fields received. Anyway, it is
required from network_2 (ie.IWF) to remove the Diversion header field
when the message is going to a network not using the Diversion header
Mohali Expires September 5, 2015 [Page 10]
Internet-Draft Mapping of Diversion and History-Info March 2015
field. Then network_3 could use call forwarding information that is
present in a single header field and add its own diversion
information if necessary.
Notes:
1. If a network is not able either to use only one header field each
time, or to maintain both header fields up to date, the
chronological order can not be certified.
2. It is not possible to have only Diversion header field when the
History-Info header field 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 field taking into
account the Diversion internal chronology.
3.5. SIP network/terminal using History-Info header to SIP network/
terminal using Diversion header
When the History-Info header field is interpreted to create a
Diversion header field, some precautions must be taken.
If the History-Info header field contains only call forwarding
information, then it must be deleted after the interworking.
If the History-Info header field contains other information, then
only the information of concern to the diverting user must be used to
create entries in the Diversion header field and the History-Info
header field must be kept as received in the INVITE and forwarded
downstream.
Note: The History-Info header field 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
field, it would be better not to lose history information due to
passing though the network which only support Diversion header field.
A recommended solution must not disrupt the standard behavior and
networks which do not implement the History-Info header field must be
transparent to a received History-Info header field.
If a Diversion header field is present in the incoming INVITE (in
addition to History-Info header field), only diversion information
present in the History-Info header field but not in the Diversion
header field must be inserted from the last entry (more recent) into
the existing Diversion header field as recommended in the [RFC5806].
Mohali Expires September 5, 2015 [Page 11]
Internet-Draft Mapping of Diversion and History-Info March 2015
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 field enables the recording of sequential
forking for the same served-user. During an interworking, from
the History-Info header field to Diversion header field, 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 A).
4. Header fields syntaxes reminder
4.1. History-Info header field syntax
The ABNF syntax [RFC5234] for the History-Info header field and
header field parameters is as follows:
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-target-param/hi-extension
hi-index = "index" EQUAL index-val
index-val = number *("." number)
number = [ %x31-39 *DIGIT ] DIGIT
hi-target-param = rc-param / mp-param / np-param
rc-param = "rc" EQUAL index-val
mp-param = "mp" EQUAL index-val
np-param = "np" EQUAL index-val
hi-extension = generic-param
The ABNF definitions for "generic-param", "name-addr", "HCOLON",
"COMMA", "SEMI", and "EQUAL" are from[RFC3261].
The History-Info header field is specified in [RFC7044]. The top-
most History-Info entry (first in the list) corresponds to the oldest
history information.
Mohali Expires September 5, 2015 [Page 12]
Internet-Draft Mapping of Diversion and History-Info March 2015
Cause URI parameter:
A hi-entry may contain a cause URI parameter expressing the
diversion reason. This cause URI parameter is defined in
[RFC4458]. The ABNF grammar [RFC5234] for the cause-param
parameter is reminded below as it has been subject to Errata [ID:
1409] in [RFC4458]. The Status-Code is defined in [RFC3261].
cause-param = "cause=" Status-Code
This parameter is also named cause-param is a SIP/SIPS URI
parameter 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
[RFC4458] . 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 in the hi-entry before the one containing a cause-param
with cause value as listed in [RFC4458].
Reason header field:
Moreover, the Reason header field 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
field 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 field 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 field parameter is not taken
into account in the mapping with a Diversion header field.
Target URI parameter:
The [RFC4458] also defines the 'target' URI parameter which could
be inserted in a Request-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 field. From the Diversion
header field, it could be possible to create the 'target' URI
parameter in the hi-entries and/or in the Request-URI but this
Mohali Expires September 5, 2015 [Page 13]
Internet-Draft Mapping of Diversion and History-Info March 2015
possibility is based on local policies not described in this
document.
Privacy header field:
A Privacy header field as defined in [RFC3323] could also be
embeded in hi-entries with the 'history' value defined in
[RFC7044].
Index header field parameter:
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.
Missing entry:
If the request clearly has a gap in the hi-entry (i.e., the last
hi-entry and Request-URI differ), the entity adding an hi-entry
must add a single index with a value of "0" (i.e., the nonnegative
integer zero) prior to adding the appropriate index for the action
to be taken (eg. Index=1.1.2.0.1). Prior to any application
usage of the History-Info header field parameters, the SIP entity
that processes the hi-entries must evaluate the hi-entries and
determine if there are any gaps in the hi-entries.
"histinfo" option tag:
According to [RFC7044], a proxy that receives a Request with the
"histinfo" option tag in the Supported header field 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.
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;mp=1,
<sip:last_diversion_target;cause=486>; index=1.1.1;mp=1.1
Mohali Expires September 5, 2015 [Page 14]
Internet-Draft Mapping of Diversion and History-Info March 2015
4.2. Diversion header field syntax
The following text is restating the exact syntax that the production
rules in [RFC5806] define, but using [RFC5234] ABNF:
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 field 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:
<sip:diverting_user2_addr>; reason=user-busy; counter=1;
privacy=full,
<sip:diverting_user1_addr>; reason=unconditional; counter=1;
privacy=off
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 field is
Mohali Expires September 5, 2015 [Page 15]
Internet-Draft Mapping of Diversion and History-Info March 2015
present, the interworking function must adapt its behavior to respect
the chronological order. For more information, see section 3.
Concerning the privacy information in the Diversion header field, the
following mapping only applies within a trusted domain, otherwise see
the privacy considerations in section 3.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 Request-URI of the received INVITE. The mapping is described
in the table hereafter.
The first entry created in the History-Info header field contains:
- a hi-target-to-uri with the name-addr parameter of the bottom-
most Diversion header field,
- if a privacy parameter is present in the bottom-most Diversion
entry, then a Privacy header field must be escaped in the History-
Info header field as described in the table hereafter,
- a hi-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):
Source Destination
Diversion header component: History-Info header component:
=======================================================================
Name-addr Hi-target-to-uri
=======================================================================
Reason of the previous Cause URI parameter
Diversion entry A cause-param "cause" is
added in each hi-entry
(except the first one)
"unknown"----------------------------------404 (default 'cause' value)
"unconditional"----------------------------302
"user-busy"--------------------------------486
"no-answer"--------------------------------408
"deflection "------------------------------480 or 487
"unavailable"------------------------------503
"time-of-day"------------------------------404 (default)
Mohali Expires September 5, 2015 [Page 16]
Internet-Draft Mapping of Diversion and History-Info March 2015
"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
extended with ".1"
Then the History-Info header
created with the Diversion
entry with the previous index
extended 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"
======================================================================
hi-target-param
A mp-param "mp" is added in
each created hi-entry
(except the first one)
The "mp" parameter is set to
the index value of the
preceding hi-entry.
=======================================================================
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,
- an index set to the previous created index extended with a new
level ".1" added at the end,
- a hi-target-param set to "mp" equals to the index value of the
previous preceding hi-entry.
Notes:
Mohali Expires September 5, 2015 [Page 17]
Internet-Draft Mapping of Diversion and History-Info March 2015
1. For other optional Diversion parameters, there is no
recommendation as History-Info header field does not provide
equivalent parameters.
2. For values of the diversion-reason 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 field can contain a "tel" URI as defined in
[RFC3966]in the name-addr parameter. The History-Info header
field can also contain an address that is a "tel" URI but if this
hi-entry has to be completed with either a SIP header field (eg.
Reason or Privacy) or a SIP URI parameter (eg. 'cause' or
'target'); the "tel" URI must be converted into a SIP URI.
[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
field, the History-Info header field should be created with a SIP
URI with user=phone and a domain set to "unknow.invalid".
4. The Diversion header field 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 listed in[RFC4458]. Read the index value is not
enough. With the use of the "placeholder" entry the History-info
header field entries could reflect the real number of diversion
occurred still thanks to the cause-param.
Example of placeholder entry in the History-Info header field:
<sip:unknown@unknown.invalid;cause=xxx>;index=1.1
<sip:bob_addr;cause=404>;index=1.1.1;mp=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.
Mohali Expires September 5, 2015 [Page 18]
Internet-Draft Mapping of Diversion and History-Info March 2015
Concerning local policies recommendations about header fields
coexistence in the INVITE request, see sections 3 and 7.5.
6. History-Info header to Diversion header
Concerning the privacy information for the History-Info header field,
the following mapping only applies within a trusted domain, otherwise
see the privacy considerations in section 3.2.
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
field entry selected will be mapped into the last Diversion header
field entry and so on. One Diversion header field entry must be
created for each History-Info entry having cause-param with a value
listed in [RFC4458].
Diversion information:
The Target_entry and the Diverting_entry terms defined below are used
to ease the mapping understanding of the History-Info header field.
The diversion information can be identified by finding the following
hi-entries:
o Target_entry: hi-entries containing a cause-param URI parameter
with a value listed in [RFC4458]will contain the diversion reason
and the address of the target of the concerned call forwarding.
Following the [RFC7044]these hi-entries may also contain a hi-
target-param set to "mp".
o Diverting_entry:
For each previously identified hi-entry:
- If there is a "mp" header field parameter, the hi-entry whose
hi-index matches the value of the hi-target-param "mp" will
contain the diverting party address, its possible privacy and/
or SIP reason when the retargeting has been caused by a
received SIP response.
- If there is no "mp" header field parameter, the information
of the diverting party address, privacy and/or SIP reason will
be found in the hi-entry that precede this identified hi-entry.
Note: Following [RFC7044], all retargeting entries must point to a
hi-entry that contain a "mp" parameter but for backward compatibility
reasons, it may be absent from some of the received hi-entries. You
Mohali Expires September 5, 2015 [Page 19]
Internet-Draft Mapping of Diversion and History-Info March 2015
can find more information on the backward compatibility aspects in
section 8.
The History-Info header field must be mapped into the Diversion
header field as following:
Source Destination
History-Info header component: Diversion header component:
=====================================================================
Hi-target-to-uri Name-addr
of the Diverting_entry.
=====================================================================
Cause-param Reason
of the Target_entry
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 field escaped Privacy
in the hi-targeted-to-uri
of the Diverting_entry
"history"----------------------------------"full"
Privacy header field ----------------------"Off"
Absent or "none"
=====================================================================
Note: For other optional History-Info parameters, there is no
recommendation as Diversion header field does not provide equivalent
parameters.
Concerning local policies recommendations about header fields
coexistence in the INVITE request, see section 3.
Mohali Expires September 5, 2015 [Page 20]
Internet-Draft Mapping of Diversion and History-Info March 2015
7. Examples
7.1. Example with Diversion header changed into History-Info header
INVITE sip:last_diverting_target
Diversion:
<sip:diverting_user3_address>;reason=unconditional;counter=1;
privacy=off,
<sip:diverting_user2_address>;reason=user-busy;counter=1;
privacy=full,
<sip: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;mp=1,
<sip:diverting_user3_address;
cause=486?privacy=none>;index=1.1.1;mp=1.1,
<sip:last_diverting_target; cause=302>;index=1.1.1.1;mp=1.1.1
7.2. Example with History-Info header changed into Diversion header
INVITE sip:last_diverting_target; cause=486
History-Info:
<sip:diverting_user1_address?privacy=history>; index=1,
<sip:diverting_user2_address; cause=302?
privacy=none>;index=1.1;mp=1,
<sip:last_diverting_target; cause=486>;index=1.1.1;mp=1.1
Mapped into:
Diversion:
<sip:diverting_user2_address>; reason=user-busy; counter=1;
privacy=off,
<sip: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.
Mohali Expires September 5, 2015 [Page 21]
Internet-Draft Mapping of Diversion and History-Info March 2015
IWF* IWF*
SIP network using | SIP network using |SIP net.
History-Info | Diversion |using
| Hist-Info
| |
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; rc=1 | | | | |
| | | | | | | | | |
| | |INV C | | | | | | |
| | |------>| | | | | | |
| | |History-Info: | | | | | |
| | <sip:proxyP1>; index=1,| | | | |
| | <sip:userB>; index=1.1; rc=1, | | | |
| | <sip:proxyP2; cause=302>; index=1.1.1; mp=1.1 |
| | | | | | | | | |
| | | |INV C | | | | | |
| | | |----->| | | | | |
| | | Diversion: | | | | | |
| | | userB; reason=unconditional; counter=1; privacy=off
| | | |History-Info: | | | | |
| | | <sip:proxyP1>; index=1,| | | |
| | | <sip:userB>; index=1.1; rc=1,| | |
| | | <sip:proxyP2; cause=302>; index=1.1.1; mp=1.1
| | | | | | | | | |
| | | | |INV C | | | | |
| | | | |------>| | | | |
| | | | No modification of Diversion header |
| | | | | | | | | |
| | | | | |INV C | | | |
| | | | | |------>| | | |
| | | | | | | | | |
| | | | | |<--180-| | | |
| | | | | | | | | |
| | | | | No response timer expires | |
| | | | | |---INV D --->| | |
| | |Diversion: | | |
| | |userC; reason=no-answer; counter=1; privacy=full, |
| | |userB; reason=unconditional; counter=1; privacy=off,
| | | History-Info: | | |
Mohali Expires September 5, 2015 [Page 22]
Internet-Draft Mapping of Diversion and History-Info March 2015
| | | <sip:proxyP1>; index=1, | | |
| | | <sip:userB>; index=1.1; rc=1, | | |
| | | <sip:proxyP2; cause=302>; index=1.1.1; mp=1.1 |
| | | | | | | | | |
| | | | | | | |INV E | |
| | | | | | | |----->| |
| | |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; rc=1, | |
| | | <sip:proxyP2; cause=302>; index=1.1.1; mp=1.1 |
| | | | | | | | | |
| | | | | | | | | INV E |
| | | | | | | | |------>|
| | History-Info: | | | | | |
| | <sip:proxyP1>; index=1, | | | | |
| | <sip:userB>; index=1.1; rc=1, | | | |
| | <sip:proxyP2; cause=302>; index=1.1.1; mp=1.1, | |
| | <sip:userC ?privacy=history>; index=1.1.1.0.1, | |
|<sip:userD;cause=408?privacy=none>;index=1.1.1.0.1.1; mp=1.1.1.0.1,|
| |<sip:userE; cause=404>; index=1.1.1.0.1.1.1; mp=1.1.1.0.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 header fields 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 field and other ones
supporting History-info header field, 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 field and the more
recent History-Info header field.
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
Mohali Expires September 5, 2015 [Page 23]
Internet-Draft Mapping of Diversion and History-Info March 2015
node capabilities then the problem is more important. In this case
there is a need to pass both History-Info header field and Diversion
header field within the core network.
These header fields 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 field,
there is a requirement to be able to compare the header fields and to
convert the header fields. Depending upon the node capability, it
may be possible to make assumptions as to how this is handled.
o If it is known that the older Diversion header field supporting
nodes do not pass on any received History-Info header field then
the interworking becomes easier. If a message is received with
only Diversion header fields 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 field.
o If the node creates a new History-Info header field for a call
diversion, then an additional Diversion header field must be
created.
o If the next node is an 'old' node then the Diversion header field
will be used by that node and the History-Info entries will be
removed from the message when it is passed on.
o If the next node is a new node then the presence of both Diversion
header field and History-Info header field means that interworking
has already occurred and the Diversion and History-Info entries
must be considered equivalent.
o If both nodes pass on both History-Info header field and Diversion
header field but only actively use one, then both types of node
need to perform the interworking and must maintain equivalence
between the header fields. This will eventually result in the use
of Diversion header field being deprecated when all nodes in the
network support History-Info header field.
o If a gap is identified in the History-Info header field by a node
that would create a new entry, it shall add a single index with a
value of "0" prior to adding the appropriate index for the action
to be taken.
Mohali Expires September 5, 2015 [Page 24]
Internet-Draft Mapping of Diversion and History-Info March 2015
8. Backward Compatibility
The backward compatibility aspects are due to the changes on the
History-Info header field evolution from [RFC4244] to [RFC7044]that
are described in section 1.3 of this document. The backawrd
compatibility is taken into account throughout this document for the
interworking with the Diversion header field. More details are
provided in the backward compatibility section of [RFC7044].
9. IANA Considerations
This document makes no request of IANA.
10. Security Considerations
The security considerations in [RFC7044] and [RFC5806] apply.
The privacy considerations described in section 3.2 apply.
The use of Diversion header field or History-Info header field
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 header fields can provide
misleading information to users and applications. A SIP entity that
can provide a redirection reason in a History-Info header field or
Diversion header field should be able to suppress this in accordance
with privacy requirements of the user concerned.
11. 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, Bob Braden and Robert
Sparks. Merci a Lionel Morand, Xavier Marjou et Philippe Fouquart.
12. References
Mohali Expires September 5, 2015 [Page 25]
Internet-Draft Mapping of Diversion and History-Info March 2015
12.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.
[RFC3966] "The tel URI for Telephone Numbers", RFC 3966, December
2004.
[RFC4244] "An Extension to the Session Initiation Protocol (SIP) for
Request History Information", RFC 4244, November 2005.
[RFC5806] "Diversion Indication in SIP", March 2010.
[RFC7044] "An Extension to the Session Initiation Protocol (SIP) for
Request History Information", RFC 7044, February 2014.
12.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.
[RFC6044] "Mapping and Interworking of Diversion Information between
Diversion and History-Info Headers in the Session
Initiation Protocol (SIP)", RFC 6044, October 2010.
[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.
Mohali Expires September 5, 2015 [Page 26]
Internet-Draft Mapping of Diversion and History-Info March 2015
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 Request-URI of the INVITE
request. This mechanism is mainly used for call diversion to a
voicemail.
A.1. Diversion header field 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 field with a default value set to 404.
If the Diversion header field 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 field into the History-Info header field.
A.2. Voicemail URI to Diversion header field
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 September 5, 2015 [Page 27]
Internet-Draft Mapping of Diversion and History-Info March 2015
Author's Address
Marianne Mohali
Orange
38-40 rue du General Leclerc
Issy-Les-Moulineaux Cedex 9 92794
France
Phone: +33 1 45 29 45 14
Email: marianne.mohali@orange.com
Mohali Expires September 5, 2015 [Page 28]