idnits 2.17.1 draft-mohali-rfc6044bis-00.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. ** 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 490: '... an hi-entry MUST add a single index...' RFC 2119 keyword, line 494: '...s the hi-entries MUST evaluate the hi-...' -- The abstract seems to indicate that this document obsoletes RFC5806, 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. -- The abstract seems to indicate that this document obsoletes RFC4244, 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 (February 14, 2014) is 3723 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** 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 (~~), 1 warning (==), 5 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) February 14, 2014 5 Intended status: Informational 6 Expires: August 18, 2014 8 Mapping and interworking of Diversion information Between Diversion and 9 History-Info Headers in the Session Initiation Protocol (SIP) 10 draft-mohali-rfc6044bis-00 12 Abstract 14 [This version of the document is a draft version for an RFC6044bis 15 that will describe the mapping between the Diversion header defined 16 in RFC5806 and the new History-Info header defined in RFC7044.] 17 Although the SIP History-Info header is the solution adopted in IETF, 18 the non-standard Diversion header is nevertheless already implemented 19 and used for conveying call diversion related information in the 20 Session Initiation Protocol (SIP) signaling. 21 This document describes a recommended interworking guideline between 22 the Diversion header and the History-Info header to handle call 23 diversion information. In addition, an interworking policy is 24 proposed to manage the headers' coexistence. The non-standard 25 Diversion header is described, as Historic, in [RFC5806]. The 26 History-Info header is described in [RFC7044] that obsoletes 27 [RFC4244] initially describing the History-Info header. [RFC7044] 28 defines an optional SIP header field, History-Info, for capturing the 29 history information in requests and SIP header field parameters for 30 the History-Info and Contact header fields to tag the method by which 31 the target of a request is determined. RFC7044 also defines a value 32 for the Privacy header field that directs the anonymization of values 33 in the History-Info header field. 35 Since the Diversion header is used in existing network 36 implementations for the transport of call diversion information, its 37 interworking with the SIP History-Info standardized solution is 38 needed. This work is intended to enable the migration from non- 39 standard implementations and deployment toward IETF specification- 40 based implementations and deployment. 41 This document obsoletes [RFC6044]. 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 August 18, 2014. 60 Copyright Notice 62 Copyright (c) 2014 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 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 78 2.1. Interworking requirements and scope . . . . . . . . . . . 4 79 2.2. Interworking recommendations . . . . . . . . . . . . . . 6 80 2.2.1. SIP network/terminal using Diversion to SIP 81 network/terminal using History-Info header . . . . . 7 82 2.2.2. SIP network/terminal using History-Info header to SIP 83 network/terminal using Diversion header . . . . . . . 9 84 3. Headers syntaxes reminder . . . . . . . . . . . . . . . . . . 10 85 3.1. History-Info header syntax . . . . . . . . . . . . . . . 10 86 3.2. Diversion header syntax . . . . . . . . . . . . . . . . . 12 87 4. Headers in SIP Method . . . . . . . . . . . . . . . . . . . . 13 88 5. Diversion header to History-Info header . . . . . . . . . . . 13 89 6. History-Info header to Diversion header . . . . . . . . . . . 17 90 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 19 91 7.1. Example with Diversion header changed into History-Info 92 header . . . . . . . . . . . . . . . . . . . . . . . . . 19 93 7.2. Example with History-Info header changed into Diversion 94 header . . . . . . . . . . . . . . . . . . . . . . . . . 19 95 7.3. Example with two SIP networks using History-Info header 96 interworking with a SIP network using Diversion header . 19 97 7.4. Additional interworking Cases . . . . . . . . . . . . . . 21 98 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 99 9. Security Considerations . . . . . . . . . . . . . . . . . . . 22 100 10. Acknowlegements . . . . . . . . . . . . . . . . . . . . . . . 23 101 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 102 11.1. Normative References . . . . . . . . . . . . . . . . . . 23 103 11.2. Informative References . . . . . . . . . . . . . . . . . 23 104 Appendix A. Interworking between Diversion header and Voicemail 105 URI . . . . . . . . . . . . . . . . . . . . . . . . 24 106 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 25 108 1. Introduction 110 [This version of the document is a draft version for RFC6044bis that 111 will describe the mapping between the Diversion header defined in 112 RFC5806 and the new History-Info header defined in RFC7044.] 114 1.1. Overview 116 For some VoIP-based services (eg. Voicemail, Interactive Voice 117 Recognition (IVR) or automatic call distribution), it is helpful for 118 the called SIP user agent to identify from whom and why the session 119 was diverted. For this information to be used in various service 120 providers or by applications, it needs to pass through the network. 121 This is possible with two different SIP headers: History-Info header 122 defined in [RFC7044] and the historic Diversion header defined in 123 [RFC5806] which are both able to transport diversion information in 124 SIP signaling. 125 Although the Diversion header is not standardized, it is widely used. 126 Therefore, it is useful to have guidelines to make this header 127 interwork with the standard History-Info header. 128 Note that the new implementation and deployment of the Diversion 129 header is strongly discouraged. 131 This document provides a mechanism for header content translation 132 between the Diversion header and the History-Info header. 134 1.2. Background 136 The History-Info header [RFC7044] and its extension for forming SIP 137 service URIs (including Voicemail URI) [RFC4458] are recommended by 138 IETF to convey redirection information. They are also recommended in 139 the "Communication Diversion (CDIV) service" 3GPP specification 140 [TS_24.604]. 142 Originally, the Diversion header was described in an Internet Draft 143 that was submitted to the SIP Working Group. It has been published 144 now as [RFC5806] for the historical record and to provide a reference 145 for this RFC. 147 This header contains a list of diverting URIs and associated 148 information providing specific information as the reason for the call 149 diversion. Most of existing SIP-based implementations have 150 implemented the Diversion header when no standard solution was ready 151 to deploy. The IETF has finally standardized the History-Info header 152 partly because it can transport general history information. This 153 allows the receiving part to determine how and why the session is 154 received. As the History-Info header may contain further information 155 than call diversion information, it is critical to avoid losing 156 information and be able to extract the relevant data using the 157 retargeting cause URI parameter described in [RFC4458] for the 158 transport of the diversion reason. 160 The Diversion header and the History-Info header have different 161 syntaxes described below. Note that the main difference is that the 162 History-Info header is a chronological writing header whereas the 163 Diversion header applies a reverse chronology (i.e. the first 164 diversion entry read corresponds to the last diverting user). 166 The Appendix A provides an interworking guideline between the 167 Diversion header and the Voicemail URI which is another way to convey 168 diversion information. The Voicemail URI is defined in [RFC4458]. 170 2. Problem Statement 172 2.1. Interworking requirements and scope 174 This section provides the baseline terminology used in the rest of 175 the document and defines the scope of interworking between the 176 Diversion header and the History-Info header. 178 They are many ways in which SIP signaling can be used to modify a 179 session destination before it is established and many reasons for 180 doing so. The behavior of the SIP entities that will have to further 181 process the session downstream will sometimes vary depending on the 182 reasons that lead to changing the destination. For example, whether 183 it is for a simple proxy to route the session or for an application 184 server to provide a supplementary service. The Diversion header and 185 the History-Info header differ in the approach and scope of 186 addressing this problem. 188 For clarity, the following vocabulary is used in this document: 190 o Retargeting/redirecting: retargeting/redirecting refer to the 191 process of a Proxy Server/User Agent Client (UAC) changing a 192 Uniform Resource Identifier (URI) in a request and thus changing 193 the target of the request. These terms are defined in [RFC7044]. 194 The History-Info header is used to capture retargeting 195 information. 197 o Call forwarding/call diversion/communication diversion: these 198 terms are equivalent and refer to the Communications Diversion 199 (CDIV) supplementary services, based on the ISDN Communication 200 diversion supplementary services and defined in 3GPP [TS_24.604]. 201 They are applicable to entities which are intended to modify the 202 original destination of an IP multimedia session during or prior 203 to the session establishment. 205 This document does not intend to describe when or how History-Info or 206 Diversion headers should be used. Hereafter is provided 207 clarification on the context in which the interworking is required. 209 The Diversion header has exactly the same scope as the call diversion 210 service and each header entry reflects a call diversion invocation. 211 The Diversion header is used for recording call forwarding 212 information which could be useful to network entities downstream. 213 Today, this SIP header is implemented by several manufacturers and 214 deployed in networks. 216 The History-Info header is used to store all retargeting information 217 including call diversion information. In practice, the History-Info 218 header [RFC7044] is used to convey call diversion related information 219 by using a cause URI parameter [RFC4458] in the relevant entry. 220 Note, however, that the use of cause URI parameter [RFC4458] in a 221 History-Info entry for a call diversion is specific to the 3GPP 222 specification [TS_24.604]. [RFC4458] focuses on retargeting toward 223 voicemail server and does not specify whether the cause URI parameter 224 should be added in a URI for other cases. As a consequence, 225 implementations that do not use the cause URI parameter for call 226 forwarding information, are not considered for the mapping described 227 in this document. Nevertheless, some recommendations are given in 228 the next sections on how to avoid the loss of non-mapped information 229 at the boundary between a network region using History-Info header 230 and one using the Diversion header. 232 The RFC7044 defines three header field parameters, "rc", "mp", and 233 "np". The header field parameters "rc" and "mp" indicate the 234 mechanism by which a new target for a request is determined. The 235 header field "np" reflects that the target has not changed. All 236 parameters contain an index whose value is the hi-index of the hi- 237 entry with an hi-targeted-to-uri that represents the Request-URI that 238 was retargeted. 240 Since both headers address call forwarding needs, diverting 241 information could be mixed-up or be inconsistent if both are present 242 in an uncoordinated fashion in the INVITE request. So, Diversion and 243 History-Info headers must not independently coexist in the same 244 session signaling. This document addresses how to convert 245 information between the Diversion header and the History-Info header, 246 and when and how to preserve both headers to cover additional cases. 248 For the transportation of consistent diversion information 249 downstream, it is necessary to make the two headers interwork. 250 Interworking between the Diversion header and the History-Info header 251 is introduced in sections 5 and 6. Since coexistence scenario may 252 vary from one use case to another one, guidelines regarding headers 253 interaction are proposed. 255 2.2. Interworking recommendations 257 Interworking function: 259 In a normal case, the network topology assumption is that the 260 interworking described in this document should be performed by a 261 specific SIP border device which is aware, by configuration, that 262 it is at the border between two regions, one using History-Info 263 header and one using Diversion header. 265 As History-Info header is a standard solution, a network using the 266 Diversion header must be able to provide information to a network 267 using the History-Info header. In this case, to avoid headers 268 coexistence it is required to replace, as often as possible, the 269 Diversion header with the History-Info header in the INVITE request 270 during the interworking. 272 Since, the History-Info header has a wider scope than the Diversion 273 header, it may be used for other needs and services than call 274 diversion. In addition to trace call diversion information, History- 275 Info header also acts as a session history and can store all 276 successive R-URI values. Consequently, even if it should be better 277 to remove the History-Info header after the creation of the Diversion 278 header avoiding confusion, the History-Info header must remain 279 unmodified in the SIP signaling if it contains supplementary (non- 280 diversion) information. It is possible to have History-Info headers 281 that do not have values that can be mapped into the Diversion header. 282 In this case, no interworking with Diversion header should be 283 performed and it must be defined per implementation what to do in 284 this case. This point is left out of the scope of this document. 286 As a conclusion, it is recommended to have local policies minimizing 287 the loss of information and find the best way to keep it up to the 288 terminating user agent. 290 The following sections describe the basic common use case. 291 Additional interworking cases are described in section 7.5. 293 2.2.1. SIP network/terminal using Diversion to SIP network/terminal 294 using History-Info header 296 When the Diversion header is used to create a History-Info header, 297 the Diversion header must be removed in the outgoing INVITE. It is 298 considered that all the information present in the Diversion header 299 is transferred in the History-Info header. 301 If a History-Info header is present in the incoming INVITE (in 302 addition to Diversion header), the Diversion header and History-Info 303 header present must be mixed and only the diversion information not 304 yet present in the History-Info header must be inserted as a last 305 entry (more recent) in the existing History-Info header, as 306 recommended in [RFC7044]. 308 As an example, this could be the case of an INVITE coming from 309 network_2 using Diversion header but previously passed through 310 network_1 using History-Info header (or the network_2 uses History- 311 Info header to transport successive URI information) and going to 312 network_3 using History-Info header. 314 IWF* IWF* 315 network1 | network_2 |network_3 316 History-Info | Diversion |using 317 | |Hist-Info 318 | | 319 UA A P1 AS B | P2 AS C UA C AS D | UA E 320 | | | | | | | | | | 321 |INVITE | | | | | | | | | 322 |------>| | | | | | | | | 323 | | | | | | | | | | 324 | |INVITE | | | | | | | | 325 | |------>| | | | | | | | 326 | |Supported: histinfo | | | | | | 327 | | History-Info: | | | | | | 328 | | ; index=1, | | | | | 329 | | ; index=1.1;rc=1 | | | | | 330 | | | | | | | | | | 331 | | |INVITE | | | | | | | 332 | | |------>| | | | | | | 333 | | |History-Info: | | | | | | 334 | | |; index=1,| | | | | 335 | | |; index=1.1;rc=1, | | | | 336 | | |; cause=302; index=1.1.1;mp=1.1 | | 338 In this case, the incoming INVITE contains a Diversion header and a 339 History-Info header. Therefore, as recommended in this document, it 340 is necessary to create for network_3, a single History-Info header 341 gathering existing information from both the History-Info and the 342 Diversion headers received. Anyway, it is required from network_2 343 (ie.IWF) to remove the Diversion header when the message is going to 344 a network not using the Diversion header. Then network_3 could use 345 call forwarding information that is present in a single header and 346 add its own diversion information if necessary. 348 Notes: 350 1. If a network is not able either to use only one header each time, 351 or to maintain both headers up to date, the chronological order 352 can not be certified. 354 2. It is not possible to have only Diversion header when the 355 History-Info header contains more than call diversion 356 information. If previous policy recommendations are applied, the 357 chronological order is respected as Diversion entries are 358 inserted at the end of the History-Info header taking into 359 account the Diversion internal chronology. 361 2.2.2. SIP network/terminal using History-Info header to SIP network/ 362 terminal using Diversion header 364 When the History-Info header is interpreted to create a Diversion 365 header, some precautions must be taken. 366 If the History-Info header contains only call forwarding information, 367 then it must be deleted after the interworking. 368 If the History-Info header contains other information, then only the 369 information of concern to the diverting user must be used to create 370 entries in the Diversion header and the History-Info header must be 371 kept as received in the INVITE and forwarded downstream. 373 Note: The History-Info header could be used for other reasons than 374 call diversion services, for example by a service which need to know 375 if a specific AS had yet been invoked in the signaling path. If the 376 call is later forwarded to a network using History-Info header, it 377 would be better to not lose history information due to passing though 378 the network which only support Diversion header. A recommended 379 solution must not disrupt the standard behavior and networks which do 380 not implement the History-Info header must be transparent to a 381 received History-Info header. 383 If a Diversion header is present in the incoming INVITE (in addition 384 to History-Info header), only diversion information present in the 385 History-Info header but not in the Diversion header must be inserted 386 from the last entry (more recent) into the existing Diversion header 387 as recommended in the [RFC5806]. 389 Note that the chronological order could not be certified. If 390 previous policy recommendations are respected, this case should not 391 happen. 393 Forking case: 395 The History-Info header enables the recording of sequential 396 forking for the same served-user. During an interworking, from 397 the History-Info header to Diversion header, the History-Info 398 entries containing a forking situation (with an incremented 399 "index" parameter) could possibly be mapped if it contains a call 400 forwarding "cause" parameter. The interworking entity could 401 choose to create only a Diversion entry or not apply the 402 interworking. The choice could be done according a local policy. 404 The same logic is applied for an interworking with Voicemail URI (see 405 the Appendix). 407 3. Headers syntaxes reminder 409 3.1. History-Info header syntax 411 The ABNF syntax [RFC5234] for the History-Info header field and 412 header field parameters is as follows: 414 History-Info = "History-Info" HCOLON hi-entry *(COMMA hi-entry) 416 hi-entry = hi-targeted-to-uri *(SEMI hi-param) 417 hi-targeted-to-uri = name-addr 418 hi-param = hi-index/hi-target-param/hi-extension 419 hi-index = "index" EQUAL index-val 420 index-val = number *("." number) 421 number = [ %x31-39 *DIGIT ] DIGIT 422 hi-target-param = rc-param / mp-param / np-param 423 rc-param = "rc" EQUAL index-val 424 mp-param = "mp" EQUAL index-val 425 np-param = "np" EQUAL index-val 426 hi-extension = generic-param 428 The ABNF definitions for "generic-param", "name-addr", "HCOLON", 429 "COMMA", "SEMI", and "EQUAL" are from[RFC3261]. 431 The History-Info header is specified in [RFC7044]. 432 The top-most History-Info entry (first in the list) corresponds to 433 the oldest history information. 435 The hi-entries representing diverting users can be identified by 436 finding the hi-entries referenced by the indexes of the hi-entries 437 tagged with an "mp" header field parameter. 439 A hi-entry may contain a cause URI parameter expressing the diversion 440 reason. This optional cause URI parameter is defined in [RFC4458] 441 with the following syntax: 443 cause-param = "cause" EQUAL Status-Code 445 This parameter is also named cause-param and should be inserted in 446 the History-Info entry (URI) of the diverted-to user in case of call 447 diversion as recommended in the 3GPP CDIV specification [TS_24.604]. 448 The cause values used in the cause-param for the diverting reason are 449 listed in the RFC and because it is a parameter dedicated to call 450 forwarding service, its presence is used to determine that a hi-entry 451 is a diverting user. More precisely, each diverting user is located 452 in the hi-entry before the one containing a cause-param with cause 453 value as listed in RFC 4458. 454 Moreover, the Reason header defined in [RFC3326] should be escaped in 455 the hi-entry of the diverting user when the call diversion is due to 456 a received SIP response. The Reason header contains a cause 457 parameter set to the true SIP response code received (Status-Code). 458 Therefore, in case of call diversion due to a SIP response, both 459 cause parameters should be used. The complexity is that these 460 parameters could be used at the same time in the History-Info header 461 but not in the same hi-entry and not with the same meaning. Only the 462 cause-param is dedicated to call diversion service. The 'cause' 463 Reason header parameter is not taken into account in the mapping with 464 a Diversion header. 466 The [RFC4458] also defines the 'target' URI parameter which could be 467 inserted in a R-URI and consequently in the hi-targeted-to-uri. This 468 parameter is used to keep the diverting user address in the 469 downstream INVITE request in Voicemail URI implementation. As this 470 information is already present in the hi-entries, the 'target' URI 471 parameter is not taken into account regarding the interworking with 472 the Diversion header. From the Diversion header, it could be 473 possible to create the 'target' URI parameter in the hi-entries and/ 474 or in the R-URI but this possibility is based on local policies not 475 described in this document. 477 A Privacy header as defined in [RFC3323] could also be included in 478 hi-entries with the 'history' value defined in the [RFC7044]. 480 The index parameter is a string of digits, separated by dots to 481 indicate the number of forward hops and retargets. 483 Note: A history entry could contain the "gr" parameter. Regardless 484 the rules concerning "gr" parameter defined in [TS_24.604] which must 485 be applied, this parameter has no impact on the mapping and must only 486 be copied with the served user address. 488 Missing entry: If the request clearly has a gap in the hi-entry 489 (i.e., the last hi-entry and Request-URI differ), the entity adding 490 an hi-entry MUST add a single index with a value of "0" (i.e., the 491 nonnegative integer zero) prior to adding the appropriate index for 492 the action to be taken (eg. Index=1.1.2.0.1). Prior to any 493 application usage of the History-Info header field parameters, the 494 SIP entity that processes the hi-entries MUST evaluate the hi-entries 495 and determine if there are any gaps in the hi-entries. 497 Example: 499 History-Info: 500 ;index=1, 502 ;index=1.1;mp=1, 503 ; index=1.1.1;mp=1.1 505 Policy concerning "histinfo" option tag in Supported header: 506 According to [RFC7044], a proxy that receives a Request with the 507 "histinfo" option tag in the Supported header should return captured 508 History-Info in subsequent, provisional and final responses to the 509 Request. The behavior depends upon whether the local policy supports 510 the capture of History-Info or not. 512 3.2. Diversion header syntax 514 The following text is restating the exact syntax that the production 515 rules in [RFC5806] define, but using [RFC5234] ABNF: 517 Diversion = "Diversion" HCOLON diversion-params 518 *(COMMA diversion-params) 520 diversion-params = name-addr *(SEMI (diversion-reason / 521 diversion-counter / diversion-limit / 522 diversion-privacy / diversion-screen / 523 diversion-extension)) 524 diversion-reason = "reason" EQUAL ("unknown" / "user-busy" / 525 "no-answer" / "unavailable" / "unconditional" 526 / "time-of-day" / "do-not-disturb" / 527 "deflection" / "follow-me" / "out-of-service" 528 / "away" / token / quoted-string) 529 diversion-counter = "counter" EQUAL 1*2DIGIT 530 diversion-limit = "limit" EQUAL 1*2DIGIT 531 diversion-privacy = "privacy" EQUAL ("full" / "name" / "uri" / 532 "off" / token / quoted-string) 533 diversion-screen = "screen" EQUAL ("yes" / "no" / token / 534 quoted-string) 535 diversion-extension = token [EQUAL (token / quoted-string)] 537 Note: The Diversion header could be used in the comma-separated 538 format as described below and in a header-separated format. Both 539 formats could be combined a received INVITE as recommended in 540 [RFC3261]. 542 Example: 544 Diversion: 546 ; reason=user-busy; counter=1; 547 privacy=full, 548 ; reason=unconditional; counter=1; 549 privacy=off 551 4. Headers in SIP Method 553 The recommended interworking presented in this document should apply 554 only for INVITE requests. 556 In 3xx responses, both headers could be present. 557 When a proxy wants to interwork with a network supporting the other 558 header field, it should apply the interworking between Diversion 559 header and History-Info header in the 3xx response. 560 When a recursing proxy redirects an initial INVITE after receiving a 561 3xx response, it should add as a last entry either a Diversion header 562 or History-Info header (according to its capabilities) in the 563 forwarded INVITE. Local policies could apply to send the received 564 header in the next INVITE or not. 566 Other messages where History-Info could be present are not used for 567 the Call Forwarding service and should not be changed into Diversion 568 header. The destination network must be transparent to the received 569 History-Info header. 571 Note : the following mapping is inspired from the ISUP to SIP 572 interworking described in [TS_29.163]. 574 5. Diversion header to History-Info header 576 The following text is valid only if no History-Info is present in the 577 INVITE request. If at least one History-Info header is present, the 578 interworking function must adapt its behavior to respect the 579 chronological order. See section 2.2. 580 For N Diversion entries N+1 History-Info entries must be created. To 581 create the History-Info entries in the same order than during a 582 session establishment, the Diversion entries must be mapped from the 583 bottom-most until the top-most. Each Diversion entry shall be mapped 584 into a History-Info entry. An additional History-Info entry (the 585 last one) must be created with the diverted-to party address present 586 in the R-URI of the received INVITE. The mapping is described below. 588 The first entry created in the History-Info header contains: 590 - a hi-target-to-uri with the name-addr parameter of the bottom- 591 most Diversion header 593 - if a privacy parameter is present in the bottom-most Diversion 594 entry, then a Privacy header could be escaped in the History-Info 595 header as described below, 597 - an index set to 1. 599 For each following Diversion entry (from bottom to top), the History- 600 info entries are created as following (from top to bottom): 602 Source Destination 603 Diversion header component: History-Info header component: 604 ======================================================================= 605 Name-addr Hi-target-to-uri 607 ======================================================================= 608 Reason of the previous cause-param (not present in 609 Diversion entry the first created hi-entry) 610 "unknown"---------------------------------404 (default 'cause' value) 611 "unconditional"---------------------------302 612 "user-busy"-------------------------------486 613 "no-answer"-------------------------------408 614 "deflection "-----------------------------480 or 487 615 "unavailable"-----------------------------503 616 "time-of-day"-----------------------------404 (default) 617 "do-not-disturb"--------------------------404 (default) 618 "follow-me"-------------------------------404 (default) 619 "out-of-service"--------------------------404 (default) 620 "away"------------------------------------404 (default) 622 ======================================================================= 623 Counter Hi-index 624 "1" or parameter -------------------------The previous created index 625 no present is incremented with ".1" 626 Superior to "1" --------------------------Create N-1 placeholder History 627 (i.e. N) entry with the previous index 628 incremented with ".1" 629 Then the History-Info header 630 created with the Diversion 631 entry with the previous index 632 incremented with ".1" 633 ======================================================================= 634 Privacy Privacy header escaped in the 635 hi-targeted-to-uri 636 "full"------------------------------------"history" 637 "Off"-------------------------------------Privacy header field 638 absent or "none" 639 "name"------------------------------------"history" 640 "uri"-------------------------------------"history" 641 ======================================================================= 643 A last History-Info entry is created and contains: 645 - a hi-target-to-uri with the Request-URI of the INVITE request. 647 - a cause-param from the top-most Diversion entry, mapped from the 648 diversion-reason as described above. 650 - if a privacy parameter is present in the top-most Diversion 651 entry, then a Privacy header could be escaped in the History-Info 652 header as described above, 654 - an index set to the previous created index and incremented with 655 ".1" 657 Each hi-entry created except the first one must contain a "mp" 658 parameter set to the index value of the previous hi-entry. 660 Notes: 662 1. For other optional Diversion parameters, there is no 663 recommendation as History-Info header does not provide equivalent 664 parameters. 666 2. For values of the diversion-reason values which are mapped with a 667 recommended default value, it could also be possible to choose 668 another value. The cause-param URI parameter offers less 669 possible values than the diversion-reason parameter. However, it 670 has been considered that cause-param values list was sufficient 671 to implement CDIV service as defined in 3GPP[TS_24.604] as it 672 cover a large portion of cases. 674 3. The Diversion header could contain a Tel:URI in the name-addr 675 parameter but it seems not possible to have a Tel:URI in the 676 History-Info header. [RFC3261] gives an indication as to the 677 mapping between sip: and tel: URIs but in this particular case it 678 is difficult to assign a valid hostport as the diversion has 679 occurred in a previous network and a valid hostport is difficult 680 to determine. So, it is suggested that in case of Tel:URI in the 681 Diversion header, the History-Info header should be created with 682 a SIP URI with user=phone. 684 4. The Diversion header allows the carrying of a counter that 685 retains the information about the number of successive 686 redirections. History-Info does not have an equivalent because 687 to trace and count the number of diversion it is necessary to 688 count cause parameter containing a value associated to a call 689 diversion. Read the index value is not enough. With the use of 690 the "placeholder" entry the History-info header entries could 691 reflect the real number of diversion occurred. 693 Example of placeholder entry in the History-Info header: 695 ;index=1.1 696 ;index=1.1.1;mp=1.1 698 "cause=xxx" reflects the diverting reason of a previous diverting 699 user. For a placeholder hi-entry the value "404" must be taken for 700 the cause-param and so, located in the next hi-entry. 702 Concerning local policies recommendations about headers coexistence 703 in the INVITE request, see sections 2.2 and 7.5. 705 6. History-Info header to Diversion header 707 To create the Diversion entries in the same order than during a 708 session establishment, the History-Info entries must be mapped from 709 the top-most until the bottom-most. The first History-Info header 710 entry selected will be mapped into the last Diversion header entry 711 and so on. One Diversion header entry must be created for each 712 History-Info entry having an index referenced by a "mp" header field 713 parameter. 715 In this case, the History-Info header must be mapped into the 716 Diversion header as following: 718 Source Destination 719 History-Info header component: Diversion header component: 720 ===================================================================== 721 Hi-target-to-uri of the Name-addr 722 History-Info referenced by the 723 upcoming "mp" parameter. 725 ===================================================================== 726 Cause-param Reason 727 404---------------------------------------"unknown" (default value) 728 302---------------------------------------"unconditional" 729 486---------------------------------------"user-busy" 730 408---------------------------------------"no-answer" 731 480 or 487--------------------------------"deflection " 732 503---------------------------------------"unavailable" 734 ===================================================================== 735 Hi-index Counter 736 Mandatory parameter for--------------------The counter is set to "1". 737 History-Info reflecting 738 the chronological order 739 of the information. 740 ===================================================================== 741 Privacy header [RFC3323]escaped in the Privacy 742 hi-targeted-to-uri of the 743 History-Info which precedes the one 744 containing a diverting cause-param. 745 Optional parameter for History-Info, 746 this Privacy indicates that this 747 specific History-Info header should 748 not be forwarded. 749 "history"----------------------------------"full" 750 Privacy header field ----------------------"Off" 751 Absent or "none" 753 ===================================================================== 755 Note: For other optional History-Info parameters, there is no 756 recommendation as Diversion header does not provide equivalent 757 parameters. 759 Concerning local policies recommendations about headers coexistence 760 in the INVITE request, see section 2.2. 762 7. Examples 764 7.1. Example with Diversion header changed into History-Info header 766 INVITE last_diverting_target 767 Diversion: 768 ;reason=unconditional;counter=1;privacy= 769 off, 770 ;reason=user- 771 busy;counter=1;privacy=full, 772 ;reason=no-answer;counter=1;privacy=off 774 Mapped into: 776 History-Info: 777 ; index=1, 778 ;index=1.1;mp=1, 780 ;index=1.1.1;mp=1.1, 782 ;index=1.1.1.1;mp=1.1.1 784 7.2. Example with History-Info header changed into Diversion header 786 History-Info: 787 ; index=1, 788 ;index=1.1;mp=1, 790 ;index=1.1.1;mp=1.1 792 Mapped into: 794 Diversion: 795 ; reason=user-busy; counter=1; 796 privacy=off, 797 ; reason=unconditional; counter=1; 798 privacy=full 800 7.3. Example with two SIP networks using History-Info header 801 interworking with a SIP network using Diversion header 803 A -> P1 -> B -> C -> P2 -> D-> E 804 A, B, C, D and E are users. 805 B, C and D have Call Forwarding service invoked. 806 P1 and P2 are proxies. 807 Only relevant information is shown on the following call flow. 809 [To be updated in the next version of the Internet-Draft] 810 IWF* IWF* 811 SIP network using | SIP network using |SIP net. 812 History-Info | Diversion |using 813 | Hist-Info 814 | | 815 UA A P1 AS B | P2 AS C UA C AS D | UA E 816 | | | | | | | | | | 817 |INV B | | | | | | | | | 818 |------>| | | | | | | | | 819 | | | | | | | | | | 820 | |INV B | | | | | | | | 821 | |------>| | | | | | | | 822 | |Supported: histinfo | | | | | | 823 | | History-Info: | | | | | | 824 | | ; index=1, | | | | | 825 | | ; index=1.1 | | | | | 826 | | | | | | | | | | 827 | | |INV C | | | | | | | 828 | | |------>| | | | | | | 829 | | |History-Info: | | | | | | 830 | | ; index=1,| | | | | 831 | | ; index=1.1 | | | | | 832 | | ; index=1.1.1 | | | 833 | | | | | | | | | | 834 | | | |INV C | | | | | | 835 | | | |----->| | | | | | 836 | | | |Diversion: | | | | | 837 | | | |B reason= unconditional counter=1 | | 838 | | | |History-Info: | | | | | 839 | | | ; index=1,| | | | 840 | | | ; index=1.1 | | | | 841 | | | ; index=1.1.1 | 842 | | | | | | | | | | 843 | | | | |INV C | | | | | 844 | | | | |------>| | | | | 845 | | | | No modification of Diversion due to P2| 846 | | | | | | | | | | 847 | | | | | |INV C | | | | 848 | | | | | |------>| | | | 849 | | | | | | | | | | 850 | | | | | |<--180-| | | | 851 | | | | | | | | | | 852 | | | | | No response timer expire | | 853 | | | | | |---INV D --->| | | 854 | | |Diversion: | | | 855 | | |userC; reason=no-answer; counter=1; privacy=full, | 856 | | |userB; reason=unconditional; counter=1; privacy=off, 857 | | | History-Info: | | | 858 | | | ; index=1, | | | 859 | | | ; index=1.1 | | | 860 | | | ; index=1.1.1 | | 861 | | | | | | | | | | 862 | | | | | | | |INV E | | 863 | | | | | | | |----->| | 864 | | |Diversion: | | 865 | | |userD; reason=time-of-day; counter=1; privacy=off | 866 | | |userC; reason=no-answer; counter=1; privacy=full, | 867 | | |userB; reason=unconditional; counter=1; privacy=off, 868 | | | History-Info: | | 869 | | | ; index=1, | | 870 | | | ; index=1.1 | | 871 | | | ; index=1.1.1 | | 872 | | | | | | | | | | 873 | | | | | | | | | INV E | 874 | | | | | | | | |------>| 875 | | | History-Info: | 876 | | | ; index=1, | 877 | | | ; index=1.1, | 878 | | | ; index=1.1.1, | 879 | | | ; index=1.1.1.1, | 880 | | ; index=1.1.1.1.1, 881 | | | ; index=1.1.1.1.1.1 | 882 | | | | | | | | | | 883 | | | | | | | | | | 885 * Note: The IWF is an interworking function which could be a stand- 886 alone equipment not defined in this document (it could be a proxy). 888 7.4. Additional interworking Cases 890 Even if for particular cases in which both headers could coexist, it 891 should be the network local policy responsibility to make it work 892 together. Here are described some situations and some 893 recommendations on the behavior to follow. 895 In the case where there is one network which includes different 896 nodes, some of them supporting Diversion header and other ones 897 supporting History-info header, there is a problem when any node 898 handling a message does not know the next node that will handle the 899 message. This case can occur when the network has new and old nodes, 900 the older ones using Diversion header and the more recent History- 901 Info header. 903 While a network replacement may be occurring there will be a time 904 when both nodes coexist in the network. If the different nodes are 905 being used to support different subscriber types due to different 906 node capabilities then the problem is more important. In this case 907 there is a need to pass both History-Info header and Diversion header 908 within the core network. 910 These headers need to be equivalent to ensure that, whatever the node 911 receiving the message, the correct diversion information is received. 912 This requires that whatever the received header, there is a 913 requirement to be able to compare the headers and to convert the 914 headers. Depending upon the node capability, it may be possible to 915 make assumptions as to how this is handled. 917 o If it is known that the older Diversion header supporting nodes do 918 not pass on any received History-Info header then the interworking 919 becomes easier. If a message is received with only Diversion 920 headers then it has originated from an 'old' node. The equivalent 921 History-Info entries can be created and these can then be passed 922 as well as the Diversion header. 924 o If the node creates a new History-Info header for a call 925 diversion, then an additional Diversion header must be created. 927 o If the next node is an 'old' node then the Diversion header will 928 be used by that node and the History-Info entries will be removed 929 from the message when it is passed on. 931 o If the next node is a new node then the presence of both Diversion 932 header and History-Info header means that interworking has already 933 occurred and the Diversion and History-Info entries must be 934 considered equivalent. 936 o If both nodes pass on both History-Info header and Diversion 937 header but only actively use one, then both types of node need to 938 perform the interworking and must maintain equivalence between the 939 headers. This will eventually result in the use of Diversion 940 header being deprecated when all nodes in the network support 941 History-Info header. 943 8. IANA Considerations 945 This document makes no request of IANA. 947 9. Security Considerations 949 The security considerations in [RFC7044] and [RFC5806] apply. 951 The use of Diversion header or History-Info header require to apply 952 the requested privacy and integrity asked by each diverting user or 953 entity. Without integrity, the requested privacy functions could be 954 downgraded or eliminated, potentially exposing identity information. 955 Without confidentiality, eavesdroppers on the network (or any 956 intermediaries between the user and the privacy service) could see 957 the very personal information that the user has asked the privacy 958 service to obscure. Unauthorised insertion, deletion of modification 959 of those headers can provide misleading information to users and 960 applications. A SIP entity that can provide a redirection reason in 961 a History-Info header or Diversion header should be able to suppress 962 this in accordance with privacy requirements of the user concerned. 964 10. Acknowlegements 966 The editor would like to acknowledge the constructive feedback and 967 support provided by Steve Norreys, Jan Van Geel, Martin Dolly, 968 Francisco Silva, Guiseppe Sciortino, Cinza Amenta, Christer Holmberg, 969 Ian Elz, Jean-Francois Mule, Mary Barnes, Francois Audet, Erick 970 Sasaki, Shida Schubert, Joel M. Halpern, Bob Braden and Robert 971 Sparks. Merci a Lionel Morand, Xavier Marjou et Philippe Fouquart. 973 11. References 975 11.1. Normative References 977 [RFC3261] "SIP: Session Initiation Protocol", RFC 3261, June 2002. 979 [RFC3323] "A Privacy Mechanism for the Session Initiation Protocol 980 (SIP)", RFC 3323, November 2002. 982 [RFC3326] "The Reason Header Field for the Session Initiation 983 Protocol (SIP)", RFC 3326, December 2002. 985 [RFC4244] "An Extension to the Session Initiation Protocol (SIP) for 986 Request History Information", RFC 4244, November 2005. 988 [RFC5806] "Diversion Indication in SIP", March 2010. 990 [RFC7044] "An Extension to the Session Initiation Protocol (SIP) for 991 Request History Information", RFC 7044, February 2014. 993 11.2. Informative References 995 [RFC4458] "Session Initiation Protocol (SIP) URIs for Applications 996 such as Voicemail and Interactive Voice Response (IVR)", 997 RFC 4458, April 2006. 999 [RFC5234] "Augmented BNF for Syntax Specifications: ABNF", RFC 5234, 1000 January 2008. 1002 [RFC6044] "Mapping and Interworking of Diversion Information between 1003 Diversion and History-Info Headers in the Session 1004 Initiation Protocol (SIP)", RFC 6044, October 2010. 1006 [TS_24.604] 1007 3rd Generation Partnership Project, "Technical 1008 Specification Group Core Network and Terminals ; 1009 Communication Diversion (CDIV) using IP Multimedia 1010 (IM)Core Network (CN) subsystem ; Protocol specification 1011 (Release 8), 3GPP TS 24.604", December 2008. 1013 [TS_29.163] 1014 3rd Generation Partnership Project, "Technical 1015 Specification Group Core Network and Terminals ; 1016 Interworking between the IP Multimedia (IM) Core Network 1017 (CN) Subsystem and Circuit Switched (CS) networks (Release 1018 8)", December 2008. 1020 Appendix A. Interworking between Diversion header and Voicemail URI 1022 [To be updated in the next version of the Internet-Draft] 1024 Voicemail URI is a mechanism described in RFC4458 to provide a simple 1025 way to transport only one redirecting user address and the reason why 1026 the diversion occurred in the R-URI of the INVITE request. This 1027 mechanism is mainly used for call diversion to a voicemail. 1029 Diversion header to Voicemail URI: 1031 Received: 1032 Diversion: userA-address;reason=user-busy;counter=1;privacy=full 1034 Sent (Voicemail URI created in the R-URI line of the INVITE): 1035 sip: voicemail@example.com;target=userA-address;cause=486 SIP/2.0 1037 Mapping of the Redirection Reason is the same as for History-Info 1038 header with a default value set to 404. 1039 If the Diversion header contains more than one Diversion entry, the 1040 choice of the redirecting user information inserted in the URI is in 1041 charge of the network local policy. For example, the choice 1042 criterion of the redirecting information inserted in the URI could be 1043 the destination of forwarded INVITE request (if the voicemail serves 1044 this user or not). 1046 Note: This interworking could be done in addition to the interworking 1047 of the Diversion header into the History-Info header. 1049 Voicemail URI to Diversion header: 1050 In case of real Voicemail, this way of interworking should not 1051 happen. However, if for any reason it occurs, it is recommended to 1052 do it as following: 1054 Received: 1055 INVITE sip: voicemail@example.com;\ 1056 target=sip:+33145454500%40example.com;user=phone;\ 1057 cause=302 SIP/2.0 1059 Sent in the forwarded INVITE: 1060 Diversion: sip:+33145454500%40example.com;user=phone;reason=unconditi 1061 onal;counter=1 1063 Author's Address 1065 Marianne Mohali 1066 Orange 1067 38-40 rue du General Leclerc 1068 Issy-Les-Moulineaux Cedex 9 92794 1069 France 1071 Phone: +33 1 45 29 45 14 1072 Email: marianne.mohali@orange.com