[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 rfc6044                               
Network Working Group                                          M. Mohali
Internet-Draft                                            France Telecom
Intended status: Informational                             June 24, 2009
Expires: December 26, 2009


Mapping and interworking of Diversion information Between Diversion and
     History-Info Headers in the Session Initiation Protocol (SIP)
                 draft-mohali-diversion-history-info-04

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on December 26, 2009.


Copyright Notice

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

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










Mohali                  Expires December 26, 2009               [Page 1]


Internet-Draft     Mapping Diversion and History-Info          June 2009



Abstract

   The Diversion header is not standardized but widely used to convey
   diverting information in Session Initiation Protocol (SIP) signaling.
   This informational document proposes a way to interwork call
   diversion information contained in Diversion header with a History-
   Info header.  In addition, an interworking policy is proposed to
   manage the headers coexistence.
   The History-Info header is described in [RFC4244] and the Diversion
   header is described in [draft-levy-sip-diversion-09].
   Note to the RFC-Editor: The reference to this draft should be
   replaced by the Historic RFC reference (work in progress).
   Since the Diversion header is used in many existing networks
   implementations for transport of diversion information and its
   interworking with standardized solutions is not obvious, an
   interworking recommendation is needed.


Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].



























Mohali                  Expires December 26, 2009               [Page 2]


Internet-Draft     Mapping Diversion and History-Info          June 2009


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Overview . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.2.  Background . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Problem Statement  . . . . . . . . . . . . . . . . . . . . . .  5
     2.1.  Interworking requirements and scope  . . . . . . . . . . .  5
     2.2.  Interworking recommendations . . . . . . . . . . . . . . .  6
       2.2.1.  SIP network/terminal using Diversion to SIP
               network/terminal using History-Info header . . . . . .  7
       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  . . . . . . . . . . . . . . . . . . . . 12
   5.  Diversion header to History-Info header  . . . . . . . . . . . 13
   6.  History-Info header to Diversion header  . . . . . . . . . . . 16
   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 interworking with a SIP network using Diversion
           header . . . . . . . . . . . . . . . . . . . . . . . . . . 17
     7.4.  Additional interworking Cases  . . . . . . . . . . . . . . 19
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 20
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 20
   10. Acknowlegements  . . . . . . . . . . . . . . . . . . . . . . . 21
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 21
     11.2. Informative References . . . . . . . . . . . . . . . . . . 22
   Appendix A.  Interworking between Diversion header and
                Voicemail URI . . . . . . . . . . . . . . . . . . . . 22
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23















Mohali                  Expires December 26, 2009               [Page 3]


Internet-Draft     Mapping Diversion and History-Info          June 2009


1.  Introduction

1.1.  Overview

   For some network services (eg.  Voicemail, IVR or automatic call
   distribution), it is helpful for the called SIP user agent to
   identify from whom and why the session was diverted.  For this
   information to be used in various service providers or by various
   applications, this redirection information needs to pass through the
   network.
   This is possible with two different SIP headers: History-Info
   header [RFC4244] and Diversion header which are both able to
   transport diversion information in SIP signaling. 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.
   This document provides a mechanism of translation between the
   Diversion header and the History-Info header.

1.2.  Background

   The History-Info header [RFC4244] and the URI extension (including
   Voicemail URI) [RFC4458] are recommended by IETF to convey
   redirection information.  They are also recommended in the
   "Communication Diversion (CDIV) service" 3GPP specification
   [TS_24.604].

   At first, the Diversion header was described in
   [draft-levy-sip-diversion-09], which is today discarded.
   Note to the RFC-Editor: The reference to this draft should be
   replaced by the Historic RFC reference (work in progress).
   This header contains a list of the diverting URIs with associated
   information providing specific information as to why a call was
   diverted.  Most of implementations have implemented the Diversion
   header when the History-Info header was not a standard.  The IETF has
   chosen to standardize the History-Info header in part because it can
   transport general "request history" information which allows the
   receiving application to determine how and why the session arrived at
   the application/user.  As History-Info header information is larger
   than call diversion information, it is really important to be sure of
   not losing information and be able to extract the relevant data using
   the retargeting cause URI parameter described in [RFC4458] for the
   transport of the diversion reason.

   Those headers have different syntaxes described below.  Note that the
   main difference is that the History-Info header is a chronological
   writing header whereas the Diversion header is the opposite (i.e. the
   first diversion entry read correspond to the last diverting user).



Mohali                  Expires December 26, 2009               [Page 4]


Internet-Draft     Mapping Diversion and History-Info          June 2009



   The Appendix provides an interworking guideline between the Diversion
   header and the Voicemail URI which is another way to convey diversion
   information described 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 these two
   headers that need to be addressed.
   They are many ways in which SIP signaling can be used to modify a
   session destination before it is established and many reasons for
   doing so.  The behavior of the SIP entities that will have to further
   process the session downstream will sometimes vary depending on the
   reasons that lead to changing the destination, for example whether it
   is for simple proxy to route the session or for an application server
   to provide a supplementary service.
   The approach and scope in which the Diversion header and the History-
   Info header address this problem are different.  For clarity, the
   following vocabulary is used in this document:

   Retargeting/redirecting:
   Retargeting/redirecting refer 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 store
   retargeting information.

   Call forwarding/call diversion/communication diversion:
   These terms are equivalent and refer to the Communications Diversion
   (CDIV) supplementary services, based on the ISDN Communication
   diversion supplementary services and defined in 3GPP [TS_24.604].
   They are applicable to entities which are intended to modify the
   original destination of an IP multimedia session prior to or during
   the session establishment.

   This document does not describe when or how History-Info or Diversion
   headers are used.  The following is offered to clarify the context in
   which this interworking is used.

   The History-Info header is used in practice to convey call diversion
   related information by using a cause URI parameter [RFC4458] in the
   relevant entry.




Mohali                  Expires December 26, 2009               [Page 5]


Internet-Draft     Mapping Diversion and History-Info          June 2009


   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 communication diversion
   information which could be useful to network entities downstream.
   Today, this SIP header is implemented by several manufacturers and
   deployed in several networks.

   The History-Info header is used to store all retargeting information
   including call diversion information.
   Note, however, that the use of cause URI parameter [RFC4458] in a
   History-Info entry for a call diversion is specific to the 3GPP
   specifications.  RFC4458 focuses on retargeting toward voicemail
   server and does not specify whether the cause URI parameter should be
   added or not 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 not to lose non-mapped information at the
   boundary between a network region using History-Info header and one
   using the Diversion header.

   Since both headers addresses call forwarding needs, diverting
   information could be mixed-up or be inconsistent if both headers are
   present in an uncoordinated fashion in the INVITE request.  So,
   Diversion and History-Info headers MUST NOT independently coexist for
   the session signaling.  This specific address how to convert
   information between the two, 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 coexistence scenario may
   vary from one use case to another, guidelines regarding headers
   interaction are proposed.

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 which by configuration is aware that it is
   at the border between two regions, one using History-Info header and
   one using Diversion header.

   History-Info header is a standardized solution, so a network using
   the Diversion header MUST be able to provide information to a network



Mohali                  Expires December 26, 2009               [Page 6]


Internet-Draft     Mapping Diversion and History-Info          June 2009


   using the History-Info header.  In this case, to avoid both headers
   coexistence it is recommended as often as possible to replace the
   Diversion header with the History-Info header in the INVITE request
   during the interworking.

   Since, the History-Info header has a boarder scope than the Diversion
   header and may be used for services other than call diversion.  In
   addition to tracing call diversion information, History-Info header
   also acts as a session history and could store all successive R-URI
   values.  Consequently, even if it should be better to remove the
   History-Info header after the Diversion header has been created to
   avoid any confusion; if the History-Info header contains
   supplementary (non-diversion) information it MUST be retained as is
   and passed transparently in this network.  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 implementations will have to decide
   what to do.  This point is out of this document scope.
   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.
   This section describes the basic and commonly used use case.  More
   unusual 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 information present in the Diversion header is
   transferred in the History-Info header.

   If a History-Info header is present in the incoming INVITE (in
   addition to Diversion header), the Diversion header and History-Info
   header present MUST be mixed and only the diversion information not
   yet present in the History-Info header MUST be inserted as a last
   entry (more recent) in the existing History-Info header as
   recommended in [RFC4244].
   As an example, this could be the case of an INVITE coming from
   network_2 using Diversion header but has previously passed through
   network_1 using History-Info header (or the network_2 uses History-
   Info header to transport successive URI information) and going to
   network_3 using History-Info header.







Mohali                  Expires December 26, 2009               [Page 7]


Internet-Draft     Mapping Diversion and History-Info          June 2009


                       IWF*                                  IWF*
     network1           |                network_2            |network_3
    History-Info        |                 Diversion           |using
                        |                                     |Hist-Info
                        |                                     |
UA A    P1     AS B     |       P2     AS C    UA C   AS D    |     UA E
|       |       |       |       |       |       |     |       |        |
|INVITE |       |       |       |       |       |     |       |        |
|------>|       |       |       |       |       |     |       |        |
|       |       |       |       |       |       |     |       |        |
|       |INVITE |       |       |       |       |     |       |        |
|       |------>|       |       |       |       |     |       |        |
|       |Supported: histinfo    |       |       |     |       |        |
|       | History-Info:         |       |       |     |       |        |
|       | <sip:proxyP1>; index=1,       |       |     |       |        |
|       | <sip:userB >; index=1.1       |       |     |       |        |
|       |       |       |       |       |       |     |       |        |
|       |       |INVITE |       |       |       |     |       |        |
|       |       |------>|       |       |       |     |       |        |
|       |       |History-Info:  |       |       |     |       |        |
|       |       |<sip:proxyP1>; index=1,|       |     |       |        |
|       |       |<sip:userB>; index=1.1 |       |     |       |        |
|       |       |<sip:userC>; cause=302; index=1.1.1  |       |        |
   In this case, the incoming INVITE contains a Diversion header and a
   History-Info header.  So that, it is necessary to create, for
   network_3, a single History-Info header gathering existing
   information from both the History-Info and the Diversion headers
   received.  Then network_3 could use call forwarding information that
   is present in a single header and add its own diversion information
   if necessary.

   Note: if a network is not able either to use only one header each
   time, or to maintain both headers up to date, the chronological order
   could not be certified.

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

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 communication diversion



Mohali                  Expires December 26, 2009               [Page 8]


Internet-Draft     Mapping Diversion and History-Info          June 2009


   information, then it MUST be suppressed 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
   CDIV services, for example by a service which need to know if a
   specific AS had yet been invoked in the signaling path.  If the call
   is later forwarded to a network using History-Info header, it would
   be better to not lose history information due to passing though the
   network which only support Diversion header.  A recommended solution
   MUST NOT disrupt the standard behavior and networks which 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 the Diversion draft [draft-levy-sip-diversion-09].
   Note to the RFC-Editor: The reference to this draft should be
   replaced by the Historic RFC reference (work in progress).
   Note that the chronological order could not be certified.  If
   previous policy recommendations are respected, this case SHOULD NOT
   happen.


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

   The same logic is applied for an interworking with Voicemail URI (see
   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 )



Mohali                  Expires December 26, 2009               [Page 9]


Internet-Draft     Mapping Diversion and History-Info          June 2009


   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 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 exactly,
   each diverting user is located in the hi-entry before the one
   containing a cause-param with cause value as listed in RFC 4458.

   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 SIP response received.  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 yet 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 on local policies
   responsabilty and 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



Mohali                  Expires December 26, 2009              [Page 10]


