Network Working GroupIndependent Submission M. MohaliInternet-DraftRequest for Comments: 6044 France Telecom OrangeIntended status:Category: InformationalJuly 02,October 2010Expires: January 3, 2011ISSN: 2070-1721 Mapping andinterworkingInterworking of Diversioninformation BetweenInformation between Diversion and History-Info Headers in the Session Initiation Protocol (SIP)draft-mohali-diversion-history-info-07Abstract Although the SIP History-Info header is the solution adopted in IETF, the non-standard Diversion header is nevertheless widely implemented and used for conveyingcall diversion relatedcall-diversion-related information inthe Session Initiation Protocol (SIP)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 theheadersheaders' coexistence. The History-Info header is described in [RFC4244] and the non-standard Diversion header is described, as Historic, inthe[RFC5806]. 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 ofthisThis Memo ThisInternet-Draftdocument issubmitted in full conformance withnot an Internet Standards Track specification; it is published for informational purposes. This is a contribution to theprovisionsRFC Series, independently ofBCP 78any other RFC stream. The RFC Editor has chosen to publish this document at its discretion andBCP 79. Internet-Draftsmakes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor areworking documentsnot a candidate for any level oftheInternetEngineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The listStandard; see Section 2 of RFC 5741. Information about the currentInternet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximumstatus ofsix monthsthis document, any errata, and how to provide feedback on it may beupdated, replaced, or obsoleted by other documentsobtained atany time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 3, 2011.http://www.rfc-editor.org/info/rfc6044. 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....................................................3 1.1. Overview. . . . . . . . . . . . . . . . . . . . . . . . . 3...................................................3 1.2. Background. . . . . . . . . . . . . . . . . . . . . . . . 3.................................................3 2. Problem Statement. . . . . . . . . . . . . . . . . . . . . . 4...............................................4 2.1. InterworkingrequirementsRequirements andscope . . . . . . . . . . . 4Scope ........................4 2.2. Interworkingrecommendations . . . . . . . . . . . . . . . 5Recommendations ...............................6 2.2.1. SIPnetwork/terminal usingNetwork/Terminal Using Diversion to SIPnetwork/terminal usingNetwork/Terminal Using History-Infoheader . . . . . . 6Header ..........6 2.2.2. SIPnetwork/terminal usingNetwork/Terminal Using History-InfoheaderHeader to SIPnetwork/terminal usingNetwork/terminal Using Diversionheader . . . . . 8Header ..............................................8 3. Headerssyntaxes reminder . . . . . . . . . . . . . . . . . . 9Syntaxes Reminder .......................................9 3.1. History-Infoheader syntax . . . . . . . . . . . . . . . . 9Header Syntax .................................9 3.2. Diversionheader syntax . . . . . . . . . . . . . . . . . 11Header Syntax ...................................11 4. Headers in SIP Method. . . . . . . . . . . . . . . . . . . . 12..........................................11 5. DiversionheaderHeader to History-Infoheader . . . . . . . . . . . 12Header ........................12 6. History-InfoheaderHeader to Diversionheader . . . . . . . . . . . 15Header ........................15 7. Examples. . . . . . . . . . . . . . . . . . . . . . . . . . . 17.......................................................17 7.1. Example with Diversionheader changedHeader Changed into History-Infoheader . . . . . . . . . . . . . . . . . . . 17Header .......................................17 7.2. Example with History-Infoheader changedHeader Changed into Diversionheader . . . . . . . . . . . . . . . . . . . . . 17Header ..........................................17 7.3. Example withtwoTwo SIPnetworks usingNetworks Using History-Infoheader interworking with a SIP network using Diversion header . . . . . . . . . . . . . . . . . . . . . . . . . . 17Header ...17 7.4. AdditionalinterworkingInterworking Cases. . . . . . . . . . . . . . 19.............................19 8.IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 9.Security Considerations. . . . . . . . . . . . . . . . . . . 20........................................20 9. Acknowledgements ...............................................21 10.Acknowlegements . . . . . . . . . . . . . . . . . . . . . . . 21 11.References. . . . . . . . . . . . . . . . . . . . . . . . . . 21 11.1.....................................................21 10.1. Normative References. . . . . . . . . . . . . . . . . . . 21 11.2......................................21 10.2. Informative References. . . . . . . . . . . . . . . . . . 21...................................21 Appendix A. Interworking between DiversionheaderHeader and Voicemail URI. . . . . . . . . . . . . . . . . . . . 22 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23........................................23 1. Introduction 1.1. Overview For some VoIP-based (Voice over IP) services(eg. Voicemail,(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 usedinby 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][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 forheader contentheader-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"3GPPThird Generation Partnership Project (3GPP) specification [TS_24.604]. Originally, the Diversion header was described inan Internet Drafta 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. Mostofexisting SIP-based implementations have implemented the Diversion header when no standard solution was ready to deploy. The IETF has finally standardized the History-Infoheaderheader, 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 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 differentsyntaxessyntaxes, 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.(i.e., the first diversion entry read corresponds to the last diverting user).TheAppendix A provides an interworking guideline between the Diversion header and the VoicemailURIURI, which is another way to convey diversion information. The Voicemail URI is defined in [RFC4458]. 2. Problem Statement 2.1. InterworkingrequirementsRequirements andscopeScope 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.TheyThere are many ways in which SIP signaling can be used to modify a session destination before it isestablishedestablished, 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/redirectingreferrefers 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 theISDNIntegrated Services Digital Network (ISDN) Communication diversion supplementary services and defined in 3GPP [TS_24.604]. They are applicable to entitieswhichthat 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 forwardinginformationinformation, 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 conveycall diversion relatedcall-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 forwardinginformation,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 bemixed-upmixed 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. 2.2. InterworkingrecommendationsRecommendations 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 devicewhichthat 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 avoidheaders coexistenceheader 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,History- Infothe 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 headeravoidingto 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 beperformedperformed, 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. SIPnetwork/terminal usingNetwork/Terminal Using Diversion to SIPnetwork/terminal usingNetwork/Terminal Using History-InfoheaderHeader 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. 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 usesHistory- InfoHistory-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 tocreatecreate, 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(ie.IWF)(i.e., IWF) to remove the Diversion header when the message is going to a network not using the Diversion header.ThenThen, network_3 could use call forwarding information that is present in a single header and add its own diversion information if necessary. Notes: 1. If a network is not able either to use only one header eachtime,time or to maintain both headers up to date, the chronological ordercan notcannot 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. SIPnetwork/terminal usingNetwork/Terminal Using History-InfoheaderHeader to SIPnetwork/ terminal usingNetwork/Terminal Using DiversionheaderHeader 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, forexampleexample, by a servicewhich needthat needs to know if a specificASApplication 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 bettertonot to lose history information due to passing though the networkwhichthat onlysupportsupports Diversionheader.headers. A recommended solution must not disrupt the standard behavior and networkswhichthat 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 Diversionheaderheader, as recommended inthe[RFC5806]. Note that the chronological order could not be certified. If previous policy recommendations are respected, this case should not happen. Forking case: The History-Info header enables the recording of sequential forking for the sameserved-user.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. Headerssyntaxes reminderSyntaxes Reminder 3.1. History-Infoheader syntaxHeader 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 ahi-entryhi- 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. 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.The[RFC4458] also defines the 'target' URIparameterparameter, 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 theR-URIR-URI, but this possibility is based on local policies not described in this document. A Privacyheaderheader, as defined in[RFC3323][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 bydotsdots, to indicate the number of forward hops and retargets. Note: A history entry could contain the "gr" parameter. Regardless of the rules concerning the "gr" parameter defined in[TS_24.604][TS_24.604], which must be applied, this parameter has no impact on the mapping and must only be copied with the served user address. 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 ofHistory-Info or not.History-Info. 3.2. Diversionheader syntaxHeader 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-separatedformatformat, as describedbelowbelow, 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. 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 nextINVITE or not.INVITE. Other messages where History-Info could be present are not used for theCall Forwardingcall forwarding service and should not be changed into Diversion header. The destination network must be transparent to the received History-Info header.Note :Note: the following mapping is inspired from theISUPISDN User Part (ISUP) to the SIP interworking described in [TS_29.163]. 5. DiversionheaderHeader to History-InfoheaderHeader 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 Diversionentriesentries, 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: - ahi-target-to-urihi-targeted-to-uri with the name-addr parameter of the bottom- most Diversionheaderheader. - 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 describedbelow,below. - an index set to 1. For each following Diversion entry (from bottom to top), the History- info entries are created as following (from top to bottom): Source Destination Diversion header component: History-Info header component: =======================================================================Name-addr Hi-target-to-uriname-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) ======================================================================= CounterHi-indexhi-index "1" or parameter -------------------------The previous created indexnonot present is incremented with ".1" Superior to "1" --------------------------Create N-1 placeholder History(i.e.(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: - ahi-target-to-urihi-targeted-to-uri with the Request-URI of the INVITE request. - a cause-param from the top-most Diversion entry, mapped from the diversion-reason as described above. - 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 describedabove,above. - 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 valueswhichthat 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 in3GPP[TS_24.604]3GPP [TS_24.604] as itcovercovers a large portion of cases. 3. The Diversion header could contain a Tel:URI in the name-addrparameterparameter, 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: andtel: URIsTel:URIs, but in this particularcasecase, 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"entryentry, theHistory-infoHistory-Info header entries could reflect the real number of diversion occurred. Example of placeholder entry in the History-Info header: <sip:unknown@unknown.invalid;cause=xxx>;index=1.1 <sip:bob_addr;cause=404>;index=1.1.1 "cause=xxx" reflects the diverting reason of a previous diverting user. For a placeholderhi-entryhi-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-InfoheaderHeader to DiversionheaderHeader 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-Infoentryentry, with a cause-param reflecting a diverting reason as listed in the [RFC4458]. In this case, the History-Info header must be mapped into the Diversion header as following: Source Destination History-Info header component: Diversion header component: =====================================================================Hi-target-to-urihi-targeted-to-uri of theName-addrname-addr History-Infowhichthat precedes the one containing a divertingcause-paramcause-param. =====================================================================Cause-paramcause-param Reason 404---------------------------------------"unknown" (default value) 302---------------------------------------"unconditional" 486---------------------------------------"user-busy" 408---------------------------------------"no-answer" 480 or 487--------------------------------"deflection " 503---------------------------------------"unavailable" =====================================================================Hi-indexhi-index Counter Mandatory parameter for--------------------The counter is set to "1". History-Info reflecting the chronological order of the information. ===================================================================== Privacy header[RFC3323]escaped[RFC3323] escaped in the Privacy hi-targeted-to-uri of theHistory-InfoHistory-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. 7. Examples 7.1. Example with Diversionheader changedHeader Changed into History-InfoheaderHeader 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-Infoheader changedHeader Changed into DiversionheaderHeader 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 withtwoTwo SIPnetworks usingNetworks Using History-Infoheader interworkingHeader Interworking with a SIPnetwork usingNetwork Using DiversionheaderHeader 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. 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 --->| | | | | |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 functionwhichthat could be a stand- alone equipment not defined in this document (it could be a proxy). 7.4. AdditionalinterworkingInterworking 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 networkwhichthat includes different nodes, some of them supporting the Diversion header and other ones supportingHistory-infothe 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. While a network replacement may beoccurringoccurring, 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 thiscasecase, 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-Infoheaderheader, then the interworking becomes easier. If a message is received with only Diversionheadersheaders, 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'nodenode, 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 Diversionheaderheader, but only actively use one, then both types ofnodenodes need to perform the interworking and must maintain equivalence between the headers. This will eventually result in the use of Diversion header being deprecated when all nodes in the network support History-Info header. 8.IANA Considerations This document makes no request of IANA. 9.Security Considerations The security considerations in [RFC4244] and [RFC5806] apply. The use of the Diversion header or the History-Info header requireto applythe 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 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.UnauthorisedUnauthorized insertion, deletion of modification of thoseheadersheaders, 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.10. Acknowlegements9. 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, BobBradenBraden, and Robert Sparks. Merci a Lionel Morand, XavierMarjouMarjou, and Philippe Fouquart.11.10. References11.1.10.1. Normative References [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, 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.11.2.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. [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. Appendix A. Interworking between DiversionheaderHeader and Voicemail URI Voicemail URI is a mechanism described inRFC4458RFC 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(if(whether or not the voicemail serves thisuser or not).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 realVoicemail,voicemail, this way of interworking should not happen. However, if for any reason it occurs, it is recommended to do it as following: Received: INVITE sip: voicemail@example.com;\ target=sip:+33145454500%40example.com;user=phone;\ cause=302 SIP/2.0 Sent in the forwarded INVITE: Diversion: sip:+ 33145454500%40example.com;user=phone;reason=unconditional;counter=1 Author's Address Marianne Mohali France Telecom Orange 38-40 rue du General Leclerc Issy-Les-Moulineaux Cedex 9 92794 France Phone: +33 1 45 29 45 14Email:EMail: marianne.mohali@orange-ftgroup.com