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