GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc7544

Table of Contents

Independent Submission M. Mohali Request for Comments: 7544 Orange Obsoletes: 6044 August 2015 Category: Informational ISSN: 2070-1721

Mapping and Interworking of Diversion Information between Diversion and

History-Info Header Fields in the Session Initiation Protocol (SIP)

Abstract

 Although the SIP History-Info header field described in RFC 7044 is
 the solution adopted in IETF, the non-standard Diversion header field
 described, as Historic, in RFC 5806 is nevertheless already
 implemented and used for conveying call-diversion-related information
 in Session Initiation Protocol (SIP) signaling.
 RFC 7044 obsoletes the original RFC 4244 and redefines the History-
 Info header field for capturing the history information in requests.
 Since the Diversion header field is used in existing network
 implementations for the transport of call diversion information, its
 interworking with the SIP History-Info standardized solution is
 needed.  This document describes a recommended interworking guideline
 between the Diversion header field and the History-Info header field
 to handle call diversion information.  This work is intended to
 enable the migration from non-standard implementations toward IETF
 specification-based implementations.
 This document obsoletes RFC 6044, which describes the interworking
 between the Diversion header field defined in RFC 5806 and the
 obsoleted History-Info header field defined on RFC 4244.

Mohali Informational [Page 1] RFC 7544 Mapping of Diversion and History-Info August 2015

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

Copyright Notice

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

Mohali Informational [Page 2] RFC 7544 Mapping of Diversion and History-Info August 2015

Table of Contents

 1. Introduction ....................................................4
    1.1. Overview ...................................................4
    1.2. Background .................................................4
    1.3. From RFC 4244 to RFC 7044 ..................................5
 2. Problem Statement ...............................................5
 3. Interworking Recommendations ....................................7
    3.1. General Recommendations ....................................7
    3.2. Privacy Considerations .....................................8
    3.3. Headers in SIP Method .....................................10
    3.4. SIP Network/Terminal Using Diversion Header Field
         to SIP Network/Terminal Using History-Info Header Field ...10
    3.5. SIP Network/Terminal Using History-Info Header
         Field to SIP Network/Terminal Using Diversion
         Header Field ..............................................12
 4. Reminder of the Syntax for Header Fields .......................13
    4.1. History-Info Header Field Syntax ..........................13
    4.2. Diversion Header Field Syntax .............................16
 5. Diversion Header Field to History-Info Header Field ............16
 6. History-Info Header Field to Diversion Header Field ............20
 7. Examples .......................................................22
   7.1.  Example with Diversion Header Field Changed into
         History-Info Header Field .................................22
   7.2.  Example with History-Info Header Field Changed into
         Diversion Header Field ....................................22
   7.3.  Example with Two SIP Networks Using History-Info Header
         Field Interworking with a SIP Network Using Diversion
         Header Field ..............................................22
   7.4.  Additional Interworking Cases .............................24
 8. Backward Compatibility .........................................26
 9. Security Considerations ........................................26
 10. References ....................................................26
    10.1. Normative References .....................................26
    10.2. Informative References ...................................27
 Appendix A.  Interworking between Diversion Header Field and
              Voicemail URI ........................................29
   A.1.  Diversion Header Field to Voicemail URI ...................29
   A.2.  Voicemail URI to Diversion Header Field ...................29
 Acknowledgements ..................................................30
 Author's Address ..................................................30

Mohali Informational [Page 3] RFC 7544 Mapping of Diversion and History-Info August 2015

1. Introduction

