Network Working Group
Independent Submission                                         M. Mohali
Internet-Draft
Request for Comments: 7544                                        Orange
Obsoletes: 6044 (if approved)                             March 04,                                              August 2015
Intended status:
Category: Informational
Expires: September 5, 2015
ISSN: 2070-1721

Mapping and interworking Interworking of Diversion information Between Information between Diversion and
  History-Info Headers Header Fields in the Session Initiation Protocol (SIP)
                       draft-mohali-rfc6044bis-02

Abstract

   Although the SIP History-Info header field described in RFC 7044 is
   the solution adopted in IETF, the non-standard Diversion header field
   described, as Historic, in RFC 5806 is nevertheless already
   implemented and used for conveying call diversion related call-diversion-related information
   in the Session Initiation Protocol (SIP) signaling.
   On one hand, the non-standard Diversion header field is described, as
   Historic, in [RFC5806].  On the other hand, the History-Info header
   field is described in [RFC7044] that

   RFC 7044 obsoletes the original[RFC4244]
   describing the History-Info header field.  [RFC7044] defines original RFC 4244 and redefines the SIP History-
   Info header field, History-Info, field for capturing the history information in
   requests and new SIP header field parameters for the History-Info and
   Contact header fields to tag the method by which the target of a
   request is determined.  [RFC7044] also defines a value for the
   Privacy header field that directs the anonymization of values in the
   History-Info header field. requests.

   Since the Diversion header field is used in existing network
   implementations for the transport of call diversion information, its
   interworking with the SIP History-Info standardized solution is
   needed.  This document describes a recommended interworking guideline
   between the Diversion header field and the History-Info header field
   to handle call diversion information.  In addition, an interworking
   policy is proposed to manage the headers' coexistence.  This work is intended to
   enable the migration from non-standard implementations
   and deployments toward IETF
   specification-based implementations and
   deployments. implementations.

   This document obsoletes [RFC6044]that RFC 6044, which describes the interworking
   between the Diversion header field [RFC5806] defined in RFC 5806 and the
   obsoleted History-Info header field as defined on [RFC4244]. RFC 4244.

Status of This Memo

   This Internet-Draft document is submitted in full conformance with not an Internet Standards Track specification; it is
   published for informational purposes.

   This is a contribution to the
   provisions RFC Series, independently of BCP 78 any other
   RFC stream.  The RFC Editor has chosen to publish this document at
   its discretion and BCP 79.

   Internet-Drafts makes no statement about its value for
   implementation or deployment.  Documents approved for publication by
   the RFC Editor are working documents not a candidate for any level of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list
   Standard; see Section 2 of RFC 5741.

   Information about the current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum status of six months this document, any errata,
   and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on September 5, 2015.
   http://www.rfc-editor.org/info/rfc7544.

Copyright Notice

   Copyright (c) 2015 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.

Table of Contents

   1. Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3 ....................................................4
      1.1. Overview  . . . . . . . . . . . . . . . . . . . . . . . .   3 ...................................................4
      1.2. Background  . . . . . . . . . . . . . . . . . . . . . . .   3 .................................................4
      1.3. From RFC4244 RFC 4244 to RFC7044 . . . . . . . . . . . . . . . . .   4 RFC 7044 ..................................5
   2. Problem Statement . . . . . . . . . . . . . . . . . . . . . .   5 ...............................................5
   3. Interworking recommendations  . . . . . . . . . . . . . . . .   7 Recommendations ....................................7
      3.1. General recommendations . . . . . . . . . . . . . . . . .   7 Recommendations ....................................7
      3.2. Privacy considerations  . . . . . . . . . . . . . . . . .   7 Considerations .....................................8
      3.3. Headers in SIP Method . . . . . . . . . . . . . . . . . .   9 .....................................10
      3.4. SIP network/terminal using Network/Terminal Using Diversion Header Field
           to SIP
           network/terminal using Network/Terminal Using History-Info header  . . . . . . .   9 Header Field ...10
      3.5. SIP network/terminal using Network/Terminal Using History-Info header Header
           Field to SIP
           network/terminal using Network/Terminal Using Diversion header . . . . . . . . .  11
           Header Field ..............................................12
   4. Reminder of the Syntax for Header fields syntaxes reminder . . . . . . . . . . . . . . .  12 Fields .......................13
      4.1. History-Info header field syntax  . . . . . . . . . . . .  12 Header Field Syntax ..........................13
      4.2. Diversion header field syntax . . . . . . . . . . . . . .  15 Header Field Syntax .............................16
   5. Diversion header Header Field to History-Info header . . . . . . . . . . .  15 Header Field ............16
   6. History-Info header Header Field to Diversion header . . . . . . . . . . .  19 Header Field ............20
   7. Examples  . . . . . . . . . . . . . . . . . . . . . . . . . .  21 .......................................................22
     7.1.  Example with Diversion header changed Header Field Changed into
           History-Info
           header  . . . . . . . . . . . . . . . . . . . . . . . . .  21 Header Field .................................22
     7.2.  Example with History-Info header changed Header Field Changed into
           Diversion
           header  . . . . . . . . . . . . . . . . . . . . . . . . .  21 Header Field ....................................22
     7.3.  Example with two Two SIP networks using Networks Using History-Info header
           interworking Header
           Field Interworking with a SIP network using Network Using Diversion header  .  21
           Header Field ..............................................22
     7.4.  Additional interworking Interworking Cases . . . . . . . . . . . . . .  23 .............................23
   8. Backward Compatibility  . . . . . . . . . . . . . . . . . . .  25 .........................................26
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  25
   10. Security Considerations . . . . . . . . . . . . . . . . . . .  25
   11. Acknowlegements . . . . . . . . . . . . . . . . . . . . . . .  25
   12. ........................................26
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  25
     12.1. ....................................................26
      10.1. Normative References . . . . . . . . . . . . . . . . . .  26
     12.2. .....................................26
      10.2. Informative References . . . . . . . . . . . . . . . . .  26 ...................................27
   Appendix A.  Interworking between Diversion header Header Field and
                Voicemail URI  . . . . . . . . . . . . . . . . . . . . . . . .  27 ........................................29
     A.1.  Diversion header field Header Field to Voicemail URI . . . . . . . . .  27 ...................29
     A.2.  Voicemail URI to Diversion header field . . . . . . . . .  27 Header Field ...................29
   Acknowledgements ..................................................30
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  28 ..................................................30

1.  Introduction

1.1.  Overview

   For some VoIP-based services (eg.  Voicemail, based on VoIP (Voice over IP) services (e.g.,
   voicemail, Interactive Voice Recognition (IVR) (IVR), or automatic call
   distribution), it is helpful for the called SIP user agent to
   identify from whom and why the session was diverted.  For this
   information to be used in by various service providers or by
   applications, it needs to pass through the network.  This is possible
   with two different SIP header fields: the History-Info header field
   defined in [RFC7044] and the historic Diversion header field defined
   in [RFC5806] which [RFC5806].  Both of these header fields are both able to transport
   diversion information in the SIP signaling.

   Although the Diversion header field is not standardized, it has been
   widely implemented.  Therefore, it is useful to have guidelines to
   make this header field interwork with the standard History-Info
   header field.

   Note that the new implementation and deployment of the Diversion header
   field is are strongly discouraged.

   This document provides a mechanism for the translation of header fields
   field content
   translation between the Diversion header field and the History-Info
   header field.

   This document obsoletes [RFC6044].

1.2.  Background

   The obsoleted History-Info header field [RFC4244] and its extension
   for forming SIP service URIs (including Voicemail URI) [RFC4458] used
   to be recommended by IETF to convey redirection information.  They
   also used to be recommended in the "Communication Communication Diversion (CDIV)
   service"
   3GPP specification [TS_24.604].

   Concerning, the

   The Diversion header field, it field was originally described in an Internet Draft a document
   that was submitted to the SIP Working Group and was finally eventually
   published as an Independent Submission as [RFC5806] for the
   historical record and to
   provide record; it serves as a reference for this RFC.

   This header field contains a list of diverting URIs and associated
   information providing specific information as the reason for the call
   diversion.  Most of the first SIP-based implementations have
   implemented the Diversion header field when no standard solution was
   ready to deploy.  The IETF has standardized the History-Info header
   field partly because it can transport general history information.

   This allows the receiving part party to determine how and why the session
   is received.  As the History-Info header field may contain further
   information than call diversion information, it is critical to avoid
   losing information and to be able to extract the relevant data using
   the retargeting cause URI parameter described in [RFC4458] for the
   transport of the call forwarding reason.

   The Diversion header field and the History-Info header field have
   different syntaxes reminded syntaxes, which are described in this document.  Note that
   the main difference is that the History-Info header field is a
   chronological writing header whereas the Diversion header field
   applies a reverse chronology (i.e. (i.e., the first diversion entry read
   corresponds to the last diverting user).

   The

   Appendix A provides an interworking guideline between the Diversion
   header field and the Voicemail URI URI, which is another way to convey
   diversion information without using the History-Info header field.
   The Voicemail URI is defined in [RFC4458].

1.3.  From RFC4244 RFC 4244 to RFC7044 RFC 7044

   The detail details of why and how [RFC4244] has been updated and replaced was obsoleted by [RFC7044] is are
   provided in section Section 16 of [RFC7044].

   Here are the

   The main changes for implementation of the History-Info header field
   implementation:
   are as follows:

   1.  Added  The header field parameters "mp", "rc" "rc", and "np" were added to
       capture the specific method by which a target is determined.

   2.  Added a  A way to indicate a gap in the History-Info header field was
       added by adding using a "0" in the index.

   3.  To apply privacy, entries are were anonymized rather than removed.

   4.  Many SHOULD are SHOULDs were changed into MUST MUSTs to have a more reliable
       header.

   Backward compatibility

   Backward-compatibility aspects are discussed in section Section 8 of this
   document.

2.  Problem Statement

   This section provides the baseline terminology used in the rest of
   the document and defines the scope of interworking between the
   Diversion header field and the History-Info header field.

   They

   There are many ways in which SIP signaling can be used to modify a
   session destination before it is established and many reasons for
   doing so.  The behavior of the SIP entities that will have to further
   process the session downstream will sometimes vary depending on the
   reasons that lead led to changing the destination.  For destination, for example, whether it
   is for a simple proxy to route the session or for an application
   server (AS) to provide a supplementary service.  The Diversion header
   field and the History-Info header field differ in the approach and
   scope of addressing this problem.

   For clarity, the following vocabulary is used in this document:

   o  Retarget/redirect: these terms refer to the process of a Proxy
      Server/User Agent Client (UAC) changing a Request-URI (Section 7.1
      of [RFC3261]) in a request and thus changing the target of the
      request.  This includes changing the Request-URI due to a location
      service lookup and redirect processing.  This also includes
      internal (to a proxy/SIP intermediary) changes of the URI prior to
      the
      forwarding of the request.  The retarget term "retarget" is defined in
      [RFC7044].

   o  Call forwarding/call diversion/communication diversion: these
      terms are equivalent and refer to the Communications Diversion
      (CDIV) supplementary services, based on the ISDN Communication
      diversion supplementary services and defined in 3GPP [TS_24.604].
      They are applicable to entities which 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 header fields should be used.  Hereafter is provided
   clarification on the context in which the interworking is required.

   The Diversion header field has exactly the same scope as the call
   diversion service service, and each header field entry reflects a call
   diversion invocation.  The Diversion header field is used for
   recording call forwarding information which that could be useful to network
   entities downstream.  Today, this SIP header field is implemented by
   several manufacturers and deployed in networks.

   The History-Info header field is used to store all retargeting
   information
   information, including call diversion information.  As such, the
   History-Info header field [RFC7044] is used to convey call diversion 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, 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 the History-Info
   header field and one using the Diversion header field.

   The

   [RFC7044] defines three header field parameters, parameters: "rc", "mp", and
   "np".  The header field parameters "rc" and "mp" indicate the
   mechanism by which a new target for a request is determined.  The
   header field "np" reflects that the target has not changed.  All
   parameters contain an index whose value refers to the hi-index of the
   hi-entry with an
   hi-entry, which contains a hi-targeted-to-uri that represents the
   Request-URI that was retargeted.

   Since both header fields address call forwarding needs, diverting
   information could be mixed-up mixed up or be inconsistent if both are present
   in an uncoordinated fashion in the INVITE request.  So, Diversion and
   History-Info header fields must not independently coexist in the same
   session signaling.  This document addresses how to convert
   information between the Diversion header field and the History-Info
   header field, field and when and how to preserve both header fields to cover
   additional cases.

   For the transportation of consistent diversion information
   downstream, it is necessary to make the two header fields interwork.
   Interworking between the Diversion header field and the History-Info
   header field is introduced in sections Sections 5 and 6.  Since the
   coexistence scenario may vary from one use case to another one, another,
   guidelines regarding interaction of header fields interaction are proposed in section
   Section 3.

3.  Interworking recommendations Recommendations

3.1.  General recommendations Recommendations

   Interworking function: function (IWF):

      In a normal case, the network topology assumption is that the
      interworking described in this document should be performed by a
      specific SIP border device which that is aware, by configuration, that
      it is at the border between two regions, one using History-Info the History-
      Info header field and one using the Diversion header field.

   As the History-Info header field is a standard solution, a network
   using the Diversion header field must be able to provide information
   to a network using the History-Info header field.  In this case, to
   avoid
   header fields coexistence of header fields, it is required to replace, as
   often as possible, the Diversion header field with the History-Info
   header field in the INVITE request during the interworking.

   Since, the History-Info header field has a wider scope than the
   Diversion header field, it may be used for other needs and services other
   than call diversion.  In addition addition, to trace call diversion
   information, the History-Info header field also acts as a session
   history and can store all successive Request-URI values.
   Consequently, even if it should be better to remove the History-Info
   header field after the creation of the Diversion header field avoiding to
   avoid confusion, the History-Info header field must remain unmodified
   in the SIP signaling if it contains supplementary (non-diversion)
   information.  It is possible to have History-Info header fields that
   do not have values that can be mapped into the Diversion header
   field.  In this case, no interworking with the Diversion header field
   should be performed 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

   In 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. cases.  Additional
   interworking cases are described in section 7.5. Section 7.4.

3.2.  Privacy considerations Considerations

   When a SIP message is forwarded to a domain for which the SIP
   intermediary is not responsible, a Privacy Service at the boundary of
   the domain applies the appropriate privacy based on the value of the
   Privacy header field in the message header or in the privacy
   parameter within the concerned header. header:

   1.  For the History-Info header field, it is the Privacy header field
       included as the "headers" component of the hi-targeted-to-uri in
       the individual hi-entries with the
       possible priv-value "history".

   2.  For the Diversion header field, it is the diversion-privacy
       parameter "privacy" in each Diversion header field.

   o

   For the History-Info header field, as recommended in [RFC7044]:

         -

   o  If there is a Privacy header field in the message header of a
      request with a priv-value of "header" or "history", then all the
      hi-targeted-to-uris (in the hi-entries associated with the domain
      for which the SIP intermediary is responsible) are anonymized by
      the Privacy Service.  The Privacy Service must change any
      hi-targeted-to-uri in these hi-entries that have not been
      anonymized to the anonymous SIP URI "anonymous@anonymous.invalid"
      as recommended in sections
         4.1.1.3 and Sections 4.1.1.2 and 4.1.1.3 of [RFC3323].

         -

   o  If there is a Privacy header field in the "headers" component of a
      hi-targeted-to-uri with a priv-value of "history", then all the
      concerned hi-entries must be anonymized as described above prior
      to forwarding.

   The Privacy Service must remove the Privacy header field from the
   "headers" component of the hi-targeted-to-uris of the concerned
   hi-entries and the priv-value of "history" from the Privacy header
   field in the message header of the request prior to forwarding.  If
   there are no remaining priv-values in the Privacy header field, the
   Privacy Service must remove the Privacy header field from the
   request.

   o

   For the Diversion header field:

         -

   o  If there is a Privacy header field in the message header of a
      request with a priv-value of "header", then all the addresses in
      the Diversion header fields (associated with the domain for which
      the SIP intermediary is responsible) are anonymized by the Privacy
      Service by changing the address to the anonymous SIP URI
      "anonymous@anonymous.invalid" as recommended in
         sections 4.1.1.3 and Sections 4.1.1.2
      and 4.1.1.3 of [RFC3323] prior to forwarding.

         -

   o  For the each Diversion header field or each entry in the Diversion
      header field, if there is a diversion-privacy parameter with a
      value set to "full", "uri" "uri", or "name", then the concerned
      Diversion header field address must be anonymized as described
      above prior to forwarding.

   In the concerned Diversion header field entries, the diversion-
   privacy parameter must be removed from the header.

   The privacy information interworking as described in sections Sections 5 and 6
   must only be considered within a trusted domain that ensure to
   correctly apply ensures correct
   application of the privacy requirements.

3.3.  Headers in SIP Method

   The recommended interworking presented in this document should apply
   only for INVITE requests.

   In 3xx responses:

      Both History-Info and Diversion header fields could be present in
      3xx responses.

      When a proxy wants to interwork with a network supporting the
      other header field, it should apply the interworking between
      Diversion header field and History-Info header field in the 3xx
      response.

      When a recursing proxy redirects an initial INVITE after receiving
      a 3xx response, it should add as a last entry either a Diversion
      header field or a History-Info header field (according to its
      capabilities) in the forwarded INVITE.  Local policies could apply
      regarding whether or not to send the received header field in the
      next INVITE or not. INVITE.

   In SIP responses other than 100:

      All SIP responses where the History-Info header field could be
      present are not used for the Call Forwarding call forwarding service and should
      not be changed into the Diversion header field.  The destination
      network must be transparent to the received History-Info header
      field.

   Note: The following mapping is inspired from by the ISUP ISDN User Part (ISUP)
   to SIP interworking described in [TS_29.163].

3.4.  SIP network/terminal using Network/Terminal Using Diversion Header Field to SIP network/terminal using Network/
      Terminal Using History-Info header Header Field

   When the Diversion header field is used to create a History-Info
   header field, the Diversion header field must be removed in the
   outgoing INVITE.  It is considered assumed that all the information present in
   the Diversion header field is transferred in the History-Info header
   field.

   If a History-Info header field is also present in the incoming INVITE
   (in addition to the Diversion header field), the Diversion header
   field and History-Info header field present must be mixed mixed, and only
   the diversion information not yet present in the History-Info header
   field must be inserted as a last entry (more (most recent) in the existing
   History-Info header field, following the creation process recommended
   in [RFC7044].

   As an example, this could be the case of an INVITE coming from
   network_2 using the Diversion header field but previously passed
   through network_1 using the History-Info header field (or the
   network_2 uses History-Info header field to transport successive URI
   information) and going to network_3 using the History-Info header
   field.

                       IWF*                                  IWF*
     network1
     network_1          |                network_2            |network_3
    History-Info        |                 Diversion           |using
                        |                                     |Hist-Info
                        |                                     |History-
                        |                                     |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:proxyP1>;index=1,|       |       |     |       |        |
|       | <sip:userB >; index=1.1;rc=1 <sip:userB>;index=1.1;rc=1    |       |     |       |        |
|       |       |       |       |       |       |     |       |        |
|       |       |INVITE |       |       |       |     |       |        |
|       |       |------>|       |       |       |     |       |        |
|       |       |History-Info:  |       |       |     |       |        |
|       |       |<sip:proxyP1>; index=1,|       |<sip:proxyP1>;index=1, |       |     |       |        |
|       |<sip:userB>; index=1.1;rc=1,       |       |<sip:userB>;index=1.1;rc=1,    |     |       |        |
|       |<sip:userC; cause=302>; index=1.1.1;mp=1.1       |       |<sip:userC;cause=302>;index=1.1.1;mp=1.1     |        |

   In this case, the incoming INVITE contains a Diversion header field
   and a History-Info header field.  Therefore, as recommended in this
   document, it is necessary to create create, for network_3, a single History-
   Info header field gathering existing information from both the
   History-Info and the Diversion header fields received.  Anyway, it is
   required from that network_2 (ie.IWF) to (i.e., IWF) remove the Diversion header field
   when the message is going to a network not using the Diversion header
   field.  Then  Then, network_3 could use call forwarding information that is
   present in a single header field and add its own diversion
   information if necessary.

   Notes:

   1.  If a network is not able either to use only one header field each
       time,
       time or to maintain both header fields up to date, the
       chronological order can not cannot be certified.

   2.  It is not possible to have only a Diversion header field when the
       History-Info header field contains more than call diversion
       information.  If previous policy recommendations are applied, the
       chronological order is respected as Diversion entries are
       inserted at the end of the History-Info header field taking into
       account the Diversion internal chronology.

3.5.  SIP network/terminal using Network/Terminal Using History-Info header Header Field to SIP network/
      terminal using
      Network/Terminal Using Diversion header Header Field

   When the History-Info header field is interpreted to create a
   Diversion header field, some precautions must be taken.

   If the History-Info header field contains only call forwarding
   information, then it must be deleted after the interworking.

   If the History-Info header field contains other information, then
   only the information of concern to the diverting user must be used to
   create entries in the Diversion header field field, and the History-Info
   header field must be kept as received in the INVITE and forwarded
   downstream.

   Note: The History-Info header field could be used for other reasons other
   than call diversion services, for example example, by a service which need that needs to
   know if a specific AS had has yet been invoked in the signaling path.  If
   the call is later forwarded to a network using the History-Info
   header field, it would be better not to lose history information due
   to passing though the network which that only support supports the Diversion header
   field.  A recommended solution must not disrupt the standard behavior
   behavior, and networks which that do not implement the History-Info header
   field must be transparent to a received History-Info header field.

   If a Diversion header field is present in the incoming INVITE (in
   addition to the History-Info header field), only diversion
   information present in the History-Info header field but not in the
   Diversion header field must be inserted from the last entry (more (most
   recent) into the existing Diversion header field as recommended in the
   [RFC5806].

   Note that the chronological order could not be certified.  If
   previous policy recommendations are respected, this case should not
   happen.

   Forking case:

      The History-Info header field enables the recording of sequential
      forking for the same served-user. served user.  During an interworking, interworking from the
      History-Info header field to the Diversion header field, the
      History-Info entries containing a forking situation (with an
      incremented "index" parameter) could possibly be mapped if it
      contains they
      contain a call forwarding "cause" parameter.  The interworking
      entity could choose to create only a Diversion entry or not apply
      the interworking.  The choice could be done according a local
      policy.

   The same logic is applied for an interworking with Voicemail URI (see
   the
   Appendix A).

4.  Reminder of the Syntax for Header fields syntaxes reminder Fields

4.1.  History-Info header field syntax Header Field Syntax

   The ABNF syntax [RFC5234] for the History-Info header field and
   header field parameters is as follows: follows.

   History-Info       = "History-Info" HCOLON hi-entry *(COMMA hi-entry)
   hi-entry           = hi-targeted-to-uri *(SEMI hi-param)
   hi-targeted-to-uri = name-addr
   hi-param           = hi-index/hi-target-param/hi-extension
   hi-index           = "index" EQUAL index-val
   index-val          =  number *("." number)
   number             =  [ %x31-39 *DIGIT ] DIGIT
   hi-target-param    = rc-param / mp-param / np-param
   rc-param           = "rc" EQUAL index-val
   mp-param           = "mp" EQUAL index-val
   np-param           = "np" EQUAL index-val
   hi-extension       = generic-param

   The ABNF definitions for "generic-param", "name-addr", "HCOLON",
   "COMMA", "SEMI", and "EQUAL" are from[RFC3261]. from [RFC3261].

   The History-Info header field is specified in [RFC7044].  The top-
   most History-Info entry (first in the list) corresponds to the oldest
   history information.

   Cause URI parameter:

      A hi-entry may contain a cause URI parameter expressing the
      diversion reason.  This cause URI parameter is defined in
      [RFC4458].  The ABNF grammar [RFC5234] for the cause-param
      parameter is reminded shown below as it has been subject to Errata [ID:
      1409] in Erratum ID 1409
      [Err1409] for [RFC4458].  The Status-Code is defined in [RFC3261].

      cause-param = "cause=" Status-Code

      This parameter is also named

      The cause-param parameter is a SIP/SIPS URI parameter and should
      be inserted in the History-Info entry (URI) of the diverted-to
      user in case of call diversion as recommended in the 3GPP CDIV
      specification [TS_24.604].  The cause values used in the cause-param cause-
      param for the diverting reason are listed in
      [RFC4458] . [RFC4458].  Because
      it is a parameter dedicated to call forwarding service, its
      presence is used to determine that a hi-
      entry hi-entry is a diverting user.
      More precisely, each diverting user is located in the hi-entry
      before the one containing a cause-param with cause value as listed
      in [RFC4458].

   Reason header field:

      Moreover, the

      The Reason header field defined in [RFC3326] should be escaped in
      the hi-entry of the diverting user when the call diversion is due
      to a received SIP response.  The Reason header field contains a
      cause parameter set to the true SIP response code received
      (Status-Code).

      Therefore, in case of call diversion due to a SIP response, both
      cause parameters should be used.  The complexity is that these
      parameters could be used at the same time in the History-Info
      header field but not in the same hi-entry and not with the same
      meaning.  Only the cause-param is dedicated to call diversion
      service.  The 'cause' Reason header field parameter is not taken
      into account in the mapping with a Diversion header field.

   Target URI parameter:

      The

      [RFC4458] also defines the 'target' URI parameter parameter, which could be
      inserted in a Request-URI and consequently in the hi-targeted-
      to-uri.
      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, hi-
      entries, the 'target' URI parameter is not taken into account
      regarding the interworking with the Diversion header field.  From
      the Diversion header field, it could be possible to create the
      'target' URI parameter in the hi-entries and/or in the Request-URI Request-
      URI, but this possibility is based on local policies not described
      in this document.

   Privacy header field:

      A Privacy header field as defined in [RFC3323] could also be
      embeded
      embedded in hi-entries with the 'history' value defined in
      [RFC7044].

   Index header field parameter:

      The index parameter is a string of digits, separated by dots 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] [TS_24.604],
   which must be applied, this parameter has no impact on the mapping
   and must only be copied with the served user address.

   Missing entry:

      If the request clearly has a gap in the hi-entry (i.e., the last
      hi-entry and Request-URI differ), the entity adding an a hi-entry
      must add a single index with a value of "0" (i.e., the nonnegative non-
      negative integer zero) prior to adding the appropriate index for
      the action to be taken (eg. (e.g., Index=1.1.2.0.1).  Prior to any
      application usage of the History-Info header field parameters, the
      SIP entity that processes the hi-entries must evaluate the
      hi-entries and determine if there are any gaps in the hi-entries. them.

   "histinfo" option tag:

      According to [RFC7044], a proxy that receives a Request with the
      "histinfo" option tag in the Supported header field should return
      captured History-Info in subsequent, provisional provisional, and final
      responses to the Request.  The behavior depends upon whether or
      not the local policy supports the capture of History-Info or not. History-Info.

   Example:

   History-Info:
   <sip:diverting_user1_addr?Privacy=none&Reason=SIP%3Bcause%3D302>;
   index=1,
   <sip:diverting_user2_addr;cause=480?Privacy=history>;index=1.1;mp=1,
   <sip:last_diversion_target;cause=486>; index=1.1.1;mp=1.1
   <sip:last_diversion_target;cause=486>;index=1.1.1;mp=1.1

4.2.  Diversion header field syntax Header Field Syntax

   The following text is restating the exact syntax that the production
   rules in [RFC5806] define, but using [RFC5234] ABNF: ABNF [RFC5234]:

    Diversion           = "Diversion" HCOLON diversion-params
                                     *(COMMA diversion-params)
    diversion-params    = name-addr *(SEMI (diversion-reason /
                          diversion-counter / diversion-limit /
                          diversion-privacy / diversion-screen /
                          diversion-extension))
    diversion-reason    = "reason" EQUAL ("unknown" / "user-busy" /
                          "no-answer" / "unavailable" / "unconditional"
                          / "time-of-day" / "do-not-disturb" /
                          "deflection" / "follow-me" / "out-of-service"
                          / "away" / token / quoted-string)
    diversion-counter   = "counter" EQUAL 1*2DIGIT
    diversion-limit     = "limit" EQUAL 1*2DIGIT
    diversion-privacy   = "privacy" EQUAL ("full" / "name" / "uri" /
                          "off" / token / quoted-string)
    diversion-screen    = "screen" EQUAL ("yes" / "no" / token /
                          quoted-string)
    diversion-extension = token [EQUAL (token / quoted-string)]

   Note: The Diversion header field could be used in the comma-separated
   format as described below and in a header-separated format.  Both
   formats could be combined in a received INVITE as recommended in
   [RFC3261].

   Example:

   Diversion:
   <sip:diverting_user2_addr>; reason=user-busy; counter=1;
   privacy=full,
   <sip:diverting_user1_addr>; reason=unconditional; counter=1;
   privacy=off
   <sip:diverting_user2_addr>;reason=user-busy;counter=1;privacy=full,
   <sip:diverting_user1_addr>;reason=unconditional;counter=1;privacy=off

5.  Diversion header Header Field to History-Info header Header Field

   The following text is valid only if no History-Info header field is
   present in the INVITE request.  If at least one History-Info header
   field is present, the interworking function must adapt its behavior
   to respect the chronological order.  For more information, see section
   Section 3.

   Concerning the privacy information in the Diversion header field, the
   following mapping only applies within a trusted domain, otherwise domain; for other
   domains, see the privacy considerations in section Section 3.2.

   For N Diversion entries entries, N+1 History-Info entries must be created.
   To create the History-Info entries in the same order than as during a
   session establishment, the Diversion entries must be mapped from the
   bottom-most until to the top-most.  Each Diversion entry shall be mapped
   into a History-Info entry.  An additional History-Info entry (the
   last one) must be created with the diverted-to party address present
   in the Request-URI of the received INVITE.  The mapping is described
   in the table hereafter. below.

   The first entry created in the History-Info header field contains:

      -

   o  a hi-target-to-uri hi-targeted-to-uri with the name-addr parameter of the bottom-
      most Diversion header field,

      - field.

   o  if a privacy parameter is present in the bottom-most Diversion
      entry, then a Privacy header field must be escaped in the History-
      Info header field as described in the table hereafter,

      - below.

   o  a hi-index set to 1.

   For each of the following Diversion entry entries (from bottom to top), the History-
   info
   History-Info entries are created as following follows (from top to bottom):

 Source                                   Destination
 Diversion header component:              History-Info header component:
 =======================================================================
 Name-addr                                Hi-target-to-uri
 name-addr                                hi-targeted-to-uri

 =======================================================================
 Reason
 reason of the previous                   Cause                   cause URI parameter
 Diversion entry                          A cause-param "cause" is
                                          added in each hi-entry
                                          (except the first one)
 "unknown"----------------------------------404 (default 'cause' value)
 "unconditional"----------------------------302
 "user-busy"--------------------------------486
 "no-answer"--------------------------------408
 "deflection "------------------------------480 or 487
 "unavailable"------------------------------503
 "time-of-day"------------------------------404 (default)
 "do-not-disturb"---------------------------404 (default)
 "follow-me"--------------------------------404 (default)
 "out-of-service"---------------------------404 (default)
 "away"-------------------------------------404 (default)
 ======================================================================
 Counter                                  Hi-index
 counter                                  hi-index
 "1" or parameter ------------------------The previous created index
 no
 not present                              is incremented extended with ".1"
 Superior to "1" -------------------------Create N-1 placeholder History
 (i.e.
 (i.e., N)                                entry with the previous index
                                          extended with ".1"
                                          Then the History-Info header
                                          created with the Diversion
                                          entry with the previous index
                                          extended with ".1"
 ======================================================================
 Privacy
 privacy                                  Privacy header escaped in the
                                          hi-targeted-to-uri
 "full"-----------------------------------"history"
 "Off"------------------------------------Privacy header field
                                          absent or "none"
 "name"-----------------------------------"history"
 "uri"------------------------------------"history"
 ======================================================================
                                          hi-target-param
                                          A
                                          An mp-param "mp" is added in
                                          each created hi-entry
                                          (except the first one)
                                          The "mp" parameter is set to
                                          the index value of the
                                          preceding hi-entry.
 =======================================================================

   A last History-Info entry is created and contains:

      -

   o  a hi-target-to-uri hi-targeted-to-uri with the Request-URI of the INVITE request,

      - request.

   o  a cause-param from the top-most Diversion entry, mapped from the
      diversion-reason as described above,

      - above.

   o  an index set to the previous created index extended with a new
      level ".1" added at the end,

      - end.

   o  a hi-target-param set to "mp" equals to the index value of the
      previous preceding hi-entry.

   Notes:

   1.  For other optional Diversion parameters, there is no
       recommendation as the History-Info header field does not provide
       equivalent parameters.

   2.  For values of the diversion-reason which that are mapped with a
       recommended default value, it could also be possible to choose
       another value.  The cause-param URI parameter offers less fewer
       possible values than the diversion-reason parameter.  However, it
       has been considered that the cause-param values list was
       sufficient to implement CDIV service as defined in 3GPP[TS_24.604] 3GPP
       [TS_24.604] as it
       cover covers a large portion of cases.

   3.  The Diversion header field can contain a "tel" URI as defined in
       [RFC3966]in
       [RFC3966] in the name-addr parameter.  The History-Info header
       field can also contain an address that is a "tel" URI URI, but if
       this hi-entry has to be completed with either a SIP header field (eg.
       (e.g., Reason or Privacy) or a SIP URI parameter (eg. (e.g., 'cause'
       or
       'target'); 'target'), the "tel" URI must be converted into a SIP URI.
       [RFC3261] gives an indication as to the mapping between sip: and
       tel: URIs URIs, but in this particular case case, it is difficult to assign
       a valid hostport as the diversion has occurred in a previous network
       and a valid hostport is difficult to determine.  So, it is
       suggested that in case of "tel" URI in the Diversion header
       field, the History-Info header field should be created with a SIP
       URI with user=phone and a domain set to "unknow.invalid". "unknown.invalid".

   4.  The Diversion header field allows the carrying of a counter that
       retains the information about the number of successive
       redirections.  History-Info does not have an equivalent because
       to trace and count the number of diversion diversions, it is necessary to
       count the cause parameter containing a value associated to a call
       diversion listed in[RFC4458].  Read in [RFC4458].  Reading the index value is not
       enough.  With the use of the "placeholder" entry the History-info History-Info
       header field field, entries could can reflect the real number of diversion
       occurred still diversions
       that occurred, thanks to the cause-param.

   Example of placeholder entry in the History-Info header field:

      <sip:unknown@unknown.invalid;cause=xxx>;index=1.1

      <sip:bob_addr;cause=404>;index=1.1.1;mp=1.1

   "cause=xxx" reflects the diverting reason of a previous diverting
   user.  For a placeholder hi-entry hi-entry, the value "404" must be taken for
   the cause-param and so, located in the next hi-entry.

   Concerning

   For recommendations for local policies recommendations about regarding the coexistence of
   header fields
   coexistence in the INVITE request, see sections Sections 3 and 7.5. 7.4.

6.  History-Info header Header Field to Diversion header Header Field

   Concerning the privacy information for the History-Info header field,
   the following mapping only applies within a trusted domain, otherwise domain; for other
   domains, see the privacy considerations in section Section 3.2.

   To create the Diversion entries in the same order than as during a session
   establishment, the History-Info entries must be mapped from the top-most until top-
   most to the bottom-most.  The first History-Info header field entry
   selected will be mapped into the last Diversion header field entry
   and so on.  One Diversion header field entry must be created for each
   History-Info entry having that has cause-param with a value listed in
   [RFC4458].

   Diversion information:

   The Target_entry definitions of "Target_entry" and the Diverting_entry terms defined below "Diverting_entry" are used included
   below to ease help readers understand the mapping understanding of the History-Info
   header field.

   The diversion information can be identified by finding the following
   hi-entries:

   o  Target_entry: hi-entries containing a cause-param URI parameter
      with a value listed in [RFC4458]will [RFC4458] will contain the diversion reason
      and the address of the target of the concerned call forwarding.
      Following the [RFC7044]these
      Per [RFC7044], these hi-entries may also contain a hi-
      target-param hi-target-param
      set to "mp".

   o  Diverting_entry: For each previously identified hi-entry:

         -

      *  If there is a an "mp" header field parameter, the hi-entry whose
         hi-index matches the value of the hi-target-param "mp" will
         contain the diverting party address, its possible privacy privacy, and/
         or SIP reason when the retargeting has been caused by a
         received SIP response.

         -

      *  If there is no "mp" header field parameter, the information of
         the diverting party address, privacy and/or SIP reason will be
         found in the hi-entry that precede this identified hi-entry.

   Note: Following Per [RFC7044], all retargeting entries must point to a hi-entry
   that contain a contains an "mp" parameter parameter, but for backward compatibility backward-compatibility
   reasons, it may be absent from some of the received hi-entries.  You
   can find  See
   Section 8 for more information on the backward compatibility aspects in
   section 8. compatibility.

   The History-Info header field must be mapped into the Diversion
   header field as following: follows:

   Source                                    Destination
   History-Info header component:            Diversion header component:
   =====================================================================
   Hi-target-to-uri                          Name-addr
   hi-targeted-to-uri                        name-addr
   of the Diverting_entry.

   =====================================================================
   Cause-param                               Reason
   cause-param                               reason
   of the Target_entry
   404---------------------------------------"unknown" (default value)
   302---------------------------------------"unconditional"
   486---------------------------------------"user-busy"
   408---------------------------------------"no-answer"
   480 or 487--------------------------------"deflection "
   503---------------------------------------"unavailable"
   =====================================================================
   Hi-index                                  Counter
   hi-index                                  counter
   Mandatory parameter for-------------------The counter is set to "1".
   History-Info reflecting
   the chronological order
   of the information.
   =====================================================================
   Privacy header field escaped              Privacy              privacy
   in the hi-targeted-to-uri
   of the Diverting_entry
   "history"----------------------------------"full"
   Privacy header field ----------------------"Off"
   Absent or "none"
   =====================================================================

   Note: For other optional History-Info parameters, there is no
   recommendation as the Diversion header field does not provide
   equivalent parameters.

   Concerning

   For recommendations for local policies recommendations about regarding the coexistence of
   header fields
   coexistence in the INVITE request, see section Section 3.

7.  Examples

7.1.  Example with Diversion header changed Header Field Changed into History-Info header
      Header Field

   INVITE sip:last_diverting_target
   Diversion:
   <sip:diverting_user3_address>;reason=unconditional;counter=1;
   privacy=off,
   <sip:diverting_user2_address>;reason=user-busy;counter=1;
   privacy=full,
   <sip:diverting_user1_address>;reason=no-answer;counter=1;
   privacy=off

   Mapped into:

   History-Info:
   <sip:diverting_user1_address?privacy=none>; index=1,
   <sip:diverting_user1_address?Privacy=none>;index=1,
   <sip:diverting_user2_address;
   cause=408?privacy=history>;index=1.1;mp=1,
   cause=408?Privacy=history>;index=1.1;mp=1,
   <sip:diverting_user3_address;
   cause=486?privacy=none>;index=1.1.1;mp=1.1,
   <sip:last_diverting_target; cause=302>;index=1.1.1.1;mp=1.1.1
   cause=486?Privacy=none>;index=1.1.1;mp=1.1,
   <sip:last_diverting_target;cause=302>;index=1.1.1.1;mp=1.1.1

7.2.  Example with History-Info header changed Header Field Changed into Diversion header
      Header Field

   INVITE sip:last_diverting_target; cause=486
   History-Info:
   <sip:diverting_user1_address?privacy=history>; index=1,
   <sip:diverting_user2_address; cause=302?
   privacy=none>;index=1.1;mp=1,
   <sip:last_diverting_target; cause=486>;index=1.1.1;mp=1.1
   <sip:diverting_user1_address?Privacy=history>;index=1,
   <sip:diverting_user2_address;cause=302?Privacy=none>;index=1.1;mp=1,
   <sip:last_diverting_target;cause=486>;index=1.1.1;mp=1.1

   Mapped into:

   Diversion:
   <sip:diverting_user2_address>; reason=user-busy; counter=1;
   privacy=off,
   <sip:diverting_user1_address>; reason=unconditional; counter=1;
   privacy=full
   <sip:diverting_user2_address>;reason=user-busy;counter=1;privacy=off,
   <sip:diverting_user1_address>;reason=unconditional;counter=1;privacy=
   full

7.3.  Example with two Two SIP networks using Networks Using History-Info header
      interworking Header Field
      Interworking with a SIP network using Network Using Diversion header Header Field

   A -> P1 -> B -> C -> P2 -> D-> E
   A, B, C, D and E are users.
   B, C and D have Call Forwarding call forwarding service invoked.
   P1 and P2 are proxies.
   Only relevant information is shown on the following call flow.

                          IWF*                                IWF*
     SIP network using     |           SIP network using       |SIP net.
       History-Info        |                Diversion          |using
                           |                                   Hist-Info                                History-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:proxyP1>;index=1,       |       |     |      |       |
   |       | <sip:userB>; index=1.1; rc=1 <sip:userB>;index=1.1;rc=1   |       |     |      |       |
   |       |       |       |      |       |       |     |      |       |
   |       |       |INV C  |      |       |       |     |      |       |
   |       |       |------>|      |       |       |     |      |       |
   |       |       |History-Info: |       |       |     |      |       |
   |       |       <sip:proxyP1>; index=1,|       <sip:proxyP1>;index=1, |       |     |      |       |
   |       |       <sip:userB>; index=1.1; rc=1,       <sip:userB>;index=1.1;rc=1,    |     |      |       |
   |       |       <sip:proxyP2; cause=302>; index=1.1.1; mp=1.1       <sip:proxyP2;cause=302>;index=1.1.1;mp=1.1  |       |
   |       |       |       |      |       |       |     |      |       |
   |       |       |       |INV C |       |       |     |      |       |
   |       |       |       |----->|       |       |     |      |       |
   |       |       | Diversion:   |       |       |     |      |       |
   |       |       | userB; reason=unconditional; counter=1; privacy=off     <sip:userB>;reason=unconditional;counter=1;privacy=off|
   |       |       |       |History-Info: |       |     |      |       |
   |       |       |       <sip:proxyP1>; index=1,|       <sip:proxyP1>;index=1, |     |      |       |
   |       |       |       <sip:userB>;index=1.1;rc=1,  |      |       <sip:userB>; index=1.1; rc=1,|       |
   |       |       |       <sip:proxyP2;cause=302>;index=1.1.1;mp=1.1  |       <sip:proxyP2; cause=302>; index=1.1.1; mp=1.1
   |       |       |       |      |       |       |     |      |       |
   |       |       |       |      |INV C  |       |     |      |       |
   |       |       |       |      |------>|       |     |      |       |
   |       |       |       |     No modification of Diversion header   |
   |       |       |       |      |       |       |     |      |       |
   |       |       |       |      |       |INV C  |     |      |       |
   |       |       |       |      |       |------>|     |      |       |
   |       |       |       |      |       |       |     |      |       |
   |       |       |       |      |       |<--180-|     |      |       |
   |       |       |       |      |       |       |     |      |       |
   |       |       |       |      |  No response timer expires |       |
   |       |       |       |      |       |---INV D --->|      |       |
   |       |       |Diversion:                          |      |       |
   |       |       |userC; reason=no-answer; counter=1; privacy=full,     <sip:userC>;reason=no-answer;counter=1;privacy=full,  |
   |       |       |userB; reason=unconditional; counter=1; privacy=off,     <sip:userB>;reason=unconditional;counter=1;privacy=off|
   |       |       |    History-Info:                   |      |       |
   |       |       |    <sip:proxyP1>; index=1,    <sip:proxyP1>;index=1,          |      |       |
   |       |       |    <sip:userB>; index=1.1; rc=1,    <sip:userB>;index=1.1;rc=1,     |      |       |
   |       |       |    <sip:proxyP2; cause=302>; index=1.1.1; mp=1.1    <sip:proxyP2;cause=302>;index=1.1.1;mp=1.1     |
   |       |       |       |      |       |       |     |      |       |
   |       |       |       |      |       |       |     |INV E |       |
   |       |       |       |      |       |       |     |----->|       |
   |       |       |Diversion:                                 |       |
   |       |       |userD; reason=time-of-day; counter=1; privacy=off     <sip:userD>;reason=time-of-day;counter=1;privacy=off, |
   |       |       |userC; reason=no-answer; counter=1; privacy=full,     <sip:userC>;reason=no-answer;counter=1;privacy=full,  |
   |       |       |userB; reason=unconditional; counter=1; privacy=off,     <sip:userB>;reason=unconditional;counter=1;privacy=off|
   |       |       |     History-Info:                         |       |
   |       |       |     <sip:proxyP1>; index=1,     <sip:proxyP1>;index=1,                |       |
   |       |       |     <sip:userB>; index=1.1; rc=1,     <sip:userB>;index=1.1;rc=1,           |       |
   |       |       |     <sip:proxyP2; cause=302>; index=1.1.1; mp=1.1     <sip:proxyP2;cause=302>;index=1.1.1;mp=1.1    |
   |       |       |       |      |       |       |     |      |       |
   |       |       |       |      |       |       |     |      | INV E |
   |       |       |       |      |       |       |     |      |------>|
   |       |   History-Info:      |       |       |     |      |       |
   |       |   <sip:proxyP1>; index=1,   <sip:proxyP1>;index=1,     |       |     |      |       |
   |       |   <sip:userB>; index=1.1; rc=1,   <sip:userB>;index=1.1;rc=1,        |     |      |       |
   |       |   <sip:proxyP2; cause=302>; index=1.1.1; mp=1.1,   <sip:proxyP2;cause=302>;index=1.1.1;mp=1.1,     |       |
   |       |   <sip:userC ?privacy=history>; index=1.1.1.0.1, ?Privacy=history>;index=1.1.1.0.1,   |       |
   |<sip:userD;cause=408?privacy=none>;index=1.1.1.0.1.1; mp=1.1.1.0.1,|
   |<sip:userD;cause=408?Privacy=none>;index=1.1.1.0.1.1;mp=1.1.1.0.1, |
   |       |<sip:userE;cause=404>;index=1.1.1.0.1.1.1;mp=1.1.1.0.1.1   |       |<sip:userE; cause=404>; index=1.1.1.0.1.1.1; mp=1.1.1.0.1.1|
   |       |       |       |      |       |       |     |       |      |
   |       |       |       |      |       |       |     |       |      |

   *

   Note: The IWF is an interworking function which that could be a stand-
    alone stand-alone
   equipment not defined in this document (it could be a proxy).

7.4.  Additional interworking Interworking Cases

   Even if for particular cases in which both header fields could coexist,
   it should be the responsibility of the network local policy responsibility to make
   it work together.  Here are described  This section describes some situations and some
   recommendations on the behavior to follow. behavior.

   In the case where there is one network which that includes different nodes,
   some of them supporting the Diversion header field and other ones
   supporting History-info the History-Info header field, there is a problem when any
   node handling a message does not know the next node that will handle
   the message.  This case can occur when the network has new and old
   nodes, the older ones using the Diversion header field and the more most
   recent using the History-Info header field.

   While a network replacement may be occurring 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 capabilities, then the problem is more important.  In this case case,
   there is a need to pass both the History-Info header field and the
   Diversion header field within the core network.

   These header fields need to be equivalent to ensure that, whatever
   the node receiving the message, the correct diversion information is
   received.  This requires that that, whatever the received header field,
   there is a requirement to be able to compare the header fields and to
   convert the header fields.  Depending upon the node capability, it
   may be possible to make assumptions as to how this is handled.

   o  If it is known that the older Diversion header field supporting
      nodes do does not pass on any received History-Info header field field,
      then the interworking becomes easier.  If a message is received
      with only Diversion header fields fields, then it has originated from an 'old'
      old node.  The equivalent History-Info entries can be created created, and
      these can then be passed as well as the Diversion header field.

   o  If the node creates a new History-Info header field for a call
      diversion, then an additional Diversion header field must be
      created.

   o  If the next node is an 'old' node old node, then the Diversion header field
      will be used by that node 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 node, then the presence of both the
      Diversion header field and History-Info header field means that
      interworking has already occurred and the Diversion and History-Info History-
      Info entries must be considered equivalent.

   o  If both nodes pass on both the History-Info header field and
      Diversion header field but only actively use one, then both types
      of node nodes need to perform the interworking and must maintain
      equivalence between the header fields.  This will eventually
      result in the use of the Diversion header field being deprecated
      when all nodes in the network support the History-Info header
      field.

   o  If a gap is identified in the History-Info header field by a node
      that would create a new entry, it shall add a single index with a
      value of "0" prior to adding the appropriate index for the action
      to be taken.

8.  Backward Compatibility

   The

   Issues with backward compatibility aspects are due to the changes on evolution of the
   History-Info header field evolution from [RFC4244] to [RFC7044]that
   are [RFC7044], as described
   in section Section 1.3 of this document.  The backawrd  Backward compatibility is taken
   into account throughout this document for the interworking with the
   Diversion header field.  More details are provided in the backward compatibility "Backwards
   Compatibility" section of [RFC7044].

9.  IANA Considerations

   This document makes no request of IANA.

10.  Security Considerations

   The security considerations in [RFC7044] and [RFC5806] apply.

   The privacy considerations described in section Section 3.2 apply.

   The use of the Diversion header field or History-Info header field
   require to apply
   requires application of the requested privacy and integrity asked requested
   by each diverting user or entity.  Without integrity, the requested
   privacy functions could be downgraded or eliminated, potentially
   exposing identity information.  Without confidentiality,
   eavesdroppers on the network (or any intermediaries between the user
   and the privacy
   service) Privacy Service) could see the very personal information that
   the user has asked the privacy service Privacy Service to obscure.  Unauthorised insertion,
   deletion of modification  Unauthorized
   insertion and deletion/modification of those header fields can
   provide misleading information to users and applications.  A SIP
   entity that can provide a redirection reason in a History-Info header
   field or Diversion header field should be able to suppress this in
   accordance with privacy requirements of the user concerned.

11.  Acknowlegements

   The editor would like to acknowledge the constructive feedback and
   support provided by Steve Norreys, Jan Van Geel, Martin Dolly,
   Francisco Silva, Guiseppe Sciortino, Cinza Amenta, Christer Holmberg,
   Ian Elz, Jean-Francois Mule, Mary Barnes, Francois Audet, Erick
   Sasaki, Shida Schubert, Joel M.  Halpern, Bob Braden and Robert
   Sparks.  Merci a Lionel Morand, Xavier Marjou et Philippe Fouquart.

12.

10.  References

12.1.

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,
              DOI 10.17487/RFC3261, June 2002. 2002,
              <http://www.rfc-editor.org/info/rfc3261>.

   [RFC3323]  Peterson, J., "A Privacy Mechanism for the Session
              Initiation Protocol (SIP)", RFC 3323,
              DOI 10.17487/RFC3323, November 2002. 2002,
              <http://www.rfc-editor.org/info/rfc3323>.

   [RFC3326]  Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason
              Header Field for the Session Initiation Protocol (SIP)",
              RFC 3326, DOI 10.17487/RFC3326, December 2002. 2002,
              <http://www.rfc-editor.org/info/rfc3326>.

   [RFC3966]  Schulzrinne, H., "The tel URI for Telephone Numbers", RFC
              3966, DOI 10.17487/RFC3966, December
              2004. 2004,
              <http://www.rfc-editor.org/info/rfc3966>.

   [RFC4244]  Barnes, M., Ed., "An Extension to the Session Initiation
              Protocol (SIP) for Request History Information", RFC 4244,
              DOI 10.17487/RFC4244, November 2005. 2005,
              <http://www.rfc-editor.org/info/rfc4244>.

   [RFC5806]  Levy, S. and M. Mohali, Ed., "Diversion Indication in
              SIP", RFC 5806, DOI 10.17487/RFC5806, March 2010. 2010,
              <http://www.rfc-editor.org/info/rfc5806>.

   [RFC7044]  Barnes, M., Audet, F., Schubert, S., van Elburg, J., and
              C. Holmberg, "An Extension to the Session Initiation
              Protocol (SIP) for Request History Information", RFC 7044,
              DOI 10.17487/RFC7044, February 2014.

12.2. 2014,
              <http://www.rfc-editor.org/info/rfc7044>.

10.2.  Informative References

   [Err1409]  RFC Errata, Erratum ID 1409, RFC 4458.

   [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,
              DOI 10.17487/RFC4458, April 2006. 2006,
              <http://www.rfc-editor.org/info/rfc4458>.

   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234,
              DOI 10.17487/RFC5234, January 2008. 2008,
              <http://www.rfc-editor.org/info/rfc5234>.

   [RFC6044]  Mohali, M., "Mapping and Interworking of Diversion
              Information between Diversion and History-Info Headers in
              the Session Initiation Protocol (SIP)", RFC 6044,
              DOI 10.17487/RFC6044, October 2010. 2010,
              <http://www.rfc-editor.org/info/rfc6044>.

   [TS_24.604]
              3rd Generation Partnership Project, "Technical
              Specification Group Core Network and Terminals ;
              Communication "Communication
              Diversion (CDIV) using IP Multimedia
              (IM)Core (IM) Core Network
              (CN) subsystem ; subsystem; Protocol specification
              (Release 8), specification", Release 13.1,
              3GPP TS 24.604", December 2008. 24.604, June 2015.

   [TS_29.163]
              3rd Generation Partnership Project, "Technical
              Specification Group Core Network and Terminals ;
              Interworking "Interworking between
              the IP Multimedia (IM) Core Network (CN) Subsystem subsystem and
              Circuit Switched (CS) networks (Release
              8)", December 2008. networks", Release 13.2, 3GPP TS
              29.163, June 2015.

Appendix A.  Interworking between Diversion header Header Field and Voicemail
             URI

   Voicemail URI is a mechanism described in [RFC4458] to provide a
   simple way to transport only one redirecting user address and the
   reason why the diversion occurred in the Request-URI of the INVITE
   request.  This mechanism is mainly used for call diversion to a
   voicemail.

A.1.  Diversion header field Header Field to Voicemail URI

   Received:
   Diversion: userA-address;reason=user-busy;counter=1;privacy=full

   Sent (Voicemail URI created in the R-URI line of the INVITE):
   sip: voicemail@example.com;target=userA-address;cause=486 SIP/2.0

   Mapping of the Redirection Reason is the same as for History-Info
   header field with a default value set to 404.

   If the Diversion header field contains more than one Diversion entry,
   the choice of the redirecting user information inserted in the URI is
   in charge of the network local policy.  For example, the choice
   criterion of the redirecting information inserted in the URI could be
   the destination of forwarded INVITE request (if (whether or note the
   voicemail serves this user or not). user).

   Note: This interworking could be done in addition to the interworking
   of the Diversion header field into the History-Info header field.

A.2.  Voicemail URI to Diversion header field Header Field

   In case of real Voicemail, voicemail, this way of interworking should not
   happen.  However, if for any reason it occurs, it is recommended to
   do it as following: follows:

   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

Acknowledgements

   The author 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, Robert Sparks,
   Merci a Lionel Morand, and Xavier Marjou et Philippe Fouquart.

Author's Address

   Marianne Mohali
   Orange
   38-40 rue du General Leclerc
   Issy-Les-Moulineaux Cedex 9  92794
   France

   Phone: +33 1 45 29 45 14
   Email: marianne.mohali@orange.com