Internet-Draft     Mapping Diversion and History-Info          June 2009


   indicate the number of forward hops and retargets. first one is

   Note: A history entry could contain the "gr" parameter.  Regardless
   the rules concerning "gr" parameter defined in [TS_24.604] which must
   be applied, this parameter has no impact on the mapping and must only
   be copied with the served user address.


   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 the local policy supports
   the capture of History-Info or not.



3.2.  Diversion header syntax

   The current document is not written to define again the Diversion
   header and its use but to be sure that the syntax is interpreted in
   the same way by everyone.  So that, the Diversion syntax is here a
   little changed to correspond to the current ABNF [RFC4234]:

   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)



Mohali                  Expires December 26, 2009              [Page 11]


Internet-Draft     Mapping Diversion and History-Info          June 2009


   diversion-extension = token [EQUAL (token / quoted-string)]


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


   Example:

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




4.  Headers in SIP Method

   You can find here a reminder of History-Info header field and
   Diversion header field in relation to methods.  As those headers do
   not have the same capabilities, it is necessary to clarify the
   interworking.

   Use of History-Info header field:

   Header field where proxy ACK BYE CAN INV OPT REG MSG
   ------------ ----- ----- --- --- --- --- --- --- ---
   History-Info        amdr   -   -   -  o   o   o   o
                            SUB NOT REF INF UPD PRA PUB
                            --- --- --- --- --- --- ---
   History-Info        amdr o    o   o   -   -   -   o


   Use of Diversion header field:

   Header field where  enc. e-e ACK BYE CAN INV OPT REG
   ------------ ----- ----- --- --- --- --- --- --- ---
   Diversion      R          h   -   -   -   o   -   -
   Diversion     3xx         h   -   -   -   o   -   -

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

   In 3xx responses, both headers could be present.
   When a proxy wants to interwork with a network supporting the other
   header field, it SHOULD apply the interworking between Diversion



Mohali                  Expires December 26, 2009              [Page 12]


Internet-Draft     Mapping Diversion and History-Info          June 2009


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

   Other messages where History-Info could be present are not used for
   the Call Forwarding service and SHOULD NOT be changed into Diversion
   header.  The destination network MUST be transparent the received
   History-Info header.
   Note : the following mapping is inspired from the ISUP to SIP
   interworking described in [TS_29.163].


5.  Diversion header to History-Info header

   The following text is valid only if no History-Info is present in the
   INVITE request.  If at least one History-Info header is present, the
   interworking function shall adapt its 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 (the last one) History-Info
   entry 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-target-to-uri with the name-addr parameter of the bottom-
      most Diversion header

      - if a privacy parameter is present in the bottom-most Diversion
      entry, then a Privacy header could be escaped in the History-Info
      header as described 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                  Expires December 26, 2009              [Page 13]


Internet-Draft     Mapping Diversion and History-Info          June 2009


Source                                   Destination
Diversion header component:              History-Info header component:
=======================================================================
Name-addr                                Hi-target-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
no present                                is incremented with ".1"
Superior to "1" --------------------------Create N-1 placeholder History
(i.e. N)                                  entry with the previous index
                                          incremented with ".1"
                                          Then the History-Info header
                                          created with the Diversion
                                          entry with the previous index
                                          incremented with ".1"
=======================================================================
Privacy                                   Privacy header escaped in the
                                          hi-targeted-to-uri
"full"------------------------------------"history"
"Off"-------------------------------------Privacy header field
                                          absent or "none"
"name"------------------------------------"history"
"uri"-------------------------------------"history"
=======================================================================

   A last History-Info entry is created and contains:

      - a hi-target-to-uri with the Request-URI of the INVITE request.

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




Mohali                  Expires December 26, 2009              [Page 14]