1.1. Overview

 For some services based on VoIP (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 header fields: the History-Info header field
 defined in [RFC7044] and the historic Diversion header field defined
 in [RFC5806].  Both of these header fields are able to transport
 diversion information in SIP signaling.
 Although the Diversion header field is not standardized, it has been
 widely implemented.  Therefore, it is useful to have guidelines to
 make this header field interwork with the standard History-Info
 header field.
 Note that new implementation and deployment of the Diversion header
 field are strongly discouraged.
 This document provides a mechanism for the translation of header
 field content between the Diversion header field and the History-Info
 header field.
 This document obsoletes [RFC6044].

1.2. Background

 The obsoleted History-Info header field [RFC4244] and its extension
 for forming SIP service URIs (including Voicemail URI) [RFC4458] used
 to be recommended by IETF to convey redirection information.  They
 also used to be recommended in the Communication Diversion (CDIV)
 3GPP specification [TS_24.604].
 The Diversion header field was originally described in a document
 that was submitted to the SIP Working Group and was eventually
 published as an Independent Submission as [RFC5806] for the
 historical record; it serves as a reference for this RFC.
 This header field contains a list of diverting URIs and associated
 information providing specific information as the reason for the call
 diversion.  Most of the first SIP-based implementations have
 implemented the Diversion header field when no standard solution was
 ready to deploy.  The IETF has standardized the History-Info header
 field partly because it can transport general history information.

Mohali Informational [Page 4] RFC 7544 Mapping of Diversion and History-Info August 2015

 This allows the receiving party to determine how and why the session
 is received.  As the History-Info header field may contain further
 information than call diversion information, it is critical to avoid
 losing information and to be able to extract the relevant data using
 the retargeting cause URI parameter described in [RFC4458] for the
 transport of the call forwarding reason.
 The Diversion header field and the History-Info header field have
 different syntaxes, which are described in this document.  Note that
 the main difference is that the History-Info header field is a
 chronological writing header whereas the Diversion header field
 applies a reverse chronology (i.e., the first diversion entry read
 corresponds to the last diverting user).
 Appendix A provides an interworking guideline between the Diversion
 header field and the Voicemail URI, which is another way to convey
 diversion information without using the History-Info header field.
 The Voicemail URI is defined in [RFC4458].

1.3. From RFC 4244 to RFC 7044

 The details of why and how [RFC4244] was obsoleted by [RFC7044] are
 provided in Section 16 of [RFC7044].
 The main changes for implementation of the History-Info header field
 are as follows:
 1.  The header field parameters "mp", "rc", and "np" were added to
     capture the specific method by which a target is determined.
 2.  A way to indicate a gap in the History-Info header field was
     added by using a "0" in the index.
 3.  To apply privacy, entries were anonymized rather than removed.
 4.  Many SHOULDs were changed into MUSTs to have a more reliable
     header.
 Backward-compatibility aspects are discussed in Section 8 of this
 document.

2. Problem Statement

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

Mohali Informational [Page 5] RFC 7544 Mapping of Diversion and History-Info August 2015

 There are many ways in which SIP signaling can be used to modify a
 session destination before it is established and many reasons for
 doing so.  The behavior of the SIP entities that will have to further
 process the session downstream will sometimes vary depending on the
 reasons that led to changing the destination, for example, whether it
 is for a simple proxy to route the session or for an application
 server (AS) to provide a supplementary service.  The Diversion header
 field and the History-Info header field differ in the approach and
 scope of addressing this problem.
 For clarity, the following vocabulary is used in this document:
 o  Retarget/redirect: these terms refer to the process of a Proxy
    Server/User Agent Client (UAC) changing a Request-URI (Section 7.1
    of [RFC3261]) in a request and thus changing the target of the
    request.  This includes changing the Request-URI due to a location
    service lookup and redirect processing.  This also includes
    internal (to a proxy/SIP intermediary) changes of the URI prior to
    forwarding of the request.  The term "retarget" is defined in
    [RFC7044].
 o  Call forwarding/call diversion/communication diversion: these
    terms are equivalent and refer to the Communications Diversion
    (CDIV) supplementary services, based on the ISDN Communication
    diversion supplementary services and defined in 3GPP [TS_24.604].
    They are applicable to entities that are intended to modify the
    original destination of an IP multimedia session during or prior
    to the session establishment.
 This document does not intend to describe when or how History-Info or
 Diversion header fields should be used.  Hereafter is provided
 clarification on the context in which the interworking is required.
 The Diversion header field has exactly the same scope as the call
 diversion service, and each header field entry reflects a call
 diversion invocation.  The Diversion header field is used for
 recording call forwarding information that could be useful to network
 entities downstream.  Today, this SIP header field is implemented by
 several manufacturers and deployed in networks.
 The History-Info header field is used to store all retargeting
 information, including call diversion information.  As such, the
 History-Info header field [RFC7044] is used to convey call-diversion-
 related information by using a cause URI parameter [RFC4458] in the
 relevant entry.

Mohali Informational [Page 6] RFC 7544 Mapping of Diversion and History-Info August 2015

 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 the History-Info
 header field and one using the Diversion header field.
 [RFC7044] defines three header field parameters: "rc", "mp", and
 "np".  The header field parameters "rc" and "mp" indicate the
 mechanism by which a new target for a request is determined.  The
 header field "np" reflects that the target has not changed.  All
 parameters contain an index whose value refers to the hi-index of the
 hi-entry, which contains a hi-targeted-to-uri that represents the
 Request-URI that was retargeted.
 Since both header fields address call forwarding needs, diverting
 information could be mixed up or be inconsistent if both are present
 in an uncoordinated fashion in the INVITE request.  So, Diversion and
 History-Info header fields must not independently coexist in the same
 session signaling.  This document addresses how to convert
 information between the Diversion header field and the History-Info
 header field and when and how to preserve both header fields to cover
 additional cases.
 For the transportation of consistent diversion information
 downstream, it is necessary to make the two header fields interwork.
 Interworking between the Diversion header field and the History-Info
 header field is introduced in Sections 5 and 6.  Since the
 coexistence scenario may vary from one use case to another,
 guidelines regarding interaction of header fields are proposed in
 Section 3.

3. Interworking Recommendations

3.1. General Recommendations

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

Mohali Informational [Page 7] RFC 7544 Mapping of Diversion and History-Info August 2015

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

3.2. Privacy Considerations

 When a SIP message is forwarded to a domain for which the SIP
 intermediary is not responsible, a Privacy Service at the boundary of
 the domain applies the appropriate privacy based on the value of the
 Privacy header field in the message header or in the privacy
 parameter within the concerned header:
 1.  For the History-Info header field, it is the Privacy header field
     included as the "headers" component of the hi-targeted-to-uri in
     the individual hi-entries with the priv-value "history".
 2.  For the Diversion header field, it is the diversion-privacy
     parameter "privacy" in each Diversion header field.

Mohali Informational [Page 8] RFC 7544 Mapping of Diversion and History-Info August 2015

 For the History-Info header field, as recommended in [RFC7044]:
 o  If there is a Privacy header field in the message header of a
    request with a priv-value of "header" or "history", then all the
    hi-targeted-to-uris (in the hi-entries associated with the domain
    for which the SIP intermediary is responsible) are anonymized by
    the Privacy Service.  The Privacy Service must change any
    hi-targeted-to-uri in these hi-entries that have not been
    anonymized to the anonymous SIP URI "anonymous@anonymous.invalid"
    as recommended in Sections 4.1.1.2 and 4.1.1.3 of [RFC3323].
 o  If there is a Privacy header field in the "headers" component of a
    hi-targeted-to-uri with a priv-value of "history", then all the
    concerned hi-entries must be anonymized as described above prior
    to forwarding.
 The Privacy Service must remove the Privacy header field from the
 "headers" component of the hi-targeted-to-uris of the concerned
 hi-entries and the priv-value of "history" from the Privacy header
 field in the message header of the request prior to forwarding.  If
 there are no remaining priv-values in the Privacy header field, the
 Privacy Service must remove the Privacy header field from the
 request.
 For the Diversion header field:
 o  If there is a Privacy header field in the message header of a
    request with a priv-value of "header", then all the addresses in
    the Diversion header fields (associated with the domain for which
    the SIP intermediary is responsible) are anonymized by the Privacy
    Service by changing the address to the anonymous SIP URI
    "anonymous@anonymous.invalid" as recommended in Sections 4.1.1.2
    and 4.1.1.3 of [RFC3323] prior to forwarding.
 o  For each Diversion header field or each entry in the Diversion
    header field, if there is a diversion-privacy parameter with a
    value set to "full", "uri", or "name", then the concerned
    Diversion header field address must be anonymized as described
    above prior to forwarding.
 In the concerned Diversion header field entries, the diversion-
 privacy parameter must be removed from the header.
 The privacy information interworking as described in Sections 5 and 6
 must only be considered within a trusted domain that ensures correct
 application of the privacy requirements.

Mohali Informational [Page 9] RFC 7544 Mapping of Diversion and History-Info August 2015

3.3. Headers in SIP Method

 The recommended interworking presented in this document should apply
 only for INVITE requests.
 In 3xx responses:
    Both History-Info and Diversion header fields could be present in
    3xx responses.
    When a proxy wants to interwork with a network supporting the
    other header field, it should apply the interworking between
    Diversion header field and History-Info header field in the 3xx
    response.
    When a recursing proxy redirects an initial INVITE after receiving
    a 3xx response, it should add as a last entry either a Diversion
    header field or a History-Info header field (according to its
    capabilities) in the forwarded INVITE.  Local policies could apply
    regarding whether or not to send the received header field in the
    next INVITE.
 In SIP responses other than 100:
    All SIP responses where the History-Info header field could be
    present are not used for the call forwarding service and should
    not be changed into the Diversion header field.  The destination
    network must be transparent to the received History-Info header
    field.
 Note: The following mapping is inspired by the ISDN User Part (ISUP)
 to SIP interworking described in [TS_29.163].

3.4. SIP Network/Terminal Using Diversion Header Field to SIP Network/

    Terminal Using History-Info Header Field
 When the Diversion header field is used to create a History-Info
 header field, the Diversion header field must be removed in the
 outgoing INVITE.  It is assumed that all the information present in
 the Diversion header field is transferred in the History-Info header
 field.
 If a History-Info header field is also present in the incoming INVITE
 (in addition to the Diversion header field), the Diversion header
 field and History-Info header field present must be mixed, and only
 the diversion information not yet present in the History-Info header

Mohali Informational [Page 10] RFC 7544 Mapping of Diversion and History-Info August 2015

 field must be inserted as a last entry (most recent) in the existing
 History-Info header field, following the creation process recommended
 in [RFC7044].
 As an example, this could be the case of an INVITE coming from
 network_2 using the Diversion header field but previously passed
 through network_1 using the History-Info header field (or the
 network_2 uses History-Info header field to transport successive URI
 information) and going to network_3 using the History-Info header
 field.
                     IWF*                                  IWF*
   network_1          |                network_2            |network_3
  History-Info        |                 Diversion           |using
                      |                                     |History-
                      |                                     |Info

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

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

Mohali Informational [Page 11] RFC 7544 Mapping of Diversion and History-Info August 2015

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

3.5. SIP Network/Terminal Using History-Info Header Field to SIP

    Network/Terminal Using Diversion Header Field
 When the History-Info header field is interpreted to create a
 Diversion header field, some precautions must be taken.
 If the History-Info header field contains only call forwarding
 information, then it must be deleted after the interworking.
 If the History-Info header field contains other information, then
 only the information of concern to the diverting user must be used to
 create entries in the Diversion header field, and the History-Info
 header field must be kept as received in the INVITE and forwarded
 downstream.
 Note: The History-Info header field could be used for reasons other
 than call diversion services, for example, by a service that needs to
 know if a specific AS has yet been invoked in the signaling path.  If
 the call is later forwarded to a network using the History-Info
 header field, it would be better not to lose history information due
 to passing though the network that only supports the Diversion header
 field.  A recommended solution must not disrupt the standard
 behavior, and networks that do not implement the History-Info header
 field must be transparent to a received History-Info header field.
 If a Diversion header field is present in the incoming INVITE (in
 addition to the History-Info header field), only diversion
 information present in the History-Info header field but not in the
 Diversion header field must be inserted from the last entry (most
 recent) into the existing Diversion header field 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 12] RFC 7544 Mapping of Diversion and History-Info August 2015

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

