[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                                S. Norreys
Expires: May 5, 2009                                     British Telecom
                                                             J. Van Geel
                                                                Belgacom
                                                                M. Dolly
                                                                     ATT
                                                                F. Silva
                                                        Portugal Telecom
                                                            G. Sciortino
                                                               C. Amenta
                                                                 Italtel
                                                             C. Holmberg
                                                                Ericsson
                                                        November 1, 2008


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

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of 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 May 5, 2009.





Mohali, et al.             Expires May 5, 2009                  [Page 1]


Internet-Draft     Mapping Diversion and History-Info      November 2008


Abstract

   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 make interwork call
   diversion information contained in a Diversion header with a History-
   Info header or with the Voicemail-URI which are standardized
   solutions.  In addition, an interworking policy is proposed to manage
   the headers coexistence.
   The History-Info header is described in [RFC4244] and the Voicemail
   URI in [RFC4458].
   Since the Diversion header is used in many existing networks
   implementations for transport of diversion informationand 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, et al.             Expires May 5, 2009                  [Page 2]


Internet-Draft     Mapping Diversion and History-Info      November 2008


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Overview . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.2.  Background . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Problem Statement  . . . . . . . . . . . . . . . . . . . . . .  5
     2.1.  Interworking need  . . . . . . . . . . . . . . . . . . . .  5
     2.2.  Interworking recommendations . . . . . . . . . . . . . . .  5
   3.  Headers syntaxes reminder  . . . . . . . . . . . . . . . . . .  8
     3.1.  History-Info header syntax . . . . . . . . . . . . . . . .  8
     3.2.  Diversion header syntax  . . . . . . . . . . . . . . . . .  9
   4.  Headers in SIP Method  . . . . . . . . . . . . . . . . . . . . 10
   5.  Diversion header to History-Info header  . . . . . . . . . . . 11
   6.  History-Info header to Diversion header  . . . . . . . . . . . 14
   7.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
     7.1.  Example with Diversion header changed into
           History-Info header  . . . . . . . . . . . . . . . . . . . 16
     7.2.  Example with History-Info header changed into
           Diversion header . . . . . . . . . . . . . . . . . . . . . 16
     7.3.  Example with two SIP networks using History-Info
           header interworking with a SIP network using Diversion
           header . . . . . . . . . . . . . . . . . . . . . . . . . . 16
     7.4.  Interworking between Diversion header and Voicemail URI  . 18
     7.5.  Additional interworking Cases  . . . . . . . . . . . . . . 19
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 20
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 20
   10. Acknowlegements  . . . . . . . . . . . . . . . . . . . . . . . 20
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 21
     11.2. Informative References . . . . . . . . . . . . . . . . . . 21
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
   Intellectual Property and Copyright Statements . . . . . . . . . . 23



















Mohali, et al.             Expires May 5, 2009                  [Page 3]


Internet-Draft     Mapping Diversion and History-Info      November 2008


1.  Introduction

1.1.  Overview

   For some network services (eg.  Voicemail, IVR or automatic call
   distribution), it is necessary for the called SIP user agent to
   identify from whom and why the session was diverted.  In order to be
   used by various service providers or applications, 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.  Because of the current
   wildely use of Diversion header even if it is not a standard, it is
   necessary to have a guideline to make this header interwork with
   History-Info header.
   This document provides a mechanism of translation between the
   Diversion header and the History-Info header and between the
   Diversion header and the Voicemail URI.

1.2.  Background

   The History-Info header [RFC4244] and a 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" TISPAN specification [TS_183004] and 3GPP
   specification[TS_24.604].

   At first, the Diversion header was described in
   [draft-levy-sip-diversion-08], which is today discarded.  This header
   contains the list of the diverting user(s) with associated
   information and the expired draft could explain why many
   implementations are based on this header.  It has been chosen to
   standardized the History-Info header because it could transport
   "request history" information which allows the receiving application
   to determine hints about how and why the session arrived at the
   application/user.  As History-Info header information is larger than
   call diversion information, it is realy important to be sure of not
   loosing information and be able to extract the good data with help of
   the retargeting cause 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, et al.             Expires May 5, 2009                  [Page 4]


Internet-Draft     Mapping Diversion and History-Info      November 2008


2.  Problem Statement

2.1.  Interworking need

   The Diversion header is used for recording communication diversion
   information which could be useful to downstream network entities.
   Today, this SIP header is implemented by several manufacturers and
   deployed in several networks.

   The History-Info header is standardized, among other needs, for the
   transportation of diversion information.

   As both are answering to call forwarding needs, according to the one
   created or completed in one side and the one interpreted in the other
   side, diverting information could be mixed-up if they are both
   present in the INVITE request.  So, Diversion and History-Info
   headers MUST NOT independently coexist for the session signalling.

   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 presented in sections 5 and 6.  As the interworking is not obvious
   and the coexistence not easy according the use cases, is it proposed
   a policy to manage the headers interaction.

   In addition, Voicemail URI proposes an other way to convey diversion
   information in the R-URI.  So, it is also necessary to describe the
   interworking between Diversion header and a Voicemail URI.  This
   interworking is presented in section 7.4.

2.2.  Interworking recommendations

   History-Info header is a standardized solution, so a network using
   the Diversion header MUST be able to provide information at the good
   format to a network 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 per the History-Info header in the
   INVITE request during the interworking.
   For some specific interworking situations (see section 7.5), it could
   be needed to create a Diversion header from a received History-Info
   header.  Since, the History-Info header has a boarder scope than the
   Diversion header and could be used for other services than call
   diversion ; in addition to trace call diversion information, it is
   acting as a session history and could store all successive R-URI
   values.  So, even if it should be better to remove the History-Info
   header after the Diversion header has been created to avoid
   confusion; if the History-Info header contains supplementary
   information it MUST be remained and passed transparently in this



Mohali, et al.             Expires May 5, 2009                  [Page 5]


Internet-Draft     Mapping Diversion and History-Info      November 2008


   network.
   These are the more simple interworking situations where a header is
   created from the other one.  More interworking cases, like situation
   where persistence of both headers is needed, are described in section
   7.5.
   If some information could be lost and use downstream or according the
   header used per network elements, it is necessary to have a local
   policy to find the best way to keep information up to the terminating
   user agent.

   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 a
   network_2 using Diversion header but before passed through a
   network_1 using History-Info header (or the network_2 uses History-
   Info header to transport successive URI information) and going to a
   network_3 using History-Info header.






















Mohali, et al.             Expires May 5, 2009                  [Page 6]


Internet-Draft     Mapping Diversion and History-Info      November 2008


                       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 in the History-Info header received and those present in
   the Diversion header.  Then network_3 could use call forwarding
   information that are 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.

   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
   information, then it MUST be suppressed after the interworking.



Mohali, et al.             Expires May 5, 2009                  [Page 7]


Internet-Draft     Mapping Diversion and History-Info      November 2008


   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 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 signalling path.  If the call
   is after forwarded to a network using History-Info header, it would
   be better to not loose history information due to passing though the
   network which only support Diversion header.  A recommended solution
   MUST NOT disrupt the standard behaviour and networks which not
   implement History-Info header MUST be transparent to an incoming
   History-Info header.

   If a Diversion header is already 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-08].  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
   section 7.4).