Internet-Draft     Mapping Diversion and History-Info          June 2009


      - if a privacy parameter is present in the top-most Diversion
      entry, then a Privacy header could be escaped in the History-Info
      header as described above,

      - an index set to the previous created index and incremented with
      ".1"

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

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

   Note : The Diversion header could contain a Tel:URI in the name-addr
   parameter but it seems to not be possible to have a Tel:URI in the
   History-Info header.  RFC3261 gives an indication as to the mapping
   between sip: and tel: URIs but in this particular case it is
   difficult to assign a valid hostport as the diversion has occurred in
   a previous network and a valid hostport is difficult to determine.
   So, it is suggested that in case of Tel:URI in the Diversion header,
   the History-Info header should be created with a SIP URI with
   user=phone.

   Note:
   The Diversion header allows the carrying of a counter which had
   retained the information about the number of redirections which have
   occurred.  History-Info does not have an equivalent because to trace
   and count diversion occurred it is necessary to count cause parameter
   containing a value associated to a call diversion.  To read the index
   value is not enough.  With the use of the "placeholder" entry the
   History-info header entries could reflect the real number of
   diversion occurred.
   Example of placeholder entry in the History-Info header:
   <sip:unknown@unknown.invalid;cause=xxx>;index=1.1
   <sip:bob_addr;cause=404>;index=1.1.1
   cause=xxx reflects the diverting reason of a previous diverting user.
   For a placeholder hi-entry the value "404" shall 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.





Mohali                  Expires December 26, 2009              [Page 15]


