idnits 2.17.1 draft-mohali-diversion-history-info-07.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 (July 02, 2010) is 5045 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 France Telecom Orange 4 Intended status: Informational July 02, 2010 5 Expires: January 3, 2011 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-07 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. This work is intended to enable the migration from non- 28 standard implementations and deployment toward IETF specification- 29 based implementations and deployment. 31 Status of this Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on January 3, 2011. 48 Copyright Notice 49 Copyright (c) 2010 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.2. Background . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 65 2.1. Interworking requirements and scope . . . . . . . . . . . 4 66 2.2. Interworking recommendations . . . . . . . . . . . . . . . 5 67 2.2.1. SIP network/terminal using Diversion to SIP 68 network/terminal using History-Info header . . . . . . 6 69 2.2.2. SIP network/terminal using History-Info header to 70 SIP network/terminal using Diversion header . . . . . 8 71 3. Headers syntaxes reminder . . . . . . . . . . . . . . . . . . 9 72 3.1. History-Info header syntax . . . . . . . . . . . . . . . . 9 73 3.2. Diversion header syntax . . . . . . . . . . . . . . . . . 11 74 4. Headers in SIP Method . . . . . . . . . . . . . . . . . . . . 12 75 5. Diversion header to History-Info header . . . . . . . . . . . 12 76 6. History-Info header to Diversion header . . . . . . . . . . . 15 77 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 78 7.1. Example with Diversion header changed into 79 History-Info header . . . . . . . . . . . . . . . . . . . 17 80 7.2. Example with History-Info header changed into 81 Diversion header . . . . . . . . . . . . . . . . . . . . . 17 82 7.3. Example with two SIP networks using History-Info 83 header interworking with a SIP network using Diversion 84 header . . . . . . . . . . . . . . . . . . . . . . . . . . 17 85 7.4. Additional interworking Cases . . . . . . . . . . . . . . 19 86 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 87 9. Security Considerations . . . . . . . . . . . . . . . . . . . 20 88 10. Acknowlegements . . . . . . . . . . . . . . . . . . . . . . . 21 89 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 90 11.1. Normative References . . . . . . . . . . . . . . . . . . . 21 91 11.2. Informative References . . . . . . . . . . . . . . . . . . 21 92 Appendix A. Interworking between Diversion header and 93 Voicemail URI . . . . . . . . . . . . . . . . . . . . 22 94 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23 96 1. Introduction 98 1.1. Overview 100 For some VoIP-based services (eg. Voicemail, Interactive Voice 101 Recognition (IVR) or automatic call distribution), it is helpful for 102 the called SIP user agent to identify from whom and why the session 103 was diverted. For this information to be used in various service 104 providers or by applications, it needs to pass through the network. 105 This is possible with two different SIP headers: History-Info header 106 defined in [RFC4244] and the historic Diversion header defined in 107 [RFC5806] which are both able to transport diversion information in 108 SIP signaling. 109 Although the Diversion header is not standardized, it is widely used. 110 Therefore, it is useful to have guidelines to make this header 111 interwork with the standard History-Info header. 112 Note that the new implementation and deployment of the Diversion 113 header is strongly discouraged. 115 This document provides a mechanism for header content translation 116 between the Diversion header and the History-Info header. 118 1.2. Background 120 The History-Info header [RFC4244] and its extension for forming SIP 121 service URIs (including Voicemail URI) [RFC4458] are recommended by 122 IETF to convey redirection information. They are also recommended in 123 the "Communication Diversion (CDIV) service" 3GPP specification 124 [TS_24.604]. 126 Originally, the Diversion header was described in an Internet Draft 127 that was submitted to the SIP Working Group. It has been published 128 now as [RFC5806] for the historical record and to provide a reference 129 for this RFC. 131 This header contains a list of diverting URIs and associated 132 information providing specific information as the reason for the call 133 diversion. Most of existing SIP-based implementations have 134 implemented the Diversion header when no standard solution was ready 135 to deploy. The IETF has finally standardized the History-Info header 136 partly because it can transport general history information. This 137 allows the receiving part to determine how and why the session is 138 received. As the History-Info header may contain further information 139 than call diversion information, it is critical to avoid losing 140 information and be able to extract the relevant data using the 141 retargeting cause URI parameter described in [RFC4458] for the 142 transport of the diversion reason. 144 The Diversion header and the History-Info header have different 145 syntaxes described below. Note that the main difference is that the 146 History-Info header is a chronological writing header whereas the 147 Diversion header applies a reverse chronology (i.e. the first 148 diversion entry read corresponds to the last diverting user). 150 The Appendix A provides an interworking guideline between the 151 Diversion header and the Voicemail URI which is another way to convey 152 diversion information. The Voicemail URI is defined in [RFC4458]. 154 2. Problem Statement 156 2.1. Interworking requirements and scope 158 This section provides the baseline terminology used in the rest of 159 the document and defines the scope of interworking between the 160 Diversion header and the History-Info header. 162 They are many ways in which SIP signaling can be used to modify a 163 session destination before it is established and many reasons for 164 doing so. The behavior of the SIP entities that will have to further 165 process the session downstream will sometimes vary depending on the 166 reasons that lead to changing the destination. For example, whether 167 it is for a simple proxy to route the session or for an application 168 server to provide a supplementary service. The Diversion header and 169 the History-Info header differ in the approach and scope of 170 addressing this problem. 172 For clarity, the following vocabulary is used in this document: 174 o Retargeting/redirecting: retargeting/redirecting refer to the 175 process of a Proxy Server/User Agent Client (UAC) changing a 176 Uniform Resource Identifier (URI) in a request and thus changing 177 the target of the request. These terms are defined in [RFC4244]. 178 The History-Info header is used to capture retargeting 179 information. 181 o Call forwarding/call diversion/communication diversion: these 182 terms are equivalent and refer to the Communications Diversion 183 (CDIV) supplementary services, based on the ISDN Communication 184 diversion supplementary services and defined in 3GPP [TS_24.604]. 185 They are applicable to entities which are intended to modify the 186 original destination of an IP multimedia session during or prior 187 to the session establishment. 189 This document does not intend to describe when or how History-Info or 190 Diversion headers should be used. Hereafter is provided 191 clarification on the context in which the interworking is required. 193 The Diversion header has exactly the same scope as the call diversion 194 service and each header entry reflects a call diversion invocation. 195 The Diversion header is used for recording call forwarding 196 information which could be useful to network entities downstream. 197 Today, this SIP header is implemented by several manufacturers and 198 deployed in networks. 200 The History-Info header is used to store all retargeting information 201 including call diversion information. In practice, the History-Info 202 header [RFC4244] is used to convey call diversion related information 203 by using a cause URI parameter [RFC4458] in the relevant entry. 204 Note, however, that the use of cause URI parameter [RFC4458] in a 205 History-Info entry for a call diversion is specific to the 3GPP 206 specification [TS_24.604]. [RFC4458] focuses on retargeting toward 207 voicemail server and does not specify whether the cause URI parameter 208 should be added in a URI for other cases. As a consequence, 209 implementations that do not use the cause URI parameter for call 210 forwarding information, are not considered for the mapping described 211 in this document. Nevertheless, some recommendations are given in 212 the next sections on how to avoid the loss of non-mapped information 213 at the boundary between a network region using History-Info header 214 and one using the Diversion header. 216 Since both headers address call forwarding needs, diverting 217 information could be mixed-up or be inconsistent if both are present 218 in an uncoordinated fashion in the INVITE request. So, Diversion and 219 History-Info headers must not independently coexist in the same 220 session signaling. This document addresses how to convert 221 information between the Diversion header and the History-Info header, 222 and when and how to preserve both headers to cover additional cases. 224 For the transportation of consistent diversion information 225 downstream, it is necessary to make the two headers interwork. 226 Interworking between the Diversion header and the History-Info header 227 is introduced in sections 5 and 6. Since coexistence scenario may 228 vary from one use case to another one, guidelines regarding headers 229 interaction are proposed. 231 2.2. Interworking recommendations 233 Interworking function: 235 In a normal case, the network topology assumption is that the 236 interworking described in this document should be performed by a 237 specific SIP border device which is aware, by configuration, that 238 it is at the border between two regions, one using History-Info 239 header and one using Diversion header. 241 As History-Info header is a standard solution, a network using the 242 Diversion header must be able to provide information to a network 243 using the History-Info header. In this case, to avoid headers 244 coexistence it is required to replace, as often as possible, the 245 Diversion header with the History-Info header in the INVITE request 246 during the interworking. 248 Since, the History-Info header has a wider scope than the Diversion 249 header, it may be used for other needs and services than call 250 diversion. In addition to trace call diversion information, History- 251 Info header also acts as a session history and can store all 252 successive R-URI values. Consequently, even if it should be better 253 to remove the History-Info header after the creation of the Diversion 254 header avoiding confusion, the History-Info header must remain 255 unmodified in the SIP signaling if it contains supplementary (non- 256 diversion) information. It is possible to have History-Info headers 257 that do not have values that can be mapped into the Diversion header. 258 In this case, no interworking with Diversion header should be 259 performed and it must be defined per implementation what to do in 260 this case. This point is left out of the scope of this document. 262 As a conclusion, it is recommended to have local policies minimizing 263 the loss of information and find the best way to keep it up to the 264 terminating user agent. 266 The following sections describe the basic common use case. 267 Additional interworking cases are described in section 7.5. 269 2.2.1. SIP network/terminal using Diversion to SIP network/terminal 270 using History-Info header 272 When the Diversion header is used to create a History-Info header, 273 the Diversion header must be removed in the outgoing INVITE. It is 274 considered that all the information present in the Diversion header 275 is transferred in the History-Info header. 277 If a History-Info header is present in the incoming INVITE (in 278 addition to Diversion header), the Diversion header and History-Info 279 header present must be mixed and only the diversion information not 280 yet present in the History-Info header must be inserted as a last 281 entry (more recent) in the existing History-Info header, as 282 recommended in [RFC4244]. 284 As an example, this could be the case of an INVITE coming from 285 network_2 using Diversion header but previously passed through 286 network_1 using History-Info header (or the network_2 uses History- 287 Info header to transport successive URI information) and going to 288 network_3 using History-Info header. 290 IWF* IWF* 291 network1 | network_2 |network_3 292 History-Info | Diversion |using 293 | |Hist-Info 294 | | 295 UA A P1 AS B | P2 AS C UA C AS D | UA E 296 | | | | | | | | | | 297 |INVITE | | | | | | | | | 298 |------>| | | | | | | | | 299 | | | | | | | | | | 300 | |INVITE | | | | | | | | 301 | |------>| | | | | | | | 302 | |Supported: histinfo | | | | | | 303 | | History-Info: | | | | | | 304 | | ; index=1, | | | | | 305 | | ; index=1.1 | | | | | 306 | | | | | | | | | | 307 | | |INVITE | | | | | | | 308 | | |------>| | | | | | | 309 | | |History-Info: | | | | | | 310 | | |; index=1,| | | | | 311 | | |; index=1.1 | | | | | 312 | | |; cause=302; index=1.1.1 | | | 314 In this case, the incoming INVITE contains a Diversion header and a 315 History-Info header. Therefore, as recommended in this document, it 316 is necessary to create for network_3, a single History-Info header 317 gathering existing information from both the History-Info and the 318 Diversion headers received. Anyway, it is required from network_2 319 (ie.IWF) to remove the Diversion header when the message is going to 320 a network not using the Diversion header. Then network_3 could use 321 call forwarding information that is present in a single header and 322 add its own diversion information if necessary. 324 Notes: 326 1. If a network is not able either to use only one header each time, 327 or to maintain both headers up to date, the chronological order 328 can not be certified. 330 2. It is not possible to have only Diversion header when the 331 History-Info header contains more than call diversion 332 information. If previous policy recommendations are applied, the 333 chronological order is respected as Diversion entries are 334 inserted at the end of the History-Info header taking into 335 account the Diversion internal chronology. 337 2.2.2. SIP network/terminal using History-Info header to SIP network/ 338 terminal using Diversion header 340 When the History-Info header is interpreted to create a Diversion 341 header, some precautions must be taken. 342 If the History-Info header contains only call forwarding information, 343 then it must be deleted after the interworking. 344 If the History-Info header contains other information, then only the 345 information of concern to the diverting user must be used to create 346 entries in the Diversion header and the History-Info header must be 347 kept as received in the INVITE and forwarded downstream. 349 Note: The History-Info header could be used for other reasons than 350 call diversion services, for example by a service which need to know 351 if a specific AS had yet been invoked in the signaling path. If the 352 call is later forwarded to a network using History-Info header, it 353 would be better to not lose history information due to passing though 354 the network which only support Diversion header. A recommended 355 solution must not disrupt the standard behavior and networks which do 356 not implement the History-Info header must be transparent to a 357 received History-Info header. 359 If a Diversion header is present in the incoming INVITE (in addition 360 to History-Info header), only diversion information present in the 361 History-Info header but not in the Diversion header must be inserted 362 from the last entry (more recent) into the existing Diversion header 363 as recommended in the [RFC5806]. 365 Note that the chronological order could not be certified. If 366 previous policy recommendations are respected, this case should not 367 happen. 369 Forking case: 371 The History-Info header enables the recording of sequential 372 forking for the same served-user. During an interworking, from 373 the History-Info header to Diversion header, the History-Info 374 entries containing a forking situation (with an incremented 375 "index" parameter) could possibly be mapped if it contains a call 376 forwarding "cause" parameter. The interworking entity could 377 choose to create only a Diversion entry or not apply the 378 interworking. The choice could be done according a local policy. 380 The same logic is applied for an interworking with Voicemail URI (see 381 the Appendix). 383 3. Headers syntaxes reminder 385 3.1. History-Info header syntax 387 History-Info = "History-Info" HCOLON hi-entry *(COMMA hi-entry) 389 hi-entry = hi-targeted-to-uri *( SEMI hi-param ) 390 hi-targeted-to-uri = name-addr 391 hi-param = hi-index / hi-extension 392 hi-index = "index" EQUAL 1*DIGIT *(DOT 1*DIGIT) 393 hi-extension = generic-param 395 The History-Info header is specified in [RFC4244]. 396 The top-most History-Info entry (first in the list) corresponds to 397 the oldest history information. 399 A hi-entry may contain a cause URI parameter expressing the diversion 400 reason. This optional cause URI parameter is defined in [RFC4458] 401 with the following syntax: 403 cause-param = "cause" EQUAL Status-Code 405 This parameter is also named cause-param and should be inserted in 406 the History-Info entry (URI) of the diverted-to user in case of call 407 diversion as recommended in the 3GPP CDIV specification [TS_24.604]. 408 The cause values used in the cause-param for the diverting reason are 409 listed in the RFC and because it is a parameter dedicated to call 410 forwarding service, its presence is used to determine that a hi-entry 411 is a diverting user. More precisely, each diverting user is located 412 in the hi-entry before the one containing a cause-param with cause 413 value as listed in RFC 4458. 414 Moreover, the Reason header defined in [RFC3326] should be escaped in 415 the hi-entry of the diverting user when the call diversion is due to 416 a received SIP response. The Reason header contains a cause 417 parameter set to the true SIP response code received (Status-Code). 418 Therefore, in case of call diversion due to a SIP response, both 419 cause parameters should be used. The complexity is that these 420 parameters could be used at the same time in the History-Info header 421 but not in the same hi-entry and not with the same meaning. Only the 422 cause-param is dedicated to call diversion service. The 'cause' 423 Reason header parameter is not taken into account in the mapping with 424 a Diversion header. 426 The [RFC4458] also defines the 'target' URI parameter which could be 427 inserted in a R-URI and consequently in the hi-targeted-to-uri. This 428 parameter is used to keep the diverting user address in the 429 downstream INVITE request in Voicemail URI implementation. As this 430 information is already present in the hi-entries, the 'target' URI 431 parameter is not taken into account regarding the interworking with 432 the Diversion header. From the Diversion header, it could be 433 possible to create the 'target' URI parameter in the hi-entries 434 and/or in the R-URI but this possibility is based on local policies 435 not described in this document. 437 A Privacy header as defined in [RFC3323] could also be included in 438 hi-entries with the 'history' value defined in the [RFC4244]. 440 The index parameter is a string of digits, separated by dots to 441 indicate the number of forward hops and retargets. 443 Note: A history entry could contain the "gr" parameter. Regardless 444 the rules concerning "gr" parameter defined in [TS_24.604] which must 445 be applied, this parameter has no impact on the mapping and must only 446 be copied with the served user address. 448 Example: 450 History-Info: 451 ;index=1, 453 ;index=1.1, 454 ; index=1.1.1 456 Policy concerning "histinfo" option tag in Supported header: 457 According to [RFC4244], a proxy that receives a Request with the 458 "histinfo" option tag in the Supported header should return captured 459 History-Info in subsequent, provisional and final responses to the 460 Request. The behavior depends upon whether the local policy supports 461 the capture of History-Info or not. 463 3.2. Diversion header syntax 465 The following text is restating the exact syntax that the production 466 rules in [RFC5806] define, but using [RFC5234] ABNF: 468 Diversion = "Diversion" HCOLON diversion-params 469 *(COMMA diversion-params) 471 diversion-params = name-addr *(SEMI (diversion-reason / 472 diversion-counter / diversion-limit / 473 diversion-privacy / diversion-screen / 474 diversion-extension)) 475 diversion-reason = "reason" EQUAL ("unknown" / "user-busy" / 476 "no-answer" / "unavailable" / "unconditional" 477 / "time-of-day" / "do-not-disturb" / 478 "deflection" / "follow-me" / "out-of-service" 479 / "away" / token / quoted-string) 480 diversion-counter = "counter" EQUAL 1*2DIGIT 481 diversion-limit = "limit" EQUAL 1*2DIGIT 482 diversion-privacy = "privacy" EQUAL ("full" / "name" / "uri" / 483 "off" / token / quoted-string) 484 diversion-screen = "screen" EQUAL ("yes" / "no" / token / 485 quoted-string) 486 diversion-extension = token [EQUAL (token / quoted-string)] 488 Note: The Diversion header could be used in the comma-separated 489 format as described below and in a header-separated format. Both 490 formats could be combined a received INVITE as recommended in 491 [RFC3261]. 493 Example: 495 Diversion: 497 diverting_user2_addr; reason="user-busy"; counter=1; privacy=full, 498 diverting_user1_addr; reason="unconditional"; counter=1; 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. 841 While a network replacement may be occurring there will be a time 842 when both nodes coexist in the network. If the different nodes are 843 being used to support different subscriber types due to different 844 node capabilities then the problem is more important. In this case 845 there is a need to pass both History-Info header and Diversion header 846 within the core network. 848 These headers need to be equivalent to ensure that, whatever the node 849 receiving the message, the correct diversion information is received. 850 This requires that whatever the received header, there is a 851 requirement to be able to compare the headers and to convert the 852 headers. Depending upon the node capability, it may be possible to 853 make assumptions as to how this is handled. 855 o If it is known that the older Diversion header supporting nodes do 856 not pass on any received History-Info header then the interworking 857 becomes easier. If a message is received with only Diversion 858 headers then it has originated from an 'old' node. The equivalent 859 History-Info entries can be created and these can then be passed 860 as well as the Diversion header. 862 o If the node creates a new History-Info header for a call 863 diversion, then an additional Diversion header must be created. 865 o If the next node is an 'old' node then the Diversion header will 866 be used by that node and the History-Info entries will be removed 867 from the message when it is passed on. 869 o If the next node is a new node then the presence of both Diversion 870 header and History-Info header means that interworking has already 871 occurred and the Diversion and History-Info entries must be 872 considered equivalent. 874 o If both nodes pass on both History-Info header and Diversion 875 header but only actively use one, then both types of node need to 876 perform the interworking and must maintain equivalence between the 877 headers. This will eventually result in the use of Diversion 878 header being deprecated when all nodes in the network support 879 History-Info header. 881 8. IANA Considerations 883 This document makes no request of IANA. 885 9. Security Considerations 887 The security considerations in [RFC4244] and [RFC5806] apply. 889 The use of Diversion header or History-Info header require to apply 890 the requested privacy and integrity asked by each diverting user or 891 entity. Without integrity, the requested privacy functions could be 892 downgraded or eliminated, potentially exposing identity information. 893 Without confidentiality, eavesdroppers on the network (or any 894 intermediaries between the user and the privacy service) could see 895 the very personal information that the user has asked the privacy 896 service to obscure. Unauthorised insertion, deletion of modification 897 of those headers can provide misleading information to users and 898 applications. A SIP entity that can provide a redirection reason in 899 a History-Info header or Diversion header should be able to suppress 900 this in accordance with privacy requirements of the user concerned. 902 10. Acknowlegements 904 The editor would like to acknowledge the constructive feedback and 905 support provided by Steve Norreys, Jan Van Geel, Martin Dolly, 906 Francisco Silva, Guiseppe Sciortino, Cinza Amenta, Christer Holmberg, 907 Ian Elz, Jean-Francois Mule, Mary Barnes, Francois Audet, Erick 908 Sasaki, Shida Schubert, Joel M. Halpern, Bob Braden and Robert 909 Sparks. Merci a Lionel Morand, Xavier Marjou and Philippe Fouquart. 911 11. References 913 11.1. Normative References 915 [RFC3261] "SIP: Session Initiation Protocol", RFC 3261, June 2002. 917 [RFC3323] "A Privacy Mechanism for the Session Initiation Protocol 918 (SIP)", RFC 3323, November 2002. 920 [RFC3326] "The Reason Header Field for the Session Initiation 921 Protocol (SIP)", RFC 3326, December 2002. 923 [RFC4244] "An Extension to the Session Initiation Protocol (SIP) for 924 Request History Information", RFC 4244, November 2005. 926 [RFC5806] "Diversion Indication in SIP", March 2010. 928 11.2. Informative References 930 [RFC4458] "Session Initiation Protocol (SIP) URIs for Applications 931 such as Voicemail and Interactive Voice Response (IVR)", 932 RFC 4458, April 2006. 934 [RFC5234] "Augmented BNF for Syntax Specifications: ABNF", RFC 5234, 935 January 2008. 937 [TS_24.604] 938 3rd Generation Partnership Project, "Technical 939 Specification Group Core Network and Terminals ; 940 Communication Diversion (CDIV) using IP Multimedia 941 (IM)Core Network (CN) subsystem ; Protocol specification 942 (Release 8), 3GPP TS 24.604", December 2008. 944 [TS_29.163] 945 3rd Generation Partnership Project, "Technical 946 Specification Group Core Network and Terminals ; 947 Interworking between the IP Multimedia (IM) Core Network 948 (CN) Subsystem and Circuit Switched (CS) networks (Release 949 8)", December 2008. 951 Appendix A. Interworking between Diversion header and Voicemail URI 953 Voicemail URI is a mechanism described in RFC4458 to provide a simple 954 way to transport only one redirecting user address and the reason why 955 the diversion occurred in the R-URI of the INVITE request. This 956 mechanism is mainly used for call diversion to a voicemail. 958 Diversion header to Voicemail URI: 960 Received: 961 Diversion: userA-address;reason=user-busy;counter=1;privacy=full 963 Sent (Voicemail URI created in the R-URI line of the INVITE): 964 sip: voicemail@example.com;target=userA-address;cause=486 SIP/2.0 966 Mapping of the Redirection Reason is the same as for History-Info 967 header with a default value set to 404. 968 If the Diversion header contains more than one Diversion entry, the 969 choice of the redirecting user information inserted in the URI is in 970 charge of the network local policy. For example, the choice 971 criterion of the redirecting information inserted in the URI could be 972 the destination of forwarded INVITE request (if the voicemail serves 973 this user or not). 975 Note: This interworking could be done in addition to the interworking 976 of the Diversion header into the History-Info header. 978 Voicemail URI to Diversion header: 979 In case of real Voicemail, this way of interworking should not 980 happen. However, if for any reason it occurs, it is recommended to 981 do it as following: 983 Received: 984 INVITE sip: voicemail@example.com;\ 985 target=sip:+33145454500%40example.com;user=phone;\ 986 cause=302 SIP/2.0 988 Sent in the forwarded INVITE: 989 Diversion: sip:+ 990 33145454500%40example.com;user=phone;reason=unconditional;counter=1 992 Author's Address 994 Marianne Mohali 995 France Telecom Orange 996 38-40 rue du General Leclerc 997 Issy-Les-Moulineaux Cedex 9 92794 998 France 1000 Phone: +33 1 45 29 45 14 1001 Email: marianne.mohali@orange-ftgroup.com