GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc6044

Table of Contents

Independent Submission M. Mohali Request for Comments: 6044 France Telecom Orange Category: Informational October 2010 ISSN: 2070-1721

Mapping and Interworking of Diversion Information between Diversion and

   History-Info Headers in the Session Initiation Protocol (SIP)

Abstract

 Although the SIP History-Info header is the solution adopted in IETF,
 the non-standard Diversion header is nevertheless widely implemented
 and used for conveying call-diversion-related information in SIP
 signaling.
 This document describes a recommended interworking guideline between
 the Diversion header and the History-Info header to handle call
 diversion information.  In addition, an interworking policy is
 proposed to manage the headers' coexistence.  The History-Info header
 is described in RFC 4244 and the non-standard Diversion header is
 described, as Historic, in RFC 5806.
 Since the Diversion header is used in many existing network
 implementations for the transport of call diversion information, its
 interworking with the SIP History-Info standardized solution is
 needed.  This work is intended to enable the migration from non-
 standard implementations and deployment toward IETF specification-
 based implementations and deployment.

Status of This Memo

 This document is not an Internet Standards Track specification; it is
 published for informational purposes.
 This is a contribution to the RFC Series, independently of any other
 RFC stream.  The RFC Editor has chosen to publish this document at
 its discretion and makes no statement about its value for
 implementation or deployment.  Documents approved for publication by
 the RFC Editor are not a candidate for any level of Internet
 Standard; see Section 2 of RFC 5741.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc6044.

Mohali Informational [Page 1] RFC 6044 Mapping Diversion and History-Info October 2010

Copyright Notice

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

Table of Contents

 1. Introduction ....................................................3
    1.1. Overview ...................................................3
    1.2. Background .................................................3
 2. Problem Statement ...............................................4
    2.1. Interworking Requirements and Scope ........................4
    2.2. Interworking Recommendations ...............................6
         2.2.1. SIP Network/Terminal Using Diversion to SIP
                Network/Terminal Using History-Info Header ..........6
         2.2.2. SIP Network/Terminal Using History-Info
                Header to SIP Network/terminal Using Diversion
                Header ..............................................8
 3. Headers Syntaxes Reminder .......................................9
    3.1. History-Info Header Syntax .................................9
    3.2. Diversion Header Syntax ...................................11
 4. Headers in SIP Method ..........................................11
 5. Diversion Header to History-Info Header ........................12
 6. History-Info Header to Diversion Header ........................15
 7. Examples .......................................................17
    7.1. Example with Diversion Header Changed into
         History-Info Header .......................................17
    7.2. Example with History-Info Header Changed into
         Diversion Header ..........................................17
    7.3. Example with Two SIP Networks Using History-Info Header ...17
    7.4. Additional Interworking Cases .............................19
 8. Security Considerations ........................................20
 9. Acknowledgements ...............................................21
 10. References ....................................................21
    10.1. Normative References .....................................21
    10.2. Informative References ...................................21
 Appendix A.  Interworking between Diversion Header and
              Voicemail URI ........................................23

Mohali Informational [Page 2] RFC 6044 Mapping Diversion and History-Info October 2010

1. Introduction

1.1. Overview

 For some VoIP-based (Voice over IP) services (e.g., voicemail,
 Interactive Voice Recognition (IVR) or automatic call distribution),
 it is helpful for the called SIP user agent to identify from whom and
 why the session was diverted.  For this information to be used by
 various service providers or by applications, it needs to pass
 through the network.  This is possible with two different SIP
 headers: the History-Info header defined in [RFC4244] and the
 historic Diversion header defined in [RFC5806], which are both able
 to transport diversion information in SIP signaling.
 Although the Diversion header is not standardized, it is widely used.
 Therefore, it is useful to have guidelines to make this header
 interwork with the standard History-Info header.
 Note that the new implementation and deployment of the Diversion
 header is strongly discouraged.
 This document provides a mechanism for header-content translation
 between the Diversion header and the History-Info header.

1.2. Background

 The History-Info header [RFC4244] and its extension for forming SIP
 service URIs (including Voicemail URI) [RFC4458] are recommended by
 the IETF to convey redirection information.  They are also
 recommended in the "Communication Diversion (CDIV) service" Third
 Generation Partnership Project (3GPP) specification [TS_24.604].
 Originally, the Diversion header was described in a document that was
 submitted to the SIP Working Group.  It has been published now as
 [RFC5806] for the historical record and to provide a reference for
 this RFC.
 This header contains a list of diverting URIs and associated
 information providing specific information as the reason for the call
 diversion.  Most existing SIP-based implementations have implemented
 the Diversion header when no standard solution was ready to deploy.
 The IETF has finally standardized the History-Info header, partly
 because it can transport general history information.  This allows
 the receiving part to determine how and why the session is received.
 As the History-Info header may contain further information than call
 diversion information, it is critical to avoid losing information and