4. Reminder of the Syntax for Header Fields

4.1. History-Info Header Field Syntax

 The ABNF syntax [RFC5234] for the History-Info header field and
 header field parameters is as follows.
 History-Info       = "History-Info" HCOLON hi-entry *(COMMA hi-entry)
 hi-entry           = hi-targeted-to-uri *(SEMI hi-param)
 hi-targeted-to-uri = name-addr
 hi-param           = hi-index/hi-target-param/hi-extension
 hi-index           = "index" EQUAL index-val
 index-val          =  number *("." number)
 number             =  [ %x31-39 *DIGIT ] DIGIT
 hi-target-param    = rc-param / mp-param / np-param
 rc-param           = "rc" EQUAL index-val
 mp-param           = "mp" EQUAL index-val
 np-param           = "np" EQUAL index-val
 hi-extension       = generic-param
 The ABNF definitions for "generic-param", "name-addr", "HCOLON",
 "COMMA", "SEMI", and "EQUAL" are from [RFC3261].
 The History-Info header field is specified in [RFC7044].  The top-
 most History-Info entry (first in the list) corresponds to the oldest
 history information.

Mohali Informational [Page 13] RFC 7544 Mapping of Diversion and History-Info August 2015

 Cause URI parameter:
    A hi-entry may contain a cause URI parameter expressing the
    diversion reason.  This cause URI parameter is defined in
    [RFC4458].  The ABNF grammar [RFC5234] for the cause-param
    parameter is shown below as it has been subject to Erratum ID 1409
    [Err1409] for [RFC4458].  The Status-Code is defined in [RFC3261].
    cause-param = "cause=" Status-Code
    The cause-param parameter is a SIP/SIPS URI parameter and should
    be inserted in the History-Info entry (URI) of the diverted-to
    user in case of call diversion as recommended in the 3GPP CDIV
    specification [TS_24.604].  The cause values used in the cause-
    param for the diverting reason are listed in [RFC4458].  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 cause value as listed
    in [RFC4458].
 Reason header field:
    The Reason header field defined in [RFC3326] should be escaped in
    the hi-entry of the diverting user when the call diversion is due
    to a received SIP response.  The Reason header field contains a
    cause parameter set to the true SIP response code received
    (Status-Code).
    Therefore, in case of call diversion due to a SIP response, both
    cause parameters should be used.  The complexity is that these
    parameters could be used at the same time in the History-Info
    header field but not in the same hi-entry and not with the same
    meaning.  Only the cause-param is dedicated to call diversion
    service.  The 'cause' Reason header field parameter is not taken
    into account in the mapping with a Diversion header field.
 Target URI parameter:
    [RFC4458] also defines the 'target' URI parameter, which could be
    inserted in a Request-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 field.  From
    the Diversion header field, it could be possible to create the

