idnits 2.17.1 draft-mohali-diversion-history-info-06.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 ([RFC4244], [RFC5806]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 28, 2010) is 5051 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4244 (Obsoleted by RFC 7044) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 2 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 Labs 4 Intended status: Informational June 28, 2010 5 Expires: December 30, 2010 7 Mapping and interworking of Diversion information Between Diversion and 8 History-Info Headers in the Session Initiation Protocol (SIP) 9 draft-mohali-diversion-history-info-06 11 Abstract 13 Although the SIP History-Info header is the solution adopted in IETF, 14 the non-standard Diversion header is nevertheless widely implemented 15 and used for conveying call diversion related information in the 16 Session Initiation Protocol (SIP) signaling. 17 This document describes a recommended interworking guideline between 18 the Diversion header and the History-Info header to handle call 19 diversion information. In addition, an interworking policy is 20 proposed to manage the headers coexistence. The History-Info header 21 is described in [RFC4244] and the non-standard Diversion header is 22 described, as Historic, in the [RFC5806]. 24 Since the Diversion header is used in many existing network 25 implementations for the transport of call diversion information, its 26 interworking with the SIP History-Info standardized solution is 27 needed. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on December 30, 2010. 46 Copyright Notice 48 Copyright (c) 2010 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.2. Background . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 64 2.1. Interworking requirements and scope . . . . . . . . . . . 4 65 2.2. Interworking recommendations . . . . . . . . . . . . . . . 5 66 2.2.1. SIP network/terminal using Diversion to SIP 67 network/terminal using History-Info header . . . . . . 6 68 2.2.2. SIP network/terminal using History-Info header to 69 SIP network/terminal using Diversion header . . . . . 8 70 3. Headers syntaxes reminder . . . . . . . . . . . . . . . . . . 9 71 3.1. History-Info header syntax . . . . . . . . . . . . . . . . 9 72 3.2. Diversion header syntax . . . . . . . . . . . . . . . . . 11 73 4. Headers in SIP Method . . . . . . . . . . . . . . . . . . . . 12 74 5. Diversion header to History-Info header . . . . . . . . . . . 12 75 6. History-Info header to Diversion header . . . . . . . . . . . 15 76 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 77 7.1. Example with Diversion header changed into 78 History-Info header . . . . . . . . . . . . . . . . . . . 17 79 7.2. Example with History-Info header changed into 80 Diversion header . . . . . . . . . . . . . . . . . . . . . 17 81 7.3. Example with two SIP networks using History-Info 82 header interworking with a SIP network using Diversion 83 header . . . . . . . . . . . . . . . . . . . . . . . . . . 17 84 7.4. Additional interworking Cases . . . . . . . . . . . . . . 19 85 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 86 9. Security Considerations . . . . . . . . . . . . . . . . . . . 20 87 10. Acknowlegements . . . . . . . . . . . . . . . . . . . . . . . 21 88 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 89 11.1. Normative References . . . . . . . . . . . . . . . . . . . 21 90 11.2. Informative References . . . . . . . . . . . . . . . . . . 21 91 Appendix A. Interworking between Diversion header and 92 Voicemail URI . . . . . . . . . . . . . . . . . . . . 22 93 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23 95 1. Introduction 97 1.1. Overview 99 For some VoIP-based services (eg. Voicemail, Interactive Voice 100 Recognition (IVR) or automatic call distribution), it is helpful for 101 the called SIP user agent to identify from whom and why the session 102 was diverted. For this information to be used in various service 103 providers or by applications, it needs to pass through the network. 104 This is possible with two different SIP headers: History-Info header 105 defined in [RFC4244] and the historic Diversion header defined in 106 [RFC5806] which are both able to transport diversion information in 107 SIP signaling. 108 Although the Diversion header is not standardized, it is widely used. 109 Therefore, it is useful to have guidelines to make this header 110 interwork with the standard History-Info header. 112 This document provides a mechanism for header content translation 113 between the Diversion header and the History-Info header. 115 1.2. Background 117 The History-Info header [RFC4244] and its extension for forming SIP 118 service URIs (including Voicemail URI) [RFC4458] are recommended by 119 IETF to convey redirection information. They are also recommended in 120 the "Communication Diversion (CDIV) service" 3GPP specification 121 [TS_24.604]. 123 Originally, the Diversion header was described in an Internet Draft 124 that was submitted to the SIP Working Group. It has been published 125 now as [RFC5806] for the historical record and to provide a reference 126 for this RFC. 128 This header contains a list of diverting URIs and associated 129 information providing specific information as the reason for the call 130 diversion. Most of existing SIP-based implementations have 131 implemented the Diversion header when no standard solution was ready 132 to deploye. The IETF has finally standardized the History-Info 133 header partly because it can transport general history information. 134 This allows the receiving part to determine how and why the session 135 is received. As the History-Info header may contain further 136 information than call diversion information, it is critical to avoid 137 losing information and be able to extract the relevant data using the 138 retargeting cause URI parameter described in [RFC4458] for the 139 transport of the diversion reason. 141 The Diversion header and the History-Info header have different 142 syntaxes described below. Note that the main difference is that the 143 History-Info header is a chronological writing header whereas the 144 Diversion header applies a reverse chronology (i.e. the first 145 diversion entry read corresponds to the last diverting user). 147 The Appendix A provides an interworking guideline between the 148 Diversion header and the Voicemail URI which is another way to convey 149 diversion information. The Voicemail URI is defined in [RFC4458]. 151 2. Problem Statement 153 2.1. Interworking requirements and scope 155 This section provides the baseline terminology used in the rest of 156 the document and defines the scope of interworking between the 157 Diversion header and the History-Info header. 159 They are many ways in which SIP signaling can be used to modify a 160 session destination before it is established and many reasons for 161 doing so. The behavior of the SIP entities that will have to further 162 process the session downstream will sometimes vary depending on the 163 reasons that lead to changing the destination. For example, whether 164 it is for a simple proxy to route the session or for an application 165 server to provide a supplementary service. The Diversion header and 166 the History-Info header differ in the approach and scope of 167 addressing this problem. 169 For clarity, the following vocabulary is used in this document: 171 o Retargeting/redirecting: retargeting/redirecting refer to the 172 process of a Proxy Server/User Agent Client (UAC) changing a 173 Uniform Resource Identifier (URI) in a request and thus changing 174 the target of the request. These terms are defined in [RFC4244]. 175 The History-Info header is used to capture retargeting 176 information. 178 o Call forwarding/call diversion/communication diversion: these 179 terms are equivalent and refer to the Communications Diversion 180 (CDIV) supplementary services, based on the ISDN Communication 181 diversion supplementary services and defined in 3GPP [TS_24.604]. 182 They are applicable to entities which are intended to modify the 183 original destination of an IP multimedia session during or prior 184 to the session establishment. 186 This document does not intend to describe when or how History-Info or 187 Diversion headers should be used. Hereafter is provided 188 clarification on the context in which the interworking is required. 190 The Diversion header has exactly the same scope as the call diversion 191 service and each header entry reflects a call diversion invocation. 192 The Diversion header is used for recording call forwarding 193 information which could be useful to network entities downstream. 194 Today, this SIP header is implemented by several manufacturers and 195 deployed in networks. 197 The History-Info header is used to store all retargeting information 198 including call diversion information. In practice, the History-Info 199 header [RFC4244] is used to convey call diversion related information 200 by using a cause URI parameter [RFC4458] in the relevant entry. 201 Note, however, that the use of cause URI parameter [RFC4458] in a 202 History-Info entry for a call diversion is specific to the 3GPP 203 specification [TS_24.604]. [RFC4458] focuses on retargeting toward 204 voicemail server and does not specify whether the cause URI parameter 205 should be added in a URI for other cases. As a consequence, 206 implementations that do not use the cause URI parameter for call 207 forwarding information, are not considered for the mapping described 208 in this document. Nevertheless, some recommendations are given in 209 the next sections on how to avoid the loss of non-mapped information 210 at the boundary between a network region using History-Info header 211 and one using the Diversion header. 213 Since both headers address call forwarding needs, diverting 214 information could be mixed-up or be inconsistent if both are present 215 in an uncoordinated fashion in the INVITE request. So, Diversion and 216 History-Info headers must not independently coexist in the same 217 session signaling. This document addresses how to convert 218 information between the Diversion header and the History-Info header, 219 and when and how to preserve both headers to cover additional cases. 221 For the transportation of consistent diversion information 222 downstream, it is necessary to make the two headers interwork. 223 Interworking between the Diversion header and the History-Info header 224 is introduced in sections 5 and 6. Since coexistence scenario may 225 vary from one use case to another one, guidelines regarding headers 226 interaction are proposed. 228 2.2. Interworking recommendations 230 Interworking function: 232 In a normal case, the network topology assumption is that the 233 interworking described in this document should be performed by a 234 specific SIP border device which is aware, by configuration, that 235 it is at the border between two regions, one using History-Info 236 header and one using Diversion header. 238 As History-Info header is a standard solution, a network using the 239 Diversion header must be able to provide information to a network 240 using the History-Info header. In this case, to avoid headers 241 coexistence it is required to replace, as often as possible, the 242 Diversion header with the History-Info header in the INVITE request 243 during the interworking. 245 Since, the History-Info header has a wider scope than the Diversion 246 header, it may be used for other needs and services than call 247 diversion. In addition to trace call diversion information, History- 248 Info header also acts as a session history and can store all 249 successive R-URI values. Consequently, even if it should be better 250 to remove the History-Info header after the creation of the Diversion 251 header avoiding confusion, the History-Info header must remain 252 unmodified in the SIP signaling if it contains supplementary (non- 253 diversion) information. It is possible to have History-Info headers 254 that do not have values that can be mapped into the Diversion header. 255 In this case, no interworking with Diversion header should be 256 performed and it must be defined per implementation what to do in 257 this case. This point is left out of the scope of this document. 259 As a conclusion, it is recommended to have local policies minimizing 260 the loss of information and find the best way to keep it up to the 261 terminating user agent. 263 The following sections describe the basic common use case. 264 Additional interworking cases are described in section 7.5. 266 2.2.1. SIP network/terminal using Diversion to SIP network/terminal 267 using History-Info header 269 When the Diversion header is used to create a History-Info header, 270 the Diversion header must be removed in the outgoing INVITE. It is 271 considered that all the information present in the Diversion header 272 is transferred in the History-Info header. 274 If a History-Info header is present in the incoming INVITE (in 275 addition to Diversion header), the Diversion header and History-Info 276 header present must be mixed and only the diversion information not 277 yet present in the History-Info header must be inserted as a last 278 entry (more recent) in the existing History-Info header, as 279 recommended in [RFC4244]. 281 As an example, this could be the case of an INVITE coming from 282 network_2 using Diversion header but previously passed through 283 network_1 using History-Info header (or the network_2 uses History- 284 Info header to transport successive URI information) and going to 285 network_3 using History-Info header. 287 IWF* IWF* 288 network1 | network_2 |network_3 289 History-Info | Diversion |using 290 | |Hist-Info 291 | | 292 UA A P1 AS B | P2 AS C UA C AS D | UA E 293 | | | | | | | | | | 294 |INVITE | | | | | | | | | 295 |------>| | | | | | | | | 296 | | | | | | | | | | 297 | |INVITE | | | | | | | | 298 | |------>| | | | | | | | 299 | |Supported: histinfo | | | | | | 300 | | History-Info: | | | | | | 301 | | ; index=1, | | | | | 302 | | ; index=1.1 | | | | | 303 | | | | | | | | | | 304 | | |INVITE | | | | | | | 305 | | |------>| | | | | | | 306 | | |History-Info: | | | | | | 307 | | |; index=1,| | | | | 308 | | |; index=1.1 | | | | | 309 | | |; cause=302; index=1.1.1 | | | 311 In this case, the incoming INVITE contains a Diversion header and a 312 History-Info header. Therefore, as recommended in this document, it 313 is necessary to create for network_3, a single History-Info header 314 gathering existing information from both the History-Info and the 315 Diversion headers received. Anyway, it is required from network_2 316 (ie.IWF) to remove the Diversion header when the message is going to 317 a network not using the Diversion header. Then network_3 could use 318 call forwarding information that is present in a single header and 319 add its own diversion information if necessary. 321 Notes: 323 1. If a network is not able either to use only one header each time, 324 or to maintain both headers up to date, the chronological order 325 can not be certified. 327 2. It is not possible to have only Diversion header when the 328 History-Info header contains more than call diversion 329 information. If previous policy recommendations are applied, the 330 chronological order is respected as Diversion entries are 331 inserted at the end of the History-Info header taking into 332 account the Diversion internal chronology. 334 2.2.2. SIP network/terminal using History-Info header to SIP network/ 335 terminal using Diversion header 337 When the History-Info header is interpreted to create a Diversion 338 header, some precautions must be taken. 339 If the History-Info header contains only call forwarding information, 340 then it must be deleted after the interworking. 341 If the History-Info header contains other information, then only the 342 information of concern to the diverting user must be used to create 343 entries in the Diversion header and the History-Info header must be 344 kept as received in the INVITE and forwarded downstream. 346 Note: The History-Info header could be used for other reasons than 347 call diversion services, for example by a service which need to know 348 if a specific AS had yet been invoked in the signaling path. If the 349 call is later forwarded to a network using History-Info header, it 350 would be better to not lose history information due to passing though 351 the network which only support Diversion header. A recommended 352 solution must not disrupt the standard behavior and networks which do 353 not implement the History-Info header must be transparent to a 354 received History-Info header. 356 If a Diversion header is present in the incoming INVITE (in addition 357 to History-Info header), only diversion information present in the 358 History-Info header but not in the Diversion header must be inserted 359 from the last entry (more recent) into the existing Diversion header 360 as recommended in the [RFC5806]. 362 Note that the chronological order could not be certified. If 363 previous policy recommendations are respected, this case should not 364 happen. 366 Forking case: 368 The History-Info header enables the recording of sequential 369 forking for the same served-user. During an interworking, from 370 the History-Info header to Diversion header, the History-Info 371 entries containing a forking situation (with an incremented 372 "index" parameter) could possibly be mapped if it contains a call 373 forwarding "cause" parameter. The interworking entity could 374 choose to create only a Diversion entry or not apply the 375 interworking. The choice could be done according a local policy. 377 The same logic is applied for an interworking with Voicemail URI (see 378 the Appendix). 380 3. Headers syntaxes reminder 382 3.1. History-Info header syntax 384 History-Info = "History-Info" HCOLON hi-entry *(COMMA hi-entry) 386 hi-entry = hi-targeted-to-uri *( SEMI hi-param ) 387 hi-targeted-to-uri = name-addr 388 hi-param = hi-index / hi-extension 389 hi-index = "index" EQUAL 1*DIGIT *(DOT 1*DIGIT) 390 hi-extension = generic-param 392 The History-Info header is specified in [RFC4244]. 393 The top-most History-Info entry (first in the list) corresponds to 394 the oldest history information. 396 A hi-entry may contain a cause URI parameter expressing the diversion 397 reason. This optional cause URI parameter is defined in [RFC4458] 398 with the following syntax: 400 cause-param = "cause" EQUAL Status-Code. 402 This parameter is also named cause-param and should be inserted in 403 the History-Info entry (URI) of the diverted-to user in case of call 404 diversion as recommended in the 3GPP CDIV specification [TS_24.604]. 405 The cause values used in the cause-param for the diverting reason are 406 listed in the RFC and because it is a parameter dedicated to call 407 forwarding service, its presence is used to determine that a hi-entry 408 is a diverting user. More precisely, each diverting user is located 409 in the hi-entry before the one containing a cause-param with cause 410 value as listed in RFC 4458. 412 Moreover, the Reason header defined in [RFC3326] should be escaped in 413 the hi-entry of the diverting user when the call diversion is due to 414 a received SIP response. The Reason header contains a cause 415 parameter set to the true SIP response code received (Status-Code). 416 Therefore, in case of call diversion due to a SIP response, both 417 cause parameters should be used. The complexity is that these 418 parameters could be used at the same time in the History-Info header 419 but not in the same hi-entry and not with the same meaning. Only the 420 cause-param is dedicated to call diversion service. The 'cause' 421 Reason header parameter is not taken into account in the mapping with 422 a Diversion header. 424 The [RFC4458] also defines the 'target' URI parameter which could be 425 inserted in a R-URI and consequently in the hi-targeted-to-uri. This 426 parameter is used to keep the diverting user address in the 427 downstream INVITE request in Voicemail URI implementation. As this 428 information is already present in the hi-entries, the 'target' URI 429 parameter is not taken into account regarding the interworking with 430 the Diversion header. From the Diversion header, it could be 431 possible to create the 'target' URI parameter in the hi-entries 432 and/or in the R-URI but this possibility is based on local policies 433 not described in this document. 435 A Privacy header as defined in [RFC3323] could also be included in 436 hi-entries with the 'history' value defined in the [RFC4244]. 438 The index parameter is a string of digits, separated by dots to 439 indicate the number of forward hops and retargets. 441 Note: A history entry could contain the "gr" parameter. Regardless 442 the rules concerning "gr" parameter defined in [TS_24.604] which must 443 be applied, this parameter has no impact on the mapping and must only 444 be copied with the served user address. 446 Example: 448 History-Info: 449 ;index=1, 451 ;index=1.1, 452 ; index=1.1.1, 454 Policy concerning "histinfo" option tag in Supported header: 455 According to [RFC4244], a proxy that receives a Request with the 456 "histinfo" option tag in the Supported header should return captured 457 History-Info in subsequent, provisional and final responses to the 458 Request. The behavior depends upon whether the local policy supports 459 the capture of History-Info or not. 461 3.2. Diversion header syntax 463 The following text is restating the exact syntax that the production 464 rules in [RFC5806] define, but using [RFC5234] ABNF: 466 Diversion = "Diversion" HCOLON diversion-params 467 *(COMMA diversion-params) 469 diversion-params = name-addr *(SEMI (diversion-reason / 470 diversion-counter / diversion-limit / 471 diversion-privacy / diversion-screen / 472 diversion-extension)) 473 diversion-reason = "reason" EQUAL ("unknown" / "user-busy" / 474 "no-answer" / "unavailable" / "unconditional" 475 / "time-of-day" / "do-not-disturb" / 476 "deflection" / "follow-me" / "out-of-service" 477 / "away" / token / quoted-string) 478 diversion-counter = "counter" EQUAL 1*2DIGIT 479 diversion-limit = "limit" EQUAL 1*2DIGIT 480 diversion-privacy = "privacy" EQUAL ("full" / "name" / "uri" / 481 "off" / token / quoted-string) 482 diversion-screen = "screen" EQUAL ("yes" / "no" / token / 483 quoted-string) 484 diversion-extension = token [EQUAL (token / quoted-string)] 486 Note: The Diversion header could be used in the comma-separated 487 format as described below and in a header-separated format. Both 488 formats could be combined a received INVITE as recommended in 489 [RFC3261]. 491 Example: 493 Diversion: 495 diverting_user2_addr; reason="user-busy"; counter=1; privacy=full, 497 diverting_user1_addr; reason="unconditional"; counter=1; 498 privacy=off 500 4. Headers in SIP Method 502 The recommended interworking presented in this document should apply 503 only for INVITE requests. 505 In 3xx responses, both headers could be present. 506 When a proxy wants to interwork with a network supporting the other 507 header field, it should apply the interworking between Diversion 508 header and History-Info header in the 3xx response. 509 When a recursing proxy redirects an initial INVITE after receiving a 510 3xx response, it should add as a last entry either a Diversion header 511 or History-Info header (according to its capabilities) in the 512 forwarded INVITE. Local policies could apply to send the received 513 header in the next INVITE or not. 515 Other messages where History-Info could be present are not used for 516 the Call Forwarding service and should not be changed into Diversion 517 header. The destination network must be transparent to the received 518 History-Info header. 520 Note : the following mapping is inspired from the ISUP to SIP 521 interworking described in [TS_29.163]. 523 5. Diversion header to History-Info header 525 The following text is valid only if no History-Info is present in the 526 INVITE request. If at least one History-Info header is present, the 527 interworking function must adapt its behavior to respect the 528 chronological order. See section 2.2. 529 For N Diversion entries N+1 History-Info entries must be created. To 530 create the History-Info entries in the same order than during a 531 session establishment, the Diversion entries must be mapped from the 532 bottom-most until the top-most. Each Diversion entry shall be mapped 533 into a History-Info entry. An additional History-Info entry (the 534 last one) must be created with the diverted-to party address present 535 in the R-URI of the received INVITE. The mapping is described below. 537 The first entry created in the History-Info header contains: 539 - a hi-target-to-uri with the name-addr parameter of the bottom- 540 most Diversion header 542 - if a privacy parameter is present in the bottom-most Diversion 543 entry, then a Privacy header could be escaped in the History-Info 544 header as described below, 545 - an index set to 1. 547 For each following Diversion entry (from bottom to top), the History- 548 info entries are created as following (from top to bottom): 549 Source Destination 550 Diversion header component: History-Info header component: 551 ======================================================================= 552 Name-addr Hi-target-to-uri 554 ======================================================================= 555 Reason of the previous cause-param (not present in 556 Diversion entry the first created hi-entry) 557 "unknown"---------------------------------404 (default 'cause' value) 558 "unconditional"---------------------------302 559 "user-busy"-------------------------------486 560 "no-answer"-------------------------------408 561 "deflection "-----------------------------480 or 487 562 "unavailable"-----------------------------404 563 "time-of-day"-----------------------------404 (default) 564 "do-not-disturb"--------------------------404 (default) 565 "follow-me"-------------------------------404 (default) 566 "out-of-service"--------------------------404 (default) 567 "away"------------------------------------404 (default) 569 ======================================================================= 570 Counter Hi-index 571 "1" or parameter -------------------------The previous created index 572 no present is incremented with ".1" 573 Superior to "1" --------------------------Create N-1 placeholder History 574 (i.e. N) entry with the previous index 575 incremented with ".1" 576 Then the History-Info header 577 created with the Diversion 578 entry with the previous index 579 incremented with ".1" 580 ======================================================================= 581 Privacy Privacy header escaped in the 582 hi-targeted-to-uri 583 "full"------------------------------------"history" 584 "Off"-------------------------------------Privacy header field 585 absent or "none" 586 "name"------------------------------------"history" 587 "uri"-------------------------------------"history" 588 ======================================================================= 590 A last History-Info entry is created and contains: 592 - a hi-target-to-uri with the Request-URI of the INVITE request. 594 - a cause-param from the top-most Diversion entry, mapped from the 595 diversion-reason as described above. 597 - if a privacy parameter is present in the top-most Diversion 598 entry, then a Privacy header could be escaped in the History-Info 599 header as described above, 601 - an index set to the previous created index and incremented with 602 ".1" 604 Notes: 606 1. For other optional Diversion parameters, there is no 607 recommendation as History-Info header does not provide equivalent 608 parameters. 610 2. For values of the diversion-reason values which are mapped with a 611 recommended default value, it could also be possible to choose 612 another value. The cause-param URI parameter offers less 613 possible values than the diversion-reason parameter. However, it 614 has been considered that cause-param values list was sufficient 615 to implement CDIV service as defined in 3GPP[TS_24.604] as it 616 cover a large portion of cases. 618 3. The Diversion header could contain a Tel:URI in the name-addr 619 parameter but it seems not possible to have a Tel:URI in the 620 History-Info header. [RFC3261] gives an indication as to the 621 mapping between sip: and tel: URIs but in this particular case it 622 is difficult to assign a valid hostport as the diversion has 623 occurred in a previous network and a valid hostport is difficult 624 to determine. So, it is suggested that in case of Tel:URI in the 625 Diversion header, the History-Info header should be created with 626 a SIP URI with user=phone. 628 4. The Diversion header allows the carrying of a counter that 629 retains the information about the number of successive 630 redirections. History-Info does not have an equivalent because 631 to trace and count the number of diversion it is necessary to 632 count cause parameter containing a value associated to a call 633 diversion. Read the index value is not enough. With the use of 634 the "placeholder" entry the History-info header entries could 635 reflect the real number of diversion occurred. 637 Example of placeholder entry in the History-Info header: 639 ;index=1.1 641 ;index=1.1.1 643 "cause=xxx" reflects the diverting reason of a previous diverting 644 user. For a placeholder hi-entry the value "404" must be taken for 645 the cause-param and so, located in the next hi-entry. 647 Concerning local policies recommendations about headers coexistence 648 in the INVITE request, see sections 2.2 and 7.5. 650 6. History-Info header to Diversion header 652 To create the Diversion entries in the same order than during a 653 session establishment, the History-Info entries must be mapped from 654 the top-most until the bottom-most. The first History-Info header 655 entry selected will be mapped into the last Diversion header entry 656 and so on. One Diversion header entry must be created for each 657 History-Info entry with a cause-param reflecting a diverting reason 658 as listed in the [RFC4458]. 660 In this case, the History-Info header must be mapped into the 661 Diversion header as following: 663 Source Destination 664 History-Info header component: Diversion header component: 665 ===================================================================== 666 Hi-target-to-uri of the Name-addr 667 History-Info which precedes the one 668 containing a diverting cause-param 670 ===================================================================== 671 Cause-param Reason 672 404---------------------------------------"unknown" (default value) 673 302---------------------------------------"unconditional" 674 486---------------------------------------"user-busy" 675 408---------------------------------------"no-answer" 676 480 or 487--------------------------------"deflection " 677 503---------------------------------------"unavailable" 679 ===================================================================== 680 Hi-index Counter 681 Mandatory parameter for--------------------The counter is set to "1". 682 History-Info reflecting 683 the chronological order 684 of the information. 685 ===================================================================== 686 Privacy header [RFC3323]escaped in the Privacy 687 hi-targeted-to-uri of the 688 History-Info which precedes the one 689 containing a diverting cause-param. 690 Optional parameter for History-Info, 691 this Privacy indicates that this 692 specific History-Info header should 693 not be forwarded. 694 "history"----------------------------------"full" 695 Privacy header field ----------------------"Off" 696 Absent or "none" 698 ===================================================================== 700 Note: For other optional History-Info parameters, there is no 701 recommendation as Diversion header does not provide equivalent 702 parameters. 704 Concerning local policies recommendations about headers coexistence 705 in the INVITE request, see section 2.2. 707 7. Examples 709 7.1. Example with Diversion header changed into History-Info header 711 INVITE last_diverting_target 712 Diversion: 713 diverting_user3_address;reason=unconditional;counter=1;privacy=off, 714 diverting_user2_address;reason=user-busy;counter=1;privacy=full, 715 diverting_user1_address;reason=no-answer;counter=1;privacy=off 717 Mapped into: 719 History-Info: 720 ; index=1, 721 ;index=1.1, 722 ;index=1.1.1, 723 ;index=1.1.1.1, 725 7.2. Example with History-Info header changed into Diversion header 727 History-Info: 728 ; index=1, 729 ;index=1.1, 730 ;index=1.1.1 732 Mapped into: 734 Diversion: 735 diverting_user2_address; reason=user-busy; counter=1; privacy=off, 736 diverting_user1_address; reason=unconditional; counter=1; 737 privacy=full 739 7.3. Example with two SIP networks using History-Info header 740 interworking with a SIP network using Diversion header 742 A -> P1 -> B -> C -> P2 -> D-> E 743 A, B, C, D and E are users. 744 B, C and D have Call Forwarding service invoked. 745 P1 and P2 are proxies. 746 Only relevant information is shown on the following call flow. 748 IWF* IWF* 749 SIP network using | SIP network using |SIP net. 750 History-Info | Diversion |using 751 | Hist-Info 752 | | 753 UA A P1 AS B | P2 AS C UA C AS D | UA E 754 | | | | | | | | | | 755 |INV B | | | | | | | | | 756 |------>| | | | | | | | | 757 | | | | | | | | | | 758 | |INV B | | | | | | | | 759 | |------>| | | | | | | | 760 | |Supported: histinfo | | | | | | 761 | | History-Info: | | | | | | 762 | | ; index=1, | | | | | 763 | | ; index=1.1 | | | | | 764 | | | | | | | | | | 765 | | |INV C | | | | | | | 766 | | |------>| | | | | | | 767 | | |History-Info: | | | | | | 768 | | ; index=1,| | | | | 769 | | ; index=1.1 | | | | | 770 | | ; index=1.1.1 | | | 771 | | | | | | | | | | 772 | | | |INV C | | | | | | 773 | | | |----->| | | | | | 774 | | | |Diversion: | | | | | 775 | | | |B reason= unconditional counter=1 | | 776 | | | |History-Info: | | | | | 777 | | | ; index=1,| | | | 778 | | | ; index=1.1 | | | | 779 | | | ; index=1.1.1 | 780 | | | | | | | | | | 781 | | | | |INV C | | | | | 782 | | | | |------>| | | | | 783 | | | | No modification of Diversion due to P2| 784 | | | | | | | | | | 785 | | | | | |INV C | | | | 786 | | | | | |------>| | | | 787 | | | | | | | | | | 788 | | | | | |<--180-| | | | 789 | | | | | | | | | | 790 | | | | | No response timer expire | | 791 | | | | | |---INV D --->| | | 792 | | |Diversion: | | | 793 | | |userC; reason=no-answer; counter=1; privacy=full, | 794 | | |userB; reason=unconditional; counter=1; privacy=off, 795 | | | History-Info: | | | 796 | | | ; index=1, | | | 797 | | | ; index=1.1 | | | 798 | | | ; index=1.1.1 | | 799 | | | | | | | | | | 800 | | | | | | | |INV E | | 801 | | | | | | | |----->| | 802 | | |Diversion: | | 803 | | |userD; reason=time-of-day; counter=1; privacy=off | 804 | | |userC; reason=no-answer; counter=1; privacy=full, | 805 | | |userB; reason=unconditional; counter=1; privacy=off, 806 | | | History-Info: | | 807 | | | ; index=1, | | 808 | | | ; index=1.1 | | 809 | | | ; index=1.1.1 | | 810 | | | | | | | | | | 811 | | | | | | | | | INV E | 812 | | | | | | | | |------>| 813 | | | History-Info: | 814 | | | ; index=1, | 815 | | | ; index=1.1, | 816 | | | ; index=1.1.1, | 817 | | | ; index=1.1.1.1, | 818 | | ; index=1.1.1.1.1, 819 | | | ; index=1.1.1.1.1.1 | 820 | | | | | | | | | | 821 | | | | | | | | | | 823 * Note: The IWF is an interworking function which could be a stand- 824 alone equipment not defined in this document (it could be a proxy). 826 7.4. Additional interworking Cases 828 Even if for particular cases in which both headers could coexist, it 829 should be the network local policy responsibility to make it work 830 together. Here are described some situations and some 831 recommendations on the behavior to follow. 833 In the case where there is one network which includes different 834 nodes, some of them supporting Diversion header and other ones 835 supporting History-info header, there is a problem when any node 836 handling a message does not know the next node that will handle the 837 message. This case can occur when the network has new and old nodes, 838 the older ones using Diversion header and the more recent History- 839 Info header. 840 While a network replacement may be occurring there will be a time 841 when both nodes coexist in the network. If the different nodes are 842 being used to support different subscriber types due to different 843 node capabilities then the problem is more important. In this case 844 there is a need to pass both History-Info header and Diversion header 845 within the core network. 846 These headers need to be equivalent to ensure that, whatever the node 847 receiving the message, the correct diversion information is received. 848 This requires that whatever the received header, there is a 849 requirement to be able to compare the headers and to convert the 850 headers. Depending upon the node capability, it may be possible to 851 make assumptions as to how this is handled. 852 If it is known that the older Diversion header supporting nodes do 853 not pass on any received History-Info header then the interworking 854 becomes easier. If a message is received with only Diversion headers 855 then it has originated from an 'old' node. The equivalent History- 856 Info entries can be created and these can then be passed as well as 857 the Diversion header. 858 If the node creates a new History-Info header for a call diversion, 859 then an additional Diversion header must be created. 860 If the next node is an 'old' node then the Diversion header will be 861 used by that node and the History-Info entries will be removed from 862 the message when it is passed on. 863 If the next node is a new node then the presence of both Diversion 864 header and History-Info header means that interworking has already 865 occurred and the Diversion and History-Info entries must be 866 considered equivalent. 867 If both nodes pass on both History-Info header and Diversion header 868 but only actively use one, then both types of node need to perform 869 the interworking and must maintain equivalence between the headers. 870 This will eventually result in the use of Diversion header being 871 deprecated when all nodes in the network support History-Info header. 873 8. IANA Considerations 875 This document makes no request of IANA. 877 9. Security Considerations 879 The use of Diversion header or History-Info header require to apply 880 the requested privacy and integrity asked by each diverting user or 881 entity. Without integrity, the requested privacy functions could be 882 downgraded or eliminated, potentially exposing identity information. 883 Without confidentiality, eavesdroppers on the network (or any 884 intermediaries between the user and the privacy service) could see 885 the very personal information that the user has asked the privacy 886 service to obscure. Unauthorised insertion, deletion of modification 887 of those headers can provide misleading information to users and 888 applications. A SIP entity that can provide a redirection reason in 889 a History-Info header or Diversion header should be able to suppress 890 this in accordance with privacy requirements of the user concerned. 892 10. Acknowlegements 894 The editor would like to acknowledge the constructive feedback and 895 support provided by Steve Norreys, Jan Van Geel, Martin Dolly, 896 Francisco Silva, Guiseppe Sciortino, Cinza Amenta, Christer Holmberg, 897 Ian Elz, Jean-Francois Mule, Mary Barnes, Francois Audet, Erick 898 Sasaki, Shida Schubert, Joel M. Halpern, Bob Braden and Robert 899 Sparks. Merci a Lionel Morand, Xavier Marjou and Philippe Fouquart. 901 11. References 903 11.1. Normative References 905 [RFC3261] "SIP: Session Initiation Protocol", RFC 3261, June 2002. 907 [RFC3323] "A Privacy Mechanism for the Session Initiation Protocol 908 (SIP)", RFC 3323, November 2002. 910 [RFC3326] "The Reason Header Field for the Session Initiation 911 Protocol (SIP)", RFC 3326, December 2002. 913 [RFC4244] "An Extension to the Session Initiation Protocol (SIP) for 914 Request History Information", RFC 4244, November 2005. 916 [RFC5806] "Diversion Indication in SIP", March 2010. 918 11.2. Informative References 920 [RFC4458] "Session Initiation Protocol (SIP) URIs for Applications 921 such as Voicemail and Interactive Voice Response (IVR)", 922 RFC 4458, April 2006. 924 [RFC5234] "Augmented BNF for Syntax Specifications: ABNF", RFC 5234, 925 January 2008. 927 [TS_24.604] 928 3rd Generation Partnership Project, "Technical 929 Specification Group Core Network and Terminals ; 930 Communication Diversion (CDIV) using IP Multimedia 931 (IM)Core Network (CN) subsystem ; Protocol specification 932 (Release 8), 3GPP TS 24.604", December 2008. 934 [TS_29.163] 935 3rd Generation Partnership Project, "Technical 936 Specification Group Core Network and Terminals ; 937 Interworking between the IP Multimedia (IM) Core Network 938 (CN) Subsystem and Circuit Switched (CS) networks (Release 939 8)", December 2008. 941 Appendix A. Interworking between Diversion header and Voicemail URI 943 Voicemail URI is a mechanism described in RFC4458 to provide a simple 944 way to transport only one redirecting user address and the reason why 945 the diversion occurred in the R-URI of the INVITE request. This 946 mechanism is mainly used for call diversion to a voicemail. 948 Diversion header to Voicemail URI: 950 Received: 951 Diversion: userA-address;reason=user-busy;counter=1;privacy=full 953 Sent (Voicemail URI created in the R-URI line of the INVITE): 954 sip: voicemail@example.com;target=userA-address;cause=486 SIP/2.0 956 Mapping of the Redirection Reason is the same as for History-Info 957 header with a default value set to 404. 958 If the Diversion header contains more than one Diversion entry, the 959 choice of the redirecting user information inserted in the URI is in 960 charge of the network local policy. For example, the choice 961 criterion of the redirecting information inserted in the URI could be 962 the destination of forwarded INVITE request (if the voicemail serves 963 this user or not). 965 Note: This interworking could be done in addition to the interworking 966 of the Diversion header into the History-Info header. 968 Voicemail URI to Diversion header: 969 In case of real Voicemail, this way of interworking should not 970 happen. However, if for any reason it occurs, it is recommended to 971 do it as following: 973 Received: 974 INVITE sip: voicemail@example.com;\ 975 target=sip:+33145454500%40example.com;user=phone;\ 976 cause=302 SIP/2.0 978 Sent in the forwarded INVITE: 979 Diversion: sip:+ 980 33145454500%40example.com;user=phone;reason=unconditional;counter=1 982 Author's Address 984 Marianne Mohali 985 Orange Labs 986 38-40 rue du General Leclerc 987 Issy-Les-Moulineaux Cedex 9 92794 988 France 990 Phone: +33 1 45 29 45 14 991 Email: marianne.mohali@orange-ftgroup.com