Mohali Informational [Page 3] RFC 6044 Mapping Diversion and History-Info October 2010

 be able to extract the relevant data using the retargeting cause URI
 parameter described in [RFC4458] for the transport of the diversion
 reason.
 The Diversion header and the History-Info header have different
 syntaxes, described below.  Note that the main difference is that the
 History-Info header is a chronological writing header whereas the
 Diversion header applies a reverse chronology (i.e., the first
 diversion entry read corresponds to the last diverting user).
 Appendix A provides an interworking guideline between the Diversion
 header and the Voicemail URI, which is another way to convey
 diversion information.  The Voicemail URI is defined in [RFC4458].

2. Problem Statement

2.1. Interworking Requirements and Scope

 This section provides the baseline terminology used in the rest of
 the document and defines the scope of interworking between the
 Diversion header and the History-Info header.
 There are many ways in which SIP signaling can be used to modify a
 session destination before it is established, and there are many
 reasons for doing so.  The behavior of the SIP entities that will
 have to further process the session downstream will sometimes vary
 depending on the reasons that lead to changing the destination.  For
 example, whether it is for a simple proxy to route the session or for
 an application server to provide a supplementary service.  The
 Diversion header and the History-Info header differ in the approach
 and scope of addressing this problem.
 For clarity, the following vocabulary is used in this document:
 o  Retargeting/redirecting: retargeting/redirecting refers to the
    process of a Proxy Server/User Agent Client (UAC) changing a
    Uniform Resource Identifier (URI) in a request and thus changing
    the target of the request.  These terms are defined in [RFC4244].
    The History-Info header is used to capture retargeting
    information.
 o  Call forwarding/call diversion/communication diversion: these
    terms are equivalent and refer to the Communications Diversion
    (CDIV) supplementary services, based on the Integrated Services
    Digital Network (ISDN) Communication diversion supplementary

Mohali Informational [Page 4] RFC 6044 Mapping Diversion and History-Info October 2010

    services and defined in 3GPP [TS_24.604].  They are applicable to
    entities that are intended to modify the original destination of
    an IP multimedia session during or prior to the session
    establishment.
 This document does not intend to describe when or how History-Info or
 Diversion headers should be used.  Hereafter is provided
 clarification on the context in which the interworking is required.
 The Diversion header has exactly the same scope as the call diversion
 service and each header entry reflects a call diversion invocation.
 The Diversion header is used for recording call forwarding
 information, which could be useful to network entities downstream.
 Today, this SIP header is implemented by several manufacturers and
 deployed in networks.
 The History-Info header is used to store all retargeting information
 including call diversion information.  In practice, the History-Info
 header [RFC4244] is used to convey call-diversion-related information
 by using a cause URI parameter [RFC4458] in the relevant entry.
 Note, however, that the use of cause URI parameter [RFC4458] in a
 History-Info entry for a call diversion is specific to the 3GPP
 specification [TS_24.604].  [RFC4458] focuses on retargeting toward a
 voicemail server and does not specify whether the cause URI parameter
 should be added in a URI for other cases.  As a consequence,
 implementations that do not use the cause URI parameter for call
 forwarding information are not considered for the mapping described
 in this document.  Nevertheless, some recommendations are given in
 the next sections on how to avoid the loss of non-mapped information
 at the boundary between a network region using History-Info header
 and one using the Diversion header.
 Since both headers address call forwarding needs, diverting
 information could be mixed up or be inconsistent if both are present
 in an uncoordinated fashion in the INVITE request.  So, Diversion and
 History-Info headers must not independently coexist in the same
 session signaling.  This document addresses how to convert
 information between the Diversion header and the History-Info header,
 and when and how to preserve both headers to cover additional cases.
 For the transportation of consistent diversion information
 downstream, it is necessary to make the two headers interwork.
 Interworking between the Diversion header and the History-Info header
 is introduced in sections 5 and 6.  Since the coexistence scenario
 may vary from one use case to another one, guidelines regarding
 headers interaction are proposed.

Mohali Informational [Page 5] RFC 6044 Mapping Diversion and History-Info October 2010