Mohali Informational [Page 14] RFC 7544 Mapping of Diversion and History-Info August 2015

    'target' URI parameter in the hi-entries and/or in the Request-
    URI, but this possibility is based on local policies not described
    in this document.
 Privacy header field:
    A Privacy header field as defined in [RFC3323] could also be
    embedded in hi-entries with the 'history' value defined in
    [RFC7044].
 Index header field parameter:
    The index parameter is a string of digits, separated by dots, 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.
 Missing entry:
    If the request clearly has a gap in the hi-entry (i.e., the last
    hi-entry and Request-URI differ), the entity adding a hi-entry
    must add a single index with a value of "0" (i.e., the non-
    negative integer zero) prior to adding the appropriate index for
    the action to be taken (e.g., Index=1.1.2.0.1).  Prior to any
    application usage of the History-Info header field parameters, the
    SIP entity that processes the hi-entries must evaluate the
    hi-entries and determine if there are any gaps in them.
 "histinfo" option tag:
    According to [RFC7044], a proxy that receives a Request with the
    "histinfo" option tag in the Supported header field should return
    captured History-Info in subsequent, provisional, and final
    responses to the Request.  The behavior depends upon whether or
    not the local policy supports the capture of History-Info.
 Example:
 History-Info:
 <sip:diverting_user1_addr?Privacy=none&Reason=SIP%3Bcause%3D302>;
 index=1,
 <sip:diverting_user2_addr;cause=480?Privacy=history>;index=1.1;mp=1,
 <sip:last_diversion_target;cause=486>;index=1.1.1;mp=1.1

