doc: Add RFC documents

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]
+