2.2. Interworking Recommendations

 Interworking function:
    In a normal case, the network topology assumption is that the
    interworking described in this document should be performed by a
    specific SIP border device that is aware, by configuration, that
    it is at the border between two regions, one using History-Info
    header and one using Diversion header.
 As History-Info header is a standard solution, a network using the
 Diversion header must be able to provide information to a network
 using the History-Info header.  In this case, to avoid header
 coexistence, it is required to replace, as often as possible, the
 Diversion header with the History-Info header in the INVITE request
 during the interworking.
 Since, the History-Info header has a wider scope than the Diversion
 header, it may be used for other needs and services than call
 diversion.  In addition to trace call diversion information, the
 History-Info header also acts as a session history and can store all
 successive R-URI values.  Consequently, even if it should be better
 to remove the History-Info header after the creation of the Diversion
 header to avoid confusion, the History-Info header must remain
 unmodified in the SIP signaling if it contains supplementary (non-
 diversion) information.  It is possible to have History-Info headers
 that do not have values that can be mapped into the Diversion header.
 In this case, no interworking with Diversion header should be
 performed, and it must be defined per implementation what to do in
 this case.  This point is left out of the scope of this document.
 As a conclusion, it is recommended to have local policies minimizing
 the loss of information and find the best way to keep it up to the
 terminating user agent.
 The following sections describe the basic common use case.
 Additional interworking cases are described in section 7.5.

2.2.1. SIP Network/Terminal Using Diversion to SIP Network/Terminal

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

Mohali Informational [Page 6] RFC 6044 Mapping Diversion and History-Info October 2010

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

UA A P1 AS B | P2 AS C UA C AS D | UA E

INVITE
——>
INVITE
——>
Supported: histinfo
History-Info:
<sip:proxyP1>; index=1,
<sip:userB >; index=1.1
INVITE
——>
History-Info:
<sip:proxyP1>; index=1,
<sip:userB>; index=1.1
<sip:userC>; cause=302; index=1.1.1
 In this case, the incoming INVITE contains a Diversion header and a
 History-Info header.  Therefore, as recommended in this document, it
 is necessary to create, for network_3, a single History-Info header
 gathering existing information from both the History-Info and the
 Diversion headers received.  Anyway, it is required from network_2
 (i.e., IWF) to remove the Diversion header when the message is going
 to a network not using the Diversion header.  Then, network_3 could
 use call forwarding information that is present in a single header
 and add its own diversion information if necessary.

Mohali Informational [Page 7] RFC 6044 Mapping Diversion and History-Info October 2010

 Notes:
 1. If a network is not able either to use only one header each time
    or to maintain both headers up to date, the chronological order
    cannot be certified.
 2. It is not possible to have only a Diversion header when the
    History-Info header contains more than call diversion information.
    If previous policy recommendations are applied, the chronological
    order is respected as Diversion entries are inserted at the end of
    the History-Info header taking into account the Diversion internal
    chronology.

2.2.2. SIP Network/Terminal Using History-Info Header to SIP

      Network/Terminal Using Diversion Header
 When the History-Info header is interpreted to create a Diversion
 header, some precautions must be taken.
 If the History-Info header contains only call forwarding information,
 then it must be deleted after the interworking.
 If the History-Info header contains other information, then only the
 information of concern to the diverting user must be used to create
 entries in the Diversion header and the History-Info header must be
 kept as received in the INVITE and forwarded downstream.
 Note: The History-Info header could be used for other reasons than
 call diversion services, for example, by a service that needs to know
 if a specific Application Server (AS) had yet been invoked in the
 signaling path.  If the call is later forwarded to a network using
 the History-Info header, it would be better not to lose history
 information due to passing though the network that only supports
 Diversion headers.  A recommended solution must not disrupt the
 standard behavior and networks that do not implement the History-Info
 header must be transparent to a received History-Info header.
 If a Diversion header is present in the incoming INVITE (in addition
 to History-Info header), only diversion information present in the
 History-Info header but not in the Diversion header must be inserted
 from the last entry (more recent) into the existing Diversion header,
 as recommended in [RFC5806].
 Note that the chronological order could not be certified.  If
 previous policy recommendations are respected, this case should not
 happen.

Mohali Informational [Page 8] RFC 6044 Mapping Diversion and History-Info October 2010

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

3. Headers Syntaxes Reminder