Mohali Informational [Page 15] RFC 7544 Mapping of Diversion and History-Info August 2015

4.2. Diversion Header Field Syntax

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

5. Diversion Header Field to History-Info Header Field

 The following text is valid only if no History-Info header field is
 present in the INVITE request.  If at least one History-Info header
 field is present, the interworking function must adapt its behavior
 to respect the chronological order.  For more information, see
 Section 3.
 Concerning the privacy information in the Diversion header field, the
 following mapping only applies within a trusted domain; for other
 domains, see the privacy considerations in Section 3.2.

Mohali Informational [Page 16] RFC 7544 Mapping of Diversion and History-Info August 2015

 For N Diversion entries, N+1 History-Info entries must be created.
 To create the History-Info entries in the same order as during a
 session establishment, the Diversion entries must be mapped from the
 bottom-most to the top-most.  Each Diversion entry shall be mapped
 into a History-Info entry.  An additional History-Info entry (the
 last one) must be created with the diverted-to party address present
 in the Request-URI of the received INVITE.  The mapping is described
 in the table below.
 The first entry created in the History-Info header field contains:
 o  a hi-targeted-to-uri with the name-addr parameter of the bottom-
    most Diversion header field.
 o  if a privacy parameter is present in the bottom-most Diversion
    entry, then a Privacy header field must be escaped in the History-
    Info header field as described in the table below.
 o  a hi-index set to 1.
 For each of the following Diversion entries (from bottom to top), the
 History-Info entries are created as follows (from top to bottom):

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

name-addr hi-targeted-to-uri

reason of the previous cause URI parameter Diversion entry A cause-param "cause" is

                                        added in each hi-entry
                                        (except the first one)

"unknown"———————————-404 (default 'cause' value) "unconditional"—————————-302 "user-busy"——————————–486 "no-answer"——————————–408 "deflection "——————————480 or 487 "unavailable"——————————503 "time-of-day"——————————404 (default) "do-not-disturb"—————————404 (default) "follow-me"——————————–404 (default) "out-of-service"—————————404 (default) "away"————————————-404 (default)

Mohali Informational [Page 17] RFC 7544 Mapping of Diversion and History-Info August 2015

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

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

privacy Privacy header escaped in the

                                        hi-targeted-to-uri

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

                                        absent or "none"

"name"———————————–"history" "uri"————————————"history"

                                        hi-target-param
                                        An mp-param "mp" is added in
                                        each created hi-entry
                                        (except the first one)
                                        The "mp" parameter is set to
                                        the index value of the
                                        preceding hi-entry.
 A last History-Info entry is created and contains:
 o  a hi-targeted-to-uri with the Request-URI of the INVITE request.
 o  a cause-param from the top-most Diversion entry, mapped from the
    diversion-reason as described above.
 o  an index set to the previous created index extended with a new
    level ".1" added at the end.
 o  a hi-target-param set to "mp" equals to the index value of the
    previous hi-entry.
 Notes:
 1.  For other optional Diversion parameters, there is no
     recommendation as the History-Info header field does not provide
     equivalent parameters.

Mohali Informational [Page 18] RFC 7544 Mapping of Diversion and History-Info August 2015

 2.  For values of the diversion-reason that are mapped with a
     recommended default value, it could also be possible to choose
     another value.  The cause-param URI parameter offers fewer
     possible values than the diversion-reason parameter.  However, it
     has been considered that the cause-param values list was
     sufficient to implement CDIV service as defined in 3GPP
     [TS_24.604] as it covers a large portion of cases.
 3.  The Diversion header field can contain a "tel" URI as defined in
     [RFC3966] in the name-addr parameter.  The History-Info header
     field can also contain an address that is a "tel" URI, but if
     this hi-entry has to be completed with either a SIP header field
     (e.g., Reason or Privacy) or a SIP URI parameter (e.g., 'cause'
     or 'target'), the "tel" URI must be converted into a SIP URI.
     [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 occurred in a previous network
     and a valid hostport is difficult to determine.  So, it is
     suggested that in case of "tel" URI in the Diversion header
     field, the History-Info header field should be created with a SIP
     URI with user=phone and a domain set to "unknown.invalid".
 4.  The Diversion header field allows carrying of a counter that
     retains the information about the number of successive
     redirections.  History-Info does not have an equivalent because
     to trace and count the number of diversions, it is necessary to
     count the cause parameter containing a value associated to a call
     diversion listed in [RFC4458].  Reading the index value is not
     enough.  With the use of the "placeholder" entry the History-Info
     header field, entries can reflect the real number of diversions
     that occurred, thanks to the cause-param.
 Example of placeholder entry in the History-Info header field:
    <sip:unknown@unknown.invalid;cause=xxx>;index=1.1
    <sip:bob_addr;cause=404>;index=1.1.1;mp=1.1
 "cause=xxx" reflects the diverting reason of a previous diverting
 user.  For a placeholder hi-entry, the value "404" must be taken for
 the cause-param and so, located in the next hi-entry.
 For recommendations for local policies regarding the coexistence of
 header fields in the INVITE request, see Sections 3 and 7.4.

Mohali Informational [Page 19] RFC 7544 Mapping of Diversion and History-Info August 2015

6. History-Info Header Field to Diversion Header Field

 Concerning the privacy information for the History-Info header field,
 the following mapping only applies within a trusted domain; for other
 domains, see the privacy considerations in Section 3.2.
 To create the Diversion entries in the same order as during a session
 establishment, the History-Info entries must be mapped from the top-
 most to the bottom-most.  The first History-Info header field entry
 selected will be mapped into the last Diversion header field entry
 and so on.  One Diversion header field entry must be created for each
 History-Info entry that has cause-param with a value listed in
 [RFC4458].
 Diversion information:
 The definitions of "Target_entry" and "Diverting_entry" are included
 below to help readers understand the mapping of the History-Info
 header field.
 The diversion information can be identified by finding the following
 hi-entries:
 o  Target_entry: hi-entries containing a cause-param URI parameter
    with a value listed in [RFC4458] will contain the diversion reason
    and the address of the target of the concerned call forwarding.
    Per [RFC7044], these hi-entries may also contain a hi-target-param
    set to "mp".
 o  Diverting_entry: For each previously identified hi-entry:
  • If there is an "mp" header field parameter, the hi-entry whose

hi-index matches the value of the hi-target-param "mp" will

       contain the diverting party address, its possible privacy, and/
       or SIP reason when the retargeting has been caused by a
       received SIP response.
  • If there is no "mp" header field parameter, the information of

the diverting party address, privacy and/or SIP reason will be

       found in the hi-entry that precede this identified hi-entry.
 Note: Per [RFC7044], all retargeting entries must point to a hi-entry
 that contains an "mp" parameter, but for backward-compatibility
 reasons, it may be absent from some of the received hi-entries.  See
 Section 8 for more information on backward compatibility.
 The History-Info header field must be mapped into the Diversion
 header field as follows:

Mohali Informational [Page 20] RFC 7544 Mapping of Diversion and History-Info August 2015

 Source                                    Destination
 History-Info header component:            Diversion header component:
 =====================================================================
 hi-targeted-to-uri                        name-addr
 of the Diverting_entry.
 =====================================================================
 cause-param                               reason
 of the Target_entry
 404---------------------------------------"unknown" (default value)
 302---------------------------------------"unconditional"
 486---------------------------------------"user-busy"
 408---------------------------------------"no-answer"
 480 or 487--------------------------------"deflection "
 503---------------------------------------"unavailable"
 =====================================================================
 hi-index                                  counter
 Mandatory parameter for-------------------The counter is set to "1".
 History-Info reflecting
 the chronological order
 of the information.
 =====================================================================
 Privacy header field escaped              privacy
 in the hi-targeted-to-uri
 of the Diverting_entry
 "history"----------------------------------"full"
 Privacy header field ----------------------"Off"
 Absent or "none"
 =====================================================================
 Note: For other optional History-Info parameters, there is no
 recommendation as the Diversion header field does not provide
 equivalent parameters.
 For recommendations for local policies regarding the coexistence of
 header fields in the INVITE request, see Section 3.

Mohali Informational [Page 21] RFC 7544 Mapping of Diversion and History-Info August 2015

7. Examples

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

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

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

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

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

    Interworking with a SIP Network Using Diversion Header Field
 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 22] RFC 7544 Mapping of Diversion and History-Info August 2015

                        IWF*                                IWF*
   SIP network using     |           SIP network using       |SIP net.
     History-Info        |                Diversion          |using
                         |                                History-Info
                         |                                   |
 UA A    P1     AS B     |      P2     AS C    UA C   AS D   |    UA E
 |       |       |       |      |       |       |     |      |       |
 |INV B  |       |       |      |       |       |     |      |       |
 |------>|       |       |      |       |       |     |      |       |
 |       |       |       |      |       |       |     |      |       |
 |       |INV B  |       |      |       |       |     |      |       |
 |       |------>|       |      |       |       |     |      |       |
 |       |Supported: histinfo   |       |       |     |      |       |
 |       | History-Info:        |       |       |     |      |       |
 |       | <sip:proxyP1>;index=1,       |       |     |      |       |
 |       | <sip:userB>;index=1.1;rc=1   |       |     |      |       |
 |       |       |       |      |       |       |     |      |       |
 |       |       |INV C  |      |       |       |     |      |       |
 |       |       |------>|      |       |       |     |      |       |
 |       |       |History-Info: |       |       |     |      |       |
 |       |       <sip:proxyP1>;index=1, |       |     |      |       |
 |       |       <sip:userB>;index=1.1;rc=1,    |     |      |       |
 |       |       <sip:proxyP2;cause=302>;index=1.1.1;mp=1.1  |       |
 |       |       |       |      |       |       |     |      |       |
 |       |       |       |INV C |       |       |     |      |       |
 |       |       |       |----->|       |       |     |      |       |
 |       |       | Diversion:   |       |       |     |      |       |
 |       |     <sip:userB>;reason=unconditional;counter=1;privacy=off|
 |       |       |       |History-Info: |       |     |      |       |
 |       |       |       <sip:proxyP1>;index=1, |     |      |       |
 |       |       |       <sip:userB>;index=1.1;rc=1,  |      |       |
 |       |       |       <sip:proxyP2;cause=302>;index=1.1.1;mp=1.1  |
 |       |       |       |      |       |       |     |      |       |
 |       |       |       |      |INV C  |       |     |      |       |
 |       |       |       |      |------>|       |     |      |       |
 |       |       |       |     No modification of Diversion header   |
 |       |       |       |      |       |       |     |      |       |
 |       |       |       |      |       |INV C  |     |      |       |
 |       |       |       |      |       |------>|     |      |       |
 |       |       |       |      |       |       |     |      |       |
 |       |       |       |      |       |<--180-|     |      |       |
 |       |       |       |      |       |       |     |      |       |
 |       |       |       |      |  No response timer expires |       |
 |       |       |       |      |       |---INV D --->|      |       |
 |       |       |Diversion:                          |      |       |
 |       |     <sip:userC>;reason=no-answer;counter=1;privacy=full,  |
 |       |     <sip:userB>;reason=unconditional;counter=1;privacy=off|
 |       |       |    History-Info:                   |      |       |

Mohali Informational [Page 23] RFC 7544 Mapping of Diversion and History-Info August 2015

 |       |       |    <sip:proxyP1>;index=1,          |      |       |
 |       |       |    <sip:userB>;index=1.1;rc=1,     |      |       |
 |       |       |    <sip:proxyP2;cause=302>;index=1.1.1;mp=1.1     |
 |       |       |       |      |       |       |     |      |       |
 |       |       |       |      |       |       |     |INV E |       |
 |       |       |       |      |       |       |     |----->|       |
 |       |       |Diversion:                                 |       |
 |       |     <sip:userD>;reason=time-of-day;counter=1;privacy=off, |
 |       |     <sip:userC>;reason=no-answer;counter=1;privacy=full,  |
 |       |     <sip:userB>;reason=unconditional;counter=1;privacy=off|
 |       |       |     History-Info:                         |       |
 |       |       |     <sip:proxyP1>;index=1,                |       |
 |       |       |     <sip:userB>;index=1.1;rc=1,           |       |
 |       |       |     <sip:proxyP2;cause=302>;index=1.1.1;mp=1.1    |
 |       |       |       |      |       |       |     |      |       |
 |       |       |       |      |       |       |     |      | INV E |
 |       |       |       |      |       |       |     |      |------>|
 |       |   History-Info:      |       |       |     |      |       |
 |       |   <sip:proxyP1>;index=1,     |       |     |      |       |
 |       |   <sip:userB>;index=1.1;rc=1,        |     |      |       |
 |       |   <sip:proxyP2;cause=302>;index=1.1.1;mp=1.1,     |       |
 |       |   <sip:userC ?Privacy=history>;index=1.1.1.0.1,   |       |
 |<sip:userD;cause=408?Privacy=none>;index=1.1.1.0.1.1;mp=1.1.1.0.1, |
 |       |<sip:userE;cause=404>;index=1.1.1.0.1.1.1;mp=1.1.1.0.1.1   |
 |       |       |       |      |       |       |     |       |      |
 |       |       |       |      |       |       |     |       |      |
 Note: The IWF is an interworking function that could be a stand-alone
 equipment not defined in this document (it could be a proxy).

7.4. Additional Interworking Cases

 Even for particular cases in which both header fields could coexist,
 it should be the responsibility of the network local policy to make
 it work together.  This section describes some situations and some
 recommendations on behavior.
 In the case where there is one network that includes different nodes,
 some of them supporting the Diversion header field and other ones
 supporting the History-Info header field, there is a problem when any
 node handling a message does not know the next node that will handle
 the message.  This case can occur when the network has new and old
 nodes, the older ones using the Diversion header field and the most
 recent using the History-Info header field.
 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

Mohali Informational [Page 24] RFC 7544 Mapping of Diversion and History-Info August 2015

 node capabilities, then the problem is more important.  In this case,
 there is a need to pass both the History-Info header field and the
 Diversion header field within the core network.
 These header fields need to be equivalent to ensure that, whatever
 the node receiving the message, the correct diversion information is
 received.  This requires that, whatever the received header field,
 there is a requirement to be able to compare the header fields and to
 convert the header fields.  Depending upon the node capability, it
 may be possible to make assumptions as to how this is handled.
 o  If it is known that the older Diversion header field supporting
    nodes does not pass on any received History-Info header field,
    then the interworking becomes easier.  If a message is received
    with only Diversion header fields, 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 field.
 o  If the node creates a new History-Info header field for a call
    diversion, then an additional Diversion header field must be
    created.
 o  If the next node is an old node, then the Diversion header field
    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 the
    Diversion header field and History-Info header field means that
    interworking has already occurred and the Diversion and History-
    Info entries must be considered equivalent.
 o  If both nodes pass on both the History-Info header field and
    Diversion header field but only actively use one, then both types
    of nodes need to perform the interworking and must maintain
    equivalence between the header fields.  This will eventually
    result in the use of the Diversion header field being deprecated
    when all nodes in the network support the History-Info header
    field.
 o  If a gap is identified in the History-Info header field by a node
    that would create a new entry, it shall add a single index with a
    value of "0" prior to adding the appropriate index for the action
    to be taken.

Mohali Informational [Page 25] RFC 7544 Mapping of Diversion and History-Info August 2015

8. Backward Compatibility

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

9. Security Considerations

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

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,
            DOI 10.17487/RFC3261, June 2002,
            <http://www.rfc-editor.org/info/rfc3261>.
 [RFC3323]  Peterson, J., "A Privacy Mechanism for the Session
            Initiation Protocol (SIP)", RFC 3323,
            DOI 10.17487/RFC3323, November 2002,
            <http://www.rfc-editor.org/info/rfc3323>.
 [RFC3326]  Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason
            Header Field for the Session Initiation Protocol (SIP)",
            RFC 3326, DOI 10.17487/RFC3326, December 2002,
            <http://www.rfc-editor.org/info/rfc3326>.

Mohali Informational [Page 26] RFC 7544 Mapping of Diversion and History-Info August 2015

 [RFC3966]  Schulzrinne, H., "The tel URI for Telephone Numbers",
            RFC 3966, DOI 10.17487/RFC3966, December 2004,
            <http://www.rfc-editor.org/info/rfc3966>.
 [RFC4244]  Barnes, M., Ed., "An Extension to the Session Initiation
            Protocol (SIP) for Request History Information", RFC 4244,
            DOI 10.17487/RFC4244, November 2005,
            <http://www.rfc-editor.org/info/rfc4244>.
 [RFC5806]  Levy, S. and M. Mohali, Ed., "Diversion Indication in
            SIP", RFC 5806, DOI 10.17487/RFC5806, March 2010,
            <http://www.rfc-editor.org/info/rfc5806>.
 [RFC7044]  Barnes, M., Audet, F., Schubert, S., van Elburg, J., and
            C. Holmberg, "An Extension to the Session Initiation
            Protocol (SIP) for Request History Information", RFC 7044,
            DOI 10.17487/RFC7044, February 2014,
            <http://www.rfc-editor.org/info/rfc7044>.

10.2. Informative References

 [Err1409]  RFC Errata, Erratum ID 1409, RFC 4458.
 [RFC4458]  Jennings, C., Audet, F., and J. Elwell, "Session
            Initiation Protocol (SIP) URIs for Applications such as
            Voicemail and Interactive Voice Response (IVR)", RFC 4458,
            DOI 10.17487/RFC4458, April 2006,
            <http://www.rfc-editor.org/info/rfc4458>.
 [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
            Specifications: ABNF", STD 68, RFC 5234,
            DOI 10.17487/RFC5234, January 2008,
            <http://www.rfc-editor.org/info/rfc5234>.
 [RFC6044]  Mohali, M., "Mapping and Interworking of Diversion
            Information between Diversion and History-Info Headers in
            the Session Initiation Protocol (SIP)", RFC 6044,
            DOI 10.17487/RFC6044, October 2010,
            <http://www.rfc-editor.org/info/rfc6044>.
 [TS_24.604]
            3rd Generation Partnership Project, "Communication
            Diversion (CDIV) using IP Multimedia (IM) Core Network
            (CN) subsystem; Protocol specification", Release 13.1,
            3GPP TS 24.604, June 2015.

Mohali Informational [Page 27] RFC 7544 Mapping of Diversion and History-Info August 2015

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

Mohali Informational [Page 28] RFC 7544 Mapping of Diversion and History-Info August 2015

Appendix A. Interworking between Diversion Header Field and Voicemail

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

A.1. Diversion Header Field to Voicemail URI

 Received:
 Diversion: userA-address;reason=user-busy;counter=1;privacy=full
 Sent (Voicemail URI created in the R-URI line of the INVITE):
 sip: voicemail@example.com;target=userA-address;cause=486 SIP/2.0
 Mapping of the Redirection Reason is the same as for History-Info
 header field with a default value set to 404.
 If the Diversion header field contains more than one Diversion entry,
 the choice of the redirecting user information inserted in the URI is
 in charge of the network local policy.  For example, the choice
 criterion of the redirecting information inserted in the URI could be
 the destination of forwarded INVITE request (whether or note the
 voicemail serves this user).
 Note: This interworking could be done in addition to the interworking
 of the Diversion header field into the History-Info header field.

A.2. Voicemail URI to Diversion Header Field

 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 follows:
 Received:
 INVITE sip: voicemail@example.com;\
 target=sip:+33145454500%40example.com;user=phone;\
 cause=302 SIP/2.0
 Sent in the forwarded INVITE:
 Diversion: sip:+33145454500%40example.com;user=phone;
 reason=unconditional;counter=1

Mohali Informational [Page 29] RFC 7544 Mapping of Diversion and History-Info August 2015

Acknowledgements

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

Author's Address

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

Mohali Informational [Page 30]

/data/webs/external/dokuwiki/data/pages/rfc/rfc7544.txt · Last modified: 2015/08/07 18:12 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki