summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6044.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6044.txt')
-rw-r--r--doc/rfc/rfc6044.txt1347
1 files changed, 1347 insertions, 0 deletions
diff --git a/doc/rfc/rfc6044.txt b/doc/rfc/rfc6044.txt
new file mode 100644
index 0000000..ff5dfcb
--- /dev/null
+++ b/doc/rfc/rfc6044.txt
@@ -0,0 +1,1347 @@
+
+
+
+
+
+
+Independent Submission M. Mohali
+Request for Comments: 6044 France Telecom Orange
+Category: Informational October 2010
+ISSN: 2070-1721
+
+
+Mapping and Interworking of Diversion Information between Diversion and
+ History-Info Headers in the Session Initiation Protocol (SIP)
+
+Abstract
+
+ Although the SIP History-Info header is the solution adopted in IETF,
+ the non-standard Diversion header is nevertheless widely implemented
+ and used for conveying call-diversion-related information in SIP
+ signaling.
+
+ This document describes a recommended interworking guideline between
+ the Diversion header and the History-Info header to handle call
+ diversion information. In addition, an interworking policy is
+ proposed to manage the headers' coexistence. The History-Info header
+ is described in RFC 4244 and the non-standard Diversion header is
+ described, as Historic, in RFC 5806.
+
+ Since the Diversion header is used in many existing network
+ implementations for the transport of call diversion information, its
+ interworking with the SIP History-Info standardized solution is
+ needed. This work is intended to enable the migration from non-
+ standard implementations and deployment toward IETF specification-
+ based implementations and deployment.
+
+Status of This Memo
+
+ This document is not an Internet Standards Track specification; it is
+ published for informational purposes.
+
+ This is a contribution to the RFC Series, independently of any other
+ RFC stream. The RFC Editor has chosen to publish this document at
+ its discretion and makes no statement about its value for
+ implementation or deployment. Documents approved for publication by
+ the RFC Editor are not a candidate for any level of Internet
+ Standard; see Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc6044.
+
+
+
+
+
+
+Mohali Informational [Page 1]
+
+RFC 6044 Mapping Diversion and History-Info October 2010
+
+
+Copyright Notice
+
+ Copyright (c) 2010 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document.
+
+Table of Contents
+
+ 1. Introduction ....................................................3
+ 1.1. Overview ...................................................3
+ 1.2. Background .................................................3
+ 2. Problem Statement ...............................................4
+ 2.1. Interworking Requirements and Scope ........................4
+ 2.2. Interworking Recommendations ...............................6
+ 2.2.1. SIP Network/Terminal Using Diversion to SIP
+ Network/Terminal Using History-Info Header ..........6
+ 2.2.2. SIP Network/Terminal Using History-Info
+ Header to SIP Network/terminal Using Diversion
+ Header ..............................................8
+ 3. Headers Syntaxes Reminder .......................................9
+ 3.1. History-Info Header Syntax .................................9
+ 3.2. Diversion Header Syntax ...................................11
+ 4. Headers in SIP Method ..........................................11
+ 5. Diversion Header to History-Info Header ........................12
+ 6. History-Info Header to Diversion Header ........................15
+ 7. Examples .......................................................17
+ 7.1. Example with Diversion Header Changed into
+ History-Info Header .......................................17
+ 7.2. Example with History-Info Header Changed into
+ Diversion Header ..........................................17
+ 7.3. Example with Two SIP Networks Using History-Info Header ...17
+ 7.4. Additional Interworking Cases .............................19
+ 8. Security Considerations ........................................20
+ 9. Acknowledgements ...............................................21
+ 10. References ....................................................21
+ 10.1. Normative References .....................................21
+ 10.2. Informative References ...................................21
+ Appendix A. Interworking between Diversion Header and
+ Voicemail URI ........................................23
+
+
+
+
+
+
+Mohali Informational [Page 2]
+
+RFC 6044 Mapping Diversion and History-Info October 2010
+
+
+1. Introduction
+
+1.1. Overview
+
+ For some VoIP-based (Voice over IP) services (e.g., 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 by
+ various service providers or by applications, it needs to pass
+ through the network. This is possible with two different SIP
+ headers: the History-Info header defined in [RFC4244] and the
+ historic Diversion header defined in [RFC5806], which are both able
+ to transport diversion information in SIP signaling.
+
+ Although the Diversion header is not standardized, it is widely used.
+ Therefore, it is useful to have guidelines to make this header
+ interwork with the standard History-Info header.
+
+ Note that the new implementation and deployment of the Diversion
+ header is strongly discouraged.
+
+ This document provides a mechanism for header-content translation
+ between the Diversion header and the History-Info header.
+
+1.2. Background
+
+ The History-Info header [RFC4244] and its extension for forming SIP
+ service URIs (including Voicemail URI) [RFC4458] are recommended by
+ the IETF to convey redirection information. They are also
+ recommended in the "Communication Diversion (CDIV) service" Third
+ Generation Partnership Project (3GPP) specification [TS_24.604].
+
+ Originally, the Diversion header was described in a document that was
+ submitted to the SIP Working Group. It has been published now as
+ [RFC5806] for the historical record and to provide a reference for
+ this RFC.
+
+ This header contains a list of diverting URIs and associated
+ information providing specific information as the reason for the call
+ diversion. Most existing SIP-based implementations have implemented
+ the Diversion header when no standard solution was ready to deploy.
+ The IETF has finally standardized the History-Info header, partly
+ because it can transport general history information. This allows
+ the receiving part to determine how and why the session is received.
+ As the History-Info header may contain further information than call
+ diversion information, it is critical to avoid losing information and
+
+
+
+
+
+Mohali Informational [Page 3]
+
+RFC 6044 Mapping Diversion and History-Info October 2010
+
+
+ be able to extract the relevant data using the retargeting cause URI
+ parameter described in [RFC4458] for the transport of the diversion
+ reason.
+
+ The Diversion header and the History-Info header have different
+ syntaxes, described below. Note that the main difference is that the
+ History-Info header is a chronological writing header whereas the
+ Diversion header applies a reverse chronology (i.e., the first
+ diversion entry read corresponds to the last diverting user).
+
+ Appendix A provides an interworking guideline between the Diversion
+ header and the Voicemail URI, which is another way to convey
+ diversion information. The Voicemail URI is defined in [RFC4458].
+
+2. Problem Statement
+
+2.1. Interworking Requirements and Scope
+
+ This section provides the baseline terminology used in the rest of
+ the document and defines the scope of interworking between the
+ Diversion header and the History-Info header.
+
+ There are many ways in which SIP signaling can be used to modify a
+ session destination before it is established, and there are many
+ reasons for doing so. The behavior of the SIP entities that will
+ have to further process the session downstream will sometimes vary
+ depending on the reasons that lead to changing the destination. For
+ example, whether it is for a simple proxy to route the session or for
+ an application server to provide a supplementary service. The
+ Diversion header and the History-Info header differ in the approach
+ and scope of addressing this problem.
+
+ For clarity, the following vocabulary is used in this document:
+
+ o Retargeting/redirecting: retargeting/redirecting refers to the
+ process of a Proxy Server/User Agent Client (UAC) changing a
+ Uniform Resource Identifier (URI) in a request and thus changing
+ the target of the request. These terms are defined in [RFC4244].
+ The History-Info header is used to capture retargeting
+ information.
+
+ o Call forwarding/call diversion/communication diversion: these
+ terms are equivalent and refer to the Communications Diversion
+ (CDIV) supplementary services, based on the Integrated Services
+ Digital Network (ISDN) Communication diversion supplementary
+
+
+
+
+
+
+Mohali Informational [Page 4]
+
+RFC 6044 Mapping Diversion and History-Info October 2010
+
+
+ services and defined in 3GPP [TS_24.604]. They are applicable to
+ entities that 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 headers should be used. Hereafter is provided
+ clarification on the context in which the interworking is required.
+
+ The Diversion header has exactly the same scope as the call diversion
+ service and each header entry reflects a call diversion invocation.
+ The Diversion header is used for recording call forwarding
+ information, which could be useful to network entities downstream.
+ Today, this SIP header is implemented by several manufacturers and
+ deployed in networks.
+
+ The History-Info header is used to store all retargeting information
+ including call diversion information. In practice, the History-Info
+ header [RFC4244] is used to convey call-diversion-related information
+ by using a cause URI parameter [RFC4458] in the relevant entry.
+ Note, however, that the use of cause URI parameter [RFC4458] in a
+ History-Info entry for a call diversion is specific to the 3GPP
+ specification [TS_24.604]. [RFC4458] focuses on retargeting toward a
+ voicemail server and does not specify whether the cause URI parameter
+ should be added in a URI for other cases. As a consequence,
+ implementations that do not use the cause URI parameter for call
+ forwarding information are not considered for the mapping described
+ in this document. Nevertheless, some recommendations are given in
+ the next sections on how to avoid the loss of non-mapped information
+ at the boundary between a network region using History-Info header
+ and one using the Diversion header.
+
+ Since both headers address call forwarding needs, diverting
+ information could be mixed up or be inconsistent if both are present
+ in an uncoordinated fashion in the INVITE request. So, Diversion and
+ History-Info headers must not independently coexist in the same
+ session signaling. This document addresses how to convert
+ information between the Diversion header and the History-Info header,
+ and when and how to preserve both headers to cover additional cases.
+
+ For the transportation of consistent diversion information
+ downstream, it is necessary to make the two headers interwork.
+ Interworking between the Diversion header and the History-Info header
+ is introduced in sections 5 and 6. Since the coexistence scenario
+ may vary from one use case to another one, guidelines regarding
+ headers interaction are proposed.
+
+
+
+
+
+Mohali Informational [Page 5]
+
+RFC 6044 Mapping Diversion and History-Info October 2010
+
+
+2.2. Interworking Recommendations
+
+ Interworking function:
+
+ In a normal case, the network topology assumption is that the
+ interworking described in this document should be performed by a
+ specific SIP border device that is aware, by configuration, that
+ it is at the border between two regions, one using History-Info
+ header and one using Diversion header.
+
+ As History-Info header is a standard solution, a network using the
+ Diversion header must be able to provide information to a network
+ using the History-Info header. In this case, to avoid header
+ coexistence, it is required to replace, as often as possible, the
+ Diversion header with the History-Info header in the INVITE request
+ during the interworking.
+
+ Since, the History-Info header has a wider scope than the Diversion
+ header, it may be used for other needs and services than call
+ diversion. In addition to trace call diversion information, the
+ History-Info header also acts as a session history and can store all
+ successive R-URI values. Consequently, even if it should be better
+ to remove the History-Info header after the creation of the Diversion
+ header to avoid confusion, the History-Info header must remain
+ unmodified in the SIP signaling if it contains supplementary (non-
+ diversion) information. It is possible to have History-Info headers
+ that do not have values that can be mapped into the Diversion header.
+ In this case, no interworking with Diversion header should be
+ performed, and it must be defined per implementation what to do in
+ this case. This point is left out of the scope of this document.
+
+ As a conclusion, it is recommended to have local policies minimizing
+ the loss of information and find the best way to keep it up to the
+ terminating user agent.
+
+ The following sections describe the basic common use case.
+ Additional interworking cases are described in section 7.5.
+
+2.2.1. SIP Network/Terminal Using Diversion to SIP Network/Terminal
+ Using History-Info Header
+
+ When the Diversion header is used to create a History-Info header,
+ the Diversion header must be removed in the outgoing INVITE. It is
+ considered that all of the information present in the Diversion
+ header is transferred in the History-Info header.
+
+
+
+
+
+
+Mohali Informational [Page 6]
+
+RFC 6044 Mapping Diversion and History-Info October 2010
+
+
+ If a History-Info header is present in the incoming INVITE (in
+ addition to Diversion header), the Diversion header and History-Info
+ header present must be mixed and only the diversion information not
+ yet present in the History-Info header must be inserted as a last
+ entry (more recent) in the existing History-Info header, as
+ recommended in [RFC4244].
+
+ As an example, this could be the case of an INVITE coming from
+ network_2 using the Diversion header but previously passed through
+ network_1 using the History-Info header (or the network_2 uses
+ History-Info header to transport successive URI information) and
+ going to network_3 using the History-Info header.
+
+ IWF* IWF*
+ network1 | network_2 |network_3
+ History-Info | Diversion |using
+ | |Hist-Info
+ | |
+UA A P1 AS B | P2 AS C UA C AS D | UA E
+| | | | | | | | | |
+|INVITE | | | | | | | | |
+|------>| | | | | | | | |
+| | | | | | | | | |
+| |INVITE | | | | | | | |
+| |------>| | | | | | | |
+| |Supported: histinfo | | | | | |
+| | History-Info: | | | | | |
+| | <sip:proxyP1>; index=1, | | | | |
+| | <sip:userB >; index=1.1 | | | | |
+| | | | | | | | | |
+| | |INVITE | | | | | | |
+| | |------>| | | | | | |
+| | |History-Info: | | | | | |
+| | |<sip:proxyP1>; index=1,| | | | |
+| | |<sip:userB>; index=1.1 | | | | |
+| | |<sip:userC>; cause=302; index=1.1.1 | | |
+
+ In this case, the incoming INVITE contains a Diversion header and a
+ History-Info header. Therefore, as recommended in this document, it
+ is necessary to create, for network_3, a single History-Info header
+ gathering existing information from both the History-Info and the
+ Diversion headers received. Anyway, it is required from network_2
+ (i.e., IWF) to remove the Diversion header when the message is going
+ to a network not using the Diversion header. Then, network_3 could
+ use call forwarding information that is present in a single header
+ and add its own diversion information if necessary.
+
+
+
+
+
+Mohali Informational [Page 7]
+
+RFC 6044 Mapping Diversion and History-Info October 2010
+
+
+ Notes:
+
+ 1. If a network is not able either to use only one header each time
+ or to maintain both headers up to date, the chronological order
+ cannot be certified.
+
+ 2. It is not possible to have only a Diversion header when the
+ History-Info header contains more than call diversion information.
+ If previous policy recommendations are applied, the chronological
+ order is respected as Diversion entries are inserted at the end of
+ the History-Info header taking into account the Diversion internal
+ chronology.
+
+2.2.2. SIP Network/Terminal Using History-Info Header to SIP
+ Network/Terminal Using Diversion Header
+
+ When the History-Info header is interpreted to create a Diversion
+ header, some precautions must be taken.
+
+ If the History-Info header contains only call forwarding information,
+ then it must be deleted after the interworking.
+
+ If the History-Info header contains other information, then only the
+ information of concern to the diverting user must be used to create
+ entries in the Diversion header and the History-Info header must be
+ kept as received in the INVITE and forwarded downstream.
+
+ Note: The History-Info header could be used for other reasons than
+ call diversion services, for example, by a service that needs to know
+ if a specific Application Server (AS) had yet been invoked in the
+ signaling path. If the call is later forwarded to a network using
+ the History-Info header, it would be better not to lose history
+ information due to passing though the network that only supports
+ Diversion headers. A recommended solution must not disrupt the
+ standard behavior and networks that do not implement the History-Info
+ header must be transparent to a received History-Info header.
+
+ If a Diversion header is present in the incoming INVITE (in addition
+ to History-Info header), only diversion information present in the
+ History-Info header but not in the Diversion header must be inserted
+ from the last entry (more recent) into the existing Diversion header,
+ as recommended in [RFC5806].
+
+ Note that the chronological order could not be certified. If
+ previous policy recommendations are respected, this case should not
+ happen.
+
+
+
+
+
+Mohali Informational [Page 8]
+
+RFC 6044 Mapping Diversion and History-Info October 2010
+
+
+ Forking case:
+
+ The History-Info header enables the recording of sequential
+ forking for the same served user. During an interworking, from
+ the History-Info header to Diversion header, the History-Info
+ entries containing a forking situation (with an incremented
+ "index" parameter) could possibly be mapped if it contains a call
+ forwarding "cause" parameter. The interworking entity could
+ choose to create only a Diversion entry or not apply the
+ interworking. The choice could be done according a local policy.
+
+ The same logic is applied for an interworking with Voicemail URI (see
+ the Appendix).
+
+3. Headers Syntaxes Reminder
+
+3.1. History-Info Header Syntax
+
+ History-Info = "History-Info" HCOLON hi-entry *(COMMA hi-entry)
+
+ hi-entry = hi-targeted-to-uri *( SEMI hi-param )
+ hi-targeted-to-uri = name-addr
+ hi-param = hi-index / hi-extension
+ hi-index = "index" EQUAL 1*DIGIT *(DOT 1*DIGIT)
+ hi-extension = generic-param
+
+ The History-Info header is specified in [RFC4244]. The top-most
+ History-Info entry (first in the list) corresponds to the oldest
+ history information.
+
+ A hi-entry may contain a cause URI parameter expressing the diversion
+ reason. This optional cause URI parameter is defined in [RFC4458]
+ with the following syntax:
+
+ cause-param = "cause" EQUAL Status-Code
+
+ This parameter is also named cause-param and should be inserted in
+ the History-Info entry (URI) of the diverted-to user in case of call
+ diversion as recommended in the 3GPP CDIV specification [TS_24.604].
+ The cause values used in the cause-param for the diverting reason are
+ listed in the RFC 4458, and because it is a parameter dedicated to
+ call forwarding service, its presence is used to determine that a hi-
+ entry is a diverting user. More precisely, each diverting user is
+ located in the hi-entry before the one containing a cause-param with
+ a cause value as listed in RFC 4458.
+
+
+
+
+
+
+Mohali Informational [Page 9]
+
+RFC 6044 Mapping Diversion and History-Info October 2010
+
+
+ Moreover, the Reason header defined in [RFC3326] should be escaped in
+ the hi-entry of the diverting user when the call diversion is due to
+ a received SIP response. The Reason header contains a cause
+ parameter set to the true SIP response code received (Status-Code).
+ Therefore, in case of call diversion due to a SIP response, both
+ cause parameters should be used. The complexity is that these
+ parameters could be used at the same time in the History-Info header
+ but not in the same hi-entry and not with the same meaning. Only the
+ cause-param is dedicated to call diversion service. The 'cause'
+ Reason header parameter is not taken into account in the mapping with
+ a Diversion header.
+
+ [RFC4458] also defines the 'target' URI parameter, which could be
+ inserted in a R-URI and consequently in the hi-targeted-to-uri. This
+ parameter is used to keep the diverting user address in the
+ downstream INVITE request in Voicemail URI implementation. As this
+ information is already present in the hi-entries, the 'target' URI
+ parameter is not taken into account regarding the interworking with
+ the Diversion header. From the Diversion header, it could be
+ possible to create the 'target' URI parameter in the hi-entries
+ and/or in the R-URI, but this possibility is based on local policies
+ not described in this document.
+
+ A Privacy header, as defined in [RFC3323], could also be included in
+ hi-entries with the 'history' value defined in the [RFC4244].
+
+ The index parameter is a string of digits, separated by dots, to
+ indicate the number of forward hops and retargets.
+
+ Note: A history entry could contain the "gr" parameter. Regardless
+ of the rules concerning the "gr" parameter defined in [TS_24.604],
+ which must be applied, this parameter has no impact on the mapping
+ and must only be copied with the served user address.
+
+ Example:
+
+ History-Info:
+ <sip: diverting_user1_addr?Privacy=none?Reason=SIP%3Bcause%
+ 3D302>;index=1,
+ <sip: diverting_user2_addr;cause=480?Privacy=history>;index=1.1,
+ <sip:last_diversion_target;cause=486>; index=1.1.1
+
+ Policy concerning "histinfo" option tag in Supported header:
+ According to [RFC4244], a proxy that receives a Request with the
+ "histinfo" option tag in the Supported header should return captured
+ History-Info in subsequent, provisional and final responses to the
+ Request. The behavior depends upon whether or not the local policy
+ supports the capture of History-Info.
+
+
+
+Mohali Informational [Page 10]
+
+RFC 6044 Mapping Diversion and History-Info October 2010
+
+
+3.2. Diversion Header 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 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
+
+ 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.
+
+
+
+
+Mohali Informational [Page 11]
+
+RFC 6044 Mapping Diversion and History-Info October 2010
+
+
+ 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 a History-Info header (according to its capabilities) in the
+ forwarded INVITE. Local policies could apply to send the received
+ header in the next INVITE.
+
+ Other messages where History-Info could be present are not used for
+ the call forwarding service and should not be changed into Diversion
+ header. The destination network must be transparent to the received
+ History-Info header.
+
+ Note: the following mapping is inspired from the ISDN User Part
+ (ISUP) to the SIP interworking described in [TS_29.163].
+
+5. Diversion Header to History-Info Header
+
+ The following text is valid only if no History-Info is present in the
+ INVITE request. If at least one History-Info header is present, the
+ interworking function must adapt its behavior to respect the
+ chronological order. See section 2.2.
+
+ For N Diversion entries, N+1 History-Info entries must be created.
+ To create the History-Info entries in the same order than during a
+ session establishment, the Diversion entries must be mapped from the
+ bottom-most until the top-most. Each Diversion entry shall be mapped
+ into a History-Info entry. An additional History-Info entry (the
+ last one) must be created with the diverted-to party address present
+ in the R-URI of the received INVITE. The mapping is described below.
+
+ The first entry created in the History-Info header contains:
+
+ - a hi-targeted-to-uri with the name-addr parameter of the bottom-
+ most Diversion header.
+
+ - if a privacy parameter is present in the bottom-most Diversion
+ entry, then a Privacy header could be escaped in the History-Info
+ header as described below.
+
+ - an index set to 1.
+
+ For each following Diversion entry (from bottom to top), the History-
+ info entries are created as following (from top to bottom):
+
+
+
+
+
+
+
+
+
+Mohali Informational [Page 12]
+
+RFC 6044 Mapping Diversion and History-Info October 2010
+
+
+Source Destination
+Diversion header component: History-Info header component:
+=======================================================================
+name-addr hi-targeted-to-uri
+
+=======================================================================
+Reason of the previous cause-param (not present in
+Diversion entry the first created hi-entry)
+"unknown"---------------------------------404 (default 'cause' value)
+"unconditional"---------------------------302
+"user-busy"-------------------------------486
+"no-answer"-------------------------------408
+"deflection "-----------------------------480 or 487
+"unavailable"-----------------------------404
+"time-of-day"-----------------------------404 (default)
+"do-not-disturb"--------------------------404 (default)
+"follow-me"-------------------------------404 (default)
+"out-of-service"--------------------------404 (default)
+"away"------------------------------------404 (default)
+
+=======================================================================
+Counter hi-index
+"1" or parameter -------------------------The previous created index
+not 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-targeted-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 Informational [Page 13]
+
+RFC 6044 Mapping Diversion and History-Info October 2010
+
+
+ - if a privacy parameter is present in the top-most Diversion entry,
+ then a Privacy header could be escaped in the History-Info header
+ as described above.
+
+ - an index set to the previous created index and incremented with
+ ".1"
+
+ Notes:
+
+ 1. For other optional Diversion parameters, there is no
+ recommendation as History-Info header does not provide equivalent
+ parameters.
+
+ 2. For values of the diversion-reason values that 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 covers
+ a large portion of cases.
+
+ 3. The Diversion header could contain a Tel:URI in the name-addr
+ parameter, but it seems not possible to have a Tel:URI in the
+ History-Info header. [RFC3261] gives an indication as to the
+ mapping between sip: and Tel:URIs, but in this particular case, it
+ is difficult to assign a valid hostport as the diversion has
+ occurred in a previous network and a valid hostport is difficult
+ to determine. So, it is suggested that in case of Tel:URI in the
+ Diversion header, the History-Info header should be created with a
+ SIP URI with user=phone.
+
+ 4. The Diversion header allows the carrying of a counter that retains
+ the information about the number of successive redirections. The
+ History-Info header does not have an equivalent because to trace
+ and count the number of diversion it is necessary to count cause
+ parameter containing a value associated to a call diversion. Read
+ the index value is not enough. With the use of the "placeholder"
+ entry, the History-Info header entries could reflect the real
+ number of diversion occurred.
+
+ Example of placeholder entry in the History-Info header:
+
+ <sip:unknown@unknown.invalid;cause=xxx>;index=1.1
+
+ <sip:bob_addr;cause=404>;index=1.1.1
+
+
+
+
+
+
+Mohali Informational [Page 14]
+
+RFC 6044 Mapping Diversion and History-Info October 2010
+
+
+ "cause=xxx" reflects the diverting reason of a previous diverting
+ user. For a placeholder hi-entry, the value "404" must be taken for
+ the cause-param and so, located in the next hi-entry.
+
+ Concerning local policies recommendations about headers coexistence
+ in the INVITE request, see sections 2.2 and 7.5.
+
+6. History-Info Header to Diversion Header
+
+ To create the Diversion entries in the same order than during a
+ session establishment, the History-Info entries must be mapped from
+ the top-most until the bottom-most. The first History-Info header
+ entry selected will be mapped into the last Diversion header entry
+ and so on. One Diversion header entry must be created for each
+ History-Info entry, with a cause-param reflecting a diverting reason
+ as listed in the [RFC4458].
+
+ In this case, the History-Info header must be mapped into the
+ Diversion header as following:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mohali Informational [Page 15]
+
+RFC 6044 Mapping Diversion and History-Info October 2010
+
+
+ Source Destination
+ History-Info header component: Diversion header component:
+ =====================================================================
+ hi-targeted-to-uri of the name-addr
+ History-Info that precedes the one
+ containing a diverting cause-param.
+
+ =====================================================================
+ cause-param Reason
+ 404---------------------------------------"unknown" (default value)
+ 302---------------------------------------"unconditional"
+ 486---------------------------------------"user-busy"
+ 408---------------------------------------"no-answer"
+ 480 or 487--------------------------------"deflection "
+ 503---------------------------------------"unavailable"
+
+ =====================================================================
+ hi-index Counter
+ Mandatory parameter for--------------------The counter is set to "1".
+ History-Info reflecting
+ the chronological order
+ of the information.
+ =====================================================================
+ Privacy header [RFC3323] escaped in the Privacy
+ hi-targeted-to-uri of the
+ History-Info, which precedes the one
+ containing a diverting cause-param.
+ Optional parameter for History-Info,
+ this Privacy indicates that this
+ specific History-Info header should
+ not be forwarded.
+ "history"----------------------------------"full"
+ Privacy header field ----------------------"Off"
+ Absent or "none"
+
+ =====================================================================
+
+ Note: For other optional History-Info parameters, there is no
+ recommendation as Diversion header does not provide equivalent
+ parameters.
+
+ Concerning local policies recommendations about headers coexistence
+ in the INVITE request, see section 2.2.
+
+
+
+
+
+
+
+
+Mohali Informational [Page 16]
+
+RFC 6044 Mapping Diversion and History-Info October 2010
+
+
+7. Examples
+
+7.1. Example with Diversion Header Changed into History-Info Header
+
+ INVITE last_diverting_target
+ Diversion:
+ diverting_user3_address;reason=unconditional;counter=1;privacy=off,
+ diverting_user2_address;reason=user-busy;counter=1;privacy=full,
+ diverting_user1_address;reason=no-answer;counter=1;privacy=off
+
+ Mapped into:
+
+ History-Info:
+ <sip: diverting_user1_address; privacy=none >; index=1,
+ <sip: diverting_user2_address; cause=408?privacy=history>;index=1.1,
+ <sip: diverting_user3_address; cause=486?privacy=none>;index=1.1.1,
+ <sip: last_diverting_target; cause=302>;index=1.1.1.1
+
+7.2. Example with History-Info Header Changed into Diversion Header
+
+ History-Info:
+ <sip: diverting_user1_address?privacy=history >; index=1,
+ <sip: diverting_user2_address; cause=302? privacy=none>;index=1.1,
+ <sip: last_diverting_target; cause=486>;index=1.1.1
+
+ Mapped into:
+
+ Diversion:
+ diverting_user2_address; reason=user-busy; counter=1; privacy=off,
+ diverting_user1_address; reason=unconditional; counter=1;
+ privacy=full
+
+7.3. Example with Two SIP Networks Using History-Info Header
+ Interworking with a SIP Network Using Diversion Header
+
+ A -> P1 -> B -> C -> P2 -> D-> E
+ A, B, C, D and E are users.
+ B, C and D have Call Forwarding service invoked.
+ P1 and P2 are proxies.
+ Only relevant information is shown on the following call flow.
+
+
+
+
+
+
+
+
+
+
+
+Mohali Informational [Page 17]
+
+RFC 6044 Mapping Diversion and History-Info October 2010
+
+
+ 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 | | | | |
+ | | | | | | | | | |
+ | | |INV C | | | | | | |
+ | | |------>| | | | | | |
+ | | |History-Info: | | | | | |
+ | | <sip:proxyP1>; index=1,| | | | |
+ | | <sip:userB>; index=1.1 | | | | |
+ | | <sip:userC; cause=302>; index=1.1.1 | | |
+ | | | | | | | | | |
+ | | | |INV C | | | | | |
+ | | | |----->| | | | | |
+ | | | |Diversion: | | | | |
+ | | | |B reason= unconditional counter=1 | |
+ | | | |History-Info: | | | | |
+ | | | <sip:proxyP1>; index=1,| | | |
+ | | | <sip:userB>; index=1.1 | | | |
+ | | | <sip:proxyP2; cause=302>; index=1.1.1 |
+ | | | | | | | | | |
+ | | | | |INV C | | | | |
+ | | | | |------>| | | | |
+ | | | | No modification of Diversion due to P2|
+ | | | | | | | | | |
+ | | | | | |INV C | | | |
+ | | | | | |------>| | | |
+ | | | | | | | | | |
+ | | | | | |<--180-| | | |
+ | | | | | | | | | |
+ | | | | | No response timer expire | |
+ | | | | | |---INV D --->| | |
+
+
+
+
+
+
+
+Mohali Informational [Page 18]
+
+RFC 6044 Mapping Diversion and History-Info October 2010
+
+
+ | | |Diversion: | | |
+ | | |userC; reason=no-answer; counter=1; privacy=full, |
+ | | |userB; reason=unconditional; counter=1; privacy=off,
+ | | | History-Info: | | |
+ | | | <sip:proxyP1>; index=1, | | |
+ | | | <sip:userB>; index=1.1 | | |
+ | | | <sip:proxyP2; cause=302>; index=1.1.1 | |
+ | | | | | | | | | |
+ | | | | | | | |INV E | |
+ | | | | | | | |----->| |
+ | | |Diversion: | |
+ | | |userD; reason=time-of-day; counter=1; privacy=off |
+ | | |userC; reason=no-answer; counter=1; privacy=full, |
+ | | |userB; reason=unconditional; counter=1; privacy=off,
+ | | | History-Info: | |
+ | | | <sip:proxyP1>; index=1, | |
+ | | | <sip:userB>; index=1.1 | |
+ | | | <sip:proxyP2; cause=302>; index=1.1.1 | |
+ | | | | | | | | | |
+ | | | | | | | | | INV E |
+ | | | | | | | | |------>|
+ | | | History-Info: |
+ | | | <sip:proxyP1>; index=1, |
+ | | | <sip:userB ?privacy=none>; index=1.1, |
+ | | | <sip:proxyP2; cause=302>; index=1.1.1, |
+ | | | <sip:userC ?privacy=history>; index=1.1.1.1, |
+ | | <sip:userD; cause=408 ?privacy=none>; index=1.1.1.1.1,
+ | | | <sip:userE; cause=404>; index=1.1.1.1.1.1 |
+ | | | | | | | | | |
+ | | | | | | | | | |
+
+ * Note: The IWF is an interworking function that could be a stand-
+ alone equipment not defined in this document (it could be a proxy).
+
+7.4. Additional Interworking Cases
+
+ Even if for particular cases in which both headers could coexist, it
+ should be the network local policy responsibility to make it work
+ together. Here are described some situations and some
+ recommendations on the behavior to follow.
+
+ In the case where there is one network that includes different nodes,
+ some of them supporting the Diversion header and other ones
+ supporting the History-Info header, there is a problem when any node
+ handling a message does not know the next node that will handle the
+ message. This case can occur when the network has new and old nodes,
+ the older ones using Diversion header and the more recent History-
+ Info header.
+
+
+
+Mohali Informational [Page 19]
+
+RFC 6044 Mapping Diversion and History-Info October 2010
+
+
+ While a network replacement may be occurring, there will be a time
+ when both nodes coexist in the network. If the different nodes are
+ being used to support different subscriber types due to different
+ node capabilities then the problem is more important. In this case,
+ there is a need to pass both History-Info header and Diversion header
+ within the core network.
+
+ These headers need to be equivalent to ensure that, whatever the node
+ receiving the message, the correct diversion information is received.
+ This requires that whatever the received header, there is a
+ requirement to be able to compare the headers and to convert the
+ headers. Depending upon the node capability, it may be possible to
+ make assumptions as to how this is handled.
+
+ o If it is known that the older Diversion header supporting nodes do
+ not pass on any received History-Info header, then the
+ interworking becomes easier. If a message is received with only
+ Diversion headers, then it has originated from an 'old' node. The
+ equivalent History-Info entries can be created and these can then
+ be passed as well as the Diversion header.
+
+ o If the node creates a new History-Info header for a call
+ diversion, then an additional Diversion header must be created.
+
+ o 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.
+
+ o 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.
+
+ o If both nodes pass on both History-Info header and Diversion
+ header, but only actively use one, then both types of nodes 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. Security Considerations
+
+ The security considerations in [RFC4244] and [RFC5806] apply.
+
+ The use of the Diversion header or the History-Info header require
+ the application of 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
+
+
+
+Mohali Informational [Page 20]
+
+RFC 6044 Mapping Diversion and History-Info October 2010
+
+
+ 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. Unauthorized 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 a Diversion header
+ should be able to suppress this in accordance with privacy
+ requirements of the user concerned.
+
+9. Acknowledgements
+
+ 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, and Philippe Fouquart.
+
+10. References
+
+10.1. Normative References
+
+ [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
+ A., Peterson, J., Sparks, R., Handley, M., and E.
+ Schooler, "SIP: Session Initiation Protocol", RFC 3261,
+ June 2002.
+
+ [RFC3323] Peterson, J., "A Privacy Mechanism for the Session
+ Initiation Protocol (SIP)", RFC 3323, November 2002.
+
+ [RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason
+ Header Field for the Session Initiation Protocol (SIP)",
+ RFC 3326, December 2002.
+
+ [RFC4244] Barnes, M., Ed., "An Extension to the Session Initiation
+ Protocol (SIP) for Request History Information", RFC
+ 4244, November 2005.
+
+ [RFC5806] Levy, S. and M. Mohali, Ed., "Diversion Indication in
+ SIP", RFC 5806, March 2010.
+
+10.2. Informative References
+
+ [RFC4458] Jennings, C., Audet, F., and J. Elwell, "Session
+ Initiation Protocol (SIP) URIs for Applications such as
+ Voicemail and Interactive Voice Response (IVR)", RFC
+ 4458, April 2006.
+
+
+
+Mohali Informational [Page 21]
+
+RFC 6044 Mapping Diversion and History-Info October 2010
+
+
+ [RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for
+ Syntax Specifications: ABNF", STD 68, RFC 5234, January
+ 2008.
+
+ [TS_24.604] 3rd Generation Partnership Project, "Technical
+ Specification Group Core Network and Terminals ;
+ Communication Diversion (CDIV) using IP Multimedia
+ (IM)Core Network (CN) subsystem ; Protocol specification
+ (Release 8), 3GPP TS 24.604", December 2008.
+
+ [TS_29.163] 3rd Generation Partnership Project, "Technical
+ Specification Group Core Network and Terminals ;
+ Interworking between the IP Multimedia (IM) Core Network
+ (CN) Subsystem and Circuit Switched (CS) networks
+ (Release 8)", December 2008.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mohali Informational [Page 22]
+
+RFC 6044 Mapping Diversion and History-Info October 2010
+
+
+Appendix A. Interworking between Diversion Header and Voicemail URI
+
+ Voicemail URI is a mechanism described in RFC 4458 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 (whether or not the
+ voicemail serves this user).
+
+ Note: This interworking could be done in addition to the interworking
+ of the Diversion header into the History-Info header.
+
+ Voicemail URI to Diversion header:
+
+ In case of real voicemail, this way of interworking should not
+ happen. However, if for any reason it occurs, it is recommended to
+ do it as following:
+
+ Received:
+ INVITE sip: voicemail@example.com;\
+ target=sip:+33145454500%40example.com;user=phone;\
+ cause=302 SIP/2.0
+
+ Sent in the forwarded INVITE:
+ Diversion: sip:+
+ 33145454500%40example.com;user=phone;reason=unconditional;counter=1
+
+
+
+
+
+
+
+
+
+Mohali Informational [Page 23]
+
+RFC 6044 Mapping Diversion and History-Info October 2010
+
+
+Author's Address
+
+ Marianne Mohali
+ France Telecom 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-ftgroup.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mohali Informational [Page 24]
+