Internet-Draft     Mapping Diversion and History-Info          June 2009


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:

   Source                                    Destination
   History-Info header component:            Diversion header component:
   =====================================================================
   Hi-target-to-uri of the                   Name-addr
   History-Info which precedes the one
   containing a diverting cause-param

   =====================================================================
   Cause-param                               Reason
   404---------------------------------------"unknown" (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"




Mohali                  Expires December 26, 2009              [Page 16]


Internet-Draft     Mapping Diversion and History-Info          June 2009


   =====================================================================

   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.




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



Mohali                  Expires December 26, 2009              [Page 17]


Internet-Draft     Mapping Diversion and History-Info          June 2009


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



                          IWF*                                  IWF*
     SIP network using     |            SIP network using        |SIP net.
       History-Info        |                 Diversion           |using
                           |                                     |Hist-Info
                           |                                     |
   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-|     |       |        |



Mohali                  Expires December 26, 2009              [Page 18]


Internet-Draft     Mapping Diversion and History-Info          June 2009


   |       |       |       |       |       |       |     |       |        |
   |       |       |       |       |  No response timer expire   |        |
   |       |       |       |       |       |---INV D --->|       |        |
   |       |       |    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 which could be a stand-alone
     equipment not defined in this draft (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 which includes different
   nodes, some of which support Diversion header and some which support
   History-info header, the problem is when any node handling a message
   does not know which node will next handle the message.  This case can



Mohali                  Expires December 26, 2009              [Page 19]


Internet-Draft     Mapping Diversion and History-Info          June 2009


   occur when the network has new and old nodes, the older ones using
   Diversion header and the more recent History-Info header.
   While a network replacement may be occurring there will be a time
   when both nodes exist in the network.  If the different nodes are
   being used to support different subscriber types due to different
   node capabilities then the problem is more important.  In this case
   there is a need to pass both History-Info header and Diversion header
   within the network core.
   These headers need to be equivalent to ensure that whatever node
   receives the message the correct diversion information is received.
   This requires that whichever header is received there is a
   requirement to be able to compare the headers and to convert the
   headers.  Depending upon node capability then it may be possible to
   make assumptions as to how this is handled.
   If it is known that the older Diversion header supporting nodes do
   not pass on any received History-Info header then the interworking
   becomes easier.  If a message is received with only Diversion headers
   then it has originated from an 'old' node.  The equivalent History-
   Info entries can be created and these can then be passed as well as
   the Diversion header.
   If the node creates a new History-Info header for a call diversion,
   then an additional Diversion header must be created.
   If the next node is an 'old' node then the Diversion header will be
   used by that node and the History-Info entries will be removed from
   the message when it is passed on.
   If the next node is a new node then the presence of both Diversion
   header and History-Info header means that interworking has already
   occurred and the Diversion and History-Info entries must be
   considered equivalent.
   If both nodes pass on both History-Info header and Diversion header
   but only actively use one, then both types of node need to perform
   the interworking and must maintain equivalence between the headers.
   This will eventually result in the use of Diversion header being
   deprecated when all nodes in the network support History-Info header.


8.  IANA Considerations

   This document makes no request of IANA.


9.  Security Considerations

   The use of Diversion header or History-Info header require to apply
   the requested privacy and integrity asked by each diverting user or
   entity.  Without integrity, the requested privacy functions could be
   downgraded or eliminated, potentially exposing identity information.
   Without confidentiality, eavesdroppers on the network (or any



Mohali                  Expires December 26, 2009              [Page 20]


Internet-Draft     Mapping Diversion and History-Info          June 2009


   intermediaries between the user and the privacy service) could see
   the very personal information that the user has asked the privacy
   service to obscure.  Unauthorised insertion, deletion of modification
   of those headers can provide misleading information to users and
   applications.  A SIP entity that can provide a redirection reason in
   a History-Info header or Diversion header SHOULD be able to suppress
   this in accordance with privacy requirements of the user concerned.


10.  Acknowlegements

   The 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, Lionel Morand, Xavier Marjou,
   Philippe Fouquart, Mary Barnes, Francois Audet, Erick Sasaki, Shida
   Schubert and Joel M. Halpern.


11.  References

11.1.  Normative References

   [RFC2119]  "Key words for use in RFCs to Indicate Requirement
              Levels", RFC 2119, March 1997.

   [RFC3261]  "SIP: Session Initiation Protocol", RFC 3261, June 2002.

   [RFC3323]  "A Privacy Mechanism for the Session Initiation Protocol
              (SIP)", RFC 3323, November 2002.

   [RFC3326]  "The Reason Header Field for the Session Initiation
              Protocol (SIP)", RFC 3326, December 2002.

   [RFC3969]  "The Internet Assigned Number Authority (IANA) Uniform
              Resource Identifier (URI) Parameter Registry for the
              Session Initiation Protocol (SIP), BCP 99", RFC 3969,
              December 2004.

   [RFC4234]  "Augmented BNF for Syntax Specifications: ABNF", RFC 4234,
              October 2005.

   [RFC4244]  "An Extension to the Session Initiation Protocol (SIP) for
              Request History Information", RFC 4244, November 2005.







Mohali                  Expires December 26, 2009              [Page 21]


Internet-Draft     Mapping Diversion and History-Info          June 2009


11.2.  Informative References

   [RFC4458]  "Session Initiation Protocol (SIP) URIs for Applications
              such as Voicemail and Interactive Voice Response (IVR)",
              RFC 4458, April 2006.

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

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

   [draft-levy-sip-diversion-09]
              "Diversion Indication in SIP,
              draft-levy-sip-diversion-09", May 2009.


Appendix A.  Interworking between Diversion header and Voicemail URI

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


   Diversion header to Voicemail URI:

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

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

   Mapping of the Redirection Reason is the same as for History-Info
   header with a default value set to 404.
   If the Diversion header contains more than one Diversion entry, the
   choice of the redirecting user information inserted in the URI is in
   charge of the network local policy.  For example, the choice
   criterion of the redirecting information inserted in the URI could be
   the destination of forwarded INVITE request (if the voicemail serves



Mohali                  Expires December 26, 2009              [Page 22]


Internet-Draft     Mapping Diversion and History-Info          June 2009


   this user or not).

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


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

   Received:
   INVITE sip: voicemail@example.com;\
   target=sip:+33145454500%40example.com;user=phone;\
   cause=302 SIP/2.0

   Sent in the forwarded INVITE:
   Diversion: sip:+
   33145454500%40example.com;user=phone;reason=unconditional;counter=1


Author's Address

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

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




















Mohali                  Expires December 26, 2009              [Page 23]