From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc6044.txt | 1347 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1347 insertions(+) create mode 100644 doc/rfc/rfc6044.txt (limited to 'doc/rfc/rfc6044.txt') diff --git a/doc/rfc/rfc6044.txt b/doc/rfc/rfc6044.txt new file mode 100644 index 0000000..ff5dfcb --- /dev/null +++ b/doc/rfc/rfc6044.txt @@ -0,0 +1,1347 @@ + + + + + + +Independent Submission M. Mohali +Request for Comments: 6044 France Telecom Orange +Category: Informational October 2010 +ISSN: 2070-1721 + + +Mapping and Interworking of Diversion Information between Diversion and + History-Info Headers in the Session Initiation Protocol (SIP) + +Abstract + + Although the SIP History-Info header is the solution adopted in IETF, + the non-standard Diversion header is nevertheless widely implemented + and used for conveying call-diversion-related information in SIP + signaling. + + This document describes a recommended interworking guideline between + the Diversion header and the History-Info header to handle call + diversion information. In addition, an interworking policy is + proposed to manage the headers' coexistence. The History-Info header + is described in RFC 4244 and the non-standard Diversion header is + described, as Historic, in RFC 5806. + + Since the Diversion header is used in many existing network + implementations for the transport of call diversion information, its + interworking with the SIP History-Info standardized solution is + needed. This work is intended to enable the migration from non- + standard implementations and deployment toward IETF specification- + based implementations and deployment. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This is a contribution to the RFC Series, independently of any other + RFC stream. The RFC Editor has chosen to publish this document at + its discretion and makes no statement about its value for + implementation or deployment. Documents approved for publication by + the RFC Editor are not a candidate for any level of Internet + Standard; see Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6044. + + + + + + +Mohali Informational [Page 1] + +RFC 6044 Mapping Diversion and History-Info October 2010 + + +Copyright Notice + + Copyright (c) 2010 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. + +Table of Contents + + 1. Introduction ....................................................3 + 1.1. Overview ...................................................3 + 1.2. Background .................................................3 + 2. Problem Statement ...............................................4 + 2.1. Interworking Requirements and Scope ........................4 + 2.2. Interworking Recommendations ...............................6 + 2.2.1. SIP Network/Terminal Using Diversion to SIP + Network/Terminal Using History-Info Header ..........6 + 2.2.2. SIP Network/Terminal Using History-Info + Header to SIP Network/terminal Using Diversion + Header ..............................................8 + 3. Headers Syntaxes Reminder .......................................9 + 3.1. History-Info Header Syntax .................................9 + 3.2. Diversion Header Syntax ...................................11 + 4. Headers in SIP Method ..........................................11 + 5. Diversion Header to History-Info Header ........................12 + 6. History-Info Header to Diversion Header ........................15 + 7. Examples .......................................................17 + 7.1. Example with Diversion Header Changed into + History-Info Header .......................................17 + 7.2. Example with History-Info Header Changed into + Diversion Header ..........................................17 + 7.3. Example with Two SIP Networks Using History-Info Header ...17 + 7.4. Additional Interworking Cases .............................19 + 8. Security Considerations ........................................20 + 9. Acknowledgements ...............................................21 + 10. References ....................................................21 + 10.1. Normative References .....................................21 + 10.2. Informative References ...................................21 + Appendix A. Interworking between Diversion Header and + Voicemail URI ........................................23 + + + + + + +Mohali Informational [Page 2] + +RFC 6044 Mapping Diversion and History-Info October 2010 + + +1. Introduction + +1.1. Overview + + For some VoIP-based (Voice over IP) services (e.g., voicemail, + Interactive Voice Recognition (IVR) or automatic call distribution), + it is helpful for the called SIP user agent to identify from whom and + why the session was diverted. For this information to be used by + various service providers or by applications, it needs to pass + through the network. This is possible with two different SIP + headers: the History-Info header defined in [RFC4244] and the + historic Diversion header defined in [RFC5806], which are both able + to transport diversion information in SIP signaling. + + Although the Diversion header is not standardized, it is widely used. + Therefore, it is useful to have guidelines to make this header + interwork with the standard History-Info header. + + Note that the new implementation and deployment of the Diversion + header is strongly discouraged. + + This document provides a mechanism for header-content translation + between the Diversion header and the History-Info header. + +1.2. Background + + The History-Info header [RFC4244] and its extension for forming SIP + service URIs (including Voicemail URI) [RFC4458] are recommended by + the IETF to convey redirection information. They are also + recommended in the "Communication Diversion (CDIV) service" Third + Generation Partnership Project (3GPP) specification [TS_24.604]. + + Originally, the Diversion header was described in a document that was + submitted to the SIP Working Group. It has been published now as + [RFC5806] for the historical record and to provide a reference for + this RFC. + + This header contains a list of diverting URIs and associated + information providing specific information as the reason for the call + diversion. Most existing SIP-based implementations have implemented + the Diversion header when no standard solution was ready to deploy. + The IETF has finally standardized the History-Info header, partly + because it can transport general history information. This allows + the receiving part to determine how and why the session is received. + As the History-Info header may contain further information than call + diversion information, it is critical to avoid losing information and + + + + + +Mohali Informational [Page 3] + +RFC 6044 Mapping Diversion and History-Info October 2010 + + + be able to extract the relevant data using the retargeting cause URI + parameter described in [RFC4458] for the transport of the diversion + reason. + + The Diversion header and the History-Info header have different + syntaxes, described below. Note that the main difference is that the + History-Info header is a chronological writing header whereas the + Diversion header applies a reverse chronology (i.e., the first + diversion entry read corresponds to the last diverting user). + + Appendix A provides an interworking guideline between the Diversion + header and the Voicemail URI, which is another way to convey + diversion information. The Voicemail URI is defined in [RFC4458]. + +2. Problem Statement + +2.1. Interworking Requirements and Scope + + This section provides the baseline terminology used in the rest of + the document and defines the scope of interworking between the + Diversion header and the History-Info header. + + There are many ways in which SIP signaling can be used to modify a + session destination before it is established, and there are many + reasons for doing so. The behavior of the SIP entities that will + have to further process the session downstream will sometimes vary + depending on the reasons that lead to changing the destination. For + example, whether it is for a simple proxy to route the session or for + an application server to provide a supplementary service. The + Diversion header and the History-Info header differ in the approach + and scope of addressing this problem. + + For clarity, the following vocabulary is used in this document: + + o Retargeting/redirecting: retargeting/redirecting refers to the + process of a Proxy Server/User Agent Client (UAC) changing a + Uniform Resource Identifier (URI) in a request and thus changing + the target of the request. These terms are defined in [RFC4244]. + The History-Info header is used to capture retargeting + information. + + o Call forwarding/call diversion/communication diversion: these + terms are equivalent and refer to the Communications Diversion + (CDIV) supplementary services, based on the Integrated Services + Digital Network (ISDN) Communication diversion supplementary + + + + + + +Mohali Informational [Page 4] + +RFC 6044 Mapping Diversion and History-Info October 2010 + + + services and defined in 3GPP [TS_24.604]. They are applicable to + entities that are intended to modify the original destination of + an IP multimedia session during or prior to the session + establishment. + + This document does not intend to describe when or how History-Info or + Diversion headers should be used. Hereafter is provided + clarification on the context in which the interworking is required. + + The Diversion header has exactly the same scope as the call diversion + service and each header entry reflects a call diversion invocation. + The Diversion header is used for recording call forwarding + information, which could be useful to network entities downstream. + Today, this SIP header is implemented by several manufacturers and + deployed in networks. + + The History-Info header is used to store all retargeting information + including call diversion information. In practice, the History-Info + header [RFC4244] is used to convey call-diversion-related information + by using a cause URI parameter [RFC4458] in the relevant entry. + Note, however, that the use of cause URI parameter [RFC4458] in a + History-Info entry for a call diversion is specific to the 3GPP + specification [TS_24.604]. [RFC4458] focuses on retargeting toward a + voicemail server and does not specify whether the cause URI parameter + should be added in a URI for other cases. As a consequence, + implementations that do not use the cause URI parameter for call + forwarding information are not considered for the mapping described + in this document. Nevertheless, some recommendations are given in + the next sections on how to avoid the loss of non-mapped information + at the boundary between a network region using History-Info header + and one using the Diversion header. + + Since both headers address call forwarding needs, diverting + information could be mixed up or be inconsistent if both are present + in an uncoordinated fashion in the INVITE request. So, Diversion and + History-Info headers must not independently coexist in the same + session signaling. This document addresses how to convert + information between the Diversion header and the History-Info header, + and when and how to preserve both headers to cover additional cases. + + For the transportation of consistent diversion information + downstream, it is necessary to make the two headers interwork. + Interworking between the Diversion header and the History-Info header + is introduced in sections 5 and 6. Since the coexistence scenario + may vary from one use case to another one, guidelines regarding + headers interaction are proposed. + + + + + +Mohali Informational [Page 5] + +RFC 6044 Mapping Diversion and History-Info October 2010 + + +2.2. Interworking Recommendations + + Interworking function: + + In a normal case, the network topology assumption is that the + interworking described in this document should be performed by a + specific SIP border device that is aware, by configuration, that + it is at the border between two regions, one using History-Info + header and one using Diversion header. + + As History-Info header is a standard solution, a network using the + Diversion header must be able to provide information to a network + using the History-Info header. In this case, to avoid header + coexistence, it is required to replace, as often as possible, the + Diversion header with the History-Info header in the INVITE request + during the interworking. + + Since, the History-Info header has a wider scope than the Diversion + header, it may be used for other needs and services than call + diversion. In addition to trace call diversion information, the + History-Info header also acts as a session history and can store all + successive R-URI values. Consequently, even if it should be better + to remove the History-Info header after the creation of the Diversion + header to avoid confusion, the History-Info header must remain + unmodified in the SIP signaling if it contains supplementary (non- + diversion) information. It is possible to have History-Info headers + that do not have values that can be mapped into the Diversion header. + In this case, no interworking with Diversion header should be + performed, and it must be defined per implementation what to do in + this case. This point is left out of the scope of this document. + + As a conclusion, it is recommended to have local policies minimizing + the loss of information and find the best way to keep it up to the + terminating user agent. + + The following sections describe the basic common use case. + Additional interworking cases are described in section 7.5. + +2.2.1. SIP Network/Terminal Using Diversion to SIP Network/Terminal + Using History-Info Header + + When the Diversion header is used to create a History-Info header, + the Diversion header must be removed in the outgoing INVITE. It is + considered that all of the information present in the Diversion + header is transferred in the History-Info header. + + + + + + +Mohali Informational [Page 6] + +RFC 6044 Mapping Diversion and History-Info October 2010 + + + If a History-Info header is present in the incoming INVITE (in + addition to Diversion header), the Diversion header and History-Info + header present must be mixed and only the diversion information not + yet present in the History-Info header must be inserted as a last + entry (more recent) in the existing History-Info header, as + recommended in [RFC4244]. + + As an example, this could be the case of an INVITE coming from + network_2 using the Diversion header but previously passed through + network_1 using the History-Info header (or the network_2 uses + History-Info header to transport successive URI information) and + going to network_3 using the History-Info header. + + IWF* IWF* + network1 | network_2 |network_3 + History-Info | Diversion |using + | |Hist-Info + | | +UA A P1 AS B | P2 AS C UA C AS D | UA E +| | | | | | | | | | +|INVITE | | | | | | | | | +|------>| | | | | | | | | +| | | | | | | | | | +| |INVITE | | | | | | | | +| |------>| | | | | | | | +| |Supported: histinfo | | | | | | +| | History-Info: | | | | | | +| | ; index=1, | | | | | +| | ; index=1.1 | | | | | +| | | | | | | | | | +| | |INVITE | | | | | | | +| | |------>| | | | | | | +| | |History-Info: | | | | | | +| | |; index=1,| | | | | +| | |; index=1.1 | | | | | +| | |; cause=302; index=1.1.1 | | | + + In this case, the incoming INVITE contains a Diversion header and a + History-Info header. Therefore, as recommended in this document, it + is necessary to create, for network_3, a single History-Info header + gathering existing information from both the History-Info and the + Diversion headers received. Anyway, it is required from network_2 + (i.e., IWF) to remove the Diversion header when the message is going + to a network not using the Diversion header. Then, network_3 could + use call forwarding information that is present in a single header + and add its own diversion information if necessary. + + + + + +Mohali Informational [Page 7] + +RFC 6044 Mapping Diversion and History-Info October 2010 + + + Notes: + + 1. If a network is not able either to use only one header each time + or to maintain both headers up to date, the chronological order + cannot be certified. + + 2. It is not possible to have only a Diversion header when the + History-Info header contains more than call diversion information. + If previous policy recommendations are applied, the chronological + order is respected as Diversion entries are inserted at the end of + the History-Info header taking into account the Diversion internal + chronology. + +2.2.2. SIP Network/Terminal Using History-Info Header to SIP + Network/Terminal Using Diversion Header + + When the History-Info header is interpreted to create a Diversion + header, some precautions must be taken. + + If the History-Info header contains only call forwarding information, + then it must be deleted after the interworking. + + If the History-Info header contains other information, then only the + information of concern to the diverting user must be used to create + entries in the Diversion header and the History-Info header must be + kept as received in the INVITE and forwarded downstream. + + Note: The History-Info header could be used for other reasons than + call diversion services, for example, by a service that needs to know + if a specific Application Server (AS) had yet been invoked in the + signaling path. If the call is later forwarded to a network using + the History-Info header, it would be better not to lose history + information due to passing though the network that only supports + Diversion headers. A recommended solution must not disrupt the + standard behavior and networks that do not implement the History-Info + header must be transparent to a received History-Info header. + + If a Diversion header is present in the incoming INVITE (in addition + to History-Info header), only diversion information present in the + History-Info header but not in the Diversion header must be inserted + from the last entry (more recent) into the existing Diversion header, + as recommended in [RFC5806]. + + Note that the chronological order could not be certified. If + previous policy recommendations are respected, this case should not + happen. + + + + + +Mohali Informational [Page 8] + +RFC 6044 Mapping Diversion and History-Info October 2010 + + + Forking case: + + The History-Info header enables the recording of sequential + forking for the same served user. During an interworking, from + the History-Info header to Diversion header, the History-Info + entries containing a forking situation (with an incremented + "index" parameter) could possibly be mapped if it contains a call + forwarding "cause" parameter. The interworking entity could + choose to create only a Diversion entry or not apply the + interworking. The choice could be done according a local policy. + + The same logic is applied for an interworking with Voicemail URI (see + the Appendix). + +3. Headers Syntaxes Reminder + +3.1. History-Info Header Syntax + + History-Info = "History-Info" HCOLON hi-entry *(COMMA hi-entry) + + hi-entry = hi-targeted-to-uri *( SEMI hi-param ) + hi-targeted-to-uri = name-addr + hi-param = hi-index / hi-extension + hi-index = "index" EQUAL 1*DIGIT *(DOT 1*DIGIT) + hi-extension = generic-param + + The History-Info header is specified in [RFC4244]. The top-most + History-Info entry (first in the list) corresponds to the oldest + history information. + + A hi-entry may contain a cause URI parameter expressing the diversion + reason. This optional cause URI parameter is defined in [RFC4458] + with the following syntax: + + cause-param = "cause" EQUAL Status-Code + + This parameter is also named cause-param and should be inserted in + the History-Info entry (URI) of the diverted-to user in case of call + diversion as recommended in the 3GPP CDIV specification [TS_24.604]. + The cause values used in the cause-param for the diverting reason are + listed in the RFC 4458, and because it is a parameter dedicated to + call forwarding service, its presence is used to determine that a hi- + entry is a diverting user. More precisely, each diverting user is + located in the hi-entry before the one containing a cause-param with + a cause value as listed in RFC 4458. + + + + + + +Mohali Informational [Page 9] + +RFC 6044 Mapping Diversion and History-Info October 2010 + + + Moreover, the Reason header defined in [RFC3326] should be escaped in + the hi-entry of the diverting user when the call diversion is due to + a received SIP response. The Reason header contains a cause + parameter set to the true SIP response code received (Status-Code). + Therefore, in case of call diversion due to a SIP response, both + cause parameters should be used. The complexity is that these + parameters could be used at the same time in the History-Info header + but not in the same hi-entry and not with the same meaning. Only the + cause-param is dedicated to call diversion service. The 'cause' + Reason header parameter is not taken into account in the mapping with + a Diversion header. + + [RFC4458] also defines the 'target' URI parameter, which could be + inserted in a R-URI and consequently in the hi-targeted-to-uri. This + parameter is used to keep the diverting user address in the + downstream INVITE request in Voicemail URI implementation. As this + information is already present in the hi-entries, the 'target' URI + parameter is not taken into account regarding the interworking with + the Diversion header. From the Diversion header, it could be + possible to create the 'target' URI parameter in the hi-entries + and/or in the R-URI, but this possibility is based on local policies + not described in this document. + + A Privacy header, as defined in [RFC3323], could also be included in + hi-entries with the 'history' value defined in the [RFC4244]. + + The index parameter is a string of digits, separated by dots, to + indicate the number of forward hops and retargets. + + Note: A history entry could contain the "gr" parameter. Regardless + of the rules concerning the "gr" parameter defined in [TS_24.604], + which must be applied, this parameter has no impact on the mapping + and must only be copied with the served user address. + + Example: + + History-Info: + ;index=1, + ;index=1.1, + ; index=1.1.1 + + Policy concerning "histinfo" option tag in Supported header: + According to [RFC4244], a proxy that receives a Request with the + "histinfo" option tag in the Supported header should return captured + History-Info in subsequent, provisional and final responses to the + Request. The behavior depends upon whether or not the local policy + supports the capture of History-Info. + + + +Mohali Informational [Page 10] + +RFC 6044 Mapping Diversion and History-Info October 2010 + + +3.2. Diversion Header Syntax + + The following text is restating the exact syntax that the production + rules in [RFC5806] define, but using [RFC5234] ABNF: + + Diversion = "Diversion" HCOLON diversion-params + *(COMMA diversion-params) + + diversion-params = name-addr *(SEMI (diversion-reason / + diversion-counter / diversion-limit / + diversion-privacy / diversion-screen / + diversion-extension)) + diversion-reason = "reason" EQUAL ("unknown" / "user-busy" / + "no-answer" / "unavailable" / "unconditional" + / "time-of-day" / "do-not-disturb" / + "deflection" / "follow-me" / "out-of-service" + / "away" / token / quoted-string) + diversion-counter = "counter" EQUAL 1*2DIGIT + diversion-limit = "limit" EQUAL 1*2DIGIT + diversion-privacy = "privacy" EQUAL ("full" / "name" / "uri" / + "off" / token / quoted-string) + diversion-screen = "screen" EQUAL ("yes" / "no" / token / + quoted-string) + diversion-extension = token [EQUAL (token / quoted-string)] + + Note: The Diversion header could be used in the comma-separated + format, as described below, and in a header-separated format. Both + formats could be combined a received INVITE as recommended in + [RFC3261]. + + Example: + + Diversion: + + diverting_user2_addr; reason="user-busy"; counter=1; privacy=full, + diverting_user1_addr; reason="unconditional"; counter=1; privacy=off + +4. Headers in SIP Method + + The recommended interworking presented in this document should apply + only for INVITE requests. + + In 3xx responses, both headers could be present. + + When a proxy wants to interwork with a network supporting the other + header field, it should apply the interworking between Diversion + header and History-Info header in the 3xx response. + + + + +Mohali Informational [Page 11] + +RFC 6044 Mapping Diversion and History-Info October 2010 + + + When a recursing proxy redirects an initial INVITE after receiving a + 3xx response, it should add as a last entry either a Diversion header + or a History-Info header (according to its capabilities) in the + forwarded INVITE. Local policies could apply to send the received + header in the next INVITE. + + Other messages where History-Info could be present are not used for + the call forwarding service and should not be changed into Diversion + header. The destination network must be transparent to the received + History-Info header. + + Note: the following mapping is inspired from the ISDN User Part + (ISUP) to the SIP interworking described in [TS_29.163]. + +5. Diversion Header to History-Info Header + + The following text is valid only if no History-Info is present in the + INVITE request. If at least one History-Info header is present, the + interworking function must adapt its behavior to respect the + chronological order. See section 2.2. + + For N Diversion entries, N+1 History-Info entries must be created. + To create the History-Info entries in the same order than during a + session establishment, the Diversion entries must be mapped from the + bottom-most until the top-most. Each Diversion entry shall be mapped + into a History-Info entry. An additional History-Info entry (the + last one) must be created with the diverted-to party address present + in the R-URI of the received INVITE. The mapping is described below. + + The first entry created in the History-Info header contains: + + - a hi-targeted-to-uri with the name-addr parameter of the bottom- + most Diversion header. + + - if a privacy parameter is present in the bottom-most Diversion + entry, then a Privacy header could be escaped in the History-Info + header as described below. + + - an index set to 1. + + For each following Diversion entry (from bottom to top), the History- + info entries are created as following (from top to bottom): + + + + + + + + + +Mohali Informational [Page 12] + +RFC 6044 Mapping Diversion and History-Info October 2010 + + +Source Destination +Diversion header component: History-Info header component: +======================================================================= +name-addr hi-targeted-to-uri + +======================================================================= +Reason of the previous cause-param (not present in +Diversion entry the first created hi-entry) +"unknown"---------------------------------404 (default 'cause' value) +"unconditional"---------------------------302 +"user-busy"-------------------------------486 +"no-answer"-------------------------------408 +"deflection "-----------------------------480 or 487 +"unavailable"-----------------------------404 +"time-of-day"-----------------------------404 (default) +"do-not-disturb"--------------------------404 (default) +"follow-me"-------------------------------404 (default) +"out-of-service"--------------------------404 (default) +"away"------------------------------------404 (default) + +======================================================================= +Counter hi-index +"1" or parameter -------------------------The previous created index +not present is incremented with ".1" +Superior to "1" --------------------------Create N-1 placeholder History +(i.e., N) entry with the previous index + incremented with ".1" + Then the History-Info header + created with the Diversion + entry with the previous index + incremented with ".1" +======================================================================= +Privacy Privacy header escaped in the + hi-targeted-to-uri +"full"------------------------------------"history" +"Off"-------------------------------------Privacy header field + absent or "none" +"name"------------------------------------"history" +"uri"-------------------------------------"history" +======================================================================= + + A last History-Info entry is created and contains: + + - a hi-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. + + + + +Mohali Informational [Page 13] + +RFC 6044 Mapping Diversion and History-Info October 2010 + + + - if a privacy parameter is present in the top-most Diversion entry, + then a Privacy header could be escaped in the History-Info header + as described above. + + - an index set to the previous created index and incremented with + ".1" + + Notes: + + 1. For other optional Diversion parameters, there is no + recommendation as History-Info header does not provide equivalent + parameters. + + 2. For values of the diversion-reason values that are mapped with a + recommended default value, it could also be possible to choose + another value. The cause-param URI parameter offers less possible + values than the diversion-reason parameter. However, it has been + considered that cause-param values list was sufficient to + implement CDIV service as defined in 3GPP [TS_24.604] as it covers + a large portion of cases. + + 3. The Diversion header could contain a Tel:URI in the name-addr + parameter, but it seems not possible to have a Tel:URI in the + History-Info header. [RFC3261] gives an indication as to the + mapping between sip: and Tel:URIs, but in this particular case, it + is difficult to assign a valid hostport as the diversion has + occurred in a previous network and a valid hostport is difficult + to determine. So, it is suggested that in case of Tel:URI in the + Diversion header, the History-Info header should be created with a + SIP URI with user=phone. + + 4. The Diversion header allows the carrying of a counter that retains + the information about the number of successive redirections. The + History-Info header does not have an equivalent because to trace + and count the number of diversion it is necessary to count cause + parameter containing a value associated to a call diversion. Read + the index value is not enough. With the use of the "placeholder" + entry, the History-Info header entries could reflect the real + number of diversion occurred. + + Example of placeholder entry in the History-Info header: + + ;index=1.1 + + ;index=1.1.1 + + + + + + +Mohali Informational [Page 14] + +RFC 6044 Mapping Diversion and History-Info October 2010 + + + "cause=xxx" reflects the diverting reason of a previous diverting + user. For a placeholder hi-entry, the value "404" must be taken for + the cause-param and so, located in the next hi-entry. + + Concerning local policies recommendations about headers coexistence + in the INVITE request, see sections 2.2 and 7.5. + +6. History-Info Header to Diversion Header + + To create the Diversion entries in the same order than during a + session establishment, the History-Info entries must be mapped from + the top-most until the bottom-most. The first History-Info header + entry selected will be mapped into the last Diversion header entry + and so on. One Diversion header entry must be created for each + History-Info entry, with a cause-param reflecting a diverting reason + as listed in the [RFC4458]. + + In this case, the History-Info header must be mapped into the + Diversion header as following: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Mohali Informational [Page 15] + +RFC 6044 Mapping Diversion and History-Info October 2010 + + + Source Destination + History-Info header component: Diversion header component: + ===================================================================== + hi-targeted-to-uri of the name-addr + History-Info that precedes the one + containing a diverting cause-param. + + ===================================================================== + cause-param Reason + 404---------------------------------------"unknown" (default value) + 302---------------------------------------"unconditional" + 486---------------------------------------"user-busy" + 408---------------------------------------"no-answer" + 480 or 487--------------------------------"deflection " + 503---------------------------------------"unavailable" + + ===================================================================== + hi-index Counter + Mandatory parameter for--------------------The counter is set to "1". + History-Info reflecting + the chronological order + of the information. + ===================================================================== + Privacy header [RFC3323] escaped in the Privacy + hi-targeted-to-uri of the + History-Info, which precedes the one + containing a diverting cause-param. + Optional parameter for History-Info, + this Privacy indicates that this + specific History-Info header should + not be forwarded. + "history"----------------------------------"full" + Privacy header field ----------------------"Off" + Absent or "none" + + ===================================================================== + + Note: For other optional History-Info parameters, there is no + recommendation as Diversion header does not provide equivalent + parameters. + + Concerning local policies recommendations about headers coexistence + in the INVITE request, see section 2.2. + + + + + + + + +Mohali Informational [Page 16] + +RFC 6044 Mapping Diversion and History-Info October 2010 + + +7. Examples + +7.1. Example with Diversion Header Changed into History-Info Header + + INVITE last_diverting_target + Diversion: + diverting_user3_address;reason=unconditional;counter=1;privacy=off, + diverting_user2_address;reason=user-busy;counter=1;privacy=full, + diverting_user1_address;reason=no-answer;counter=1;privacy=off + + Mapped into: + + History-Info: + ; index=1, + ;index=1.1, + ;index=1.1.1, + ;index=1.1.1.1 + +7.2. Example with History-Info Header Changed into Diversion Header + + History-Info: + ; index=1, + ;index=1.1, + ;index=1.1.1 + + Mapped into: + + Diversion: + diverting_user2_address; reason=user-busy; counter=1; privacy=off, + diverting_user1_address; reason=unconditional; counter=1; + privacy=full + +7.3. Example with Two SIP Networks Using History-Info Header + Interworking with a SIP Network Using Diversion Header + + A -> P1 -> B -> C -> P2 -> D-> E + A, B, C, D and E are users. + B, C and D have Call Forwarding service invoked. + P1 and P2 are proxies. + Only relevant information is shown on the following call flow. + + + + + + + + + + + +Mohali Informational [Page 17] + +RFC 6044 Mapping Diversion and History-Info October 2010 + + + IWF* IWF* + SIP network using | SIP network using |SIP net. + History-Info | Diversion |using + | Hist-Info + | | + UA A P1 AS B | P2 AS C UA C AS D | UA E + | | | | | | | | | | + |INV B | | | | | | | | | + |------>| | | | | | | | | + | | | | | | | | | | + | |INV B | | | | | | | | + | |------>| | | | | | | | + | |Supported: histinfo | | | | | | + | | History-Info: | | | | | | + | | ; index=1, | | | | | + | | ; index=1.1 | | | | | + | | | | | | | | | | + | | |INV C | | | | | | | + | | |------>| | | | | | | + | | |History-Info: | | | | | | + | | ; index=1,| | | | | + | | ; index=1.1 | | | | | + | | ; index=1.1.1 | | | + | | | | | | | | | | + | | | |INV C | | | | | | + | | | |----->| | | | | | + | | | |Diversion: | | | | | + | | | |B reason= unconditional counter=1 | | + | | | |History-Info: | | | | | + | | | ; index=1,| | | | + | | | ; index=1.1 | | | | + | | | ; index=1.1.1 | + | | | | | | | | | | + | | | | |INV C | | | | | + | | | | |------>| | | | | + | | | | No modification of Diversion due to P2| + | | | | | | | | | | + | | | | | |INV C | | | | + | | | | | |------>| | | | + | | | | | | | | | | + | | | | | |<--180-| | | | + | | | | | | | | | | + | | | | | No response timer expire | | + | | | | | |---INV D --->| | | + + + + + + + +Mohali Informational [Page 18] + +RFC 6044 Mapping Diversion and History-Info October 2010 + + + | | |Diversion: | | | + | | |userC; reason=no-answer; counter=1; privacy=full, | + | | |userB; reason=unconditional; counter=1; privacy=off, + | | | History-Info: | | | + | | | ; index=1, | | | + | | | ; index=1.1 | | | + | | | ; 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: | | + | | | ; index=1, | | + | | | ; index=1.1 | | + | | | ; index=1.1.1 | | + | | | | | | | | | | + | | | | | | | | | INV E | + | | | | | | | | |------>| + | | | History-Info: | + | | | ; index=1, | + | | | ; index=1.1, | + | | | ; index=1.1.1, | + | | | ; index=1.1.1.1, | + | | ; index=1.1.1.1.1, + | | | ; index=1.1.1.1.1.1 | + | | | | | | | | | | + | | | | | | | | | | + + * Note: The IWF is an interworking function that could be a stand- + alone equipment not defined in this document (it could be a proxy). + +7.4. Additional Interworking Cases + + Even if for particular cases in which both headers could coexist, it + should be the network local policy responsibility to make it work + together. Here are described some situations and some + recommendations on the behavior to follow. + + In the case where there is one network that includes different nodes, + some of them supporting the Diversion header and other ones + supporting the History-Info header, there is a problem when any node + handling a message does not know the next node that will handle the + message. This case can occur when the network has new and old nodes, + the older ones using Diversion header and the more recent History- + Info header. + + + +Mohali Informational [Page 19] + +RFC 6044 Mapping Diversion and History-Info October 2010 + + + While a network replacement may be occurring, there will be a time + when both nodes coexist in the network. If the different nodes are + being used to support different subscriber types due to different + node capabilities then the problem is more important. In this case, + there is a need to pass both History-Info header and Diversion header + within the core network. + + These headers need to be equivalent to ensure that, whatever the node + receiving the message, the correct diversion information is received. + This requires that whatever the received header, there is a + requirement to be able to compare the headers and to convert the + headers. Depending upon the node capability, it may be possible to + make assumptions as to how this is handled. + + o If it is known that the older Diversion header supporting nodes do + not pass on any received History-Info header, then the + interworking becomes easier. If a message is received with only + Diversion headers, then it has originated from an 'old' node. The + equivalent History-Info entries can be created and these can then + be passed as well as the Diversion header. + + o If the node creates a new History-Info header for a call + diversion, then an additional Diversion header must be created. + + o If the next node is an 'old' node, then the Diversion header will + be used by that node and the History-Info entries will be removed + from the message when it is passed on. + + o If the next node is a new node then the presence of both Diversion + header and History-Info header means that interworking has already + occurred and the Diversion and History-Info entries must be + considered equivalent. + + o If both nodes pass on both History-Info header and Diversion + header, but only actively use one, then both types of nodes need + to perform the interworking and must maintain equivalence between + the headers. This will eventually result in the use of Diversion + header being deprecated when all nodes in the network support + History-Info header. + +8. Security Considerations + + The security considerations in [RFC4244] and [RFC5806] apply. + + The use of the Diversion header or the History-Info header require + the application of the requested privacy and integrity asked by each + diverting user or entity. Without integrity, the requested privacy + functions could be downgraded or eliminated, potentially exposing + + + +Mohali Informational [Page 20] + +RFC 6044 Mapping Diversion and History-Info October 2010 + + + identity information. Without confidentiality, eavesdroppers on the + network (or any intermediaries between the user and the privacy + service) could see the very personal information that the user has + asked the privacy service to obscure. Unauthorized insertion, + deletion of modification of those headers, can provide misleading + information to users and applications. A SIP entity that can provide + a redirection reason in a History-Info header or a Diversion header + should be able to suppress this in accordance with privacy + requirements of the user concerned. + +9. Acknowledgements + + The editor would like to acknowledge the constructive feedback and + support provided by Steve Norreys, Jan Van Geel, Martin Dolly, + Francisco Silva, Guiseppe Sciortino, Cinza Amenta, Christer Holmberg, + Ian Elz, Jean-Francois Mule, Mary Barnes, Francois Audet, Erick + Sasaki, Shida Schubert, Joel M. Halpern, Bob Braden, and Robert + Sparks. Merci a Lionel Morand, Xavier Marjou, and Philippe Fouquart. + +10. References + +10.1. Normative References + + [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, + A., Peterson, J., Sparks, R., Handley, M., and E. + Schooler, "SIP: Session Initiation Protocol", RFC 3261, + June 2002. + + [RFC3323] Peterson, J., "A Privacy Mechanism for the Session + Initiation Protocol (SIP)", RFC 3323, November 2002. + + [RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason + Header Field for the Session Initiation Protocol (SIP)", + RFC 3326, December 2002. + + [RFC4244] Barnes, M., Ed., "An Extension to the Session Initiation + Protocol (SIP) for Request History Information", RFC + 4244, November 2005. + + [RFC5806] Levy, S. and M. Mohali, Ed., "Diversion Indication in + SIP", RFC 5806, March 2010. + +10.2. Informative References + + [RFC4458] Jennings, C., Audet, F., and J. Elwell, "Session + Initiation Protocol (SIP) URIs for Applications such as + Voicemail and Interactive Voice Response (IVR)", RFC + 4458, April 2006. + + + +Mohali Informational [Page 21] + +RFC 6044 Mapping Diversion and History-Info October 2010 + + + [RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for + Syntax Specifications: ABNF", STD 68, RFC 5234, January + 2008. + + [TS_24.604] 3rd Generation Partnership Project, "Technical + Specification Group Core Network and Terminals ; + Communication Diversion (CDIV) using IP Multimedia + (IM)Core Network (CN) subsystem ; Protocol specification + (Release 8), 3GPP TS 24.604", December 2008. + + [TS_29.163] 3rd Generation Partnership Project, "Technical + Specification Group Core Network and Terminals ; + Interworking between the IP Multimedia (IM) Core Network + (CN) Subsystem and Circuit Switched (CS) networks + (Release 8)", December 2008. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Mohali Informational [Page 22] + +RFC 6044 Mapping Diversion and History-Info October 2010 + + +Appendix A. Interworking between Diversion Header and Voicemail URI + + Voicemail URI is a mechanism described in RFC 4458 to provide a + simple way to transport only one redirecting user address and the + reason why the diversion occurred in the R-URI of the INVITE request. + This mechanism is mainly used for call diversion to a voicemail. + + Diversion header to Voicemail URI: + + Received: + Diversion: userA-address;reason=user-busy;counter=1;privacy=full + + Sent (Voicemail URI created in the R-URI line of the INVITE): + sip: voicemail@example.com;target=userA-address;cause=486 SIP/2.0 + + Mapping of the Redirection Reason is the same as for History-Info + header with a default value set to 404. + + If the Diversion header contains more than one Diversion entry, the + choice of the redirecting user information inserted in the URI is in + charge of the network local policy. For example, the choice + criterion of the redirecting information inserted in the URI could be + the destination of forwarded INVITE request (whether or not the + voicemail serves this user). + + Note: This interworking could be done in addition to the interworking + of the Diversion header into the History-Info header. + + Voicemail URI to Diversion header: + + In case of real voicemail, this way of interworking should not + happen. However, if for any reason it occurs, it is recommended to + do it as following: + + Received: + INVITE sip: voicemail@example.com;\ + target=sip:+33145454500%40example.com;user=phone;\ + cause=302 SIP/2.0 + + Sent in the forwarded INVITE: + Diversion: sip:+ + 33145454500%40example.com;user=phone;reason=unconditional;counter=1 + + + + + + + + + +Mohali Informational [Page 23] + +RFC 6044 Mapping Diversion and History-Info October 2010 + + +Author's Address + + Marianne Mohali + France Telecom Orange + 38-40 rue du General Leclerc + Issy-Les-Moulineaux Cedex 9 92794 + France + + Phone: +33 1 45 29 45 14 + EMail: marianne.mohali@orange-ftgroup.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Mohali Informational [Page 24] + -- cgit v1.2.3