3.1. History-Info Header Syntax

 History-Info = "History-Info" HCOLON hi-entry *(COMMA hi-entry)
   hi-entry           = hi-targeted-to-uri *( SEMI hi-param )
   hi-targeted-to-uri = name-addr
   hi-param           = hi-index / hi-extension
   hi-index           = "index" EQUAL 1*DIGIT *(DOT 1*DIGIT)
   hi-extension       = generic-param
 The History-Info header is specified in [RFC4244].  The top-most
 History-Info entry (first in the list) corresponds to the oldest
 history information.
 A hi-entry may contain a cause URI parameter expressing the diversion
 reason.  This optional cause URI parameter is defined in [RFC4458]
 with the following syntax:
 cause-param = "cause" EQUAL Status-Code
 This parameter is also named cause-param and should be inserted in
 the History-Info entry (URI) of the diverted-to user in case of call
 diversion as recommended in the 3GPP CDIV specification [TS_24.604].
 The cause values used in the cause-param for the diverting reason are
 listed in the RFC 4458, and because it is a parameter dedicated to
 call forwarding service, its presence is used to determine that a hi-
 entry is a diverting user.  More precisely, each diverting user is
 located in the hi-entry before the one containing a cause-param with
 a cause value as listed in RFC 4458.

Mohali Informational [Page 9] RFC 6044 Mapping Diversion and History-Info October 2010

 Moreover, the Reason header defined in [RFC3326] should be escaped in
 the hi-entry of the diverting user when the call diversion is due to
 a received SIP response.  The Reason header contains a cause
 parameter set to the true SIP response code received (Status-Code).
 Therefore, in case of call diversion due to a SIP response, both
 cause parameters should be used.  The complexity is that these
 parameters could be used at the same time in the History-Info header
 but not in the same hi-entry and not with the same meaning.  Only the
 cause-param is dedicated to call diversion service.  The 'cause'
 Reason header parameter is not taken into account in the mapping with
 a Diversion header.
 [RFC4458] also defines the 'target' URI parameter, which could be
 inserted in a R-URI and consequently in the hi-targeted-to-uri.  This
 parameter is used to keep the diverting user address in the
 downstream INVITE request in Voicemail URI implementation.  As this
 information is already present in the hi-entries, the 'target' URI
 parameter is not taken into account regarding the interworking with
 the Diversion header.  From the Diversion header, it could be
 possible to create the 'target' URI parameter in the hi-entries
 and/or in the R-URI, but this possibility is based on local policies
 not described in this document.
 A Privacy header, as defined in [RFC3323], could also be included in
 hi-entries with the 'history' value defined in the [RFC4244].
 The index parameter is a string of digits, separated by dots, to
 indicate the number of forward hops and retargets.
 Note: A history entry could contain the "gr" parameter.  Regardless
 of the rules concerning the "gr" parameter defined in [TS_24.604],
 which must be applied, this parameter has no impact on the mapping
 and must only be copied with the served user address.
 Example:
 History-Info:
 <sip: diverting_user1_addr?Privacy=none?Reason=SIP%3Bcause%
 3D302>;index=1,
 <sip: diverting_user2_addr;cause=480?Privacy=history>;index=1.1,
 <sip:last_diversion_target;cause=486>; index=1.1.1
 Policy concerning "histinfo" option tag in Supported header:
 According to [RFC4244], a proxy that receives a Request with the
 "histinfo" option tag in the Supported header should return captured
 History-Info in subsequent, provisional and final responses to the
 Request.  The behavior depends upon whether or not the local policy
 supports the capture of History-Info.

Mohali Informational [Page 10] RFC 6044 Mapping Diversion and History-Info October 2010

3.2. Diversion Header Syntax

 The following text is restating the exact syntax that the production
 rules in [RFC5806] define, but using [RFC5234] ABNF:
  Diversion = "Diversion" HCOLON diversion-params
                               *(COMMA diversion-params)
  diversion-params    = name-addr *(SEMI (diversion-reason /
                        diversion-counter / diversion-limit /
                        diversion-privacy / diversion-screen /
                        diversion-extension))
  diversion-reason    = "reason" EQUAL ("unknown" / "user-busy" /
                        "no-answer" / "unavailable" / "unconditional"
                        / "time-of-day" / "do-not-disturb" /
                        "deflection" / "follow-me" / "out-of-service"
                        / "away" / token / quoted-string)
  diversion-counter   = "counter" EQUAL 1*2DIGIT
  diversion-limit     = "limit" EQUAL 1*2DIGIT
  diversion-privacy   = "privacy" EQUAL ("full" / "name" / "uri" /
                        "off" / token / quoted-string)
  diversion-screen    = "screen" EQUAL ("yes" / "no" / token /
                        quoted-string)
  diversion-extension = token [EQUAL (token / quoted-string)]
 Note: The Diversion header could be used in the comma-separated
 format, as described below, and in a header-separated format.  Both
 formats could be combined a received INVITE as recommended in
 [RFC3261].
 Example:
 Diversion:
 diverting_user2_addr; reason="user-busy"; counter=1; privacy=full,
 diverting_user1_addr; reason="unconditional"; counter=1; privacy=off

4. Headers in SIP Method

 The recommended interworking presented in this document should apply
 only for INVITE requests.
 In 3xx responses, both headers could be present.
 When a proxy wants to interwork with a network supporting the other
 header field, it should apply the interworking between Diversion
 header and History-Info header in the 3xx response.

Mohali Informational [Page 11] RFC 6044 Mapping Diversion and History-Info October 2010

 When a recursing proxy redirects an initial INVITE after receiving a
 3xx response, it should add as a last entry either a Diversion header
 or a History-Info header (according to its capabilities) in the
 forwarded INVITE.  Local policies could apply to send the received
 header in the next INVITE.
 Other messages where History-Info could be present are not used for
 the call forwarding service and should not be changed into Diversion
 header.  The destination network must be transparent to the received
 History-Info header.
 Note: the following mapping is inspired from the ISDN User Part
 (ISUP) to the SIP interworking described in [TS_29.163].

5. Diversion Header to History-Info Header

 The following text is valid only if no History-Info is present in the
 INVITE request.  If at least one History-Info header is present, the
 interworking function must adapt its behavior to respect the
 chronological order.  See section 2.2.
 For N Diversion entries, N+1 History-Info entries must be created.
 To create the History-Info entries in the same order than during a
 session establishment, the Diversion entries must be mapped from the
 bottom-most until the top-most.  Each Diversion entry shall be mapped
 into a History-Info entry.  An additional History-Info entry (the
 last one) must be created with the diverted-to party address present
 in the R-URI of the received INVITE.  The mapping is described below.
 The first entry created in the History-Info header contains:
  1. a hi-targeted-to-uri with the name-addr parameter of the bottom-

most Diversion header.

  1. 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.
  1. an index set to 1.
 For each following Diversion entry (from bottom to top), the History-
 info entries are created as following (from top to bottom):

Mohali Informational [Page 12] RFC 6044 Mapping Diversion and History-Info October 2010

Source Destination Diversion header component: History-Info header component:

name-addr hi-targeted-to-uri

Reason of the previous cause-param (not present in Diversion entry the first created hi-entry) "unknown"———————————404 (default 'cause' value) "unconditional"—————————302 "user-busy"——————————-486 "no-answer"——————————-408 "deflection "—————————–480 or 487 "unavailable"—————————–404 "time-of-day"—————————–404 (default) "do-not-disturb"————————–404 (default) "follow-me"——————————-404 (default) "out-of-service"————————–404 (default) "away"————————————404 (default)

Counter hi-index "1" or parameter ————————-The previous created index not present is incremented with ".1" Superior to "1" ————————–Create N-1 placeholder History (i.e., N) entry with the previous index

                                        incremented with ".1"
                                        Then the History-Info header
                                        created with the Diversion
                                        entry with the previous index
                                        incremented with ".1"

Privacy Privacy header escaped in the

                                        hi-targeted-to-uri

"full"————————————"history" "Off"————————————-Privacy header field

                                        absent or "none"

"name"————————————"history" "uri"————————————-"history"

 A last History-Info entry is created and contains:
  1. a hi-targeted-to-uri with the Request-URI of the INVITE request.
  1. a cause-param from the top-most Diversion entry, mapped from the

diversion-reason as described above.

Mohali Informational [Page 13] RFC 6044 Mapping Diversion and History-Info October 2010

  1. 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.
  1. an index set to the previous created index and incremented with

".1"

 Notes:
 1. For other optional Diversion parameters, there is no
    recommendation as History-Info header does not provide equivalent
    parameters.
 2. For values of the diversion-reason values that are mapped with a
    recommended default value, it could also be possible to choose
    another value.  The cause-param URI parameter offers less possible
    values than the diversion-reason parameter.  However, it has been
    considered that cause-param values list was sufficient to
    implement CDIV service as defined in 3GPP [TS_24.604] as it covers
    a large portion of cases.
 3. The Diversion header could contain a Tel:URI in the name-addr
    parameter, but it seems not possible to have a Tel:URI in the
    History-Info header.  [RFC3261] gives an indication as to the
    mapping between sip: and Tel:URIs, but in this particular case, it
    is difficult to assign a valid hostport as the diversion has
    occurred in a previous network and a valid hostport is difficult
    to determine.  So, it is suggested that in case of Tel:URI in the
    Diversion header, the History-Info header should be created with a
    SIP URI with user=phone.
 4. The Diversion header allows the carrying of a counter that retains
    the information about the number of successive redirections.  The
    History-Info header does not have an equivalent because to trace
    and count the number of diversion it is necessary to count cause
    parameter containing a value associated to a call diversion.  Read
    the index value is not enough.  With the use of the "placeholder"
    entry, the History-Info header entries could reflect the real
    number of diversion occurred.
 Example of placeholder entry in the History-Info header:
    <sip:unknown@unknown.invalid;cause=xxx>;index=1.1
    <sip:bob_addr;cause=404>;index=1.1.1

Mohali Informational [Page 14] RFC 6044 Mapping Diversion and History-Info October 2010

 "cause=xxx" reflects the diverting reason of a previous diverting
 user.  For a placeholder hi-entry, the value "404" must be taken for
 the cause-param and so, located in the next hi-entry.
 Concerning local policies recommendations about headers coexistence
 in the INVITE request, see sections 2.2 and 7.5.

6. History-Info Header to Diversion Header

 To create the Diversion entries in the same order than during a
 session establishment, the History-Info entries must be mapped from
 the top-most until the bottom-most.  The first History-Info header
 entry selected will be mapped into the last Diversion header entry
 and so on.  One Diversion header entry must be created for each
 History-Info entry, with a cause-param reflecting a diverting reason
 as listed in the [RFC4458].
 In this case, the History-Info header must be mapped into the
 Diversion header as following:

Mohali Informational [Page 15] RFC 6044 Mapping Diversion and History-Info October 2010

 Source                                    Destination
 History-Info header component:            Diversion header component:
 =====================================================================
 hi-targeted-to-uri of the                   name-addr
 History-Info that precedes the one
 containing a diverting cause-param.
 =====================================================================
 cause-param                               Reason
 404---------------------------------------"unknown" (default value)
 302---------------------------------------"unconditional"
 486---------------------------------------"user-busy"
 408---------------------------------------"no-answer"
 480 or 487--------------------------------"deflection "
 503---------------------------------------"unavailable"
 =====================================================================
 hi-index                                   Counter
 Mandatory parameter for--------------------The counter is set to "1".
 History-Info reflecting
 the chronological order
 of the information.
 =====================================================================
 Privacy header [RFC3323] escaped in the    Privacy
 hi-targeted-to-uri of the
 History-Info, which precedes the one
 containing a diverting cause-param.
 Optional parameter for History-Info,
 this Privacy indicates that this
 specific History-Info header should
 not be forwarded.
 "history"----------------------------------"full"
 Privacy header field ----------------------"Off"
 Absent or "none"
 =====================================================================
 Note: For other optional History-Info parameters, there is no
 recommendation as Diversion header does not provide equivalent
 parameters.
 Concerning local policies recommendations about headers coexistence
 in the INVITE request, see section 2.2.

Mohali Informational [Page 16] RFC 6044 Mapping Diversion and History-Info October 2010

7. Examples

7.1. Example with Diversion Header Changed into History-Info Header

 INVITE last_diverting_target
 Diversion:
 diverting_user3_address;reason=unconditional;counter=1;privacy=off,
 diverting_user2_address;reason=user-busy;counter=1;privacy=full,
 diverting_user1_address;reason=no-answer;counter=1;privacy=off
 Mapped into:
 History-Info:
 <sip: diverting_user1_address; privacy=none >; index=1,
 <sip: diverting_user2_address; cause=408?privacy=history>;index=1.1,
 <sip: diverting_user3_address; cause=486?privacy=none>;index=1.1.1,
 <sip: last_diverting_target; cause=302>;index=1.1.1.1

7.2. Example with History-Info Header Changed into Diversion Header

 History-Info:
 <sip: diverting_user1_address?privacy=history >; index=1,
 <sip: diverting_user2_address; cause=302? privacy=none>;index=1.1,
 <sip: last_diverting_target; cause=486>;index=1.1.1
 Mapped into:
 Diversion:
 diverting_user2_address; reason=user-busy; counter=1; privacy=off,
 diverting_user1_address; reason=unconditional; counter=1;
 privacy=full

7.3. Example with Two SIP Networks Using History-Info Header

    Interworking with a SIP Network Using Diversion Header
 A -> P1 -> B -> C -> P2 -> D-> E
 A, B, C, D and E are users.
 B, C and D have Call Forwarding service invoked.
 P1 and P2 are proxies.
 Only relevant information is shown on the following call flow.

Mohali Informational [Page 17] RFC 6044 Mapping Diversion and History-Info October 2010

                        IWF*                                IWF*
   SIP network using     |           SIP network using       |SIP net.
     History-Info        |                Diversion          |using
                         |                                   Hist-Info
                         |                                   |
 UA A    P1     AS B     |      P2     AS C    UA C   AS D   |    UA E
 |       |       |       |      |       |       |     |      |       |
 |INV B  |       |       |      |       |       |     |      |       |
 |------>|       |       |      |       |       |     |      |       |
 |       |       |       |      |       |       |     |      |       |
 |       |INV B  |       |      |       |       |     |      |       |
 |       |------>|       |      |       |       |     |      |       |
 |       |Supported: histinfo   |       |       |     |      |       |
 |       | History-Info:        |       |       |     |      |       |
 |       | <sip:proxyP1>; index=1,      |       |     |      |       |
 |       | <sip:userB >; index=1.1      |       |     |      |       |
 |       |       |       |      |       |       |     |      |       |
 |       |       |INV C  |      |       |       |     |      |       |
 |       |       |------>|      |       |       |     |      |       |
 |       |       |History-Info: |       |       |     |      |       |
 |       |       <sip:proxyP1>; index=1,|       |     |      |       |
 |       |       <sip:userB>; index=1.1 |       |     |      |       |
 |       |       <sip:userC; cause=302>; index=1.1.1  |      |       |
 |       |       |       |      |       |       |     |      |       |
 |       |       |       |INV C |       |       |     |      |       |
 |       |       |       |----->|       |       |     |      |       |
 |       |       |       |Diversion:    |       |     |      |       |
 |       |       |       |B reason= unconditional counter=1  |       |
 |       |       |       |History-Info: |       |     |      |       |
 |       |       |       <sip:proxyP1>; index=1,|     |      |       |
 |       |       |       <sip:userB>; index=1.1 |     |      |       |
 |       |       |       <sip:proxyP2; cause=302>; index=1.1.1       |
 |       |       |       |      |       |       |     |      |       |
 |       |       |       |      |INV C  |       |     |      |       |
 |       |       |       |      |------>|       |     |      |       |
 |       |       |       |     No modification of Diversion due to P2|
 |       |       |       |      |       |       |     |      |       |
 |       |       |       |      |       |INV C  |     |      |       |
 |       |       |       |      |       |------>|     |      |       |
 |       |       |       |      |       |       |     |      |       |
 |       |       |       |      |       |<--180-|     |      |       |
 |       |       |       |      |       |       |     |      |       |
 |       |       |       |      |  No response timer expire  |       |
 |       |       |       |      |       |---INV D --->|      |       |

Mohali Informational [Page 18] RFC 6044 Mapping Diversion and History-Info October 2010

 |       |       |Diversion:                          |      |       |
 |       |       |userC; reason=no-answer; counter=1; privacy=full,  |
 |       |       |userB; reason=unconditional; counter=1; privacy=off,
 |       |       |    History-Info:                   |      |       |
 |       |       |    <sip:proxyP1>; index=1,         |      |       |
 |       |       |    <sip:userB>; index=1.1          |      |       |
 |       |       |    <sip:proxyP2; cause=302>; index=1.1.1  |       |
 |       |       |       |      |       |       |     |      |       |
 |       |       |       |      |       |       |     |INV E |       |
 |       |       |       |      |       |       |     |----->|       |
 |       |       |Diversion:                                 |       |
 |       |       |userD; reason=time-of-day; counter=1; privacy=off  |
 |       |       |userC; reason=no-answer; counter=1; privacy=full,  |
 |       |       |userB; reason=unconditional; counter=1; privacy=off,
 |       |       |     History-Info:                         |       |
 |       |       |     <sip:proxyP1>; index=1,               |       |
 |       |       |     <sip:userB>; index=1.1                |       |
 |       |       |     <sip:proxyP2; cause=302>; index=1.1.1 |       |
 |       |       |       |      |       |       |     |      |       |
 |       |       |       |      |       |       |     |      | INV E |
 |       |       |       |      |       |       |     |      |------>|
 |       |       | History-Info:                                     |
 |       |       |  <sip:proxyP1>; index=1,                          |
 |       |       |  <sip:userB ?privacy=none>; index=1.1,            |
 |       |       |  <sip:proxyP2; cause=302>; index=1.1.1,           |
 |       |       |  <sip:userC ?privacy=history>; index=1.1.1.1,     |
 |       |      <sip:userD; cause=408 ?privacy=none>; index=1.1.1.1.1,
 |       |       |  <sip:userE; cause=404>; index=1.1.1.1.1.1        |
 |       |       |       |      |       |       |     |       |      |
 |       |       |       |      |       |       |     |       |      |
  • Note: The IWF is an interworking function that could be a stand-

alone equipment not defined in this document (it could be a proxy).

7.4. Additional Interworking Cases

 Even if for particular cases in which both headers could coexist, it
 should be the network local policy responsibility to make it work
 together.  Here are described some situations and some
 recommendations on the behavior to follow.
 In the case where there is one network that includes different nodes,
 some of them supporting the Diversion header and other ones
 supporting the History-Info header, there is a problem when any node
 handling a message does not know the next node that will handle the
 message.  This case can occur when the network has new and old nodes,
 the older ones using Diversion header and the more recent History-
 Info header.

Mohali Informational [Page 19] RFC 6044 Mapping Diversion and History-Info October 2010

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

8. Security Considerations

 The security considerations in [RFC4244] and [RFC5806] apply.
 The use of the Diversion header or the History-Info header require
 the application of the requested privacy and integrity asked by each
 diverting user or entity.  Without integrity, the requested privacy
 functions could be downgraded or eliminated, potentially exposing

Mohali Informational [Page 20] RFC 6044 Mapping Diversion and History-Info October 2010

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

9. Acknowledgements

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

10. References

10.1. Normative References

 [RFC3261]   Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
             A., Peterson, J., Sparks, R., Handley, M., and E.
             Schooler, "SIP: Session Initiation Protocol", RFC 3261,
             June 2002.
 [RFC3323]   Peterson, J., "A Privacy Mechanism for the Session
             Initiation Protocol (SIP)", RFC 3323, November 2002.
 [RFC3326]   Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason
             Header Field for the Session Initiation Protocol (SIP)",
             RFC 3326, December 2002.
 [RFC4244]   Barnes, M., Ed., "An Extension to the Session Initiation
             Protocol (SIP) for Request History Information", RFC
             4244, November 2005.
 [RFC5806]   Levy, S. and M. Mohali, Ed., "Diversion Indication in
             SIP", RFC 5806, March 2010.

10.2. Informative References

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

Mohali Informational [Page 21] RFC 6044 Mapping Diversion and History-Info October 2010

 [RFC5234]   Crocker, D., Ed., and P. Overell, "Augmented BNF for
             Syntax Specifications: ABNF", STD 68, RFC 5234, January
             2008.
 [TS_24.604] 3rd Generation Partnership Project, "Technical
             Specification Group Core Network and Terminals ;
             Communication Diversion (CDIV) using IP Multimedia
             (IM)Core Network (CN) subsystem ; Protocol specification
             (Release 8), 3GPP TS 24.604", December 2008.
 [TS_29.163] 3rd Generation Partnership Project, "Technical
             Specification Group Core Network and Terminals ;
             Interworking between the IP Multimedia (IM) Core Network
             (CN) Subsystem and Circuit Switched (CS) networks
             (Release 8)", December 2008.

Mohali Informational [Page 22] RFC 6044 Mapping Diversion and History-Info October 2010

Appendix A. Interworking between Diversion Header and Voicemail URI

 Voicemail URI is a mechanism described in RFC 4458 to provide a
 simple way to transport only one redirecting user address and the
 reason why the diversion occurred in the R-URI of the INVITE request.
 This mechanism is mainly used for call diversion to a voicemail.
 Diversion header to Voicemail URI:
 Received:
 Diversion: userA-address;reason=user-busy;counter=1;privacy=full
 Sent (Voicemail URI created in the R-URI line of the INVITE):
 sip: voicemail@example.com;target=userA-address;cause=486 SIP/2.0
 Mapping of the Redirection Reason is the same as for History-Info
 header with a default value set to 404.
 If the Diversion header contains more than one Diversion entry, the
 choice of the redirecting user information inserted in the URI is in
 charge of the network local policy.  For example, the choice
 criterion of the redirecting information inserted in the URI could be
 the destination of forwarded INVITE request (whether or not the
 voicemail serves this user).
 Note: This interworking could be done in addition to the interworking
 of the Diversion header into the History-Info header.
 Voicemail URI to Diversion header:
 In case of real voicemail, this way of interworking should not
 happen.  However, if for any reason it occurs, it is recommended to
 do it as following:
 Received:
 INVITE sip: voicemail@example.com;\
 target=sip:+33145454500%40example.com;user=phone;\
 cause=302 SIP/2.0
 Sent in the forwarded INVITE:
 Diversion: sip:+
 33145454500%40example.com;user=phone;reason=unconditional;counter=1

Mohali Informational [Page 23] RFC 6044 Mapping Diversion and History-Info October 2010

Author's Address

 Marianne Mohali
 France Telecom Orange
 38-40 rue du General Leclerc
 Issy-Les-Moulineaux Cedex 9  92794
 France
 Phone: +33 1 45 29 45 14
 EMail: marianne.mohali@orange-ftgroup.com

Mohali Informational [Page 24]

/data/webs/external/dokuwiki/data/pages/rfc/rfc6044.txt · Last modified: 2010/10/30 01:52 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki