RFC 6044
Mapping and Interworking of Diversion Information between Diversion and History-Info Headers in the Session Initiation Protocol (SIP)
RFC 6044: Mapping and Interworking of Diversion Information between Diversion and History-Info Headers in SIP 🎀
okay bestie, here's the title block 💖
Request for Comments: 6044 Author: M. Mohali, France Telecom Orange Category: Informational Date: October 2010 ISSN: 2070-1721 Stream: Independent Submission
The title block doesn't list anything it obsoletes or updates, so there's nothing to chase down there 🌸
Abstract 🎀
okay so the SIP History-Info header is the solution the IETF went with 🙌 but the non-standard Diversion header is still super widely implemented and used for passing call-diversion info around in SIP signaling. like, it's everywhere, and it's giving "we're not going anywhere" 💅
this doc is a recommended interworking guideline between the Diversion header and the History-Info header so they can handle call diversion info together. it also proposes an interworking policy for how the two headers coexist 🦋 The History-Info header is described in RFC 4244, and the non-standard Diversion header is described, as Historic, in RFC 5806.
since so many existing networks already move call diversion info with the Diversion header, interworking it with the standardized History-Info solution is needed 💜 the goal is to help people migrate from non-standard setups over to IETF specification-based implementations and deployments. main character glow-up energy ✨
Status of This Memo 🌸
ngl this part is very important, so read it 🫶 This document is not an Internet Standards Track specification. It's published for informational purposes only 🍓
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor chose to publish it at its discretion, and they make 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 💅
For info about the current status of this document, any errata, and how to give feedback on it, check 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, because 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 ........................................231. Introduction 💖
1.1. Overview ✨
okay so for some VoIP-based (Voice over IP) services, like voicemail, Interactive Voice Recognition (IVR), or automatic call distribution, it's super helpful for the called SIP user agent to figure out who the session was diverted from and why 🎧 For that info to be useful to different service providers or apps, it has to travel through the network. There are two SIP headers that can do this: the History-Info header defined in [RFC4244] and the historic Diversion header defined in [RFC5806]. Both can carry diversion info in SIP signaling 🦋
the Diversion header isn't standardized, but it's widely used 😭 so it's useful to have guidelines that let it interwork with the standard History-Info header 💅
heads up, though: starting new implementations or deployments of the Diversion header is strongly discouraged 🙈
this document gives a mechanism for translating header content 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 for conveying redirection information 💜 They're 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 submitted to the SIP Working Group. It's now been published as [RFC5806] for the historical record and to give a reference for this RFC 📜
this header holds a list of diverting URIs along with associated info that gives the specific reason for the call diversion. Most existing SIP-based implementations added the Diversion header back when no standard solution was ready to deploy 🛠️ Then the IETF finally standardized the History-Info header, partly because it can carry general history info too. That lets the receiving side figure out how and why the session came in 👀
here's the tea: History-Info may contain more than just call diversion info, so it's critical not to lose information. To pull out the relevant data, you use the retargeting cause URI parameter described in [RFC4458] to carry the diversion reason 🫶
the Diversion header and the History-Info header have different syntaxes, which are described below. The main difference is that History-Info is a chronological header, while Diversion uses reverse chronology (meaning the first diversion entry you read is the last diverting user) 🔄
Appendix A gives an interworking guideline between the Diversion header and the Voicemail URI, which is another way to convey diversion info. The Voicemail URI is defined in [RFC4458] 🎀
2. Problem Statement 🫶
2.1. Interworking Requirements and Scope 💅
this section sets up the baseline terminology used in the rest of the doc and defines the scope of interworking between the Diversion header and the History-Info header 🧠
there are lots of ways SIP signaling can change a session's destination before it's established, and lots of reasons to do it 🗺️ how the SIP entities further downstream handle the session can vary depending on why the destination changed. For example, a simple proxy might just be routing the session, or an application server might be providing a supplementary service. The Diversion header and the History-Info header take different approaches and have different scopes for solving this 💖
here's the vocab used in this document, for clarity ✨
- Retargeting/redirecting: this is when a Proxy Server or User Agent Client (UAC) changes a Uniform Resource Identifier (URI) in a request, which changes the target of that request 🎯 These terms are defined in [RFC4244]. The History-Info header is used to capture retargeting info 📝
- Call forwarding/call diversion/communication diversion: these terms mean the same thing and refer to the Communications Diversion (CDIV) supplementary services, which are based on the Integrated Services Digital Network (ISDN) Communication diversion supplementary services and defined in 3GPP [TS_24.604] 📞 They apply to entities meant to change the original destination of an IP multimedia session during or before session establishment 🧚
this document doesn't try to describe when or how History-Info or Diversion headers should be used 🙅♀️ Instead, it clarifies the context where interworking is needed, just below 👇
the Diversion header has exactly the same scope as the call diversion service, and each header entry reflects one call diversion invocation 💅 It's used to record call forwarding info, which could be useful to network entities downstream. Today, several manufacturers implement this SIP header and it's deployed in networks 🌐
the History-Info header is used to store all retargeting info, including call diversion info 📚 In practice, [RFC4244] History-Info is used to convey call-diversion-related info by using a cause URI parameter [RFC4458] in the relevant entry. Note, however, that using the 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 doesn't specify whether the cause URI parameter should be added to a URI for other cases 🤷♀️ As a consequence, implementations that don't use the cause URI parameter for call forwarding info are not considered for the mapping described in this document 🚫 Still, some recommendations are given in the next sections on how to avoid losing non-mapped info at the boundary between a network region using the History-Info header and one using the Diversion header 🛡️
since both headers handle call forwarding needs, diversion info could get mixed up or become inconsistent if both show up in an uncoordinated way in the INVITE request 😵 So Diversion and History-Info headers must not independently coexist in the same session signaling 🙅♀️ This document explains how to convert info between the Diversion header and the History-Info header, and when and how to preserve both headers to cover additional cases 🧩
to transport consistent diversion info downstream, the two headers need to interwork 🔗 Interworking between the Diversion header and the History-Info header is introduced in sections 5 and 6 💜 Since the coexistence scenario can vary from one use case to another, guidelines about how the headers interact are proposed too ✨
2.2. Interworking Recommendations ✨
Interworking function: okay so bestie, in the normal case the interworking described in this document should be performed by a specific SIP border device 🧱. That device is set up by configuration to know it's sitting on the border between two regions: one using the History-Info header and one using the Diversion header 🫶
History-Info is the standard solution, so a network using the Diversion header has to be able to pass info along to a network using History-Info. To avoid header coexistence (which is giving chaotic 💀), it is required to replace, as often as possible, the Diversion header with the History-Info header in the INVITE request during the interworking 🎀
History-Info has a wider scope than Diversion, so it can be used for other needs and services, not just call diversion 🌈 On top of tracing call diversion info, it also works as a session history and can store all the successive R-URI values 📜 So even though it's better to remove the History-Info header after the Diversion header is created (to avoid confusion), the History-Info header must remain unmodified in the SIP signaling if it contains supplementary (non-diversion) information 🙈 It's also possible to have History-Info headers with no values that can be mapped into the Diversion header. In that case, no interworking with the Diversion header should be performed, and it must be defined per implementation what to do. This point is out of scope for this document, so that's a you-decide moment 🤷♀️
As a conclusion, it is recommended to have local policies that minimize 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 🦋
If a History-Info header is present in the incoming INVITE (in addition to the Diversion header), the Diversion header and the History-Info header present must be mixed. 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 network_2 uses the History-Info header to transport successive URI information), and going to network_3 using the History-Info header 🌸
Here's the picture:
IWF* IWF*
network1 | network_2 |network_3
History-Info | Diversion |using
| |Hist-Info
| |
UA A P1 AS B | P2 AS C UA C AS D | UA E
| | | | | | | | | |
|INVITE | | | | | | | | |
|------>| | | | | | | | |
| | | | | | | | | |
| |INVITE | | | | | | | |
| |------>| | | | | | | |
| |Supported: histinfo | | | | | |
| | History-Info: | | | | | |
| | <sip:proxyP1>; index=1, | | | | |
| | <sip:userB >; index=1.1 | | | | |
| | | | | | | | | |
| | |INVITE | | | | | | |
| | |------>| | | | | | |
| | |History-Info: | | | | | |
| | |<sip:proxyP1>; index=1,| | | | |
| | |<sip:userB>; index=1.1 | | | | |
| | |<sip:userC>; cause=302; index=1.1.1 | | |In this case, the incoming INVITE contains a Diversion header and a History-Info header. Therefore, as recommended in this document, it is necessary to create, for network_3, a single History-Info header gathering the 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 can use the call forwarding information that's present in a single header and add its own diversion information if necessary ✨
Notes:
- 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. 😬
- It is not possible to have only a Diversion header when the History-Info header contains more than call diversion information. If the previous policy recommendations are applied, the chronological order is respected, because Diversion entries are inserted at the end of the History-Info header, taking the Diversion internal chronology into account 🕰️
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, a service might need to know if a specific Application Server (AS) had already 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 just because it passed through a 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 the History-Info header), only the 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 the previous policy recommendations are respected, this case should not happen 🤞
Forking case:
The History-Info header enables the recording of sequential forking for the same served user. During an interworking, from the History-Info header to the Diversion header, the History-Info entries containing a forking situation (with an incremented "index" parameter) could possibly be mapped if they contain a call forwarding "cause" parameter. The interworking entity could choose to create only a Diversion entry or not apply the interworking. The choice could be made according to local policy 🍭
The same logic is applied for an interworking with a 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-paramOkay so the History-Info header is specified in [RFC4244], and the top-most History-Info entry (the first one in the list) is the oldest history info. Bestie, that's the vibe: oldest at the top, newest at the bottom, like a scroll-back chat 💅
A hi-entry can carry a cause URI parameter that spills the diversion reason 🫶 This optional cause URI parameter is defined in [RFC4458] with this syntax:
cause-param = "cause" EQUAL Status-CodeThis parameter is also named cause-param, and it should be inserted in the History-Info entry (URI) of the diverted-to user when there's 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 RFC 4458. Because it's a parameter dedicated to call forwarding service, its presence is how you know a hi-entry belongs to a diverting user. More precisely, each diverting user sits in the hi-entry before the one that contains a cause-param with a cause value listed in RFC 4458. It's giving detective work 🔍
Also, 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). So if the call diversion is due to a SIP response, both cause parameters should be used. The tea is that these parameters could both show up in the History-Info header at the same time, but not in the same hi-entry and not with the same meaning. Only the cause-param is dedicated to the call diversion service. The 'cause' Reason header parameter is not taken into account in the mapping with a Diversion header. Two causes, two jobs, no mixing it up 🙈
[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's address in the downstream INVITE request in the Voicemail URI implementation. Since that info is already in the hi-entries, the 'target' URI parameter is not taken into account for 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 that possibility depends on local policies that this document doesn't describe. Not our problem here, babe 💅
A Privacy header, as defined in [RFC3323], could also be included in hi-entries with the 'history' value defined in [RFC4244] 🔒
The index parameter is a string of digits separated by dots, showing the number of forward hops and retargets. Think of it as a little hop counter 🦋
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. Read that twice, it's important 💜
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.1Policy concerning the "histinfo" option tag in the 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 on whether or not the local policy supports the capture of History-Info. Main character proxy energy 👑
3.2. Diversion Header Syntax 🦋
The following text restates the exact syntax that the production rules in [RFC5806] define, but written in [RFC5234] ABNF. Same tea, new cup ☕
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, described below, and in a header-separated format. Both formats could be combined in a received INVITE, as recommended in [RFC3261]. Mix and match, it's giving flexible 💖
Example:
Diversion:
diverting_user2_addr; reason="user-busy"; counter=1; privacy=full,
diverting_user1_addr; reason="unconditional"; counter=1; privacy=off4. Headers in SIP Method ✨
The recommended interworking presented in this document should apply only for INVITE requests. Only INVITEs get the glow-up 🌸
In 3xx responses, both headers could be present. Two headers, one response, zero drama 🫶
When a proxy wants to interwork with a network that supports the other header field, it should apply the interworking between the Diversion header and the 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 (depending on its capabilities) in the forwarded INVITE. Local policies could apply to send the received header in the next INVITE. The proxy's personal brand, lol 💅
Other messages where History-Info could be present are not used for the call forwarding service and should not be changed into a Diversion header. The destination network must be transparent to the received History-Info header. Hands off 🙈
Note: the following mapping is inspired by the ISDN User Part (ISUP) to SIP interworking described in [TS_29.163]. Shoutout to ISUP, the OG 🧚
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 as during session establishment, the Diversion entries must be mapped from the bottom-most up to the top-most. Each Diversion entry shall be mapped into a History-Info entry. An additional History-Info entry (the last one) must be created with the diverted-to party address present in the R-URI of the received INVITE. The mapping is described below. Flip the stack, then flip it again, it's a whole arc 🦋
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 follows (from top to bottom):
Source Destination
Diversion header component: History-Info header component:
=======================================================================
name-addr hi-targeted-to-uri
=======================================================================
Reason of the previous cause-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 it's the one that wraps the whole chain up 💅 It 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. 🦋
- 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, bestie 📝
- For other optional Diversion parameters, there is no recommendation, because the History-Info header doesn't have equivalent parameters. 🙈
- For diversion-reason values that are mapped to a recommended default value, it's also possible to pick another value. The cause-param URI parameter offers fewer possible values than the diversion-reason parameter, but the cause-param value list was considered enough to implement the CDIV service as defined in 3GPP [TS_24.604], since it covers a big chunk of cases. 💜
- The Diversion header can carry a Tel:URI in the name-addr, but it doesn't seem possible to have a Tel:URI in the History-Info header. [RFC3261] gives some pointers on mapping between sip: and Tel:URIs, but here it's hard to assign a valid hostport, because the diversion happened in a previous network and a valid hostport is tricky to figure out. So, in the case of a Tel:URI in the Diversion header, the History-Info header should be created with a SIP URI with user=phone. 📞
- The Diversion header lets you carry a counter that tracks how many successive redirections happened. The History-Info header has no equivalent, because to trace and count the diversions you have to count cause parameters containing a value tied to a call diversion. Reading the index value alone isn't enough. With the "placeholder" entry, the History-Info header entries can reflect the real number of diversions that 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 placeholder hi-entry, the value "404" must be taken for the cause-param and so, located in the next hi-entry. 🌸
For local policy recommendations about headers coexisting 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 as during session establishment, the History-Info entries must be mapped from the top-most to the bottom-most. The first History-Info header entry selected gets 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 [RFC4458]. 👑
So here's how the History-Info header gets mapped into the Diversion header:
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, because the Diversion header doesn't have equivalent parameters. 🙈
For local policy recommendations about headers coexisting in the INVITE request, see section 2.2. 💅
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=offMapped 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.17.2. Example with History-Info Header Changed into Diversion Header
History-Info:
<sip: diverting_user1_address?privacy=history >; index=1,
<sip: diverting_user2_address; cause=302? privacy=none>;index=1.1,
<sip: last_diverting_target; cause=486>;index=1.1.1Mapped into:
Diversion:
diverting_user2_address; reason=user-busy; counter=1; privacy=off,
diverting_user1_address; reason=unconditional; counter=1;
privacy=full7.3. Example with Two SIP Networks Using History-Info Header Interworking with a SIP Network Using Diversion Header ✨
Okay bestie, this is the big one 💅 Two SIP networks chatting with each other, one using History-Info and one using Diversion, with an interworking function (IWF) in the middle keeping things smooth. Users A through E are all in the mix, and B, C, and D each have Call Forwarding turned on. Only the relevant bits are on the call flow, so no fluff 🫶
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 function that could be a stand-alone equipment not defined in this document (it could be a proxy).
7.4. Additional Interworking Cases 🌈
Okay so even when both headers could coexist in the same call, it should be the network local policy responsibility to make it work together. Here are some situations and some recommendations on the behavior to follow 🦋
First up, picture one network that has a mix of nodes. Some support the Diversion header, and others support the History-Info header. That gets messy fast 😭 The problem shows up whenever a node handling a message doesn't know which node will handle the message next. This can happen when the network has new and old nodes, where the older ones use the Diversion header and the newer ones use the History-Info header.
Then there's the network replacement situation. While a replacement is happening, there will be a time when both kinds of nodes coexist in the network. If the different nodes are being used for different subscriber types because of different node capabilities, the problem gets even bigger 💀 In that case, both the History-Info header and the Diversion header need to be passed within the core network.
These headers need to be equivalent so that, no matter which node receives the message, the correct diversion information shows up 🎀 That means whatever header arrives, it has to be possible to compare the headers and convert between them. Depending on the node capability, it may be possible to make assumptions about how this is handled.
- If it is known that the older Diversion header supporting nodes do not pass on any received History-Info header, then the interworking becomes easier. If a message is received with only Diversion headers, then it has originated from an 'old' node. The equivalent History-Info entries can be created and these can then be passed as well as the Diversion header.
- If the node creates a new History-Info header for a call diversion, then an additional Diversion header must be created.
- If the next node is an 'old' node, then the Diversion header will be used by that node and the History-Info entries will be removed from the message when it is passed on.
- If the next node is a new node then the presence of both Diversion header and History-Info header means that interworking has already occurred and the Diversion and History-Info entries must be considered equivalent.
- If both nodes pass on both History-Info header and Diversion header, but only actively use one, then both types of 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 🔐
Security is serious business, so no skipping this one 🫢 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 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 or 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
Now the "just for context" refs 💅✨
- [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 Diversion Header and Voicemail URI 🧚
okay so this appendix is all about voicemail 📬 RFC 4458 gives us a Voicemail URI, which is a neat little trick for passing along just one redirecting user address and the reason the call got diverted, and it all rides in the R-URI of the INVITE request 💌 this is mostly used for call diversion to a voicemail, so it's very much a voicemail vibe ✨
Diversion header to Voicemail URI:
Here's what comes in:
Diversion: userA-address;reason=user-busy;counter=1;privacy=fullAnd here's what goes out, with the Voicemail URI made in the R-URI line of the INVITE:
sip: voicemail@example.com;target=userA-address;cause=486 SIP/2.0The mapping of the Redirection Reason is the same as for the History-Info header, with a default value set to 404. 🔢
If the Diversion header has more than one Diversion entry, the choice of which redirecting user information goes into the URI is up to the network's local policy 🏠 for example, the choice criterion could be the destination of the 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 🙈 but if for any reason it does occur, it is recommended to handle it like this:
Received:
INVITE sip: voicemail@example.com;\
target=sip:+33145454500%40example.com;user=phone;\
cause=302 SIP/2.0Sent in the forwarded INVITE:
Diversion: sip:+
33145454500%40example.com;user=phone;reason=unconditional;counter=1Author'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📦 where this page comes from
- ietf: rfc6044 2010-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms