idnits 2.17.1 draft-mohali-rfc6044bis-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC6044], [RFC4244], [RFC5806], [RFC7044]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 191: '... 4. Many SHOULD are changed into MU...' -- The abstract seems to indicate that this document obsoletes RFC4244, but the header doesn't have an 'Obsoletes:' line to match this. -- The abstract seems to indicate that this document obsoletes RFC7044, but the header doesn't have an 'Obsoletes:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 04, 2015) is 3313 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC3966' is defined on line 1171, but no explicit reference was found in the text == Unused Reference: 'RFC6044' is defined on line 1191, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4244 (Obsoleted by RFC 7044) -- Obsolete informational reference (is this intentional?): RFC 6044 (Obsoleted by RFC 7544) Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Mohali 3 Internet-Draft Orange 4 Obsoletes: 6044 (if approved) March 04, 2015 5 Intended status: Informational 6 Expires: September 5, 2015 8 Mapping and interworking of Diversion information Between Diversion and 9 History-Info Headers in the Session Initiation Protocol (SIP) 10 draft-mohali-rfc6044bis-02 12 Abstract 14 Although the SIP History-Info header field is the solution adopted in 15 IETF, the non-standard Diversion header field is nevertheless already 16 implemented and used for conveying call diversion related information 17 in the Session Initiation Protocol (SIP) signaling. 18 On one hand, the non-standard Diversion header field is described, as 19 Historic, in [RFC5806]. On the other hand, the History-Info header 20 field is described in [RFC7044] that obsoletes the original[RFC4244] 21 describing the History-Info header field. [RFC7044] defines the SIP 22 header field, History-Info, for capturing the history information in 23 requests and new SIP header field parameters for the History-Info and 24 Contact header fields to tag the method by which the target of a 25 request is determined. [RFC7044] also defines a value for the 26 Privacy header field that directs the anonymization of values in the 27 History-Info header field. 29 Since the Diversion header field is used in existing network 30 implementations for the transport of call diversion information, its 31 interworking with the SIP History-Info standardized solution is 32 needed. This document describes a recommended interworking guideline 33 between the Diversion header field and the History-Info header field 34 to handle call diversion information. In addition, an interworking 35 policy is proposed to manage the headers' coexistence. This work is 36 intended to enable the migration from non-standard implementations 37 and deployments toward IETF specification-based implementations and 38 deployments. 39 This document obsoletes [RFC6044]that describes the interworking 40 between the Diversion header field [RFC5806] and the obsoleted 41 History-Info header field as defined on [RFC4244]. 43 Status of This Memo 45 This Internet-Draft is submitted in full conformance with the 46 provisions of BCP 78 and BCP 79. 48 Internet-Drafts are working documents of the Internet Engineering 49 Task Force (IETF). Note that other groups may also distribute 50 working documents as Internet-Drafts. The list of current Internet- 51 Drafts is at http://datatracker.ietf.org/drafts/current/. 53 Internet-Drafts are draft documents valid for a maximum of six months 54 and may be updated, replaced, or obsoleted by other documents at any 55 time. It is inappropriate to use Internet-Drafts as reference 56 material or to cite them other than as "work in progress." 58 This Internet-Draft will expire on September 5, 2015. 60 Copyright Notice 62 Copyright (c) 2015 IETF Trust and the persons identified as the 63 document authors. All rights reserved. 65 This document is subject to BCP 78 and the IETF Trust's Legal 66 Provisions Relating to IETF Documents 67 (http://trustee.ietf.org/license-info) in effect on the date of 68 publication of this document. Please review these documents 69 carefully, as they describe your rights and restrictions with respect 70 to this document. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 75 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3 76 1.2. Background . . . . . . . . . . . . . . . . . . . . . . . 3 77 1.3. From RFC4244 to RFC7044 . . . . . . . . . . . . . . . . . 4 78 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 79 3. Interworking recommendations . . . . . . . . . . . . . . . . 7 80 3.1. General recommendations . . . . . . . . . . . . . . . . . 7 81 3.2. Privacy considerations . . . . . . . . . . . . . . . . . 7 82 3.3. Headers in SIP Method . . . . . . . . . . . . . . . . . . 9 83 3.4. SIP network/terminal using Diversion to SIP 84 network/terminal using History-Info header . . . . . . . 9 85 3.5. SIP network/terminal using History-Info header to SIP 86 network/terminal using Diversion header . . . . . . . . . 11 87 4. Header fields syntaxes reminder . . . . . . . . . . . . . . . 12 88 4.1. History-Info header field syntax . . . . . . . . . . . . 12 89 4.2. Diversion header field syntax . . . . . . . . . . . . . . 15 90 5. Diversion header to History-Info header . . . . . . . . . . . 15 91 6. History-Info header to Diversion header . . . . . . . . . . . 19 92 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 21 93 7.1. Example with Diversion header changed into History-Info 94 header . . . . . . . . . . . . . . . . . . . . . . . . . 21 95 7.2. Example with History-Info header changed into Diversion 96 header . . . . . . . . . . . . . . . . . . . . . . . . . 21 97 7.3. Example with two SIP networks using History-Info header 98 interworking with a SIP network using Diversion header . 21 99 7.4. Additional interworking Cases . . . . . . . . . . . . . . 23 100 8. Backward Compatibility . . . . . . . . . . . . . . . . . . . 25 101 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 102 10. Security Considerations . . . . . . . . . . . . . . . . . . . 25 103 11. Acknowlegements . . . . . . . . . . . . . . . . . . . . . . . 25 104 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 105 12.1. Normative References . . . . . . . . . . . . . . . . . . 26 106 12.2. Informative References . . . . . . . . . . . . . . . . . 26 107 Appendix A. Interworking between Diversion header and Voicemail 108 URI . . . . . . . . . . . . . . . . . . . . . . . . 27 109 A.1. Diversion header field to Voicemail URI . . . . . . . . . 27 110 A.2. Voicemail URI to Diversion header field . . . . . . . . . 27 111 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 28 113 1. Introduction 115 1.1. Overview 117 For some VoIP-based services (eg. Voicemail, Interactive Voice 118 Recognition (IVR) or automatic call distribution), it is helpful for 119 the called SIP user agent to identify from whom and why the session 120 was diverted. For this information to be used in various service 121 providers or by applications, it needs to pass through the network. 122 This is possible with two different SIP header fields: History-Info 123 header field defined in [RFC7044] and the historic Diversion header 124 field defined in [RFC5806] which are both able to transport diversion 125 information in the SIP signaling. 126 Although the Diversion header field is not standardized, it has been 127 widely implemented. Therefore, it is useful to have guidelines to 128 make this header field interwork with the standard History-Info 129 header field. 130 Note that the new implementation and deployment of the Diversion 131 header field is strongly discouraged. 133 This document provides a mechanism for header fields content 134 translation between the Diversion header field and the History-Info 135 header field. 137 1.2. Background 139 The obsoleted History-Info header field [RFC4244] and its extension 140 for forming SIP service URIs (including Voicemail URI) [RFC4458] used 141 to be recommended by IETF to convey redirection information. They 142 also used to be recommended in the "Communication Diversion (CDIV) 143 service" 3GPP specification [TS_24.604]. 145 Concerning, the Diversion header field, it was originally described 146 in an Internet Draft that was submitted to the SIP Working Group and 147 was finally published as [RFC5806] for the historical record and to 148 provide a reference for this RFC. 150 This header field contains a list of diverting URIs and associated 151 information providing specific information as the reason for the call 152 diversion. Most of the first SIP-based implementations have 153 implemented the Diversion header field when no standard solution was 154 ready to deploy. The IETF has standardized the History-Info header 155 field partly because it can transport general history information. 156 This allows the receiving part to determine how and why the session 157 is received. As the History-Info header field may contain further 158 information than call diversion information, it is critical to avoid 159 losing information and be able to extract the relevant data using the 160 retargeting cause URI parameter described in [RFC4458] for the 161 transport of the call forwarding reason. 163 The Diversion header field and the History-Info header field have 164 different syntaxes reminded in this document. Note that the main 165 difference is that the History-Info header field is a chronological 166 writing header whereas the Diversion header field applies a reverse 167 chronology (i.e. the first diversion entry read corresponds to the 168 last diverting user). 170 The Appendix A provides an interworking guideline between the 171 Diversion header field and the Voicemail URI which is another way to 172 convey diversion information without using the History-Info header 173 field. The Voicemail URI is defined in [RFC4458]. 175 1.3. From RFC4244 to RFC7044 177 The detail of why and how [RFC4244] has been updated and replaced by 178 [RFC7044] is provided in section 16 of [RFC7044]. 180 Here are the main changes for the History-Info header field 181 implementation: 183 1. Added header field parameters "mp", "rc" and "np" to capture the 184 specific method by which a target is determined. 186 2. Added a way to indicate a gap in History-Info by adding a "0" in 187 the index. 189 3. To apply privacy, entries are anonymized rather than removed. 191 4. Many SHOULD are changed into MUST to have a more reliable header. 193 Backward compatibility aspects are discussed in section 8 of this 194 document. 196 2. Problem Statement 198 This section provides the baseline terminology used in the rest of 199 the document and defines the scope of interworking between the 200 Diversion header field and the History-Info header field. 202 They are many ways in which SIP signaling can be used to modify a 203 session destination before it is established and many reasons for 204 doing so. The behavior of the SIP entities that will have to further 205 process the session downstream will sometimes vary depending on the 206 reasons that lead to changing the destination. For example, whether 207 it is for a simple proxy to route the session or for an application 208 server to provide a supplementary service. The Diversion header 209 field and the History-Info header field differ in the approach and 210 scope of addressing this problem. 212 For clarity, the following vocabulary is used in this document: 214 o Retarget/redirect: these terms refer to the process of a Proxy 215 Server/User Agent Client (UAC) changing a Request-URI (Section 7.1 216 of [RFC3261]) in a request and thus changing the target of the 217 request. This includes changing the Request-URI due to a location 218 service lookup and redirect processing. This also includes 219 internal (to a proxy/SIP intermediary) changes of the URI prior to 220 the forwarding of the request. The retarget term is defined in 221 [RFC7044]. 223 o Call forwarding/call diversion/communication diversion: these 224 terms are equivalent and refer to the Communications Diversion 225 (CDIV) supplementary services, based on the ISDN Communication 226 diversion supplementary services and defined in 3GPP [TS_24.604]. 227 They are applicable to entities which are intended to modify the 228 original destination of an IP multimedia session during or prior 229 to the session establishment. 231 This document does not intend to describe when or how History-Info or 232 Diversion header fields should be used. Hereafter is provided 233 clarification on the context in which the interworking is required. 235 The Diversion header field has exactly the same scope as the call 236 diversion service and each header field entry reflects a call 237 diversion invocation. The Diversion header field is used for 238 recording call forwarding information which could be useful to 239 network entities downstream. Today, this SIP header field is 240 implemented by several manufacturers and deployed in networks. 242 The History-Info header field is used to store all retargeting 243 information including call diversion information. As such, the 244 History-Info header field [RFC7044] is used to convey call diversion 245 related information by using a cause URI parameter [RFC4458] in the 246 relevant entry. 247 Note, however, that the use of cause URI parameter [RFC4458] in a 248 History-Info entry for a call diversion is specific to the 3GPP 249 specification [TS_24.604]. [RFC4458] focuses on retargeting toward 250 voicemail server and does not specify whether the cause URI parameter 251 should be added in a URI for other cases. As a consequence, 252 implementations that do not use the cause URI parameter for call 253 forwarding information, are not considered for the mapping described 254 in this document. Nevertheless, some recommendations are given in 255 the next sections on how to avoid the loss of non-mapped information 256 at the boundary between a network region using History-Info header 257 field and one using the Diversion header field. 259 The [RFC7044] defines three header field parameters, "rc", "mp", and 260 "np". The header field parameters "rc" and "mp" indicate the 261 mechanism by which a new target for a request is determined. The 262 header field "np" reflects that the target has not changed. All 263 parameters contain an index whose value refers to the hi-index of the 264 hi-entry with an hi-targeted-to-uri that represents the Request-URI 265 that was retargeted. 267 Since both header fields address call forwarding needs, diverting 268 information could be mixed-up or be inconsistent if both are present 269 in an uncoordinated fashion in the INVITE request. So, Diversion and 270 History-Info header fields must not independently coexist in the same 271 session signaling. This document addresses how to convert 272 information between the Diversion header field and the History-Info 273 header field, and when and how to preserve both header fields to 274 cover additional cases. 276 For the transportation of consistent diversion information 277 downstream, it is necessary to make the two header fields interwork. 278 Interworking between the Diversion header field and the History-Info 279 header field is introduced in sections 5 and 6. Since coexistence 280 scenario may vary from one use case to another one, guidelines 281 regarding header fields interaction are proposed in section 3. 283 3. Interworking recommendations 285 3.1. General recommendations 287 Interworking function: 289 In a normal case, the network topology assumption is that the 290 interworking described in this document should be performed by a 291 specific SIP border device which is aware, by configuration, that 292 it is at the border between two regions, one using History-Info 293 header field and one using Diversion header field. 295 As History-Info header field is a standard solution, a network using 296 the Diversion header field must be able to provide information to a 297 network using the History-Info header field. In this case, to avoid 298 header fields coexistence it is required to replace, as often as 299 possible, the Diversion header field with the History-Info header 300 field in the INVITE request during the interworking. 302 Since, the History-Info header field has a wider scope than the 303 Diversion header field, it may be used for other needs and services 304 than call diversion. In addition to trace call diversion 305 information, History-Info header field also acts as a session history 306 and can store all successive Request-URI values. Consequently, even 307 if it should be better to remove the History-Info header field after 308 the creation of the Diversion header field avoiding confusion, the 309 History-Info header field must remain unmodified in the SIP signaling 310 if it contains supplementary (non-diversion) information. It is 311 possible to have History-Info header fields that do not have values 312 that can be mapped into the Diversion header field. In this case, no 313 interworking with Diversion header field should be performed and it 314 must be defined per implementation what to do in this case. This 315 point is left out of the scope of this document. 317 As a conclusion, it is recommended to have local policies minimizing 318 the loss of information and find the best way to keep it up to the 319 terminating user agent. 321 The following sections describe the basic common use case. 322 Additional interworking cases are described in section 7.5. 324 3.2. Privacy considerations 326 When a SIP message is forwarded to a domain for which the SIP 327 intermediary is not responsible, a Privacy Service at the boundary of 328 the domain applies the appropriate privacy based on the value of the 329 Privacy header field in the message header or in the privacy 330 parameter within concerned header. 332 1. For the History-Info header field, it is the "headers" component 333 of the hi-targeted-to-uri in the individual hi-entries with the 334 possible priv-value "history". 336 2. For the Diversion header field, it is the diversion-privacy 337 parameter "privacy" in each Diversion header field. 339 o For the History-Info header field, as recommended in [RFC7044]: 341 - If there is a Privacy header field in the message header of a 342 request with a priv-value of "header" or "history", then all 343 the hi-targeted-to-uris (in the hi-entries associated with the 344 domain for which the SIP intermediary is responsible) are 345 anonymized by the Privacy Service. The Privacy Service must 346 change any hi-targeted-to-uri in these hi-entries that have not 347 been anonymized to the anonymous SIP URI 348 "anonymous@anonymous.invalid" as recommended in sections 349 4.1.1.3 and 4.1.1.2 of [RFC3323]. 351 - If there is a Privacy header field in the "headers" component 352 of a hi-targeted-to-uri with a priv-value of "history", then 353 all the concerned hi-entries must be anonymized as described 354 above prior to forwarding. 356 The Privacy Service must remove the Privacy header field from the 357 "headers" component of the hi-targeted-to-uris of the concerned 358 hi-entries and the priv-value of "history" from the Privacy header 359 field in the message header of the request prior to forwarding. 360 If there are no remaining priv-values in the Privacy header field, 361 the Privacy Service must remove the Privacy header field from the 362 request. 364 o For the Diversion header field: 366 - If there is a Privacy header field in the message header of a 367 request with a priv-value of "header", then all the addresses 368 in the Diversion header fields (associated with the domain for 369 which the SIP intermediary is responsible) are anonymized by 370 the Privacy Service by changing the address to the anonymous 371 SIP URI "anonymous@anonymous.invalid" as recommended in 372 sections 4.1.1.3 and 4.1.1.2 of [RFC3323] prior to forwarding. 374 - For the each Diversion header field or each entry in the 375 Diversion header field, if there is a diversion-privacy 376 parameter with a value set to "full", "uri" or "name", then the 377 concerned Diversion header field address must be anonymized as 378 described above prior to forwarding. 380 In the concerned Diversion header field entries, the diversion- 381 privacy parameter must be removed from the header. 383 The privacy information interworking as described in sections 5 and 6 384 must only be considered within a trusted domain that ensure to 385 correctly apply the privacy requirements. 387 3.3. Headers in SIP Method 389 The recommended interworking presented in this document should apply 390 only for INVITE requests. 392 In 3xx responses: 394 Both History-Info and Diversion header fields could be present in 395 3xx responses. 396 When a proxy wants to interwork with a network supporting the 397 other header field, it should apply the interworking between 398 Diversion header field and History-Info header field in the 3xx 399 response. 400 When a recursing proxy redirects an initial INVITE after receiving 401 a 3xx response, it should add as a last entry either a Diversion 402 header field or History-Info header field (according to its 403 capabilities) in the forwarded INVITE. Local policies could apply 404 to send the received header field in the next INVITE or not. 406 In SIP responses other than 100: 408 All SIP responses where History-Info could be present are not used 409 for the Call Forwarding service and should not be changed into 410 Diversion header field. The destination network must be 411 transparent to the received History-Info header field. 413 Note: The following mapping is inspired from the ISUP to SIP 414 interworking described in [TS_29.163]. 416 3.4. SIP network/terminal using Diversion to SIP network/terminal using 417 History-Info header 419 When the Diversion header field is used to create a History-Info 420 header field, the Diversion header field must be removed in the 421 outgoing INVITE. It is considered that all the information present 422 in the Diversion header field is transferred in the History-Info 423 header field. 425 If a History-Info header field is also present in the incoming INVITE 426 (in addition to Diversion header field), the Diversion header field 427 and History-Info header field present must be mixed and only the 428 diversion information not yet present in the History-Info header 429 field must be inserted as a last entry (more recent) in the existing 430 History-Info header field, following the creation process recommended 431 in [RFC7044]. 433 As an example, this could be the case of an INVITE coming from 434 network_2 using Diversion header field but previously passed through 435 network_1 using History-Info header field (or the network_2 uses 436 History-Info header field to transport successive URI information) 437 and going to network_3 using History-Info header field. 439 IWF* IWF* 440 network1 | network_2 |network_3 441 History-Info | Diversion |using 442 | |Hist-Info 443 | | 444 UA A P1 AS B | P2 AS C UA C AS D | UA E 445 | | | | | | | | | | 446 |INVITE | | | | | | | | | 447 |------>| | | | | | | | | 448 | | | | | | | | | | 449 | |INVITE | | | | | | | | 450 | |------>| | | | | | | | 451 | |Supported: histinfo | | | | | | 452 | | History-Info: | | | | | | 453 | | ; index=1, | | | | | 454 | | ; index=1.1;rc=1 | | | | | 455 | | | | | | | | | | 456 | | |INVITE | | | | | | | 457 | | |------>| | | | | | | 458 | | |History-Info: | | | | | | 459 | | |; index=1,| | | | | 460 | | |; index=1.1;rc=1, | | | | 461 | | |; index=1.1.1;mp=1.1 | | 463 In this case, the incoming INVITE contains a Diversion header field 464 and a History-Info header field. Therefore, as recommended in this 465 document, it is necessary to create for network_3, a single History- 466 Info header field gathering existing information from both the 467 History-Info and the Diversion header fields received. Anyway, it is 468 required from network_2 (ie.IWF) to remove the Diversion header field 469 when the message is going to a network not using the Diversion header 470 field. Then network_3 could use call forwarding information that is 471 present in a single header field and add its own diversion 472 information if necessary. 474 Notes: 476 1. If a network is not able either to use only one header field each 477 time, or to maintain both header fields up to date, the 478 chronological order can not be certified. 480 2. It is not possible to have only Diversion header field when the 481 History-Info header field contains more than call diversion 482 information. If previous policy recommendations are applied, the 483 chronological order is respected as Diversion entries are 484 inserted at the end of the History-Info header field taking into 485 account the Diversion internal chronology. 487 3.5. SIP network/terminal using History-Info header to SIP network/ 488 terminal using Diversion header 490 When the History-Info header field is interpreted to create a 491 Diversion header field, some precautions must be taken. 492 If the History-Info header field contains only call forwarding 493 information, then it must be deleted after the interworking. 494 If the History-Info header field contains other information, then 495 only the information of concern to the diverting user must be used to 496 create entries in the Diversion header field and the History-Info 497 header field must be kept as received in the INVITE and forwarded 498 downstream. 500 Note: The History-Info header field could be used for other reasons 501 than call diversion services, for example by a service which need to 502 know if a specific AS had yet been invoked in the signaling path. If 503 the call is later forwarded to a network using History-Info header 504 field, it would be better not to lose history information due to 505 passing though the network which only support Diversion header field. 506 A recommended solution must not disrupt the standard behavior and 507 networks which do not implement the History-Info header field must be 508 transparent to a received History-Info header field. 510 If a Diversion header field is present in the incoming INVITE (in 511 addition to History-Info header field), only diversion information 512 present in the History-Info header field but not in the Diversion 513 header field must be inserted from the last entry (more recent) into 514 the existing Diversion header field as recommended in the [RFC5806]. 516 Note that the chronological order could not be certified. If 517 previous policy recommendations are respected, this case should not 518 happen. 520 Forking case: 522 The History-Info header field enables the recording of sequential 523 forking for the same served-user. During an interworking, from 524 the History-Info header field to Diversion header field, the 525 History-Info entries containing a forking situation (with an 526 incremented "index" parameter) could possibly be mapped if it 527 contains a call forwarding "cause" parameter. The interworking 528 entity could choose to create only a Diversion entry or not apply 529 the interworking. The choice could be done according a local 530 policy. 532 The same logic is applied for an interworking with Voicemail URI (see 533 the Appendix A). 535 4. Header fields syntaxes reminder 537 4.1. History-Info header field syntax 539 The ABNF syntax [RFC5234] for the History-Info header field and 540 header field parameters is as follows: 542 History-Info = "History-Info" HCOLON hi-entry *(COMMA hi-entry) 544 hi-entry = hi-targeted-to-uri *(SEMI hi-param) 545 hi-targeted-to-uri = name-addr 546 hi-param = hi-index/hi-target-param/hi-extension 547 hi-index = "index" EQUAL index-val 548 index-val = number *("." number) 549 number = [ %x31-39 *DIGIT ] DIGIT 550 hi-target-param = rc-param / mp-param / np-param 551 rc-param = "rc" EQUAL index-val 552 mp-param = "mp" EQUAL index-val 553 np-param = "np" EQUAL index-val 554 hi-extension = generic-param 556 The ABNF definitions for "generic-param", "name-addr", "HCOLON", 557 "COMMA", "SEMI", and "EQUAL" are from[RFC3261]. 559 The History-Info header field is specified in [RFC7044]. The top- 560 most History-Info entry (first in the list) corresponds to the oldest 561 history information. 563 Cause URI parameter: 565 A hi-entry may contain a cause URI parameter expressing the 566 diversion reason. This cause URI parameter is defined in 567 [RFC4458]. The ABNF grammar [RFC5234] for the cause-param 568 parameter is reminded below as it has been subject to Errata [ID: 569 1409] in [RFC4458]. The Status-Code is defined in [RFC3261]. 571 cause-param = "cause=" Status-Code 573 This parameter is also named cause-param is a SIP/SIPS URI 574 parameter and should be inserted in the History-Info entry (URI) 575 of the diverted-to user in case of call diversion as recommended 576 in the 3GPP CDIV specification [TS_24.604]. The cause values used 577 in the cause-param for the diverting reason are listed in 578 [RFC4458] . Because it is a parameter dedicated to call 579 forwarding service, its presence is used to determine that a hi- 580 entry is a diverting user. More precisely, each diverting user is 581 located in the hi-entry before the one containing a cause-param 582 with cause value as listed in [RFC4458]. 584 Reason header field: 586 Moreover, the Reason header field defined in [RFC3326] should be 587 escaped in the hi-entry of the diverting user when the call 588 diversion is due to a received SIP response. The Reason header 589 field contains a cause parameter set to the true SIP response code 590 received (Status-Code). 591 Therefore, in case of call diversion due to a SIP response, both 592 cause parameters should be used. The complexity is that these 593 parameters could be used at the same time in the History-Info 594 header field but not in the same hi-entry and not with the same 595 meaning. Only the cause-param is dedicated to call diversion 596 service. The 'cause' Reason header field parameter is not taken 597 into account in the mapping with a Diversion header field. 599 Target URI parameter: 601 The [RFC4458] also defines the 'target' URI parameter which could 602 be inserted in a Request-URI and consequently in the hi-targeted- 603 to-uri. This parameter is used to keep the diverting user address 604 in the downstream INVITE request in Voicemail URI implementation. 605 As this information is already present in the hi-entries, the 606 'target' URI parameter is not taken into account regarding the 607 interworking with the Diversion header field. From the Diversion 608 header field, it could be possible to create the 'target' URI 609 parameter in the hi-entries and/or in the Request-URI but this 610 possibility is based on local policies not described in this 611 document. 613 Privacy header field: 615 A Privacy header field as defined in [RFC3323] could also be 616 embeded in hi-entries with the 'history' value defined in 617 [RFC7044]. 619 Index header field parameter: 621 The index parameter is a string of digits, separated by dots to 622 indicate the number of forward hops and retargets. 624 Note: A history entry could contain the "gr" parameter. Regardless 625 the rules concerning "gr" parameter defined in [TS_24.604] which must 626 be applied, this parameter has no impact on the mapping and must only 627 be copied with the served user address. 629 Missing entry: 631 If the request clearly has a gap in the hi-entry (i.e., the last 632 hi-entry and Request-URI differ), the entity adding an hi-entry 633 must add a single index with a value of "0" (i.e., the nonnegative 634 integer zero) prior to adding the appropriate index for the action 635 to be taken (eg. Index=1.1.2.0.1). Prior to any application 636 usage of the History-Info header field parameters, the SIP entity 637 that processes the hi-entries must evaluate the hi-entries and 638 determine if there are any gaps in the hi-entries. 640 "histinfo" option tag: 642 According to [RFC7044], a proxy that receives a Request with the 643 "histinfo" option tag in the Supported header field should return 644 captured History-Info in subsequent, provisional and final 645 responses to the Request. The behavior depends upon whether the 646 local policy supports the capture of History-Info or not. 648 Example: 650 History-Info: 651 ; 652 index=1, 653 ;index=1.1;mp=1, 654 ; index=1.1.1;mp=1.1 656 4.2. Diversion header field syntax 658 The following text is restating the exact syntax that the production 659 rules in [RFC5806] define, but using [RFC5234] ABNF: 661 Diversion = "Diversion" HCOLON diversion-params 662 *(COMMA diversion-params) 664 diversion-params = name-addr *(SEMI (diversion-reason / 665 diversion-counter / diversion-limit / 666 diversion-privacy / diversion-screen / 667 diversion-extension)) 668 diversion-reason = "reason" EQUAL ("unknown" / "user-busy" / 669 "no-answer" / "unavailable" / "unconditional" 670 / "time-of-day" / "do-not-disturb" / 671 "deflection" / "follow-me" / "out-of-service" 672 / "away" / token / quoted-string) 673 diversion-counter = "counter" EQUAL 1*2DIGIT 674 diversion-limit = "limit" EQUAL 1*2DIGIT 675 diversion-privacy = "privacy" EQUAL ("full" / "name" / "uri" / 676 "off" / token / quoted-string) 677 diversion-screen = "screen" EQUAL ("yes" / "no" / token / 678 quoted-string) 679 diversion-extension = token [EQUAL (token / quoted-string)] 681 Note: The Diversion header field could be used in the comma-separated 682 format as described below and in a header-separated format. Both 683 formats could be combined a received INVITE as recommended in 684 [RFC3261]. 686 Example: 688 Diversion: 689 ; reason=user-busy; counter=1; 690 privacy=full, 691 ; reason=unconditional; counter=1; 692 privacy=off 694 5. Diversion header to History-Info header 696 The following text is valid only if no History-Info is present in the 697 INVITE request. If at least one History-Info header field is 698 present, the interworking function must adapt its behavior to respect 699 the chronological order. For more information, see section 3. 701 Concerning the privacy information in the Diversion header field, the 702 following mapping only applies within a trusted domain, otherwise see 703 the privacy considerations in section 3.2. 705 For N Diversion entries N+1 History-Info entries must be created. To 706 create the History-Info entries in the same order than during a 707 session establishment, the Diversion entries must be mapped from the 708 bottom-most until the top-most. Each Diversion entry shall be mapped 709 into a History-Info entry. An additional History-Info entry (the 710 last one) must be created with the diverted-to party address present 711 in the Request-URI of the received INVITE. The mapping is described 712 in the table hereafter. 714 The first entry created in the History-Info header field contains: 716 - a hi-target-to-uri with the name-addr parameter of the bottom- 717 most Diversion header field, 719 - if a privacy parameter is present in the bottom-most Diversion 720 entry, then a Privacy header field must be escaped in the History- 721 Info header field as described in the table hereafter, 723 - a hi-index set to 1. 725 For each following Diversion entry (from bottom to top), the History- 726 info entries are created as following (from top to bottom): 728 Source Destination 729 Diversion header component: History-Info header component: 730 ======================================================================= 731 Name-addr Hi-target-to-uri 733 ======================================================================= 734 Reason of the previous Cause URI parameter 735 Diversion entry A cause-param "cause" is 736 added in each hi-entry 737 (except the first one) 738 "unknown"----------------------------------404 (default 'cause' value) 739 "unconditional"----------------------------302 740 "user-busy"--------------------------------486 741 "no-answer"--------------------------------408 742 "deflection "------------------------------480 or 487 743 "unavailable"------------------------------503 744 "time-of-day"------------------------------404 (default) 745 "do-not-disturb"---------------------------404 (default) 746 "follow-me"--------------------------------404 (default) 747 "out-of-service"---------------------------404 (default) 748 "away"-------------------------------------404 (default) 750 ====================================================================== 751 Counter Hi-index 752 "1" or parameter ------------------------The previous created index 753 no present is incremented with ".1" 754 Superior to "1" -------------------------Create N-1 placeholder History 755 (i.e. N) entry with the previous index 756 extended with ".1" 757 Then the History-Info header 758 created with the Diversion 759 entry with the previous index 760 extended with ".1" 761 ====================================================================== 762 Privacy Privacy header escaped in the 763 hi-targeted-to-uri 764 "full"-----------------------------------"history" 765 "Off"------------------------------------Privacy header field 766 absent or "none" 767 "name"-----------------------------------"history" 768 "uri"------------------------------------"history" 769 ====================================================================== 770 hi-target-param 771 A mp-param "mp" is added in 772 each created hi-entry 773 (except the first one) 774 The "mp" parameter is set to 775 the index value of the 776 preceding hi-entry. 777 ======================================================================= 779 A last History-Info entry is created and contains: 781 - a hi-target-to-uri with the Request-URI of the INVITE request, 783 - a cause-param from the top-most Diversion entry, mapped from the 784 diversion-reason as described above, 786 - an index set to the previous created index extended with a new 787 level ".1" added at the end, 789 - a hi-target-param set to "mp" equals to the index value of the 790 previous preceding hi-entry. 792 Notes: 794 1. For other optional Diversion parameters, there is no 795 recommendation as History-Info header field does not provide 796 equivalent parameters. 798 2. For values of the diversion-reason which are mapped with a 799 recommended default value, it could also be possible to choose 800 another value. The cause-param URI parameter offers less 801 possible values than the diversion-reason parameter. However, it 802 has been considered that cause-param values list was sufficient 803 to implement CDIV service as defined in 3GPP[TS_24.604] as it 804 cover a large portion of cases. 806 3. The Diversion header field can contain a "tel" URI as defined in 807 [RFC3966]in the name-addr parameter. The History-Info header 808 field can also contain an address that is a "tel" URI but if this 809 hi-entry has to be completed with either a SIP header field (eg. 810 Reason or Privacy) or a SIP URI parameter (eg. 'cause' or 811 'target'); the "tel" URI must be converted into a SIP URI. 812 [RFC3261] gives an indication as to the mapping between sip: and 813 tel: URIs but in this particular case it is difficult to assign a 814 valid hostport as the diversion has occurred in a previous 815 network and a valid hostport is difficult to determine. So, it 816 is suggested that in case of "tel" URI in the Diversion header 817 field, the History-Info header field should be created with a SIP 818 URI with user=phone and a domain set to "unknow.invalid". 820 4. The Diversion header field allows the carrying of a counter that 821 retains the information about the number of successive 822 redirections. History-Info does not have an equivalent because 823 to trace and count the number of diversion it is necessary to 824 count cause parameter containing a value associated to a call 825 diversion listed in[RFC4458]. Read the index value is not 826 enough. With the use of the "placeholder" entry the History-info 827 header field entries could reflect the real number of diversion 828 occurred still thanks to the cause-param. 830 Example of placeholder entry in the History-Info header field: 832 ;index=1.1 834 ;index=1.1.1;mp=1.1 836 "cause=xxx" reflects the diverting reason of a previous diverting 837 user. For a placeholder hi-entry the value "404" must be taken for 838 the cause-param and so, located in the next hi-entry. 840 Concerning local policies recommendations about header fields 841 coexistence in the INVITE request, see sections 3 and 7.5. 843 6. History-Info header to Diversion header 845 Concerning the privacy information for the History-Info header field, 846 the following mapping only applies within a trusted domain, otherwise 847 see the privacy considerations in section 3.2. 849 To create the Diversion entries in the same order than during a 850 session establishment, the History-Info entries must be mapped from 851 the top-most until the bottom-most. The first History-Info header 852 field entry selected will be mapped into the last Diversion header 853 field entry and so on. One Diversion header field entry must be 854 created for each History-Info entry having cause-param with a value 855 listed in [RFC4458]. 857 Diversion information: 859 The Target_entry and the Diverting_entry terms defined below are used 860 to ease the mapping understanding of the History-Info header field. 862 The diversion information can be identified by finding the following 863 hi-entries: 865 o Target_entry: hi-entries containing a cause-param URI parameter 866 with a value listed in [RFC4458]will contain the diversion reason 867 and the address of the target of the concerned call forwarding. 868 Following the [RFC7044]these hi-entries may also contain a hi- 869 target-param set to "mp". 871 o Diverting_entry: 872 For each previously identified hi-entry: 874 - If there is a "mp" header field parameter, the hi-entry whose 875 hi-index matches the value of the hi-target-param "mp" will 876 contain the diverting party address, its possible privacy and/ 877 or SIP reason when the retargeting has been caused by a 878 received SIP response. 880 - If there is no "mp" header field parameter, the information 881 of the diverting party address, privacy and/or SIP reason will 882 be found in the hi-entry that precede this identified hi-entry. 884 Note: Following [RFC7044], all retargeting entries must point to a 885 hi-entry that contain a "mp" parameter but for backward compatibility 886 reasons, it may be absent from some of the received hi-entries. You 887 can find more information on the backward compatibility aspects in 888 section 8. 890 The History-Info header field must be mapped into the Diversion 891 header field as following: 893 Source Destination 894 History-Info header component: Diversion header component: 895 ===================================================================== 896 Hi-target-to-uri Name-addr 897 of the Diverting_entry. 899 ===================================================================== 900 Cause-param Reason 901 of the Target_entry 902 404---------------------------------------"unknown" (default value) 903 302---------------------------------------"unconditional" 904 486---------------------------------------"user-busy" 905 408---------------------------------------"no-answer" 906 480 or 487--------------------------------"deflection " 907 503---------------------------------------"unavailable" 908 ===================================================================== 909 Hi-index Counter 910 Mandatory parameter for-------------------The counter is set to "1". 911 History-Info reflecting 912 the chronological order 913 of the information. 914 ===================================================================== 915 Privacy header field escaped Privacy 916 in the hi-targeted-to-uri 917 of the Diverting_entry 918 "history"----------------------------------"full" 919 Privacy header field ----------------------"Off" 920 Absent or "none" 921 ===================================================================== 923 Note: For other optional History-Info parameters, there is no 924 recommendation as Diversion header field does not provide equivalent 925 parameters. 927 Concerning local policies recommendations about header fields 928 coexistence in the INVITE request, see section 3. 930 7. Examples 932 7.1. Example with Diversion header changed into History-Info header 934 INVITE sip:last_diverting_target 935 Diversion: 936 ;reason=unconditional;counter=1; 937 privacy=off, 938 ;reason=user-busy;counter=1; 939 privacy=full, 940 ;reason=no-answer;counter=1; 941 privacy=off 943 Mapped into: 945 History-Info: 946 ; index=1, 947 ;index=1.1;mp=1, 949 ;index=1.1.1;mp=1.1, 951 ;index=1.1.1.1;mp=1.1.1 953 7.2. Example with History-Info header changed into Diversion header 955 INVITE sip:last_diverting_target; cause=486 956 History-Info: 957 ; index=1, 958 ;index=1.1;mp=1, 960 ;index=1.1.1;mp=1.1 962 Mapped into: 964 Diversion: 965 ; reason=user-busy; counter=1; 966 privacy=off, 967 ; reason=unconditional; counter=1; 968 privacy=full 970 7.3. Example with two SIP networks using History-Info header 971 interworking with a SIP network using Diversion header 973 A -> P1 -> B -> C -> P2 -> D-> E 974 A, B, C, D and E are users. 975 B, C and D have Call Forwarding service invoked. 976 P1 and P2 are proxies. 977 Only relevant information is shown on the following call flow. 979 IWF* IWF* 980 SIP network using | SIP network using |SIP net. 981 History-Info | Diversion |using 982 | Hist-Info 983 | | 984 UA A P1 AS B | P2 AS C UA C AS D | UA E 985 | | | | | | | | | | 986 |INV B | | | | | | | | | 987 |------>| | | | | | | | | 988 | | | | | | | | | | 989 | |INV B | | | | | | | | 990 | |------>| | | | | | | | 991 | |Supported: histinfo | | | | | | 992 | | History-Info: | | | | | | 993 | | ; index=1, | | | | | 994 | | ; index=1.1; rc=1 | | | | | 995 | | | | | | | | | | 996 | | |INV C | | | | | | | 997 | | |------>| | | | | | | 998 | | |History-Info: | | | | | | 999 | | ; index=1,| | | | | 1000 | | ; index=1.1; rc=1, | | | | 1001 | | ; index=1.1.1; mp=1.1 | 1002 | | | | | | | | | | 1003 | | | |INV C | | | | | | 1004 | | | |----->| | | | | | 1005 | | | Diversion: | | | | | | 1006 | | | userB; reason=unconditional; counter=1; privacy=off 1007 | | | |History-Info: | | | | | 1008 | | | ; index=1,| | | | 1009 | | | ; index=1.1; rc=1,| | | 1010 | | | ; index=1.1.1; mp=1.1 1011 | | | | | | | | | | 1012 | | | | |INV C | | | | | 1013 | | | | |------>| | | | | 1014 | | | | No modification of Diversion header | 1015 | | | | | | | | | | 1016 | | | | | |INV C | | | | 1017 | | | | | |------>| | | | 1018 | | | | | | | | | | 1019 | | | | | |<--180-| | | | 1020 | | | | | | | | | | 1021 | | | | | No response timer expires | | 1022 | | | | | |---INV D --->| | | 1023 | | |Diversion: | | | 1024 | | |userC; reason=no-answer; counter=1; privacy=full, | 1025 | | |userB; reason=unconditional; counter=1; privacy=off, 1026 | | | History-Info: | | | 1027 | | | ; index=1, | | | 1028 | | | ; index=1.1; rc=1, | | | 1029 | | | ; index=1.1.1; mp=1.1 | 1030 | | | | | | | | | | 1031 | | | | | | | |INV E | | 1032 | | | | | | | |----->| | 1033 | | |Diversion: | | 1034 | | |userD; reason=time-of-day; counter=1; privacy=off | 1035 | | |userC; reason=no-answer; counter=1; privacy=full, | 1036 | | |userB; reason=unconditional; counter=1; privacy=off, 1037 | | | History-Info: | | 1038 | | | ; index=1, | | 1039 | | | ; index=1.1; rc=1, | | 1040 | | | ; index=1.1.1; mp=1.1 | 1041 | | | | | | | | | | 1042 | | | | | | | | | INV E | 1043 | | | | | | | | |------>| 1044 | | History-Info: | | | | | | 1045 | | ; index=1, | | | | | 1046 | | ; index=1.1; rc=1, | | | | 1047 | | ; index=1.1.1; mp=1.1, | | 1048 | | ; index=1.1.1.0.1, | | 1049 |;index=1.1.1.0.1.1; mp=1.1.1.0.1,| 1050 | |; index=1.1.1.0.1.1.1; mp=1.1.1.0.1.1| 1051 | | | | | | | | | | 1052 | | | | | | | | | | 1054 * Note: The IWF is an interworking function which could be a stand- 1055 alone equipment not defined in this document (it could be a proxy). 1057 7.4. Additional interworking Cases 1059 Even if for particular cases in which both header fields could 1060 coexist, it should be the network local policy responsibility to make 1061 it work together. Here are described some situations and some 1062 recommendations on the behavior to follow. 1064 In the case where there is one network which includes different 1065 nodes, some of them supporting Diversion header field and other ones 1066 supporting History-info header field, there is a problem when any 1067 node handling a message does not know the next node that will handle 1068 the message. This case can occur when the network has new and old 1069 nodes, the older ones using Diversion header field and the more 1070 recent History-Info header field. 1072 While a network replacement may be occurring there will be a time 1073 when both nodes coexist in the network. If the different nodes are 1074 being used to support different subscriber types due to different 1075 node capabilities then the problem is more important. In this case 1076 there is a need to pass both History-Info header field and Diversion 1077 header field within the core network. 1079 These header fields need to be equivalent to ensure that, whatever 1080 the node receiving the message, the correct diversion information is 1081 received. This requires that whatever the received header field, 1082 there is a requirement to be able to compare the header fields and to 1083 convert the header fields. Depending upon the node capability, it 1084 may be possible to make assumptions as to how this is handled. 1086 o If it is known that the older Diversion header field supporting 1087 nodes do not pass on any received History-Info header field then 1088 the interworking becomes easier. If a message is received with 1089 only Diversion header fields then it has originated from an 'old' 1090 node. The equivalent History-Info entries can be created and 1091 these can then be passed as well as the Diversion header field. 1093 o If the node creates a new History-Info header field for a call 1094 diversion, then an additional Diversion header field must be 1095 created. 1097 o If the next node is an 'old' node then the Diversion header field 1098 will be used by that node and the History-Info entries will be 1099 removed from the message when it is passed on. 1101 o If the next node is a new node then the presence of both Diversion 1102 header field and History-Info header field means that interworking 1103 has already occurred and the Diversion and History-Info entries 1104 must be considered equivalent. 1106 o If both nodes pass on both History-Info header field and Diversion 1107 header field but only actively use one, then both types of node 1108 need to perform the interworking and must maintain equivalence 1109 between the header fields. This will eventually result in the use 1110 of Diversion header field being deprecated when all nodes in the 1111 network support History-Info header field. 1113 o If a gap is identified in the History-Info header field by a node 1114 that would create a new entry, it shall add a single index with a 1115 value of "0" prior to adding the appropriate index for the action 1116 to be taken. 1118 8. Backward Compatibility 1120 The backward compatibility aspects are due to the changes on the 1121 History-Info header field evolution from [RFC4244] to [RFC7044]that 1122 are described in section 1.3 of this document. The backawrd 1123 compatibility is taken into account throughout this document for the 1124 interworking with the Diversion header field. More details are 1125 provided in the backward compatibility section of [RFC7044]. 1127 9. IANA Considerations 1129 This document makes no request of IANA. 1131 10. Security Considerations 1133 The security considerations in [RFC7044] and [RFC5806] apply. 1135 The privacy considerations described in section 3.2 apply. 1137 The use of Diversion header field or History-Info header field 1138 require to apply the requested privacy and integrity asked by each 1139 diverting user or entity. Without integrity, the requested privacy 1140 functions could be downgraded or eliminated, potentially exposing 1141 identity information. Without confidentiality, eavesdroppers on the 1142 network (or any intermediaries between the user and the privacy 1143 service) could see the very personal information that the user has 1144 asked the privacy service to obscure. Unauthorised insertion, 1145 deletion of modification of those header fields can provide 1146 misleading information to users and applications. A SIP entity that 1147 can provide a redirection reason in a History-Info header field or 1148 Diversion header field should be able to suppress this in accordance 1149 with privacy requirements of the user concerned. 1151 11. Acknowlegements 1153 The editor would like to acknowledge the constructive feedback and 1154 support provided by Steve Norreys, Jan Van Geel, Martin Dolly, 1155 Francisco Silva, Guiseppe Sciortino, Cinza Amenta, Christer Holmberg, 1156 Ian Elz, Jean-Francois Mule, Mary Barnes, Francois Audet, Erick 1157 Sasaki, Shida Schubert, Joel M. Halpern, Bob Braden and Robert 1158 Sparks. Merci a Lionel Morand, Xavier Marjou et Philippe Fouquart. 1160 12. References 1161 12.1. Normative References 1163 [RFC3261] "SIP: Session Initiation Protocol", RFC 3261, June 2002. 1165 [RFC3323] "A Privacy Mechanism for the Session Initiation Protocol 1166 (SIP)", RFC 3323, November 2002. 1168 [RFC3326] "The Reason Header Field for the Session Initiation 1169 Protocol (SIP)", RFC 3326, December 2002. 1171 [RFC3966] "The tel URI for Telephone Numbers", RFC 3966, December 1172 2004. 1174 [RFC4244] "An Extension to the Session Initiation Protocol (SIP) for 1175 Request History Information", RFC 4244, November 2005. 1177 [RFC5806] "Diversion Indication in SIP", March 2010. 1179 [RFC7044] "An Extension to the Session Initiation Protocol (SIP) for 1180 Request History Information", RFC 7044, February 2014. 1182 12.2. Informative References 1184 [RFC4458] "Session Initiation Protocol (SIP) URIs for Applications 1185 such as Voicemail and Interactive Voice Response (IVR)", 1186 RFC 4458, April 2006. 1188 [RFC5234] "Augmented BNF for Syntax Specifications: ABNF", RFC 5234, 1189 January 2008. 1191 [RFC6044] "Mapping and Interworking of Diversion Information between 1192 Diversion and History-Info Headers in the Session 1193 Initiation Protocol (SIP)", RFC 6044, October 2010. 1195 [TS_24.604] 1196 3rd Generation Partnership Project, "Technical 1197 Specification Group Core Network and Terminals ; 1198 Communication Diversion (CDIV) using IP Multimedia 1199 (IM)Core Network (CN) subsystem ; Protocol specification 1200 (Release 8), 3GPP TS 24.604", December 2008. 1202 [TS_29.163] 1203 3rd Generation Partnership Project, "Technical 1204 Specification Group Core Network and Terminals ; 1205 Interworking between the IP Multimedia (IM) Core Network 1206 (CN) Subsystem and Circuit Switched (CS) networks (Release 1207 8)", December 2008. 1209 Appendix A. Interworking between Diversion header and Voicemail URI 1211 Voicemail URI is a mechanism described in [RFC4458] to provide a 1212 simple way to transport only one redirecting user address and the 1213 reason why the diversion occurred in the Request-URI of the INVITE 1214 request. This mechanism is mainly used for call diversion to a 1215 voicemail. 1217 A.1. Diversion header field to Voicemail URI 1219 Received: 1220 Diversion: userA-address;reason=user-busy;counter=1;privacy=full 1222 Sent (Voicemail URI created in the R-URI line of the INVITE): 1223 sip: voicemail@example.com;target=userA-address;cause=486 SIP/2.0 1225 Mapping of the Redirection Reason is the same as for History-Info 1226 header field with a default value set to 404. 1227 If the Diversion header field contains more than one Diversion entry, 1228 the choice of the redirecting user information inserted in the URI is 1229 in charge of the network local policy. For example, the choice 1230 criterion of the redirecting information inserted in the URI could be 1231 the destination of forwarded INVITE request (if the voicemail serves 1232 this user or not). 1234 Note: This interworking could be done in addition to the interworking 1235 of the Diversion header field into the History-Info header field. 1237 A.2. Voicemail URI to Diversion header field 1239 In case of real Voicemail, this way of interworking should not 1240 happen. However, if for any reason it occurs, it is recommended to 1241 do it as following: 1243 Received: 1244 INVITE sip: voicemail@example.com;\ 1245 target=sip:+33145454500%40example.com;user=phone;\ 1246 cause=302 SIP/2.0 1248 Sent in the forwarded INVITE: 1249 Diversion: sip:+33145454500%40example.com;user=phone; 1250 reason=unconditional;counter=1 1252 Author's Address 1254 Marianne Mohali 1255 Orange 1256 38-40 rue du General Leclerc 1257 Issy-Les-Moulineaux Cedex 9 92794 1258 France 1260 Phone: +33 1 45 29 45 14 1261 Email: marianne.mohali@orange.com