3.  Headers syntaxes reminder

3.1.  History-Info header syntax

   History-Info = "History-Info" HCOLON hi-entry *(COMMA hi-entry)
   hi-entry = hi-targeted-to-uri *( SEMI hi-param )
   hi-targeted-to-uri= name-addr
   hi-param = hi-index / hi-extension
   hi-index = "index" EQUAL 1*DIGIT *(DOT 1*DIGIT)



Mohali, et al.             Expires May 5, 2009                  [Page 8]


Internet-Draft     Mapping Diversion and History-Info      November 2008


   hi-extension = generic-param


   The History-Info header is specified in [RFC4244].  Amongst the
   information contained in the header list is the diversion information
   with a specific cause code mentioning the diversion reason.  These
   optional cause codes are defined in [RFC4458].  The RFC4244 contains
   a Privacy section introducing the use of Privacy header defined in
   [RFC3323] for diversion information.  The top-most History-Info entry
   (first in the list) corresponds to the oldest history information.
   A diverting user information is identifiable by the History-Info
   entry containing a cause-param with cause value as listed in
   [RFC4458] and by the entry just before.  The last diversion target is
   identifiable by the last History-Info entries containing a cause-
   param with cause value as listed in RFC 4458.
   The cause-param is inserted in the hi-targeted-to-uri of the address
   were the communication is diverted to.  The index parameter is a
   string of digits, separated by dots to indicate the number of forward
   hops and retargets.


   Example:

   History-Info:
   <sip: diverting_user1_addr? ?Privacy=none >;index=1,
   <sip: diverting_user2_addr? ?Privacy=history&
   Reason=SIP%3Bcause%3D302>;index=1.1,
   <sip:last_diversion_target&Reason=SIP%3Bcause%3D486>; 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 behaviour depend whether the local policy support 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 shure 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)



Mohali, et al.             Expires May 5, 2009                  [Page 9]


Internet-Draft     Mapping Diversion and History-Info      November 2008


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


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


   Example:

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




4.  Headers in SIP Method

   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.














Mohali, et al.             Expires May 5, 2009                 [Page 10]


Internet-Draft     Mapping Diversion and History-Info      November 2008


   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
   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.


5.  Diversion header to History-Info header

   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.

   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




Mohali, et al.             Expires May 5, 2009                 [Page 11]


Internet-Draft     Mapping Diversion and History-Info      November 2008


      - the privacy entry interworking the privacy parameter of the
      bottom-most Diversion header,

      - an index set to 1.


   For each Diversion header, the next History-info entries are mapped
   as following:











































Mohali, et al.             Expires May 5, 2009                 [Page 12]


Internet-Draft     Mapping Diversion and History-Info      November 2008


Source                                   Destination
Diversion header component:              History-Info header component:
=======================================================================
Name-addr of the previous                Hi-target-to-uri
(on top) Diversion header.
If there is no previous(top-most),
it is the Request-URI address.

=======================================================================
Reason                                   Cause
"unknown"---------------------------------404
"unconditional"---------------------------302
"user-busy"-------------------------------486
"no-answer"-------------------------------408
"deflection "-----------------------------480
"unavailable"-----------------------------503
"time-of-day"-----------------------------404 (default) or 302
"do-not-disturb"--------------------------404 (default) or 302
"follow-me"-------------------------------404 (default) or 302
"out-of-service"--------------------------404 (default)
"away"------------------------------------404 (default) or 302

=======================================================================
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 of the previous                   Privacy escaped in the
(on top) Diversion header.                hi-targeted-to-uri
If there is no previous(top-most),
no privacy parameter is created.
"full"------------------------------------"history"
"Off"-------------------------------------Privacy header field
                                          absent or "none"
"name"------------------------------------"history"
"uri"-------------------------------------"history"
=======================================================================

   Note: For other optional Diversion parameters, there is no
   recommendation.




Mohali, et al.             Expires May 5, 2009                 [Page 13]


Internet-Draft     Mapping Diversion and History-Info      November 2008


   Note: For values of the "reason" parameter which are mapped with a
   recommended default value, it could also be possible to choose an
   other value or to omit the parameter.

   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?Reason=SIP;cause=404>;index=1.1
   For a placeholder History entry the value "404" shall be taken.

   Concerning local policies recommendations about headers coexistence
   in the INVITE request, see sections 2.2 and 7.5.


6.  History-Info header to Diversion header

   As each previous diverting user MUST be present in the received
   History-Info header, one Diversion header entry per diverting user
   MUST be created in order not to loose any diverting information.

   For each History-Info header containing a cause-param with cause
   value as listed in the [RFC4458]; a Diversion header entry MUST be
   created.  The first History-Info header entry selected will be mapped
   into the last Diversion header entry and so on.

   In this case, the History-Info header MUST be mapped into the
   Diversion header as following:









Mohali, et al.             Expires May 5, 2009                 [Page 14]


Internet-Draft     Mapping Diversion and History-Info      November 2008


   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                                     Reason
   404---------------------------------------"unknown"
   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 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"

   =====================================================================
   Privacy header [RFC3323]                   Privacy
   The Privacy indicates that all
   History-Info headers SHOULD NOT
   be forwarded.
   "history"----------------------------------"full"
   =====================================================================

   Concerning local policies recommendations about headers coexistence
   in the INVITE request, see section 2.2.


   Editor's note: interworking with Voicemail URI, defined in [RFC4458],



Mohali, et al.             Expires May 5, 2009                 [Page 15]


Internet-Draft     Mapping Diversion and History-Info      November 2008


   will be added in the next release of the document.


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; privacy=history, reason=SIP;
   cause=408>index=1.1,
   <sip: diverting_user3_address; privacy=none, reason=SIP;
   cause=486>index=1.1.1,
   <sip: last_diverting_target; reason=SIP; 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; privacy=none; Reason=SIP;
   cause=302>index=1.1,
   <sip: last_diverting_target; reason=SIP; cause=486>index=1.1.1

   Mapped into:

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

7.3.  Example with two SIP networks using History-Info header
      interworking with a SIP network using Diversion header

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





Mohali, et al.             Expires May 5, 2009                 [Page 16]


Internet-Draft     Mapping Diversion and History-Info      November 2008


                          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
   |       |       |       |       |       |       |     |       |        |
   |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  |       |        |
   |       |       |       |       |       |       |     |       |        |
   |       |       |       |INVITE |       |       |     |       |        |
   |       |       |       |------>|       |       |     |       |        |
   |       |       |       |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|        |
   |       |       |       |       |       |       |     |       |        |
   |       |       |       |       |INVITE |       |     |       |        |
   |       |       |       |       |------>|       |     |       |        |
   |       |       |       |       |No modification of Diversion due to P2|
   |       |       |       |       |       |       |     |       |        |
   |       |       |       |       |       |INVITE |     |       |        |
   |       |       |       |       |       |------>|     |       |        |
   |       |       |       |       |       |       |     |       |        |
   |       |       |       |       |       |<--180-|     |       |        |
   |       |       |       |       |       |       |     |       |        |
   |       |       |       |       |  No response timer expire   |        |
   |       |       |       |       |       |---INVITE--->|       |        |
   |       |       |    Diversion:                       |       |        |
   |       |       |    userC; reason=no-answer; counter=1; privacy=full,
   |       |       |    userB; reason=unconditional; counter=1; privacy=off,
   |       |       |    History-Info:                    |       |        |



Mohali, et al.             Expires May 5, 2009                 [Page 17]


Internet-Draft     Mapping Diversion and History-Info      November 2008


   |       |       |    <sip:proxyP1>; index=1,          |       |        |
   |       |       |    <sip:userB>; index=1.1           |       |        |
   |       |       |    <sip:proxyP2>; cause=302; index=1.1.1    |        |
   |       |       |       |       |       |       |     |       |        |
   |       |       |       |       |       |       |     |INVITE |        |
   |       |       |       |       |       |       |     |------>|        |
   |       |       |     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   |        |
   |       |       |       |       |       |       |     |       |        |
   |       |       |       |       |       |       |     |       | INVITE |
   |       |       |       |       |       |       |     |       |------->|
   |       |       |     History-Info:                                    |
   |       |       |     <sip:proxyP1>; index=1,                          |
   |       |       |     <sip:userB>; index=1.1; privacy=none,            |
   |       |       |     <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.  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.



Mohali, et al.             Expires May 5, 2009                 [Page 18]


Internet-Draft     Mapping Diversion and History-Info      November 2008


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

7.5.  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 behaviour 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
   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



Mohali, et al.             Expires May 5, 2009                 [Page 19]


Internet-Draft     Mapping Diversion and History-Info      November 2008


   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
   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 editors would like to acknowledge the constructive feedback



Mohali, et al.             Expires May 5, 2009                 [Page 20]


Internet-Draft     Mapping Diversion and History-Info      November 2008


   provided by Ian Elz, Jean-Francois Mule, Lionel Morand, Xavier
   Marjou, Philippe Fouquart, Mary Barnes, Francois Audet, Erick Sasaki
   and Shida Schubert.


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.

   [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.

11.2.  Informative References

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

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

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

   [TS_183004]
              Telecommunications and Internet converged Services and
              Protocols for Advanced Networking (TISPAN), "PSTN/ISDN
              simulation services: Communication Diversion (CDIV);
              Protocol specification, Release 2, ETSI TS 183004",
              November 2007.

   [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", April 2008.




Mohali, et al.             Expires May 5, 2009                 [Page 21]


Internet-Draft     Mapping Diversion and History-Info      November 2008


   [draft-levy-sip-diversion-08]
              "Diversion Indication in SIP,
              draft-levy-sip-diversion-08", August 2004.


Authors' Addresses

   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


   Steve Norreys
   British Telecom


   Jan Van Geel
   Belgacom


   Martin Dolly
   ATT


   Francisco Silva
   Portugal Telecom


   Guiseppe Sciortino
   Italtel


   Cinzia Amenta
   Italtel


   Christer Holmberg
   Ericsson








Mohali, et al.             Expires May 5, 2009                 [Page 22]


Internet-Draft     Mapping Diversion and History-Info      November 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.











Mohali, et al.             Expires May 5, 2009                 [Page 23]